Subject: [dnsext] draft-mohan-dns-query-xml-00.txt

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 28 Sep 2011 11:24:58 -0700

Hi,

DNSSEC validation is stub resolver is dependent on DNSSEC-aware CPEs,
recursive servers etc. Here is a draft that we submitted yesterday to
address this problem.

http://www.ietf.org/id/draft-mohan-dns-query-xml-00.txt

Please send your comments/feedback to the list.

thanks
-mohan
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Paul Wouters <[email-masked]>
Date: Wed, 28 Sep 2011 15:32:45 -0400 (EDT)

> Please send your comments/feedback to the list.

Have you done any research on running DNS over port 80/443? That seems
to work quite often (after hotspot auth that breaks all dns)

I'm wondering about the difference in working with running dns over http
on port 80/443 and running plain dns over port 80/443

Also, if this is considered a good idea (of which I am not yet convinced),
why not add a mode similar to the "dnssec chains" proposal to speed things up
for the resolver, as we're already on TCP so response size shouldn't matter
as much as latency does.

You can test running dns over port 80/443 using ounbound and forwarding it
to open.nlnetlabs.nl

Paul

---

From: Ted Hardie <[email-masked]>
Date: Wed, 28 Sep 2011 14:06:38 -0700

Howdy,

I have a few questions on this proposal.

Why not re-use the syntax of RFC4501 for the query?  That is:
https://relayingwebserver.example.com/query.cgi?dns:[//authority/]domain[?CLASS=class;TYPE=type]
?

Declaring a namespace for the xml is generally good practice.  It's also not
clear why you need an XML-based representation, rather than using a
mime-type like that set out in RFC 4027 (which uses detached domain name
information as set out in RFC 2540).  Even if those need updating, it's not
clear to me what you're gaining with the use of XML here.

It seems like you're wanting this to be used when CD bit is set to 1; any
reason why you'd want to support this for CD bit set to 0?
In general, I think a little bit more wording on when this tunneling would
be used would be really useful to flesh out when this is needed.

NIT: You cite RFC 2396, but the current reference is RFC 3986

regards,

Ted Hardie

---

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 28 Sep 2011 14:07:04 -0700

> on port 80/443 and running plain dns over port 80/443

If I want to be able to run both my web service and DNS service from
the same address, then I can't just run DNS alone over 80/443.

> for the resolver, as we're already on TCP so response size shouldn't matter

I am not sure I understand. It is not about speed. It is about the
stub validator being able to get the DNSSEC records when sitting
behind CPEs and recursive servers (and other middle boxes) that are
not DNSSEC aware.

-mohan

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 28 Sep 2011 14:16:09 -0700

> the same address, then I can't just run DNS alone over 80/443.

Have you looked at just running normal DNS recursively from the end host, including failover to TCP when things are obviously breaking?

We don't have ALL the information yet (our test is not comprehensive enough), but most systems CAN do direct fetches on UDP or TCP if they must: non-functioning recursive resolvers should not be a problem for DNSSEC validation.

In fact, for the purposes of A records, etc, just the recursive request from the end host is enough to be "close enough" to the security effect you would get from full DNSSEC validation.  (DANE or the like, where DNSSEC is used to validate key material not host->IP mappings, requires end-host validation)

---

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 28 Sep 2011 14:49:43 -0700

> https://relayingwebserver.example.com/query.cgi?dns:[//authority/]domain[?CLASS=class;TYPE=type]
We should definitely study that for the next revision. We need to be
able to specify more than what is given in RFC 4501. Is that
extensible ?

> clear to me what you're gaining with the use of XML here.

We chose XML because it is readily available and also better inter-operability.

> be used would be really useful to flesh out when this is needed.
Yes, the main use case is DNSSEC. Does it make sense to restrict to just that ?

> NIT: You cite RFC 2396, but the current reference is RFC 3986
Will fix that.

thanks
mohan

---

From: Wilmer van der Gaast <[email-masked]>
Date: Wed, 28 Sep 2011 15:10:42 -0700

> Please send your comments/feedback to the list.
Two things off the top of my head after quickly reading this:

A) Is it necessary to hardcode the /dns_service path? IMHO it would be
nice to allow the use of base URLs instead, in case for some reason
/dns_service can't be used on a host. Also, this lets the user choose
if s/he wants to talk to a DNS service with/without DNSSEC validation
for example (or opt out from things like ISP DNS "monetisation" in a
nicer way).

B) Nit, but why not convert the booleans in responses from
<xx>value</xx> into <xx/> if it's 1 and <xx/> being absent if it's 0?

Cheers,

-- 
Wilmer van der Gaast, Traffic SRE/Google Public DNS team.
Google Ireland.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 28 Sep 2011 16:26:02 -0700

(I sent Mohan and Paul comments offline yesterday. The following are the most significant.)

XML carries a lot of baggage with it. Instead of an XML format, JSON would be a lot easier. "response" is a dictionary; ID, aa, rcode, anscount are integers, answers is a list of integers. In the RR format, name, type, class, and rdlength are integers and ttl is an integer. rdata is a string of Base64 of the data with no escaping. 

Also, "anscount" and "rdlength" should not be there either for XML or JSON: they introduce a silly state.
 
--Paul Hoffman

---

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 28 Sep 2011 16:48:25 -0700

> We don't have ALL the information yet (our test is not comprehensive enough), but most systems CAN do direct fetches on UDP or TCP if they must: non-functioning recursive resolvers should not be a…

I am not sure I understand the question. If you are dependent on a
recursive server to fetch the DNSSEC records, then that server needs
to be DNSSEC aware. If you are operating in iterative mode fetching it
yourself, then it does not work in environments where firewalls
normally prohibit talking to external name servers. Which one are you
talking about ? We had a lengthy discussion about the various options
in the dnssec-deployment group recently.

> In fact, for the purposes of A records, etc, just the recursive request from the end host is enough to be "close enough" to the security effect you would get from full DNSSEC validation.  (DANE or…

Why do you assume that the draft is not applicable for DANE use case ?

-mohan

---

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 28 Sep 2011 16:57:38 -0700

> for example (or opt out from things like ISP DNS "monetisation" in a

If we can avoid hardcoding that would be nice. I am not sure I
understand your proposal. Could you clarify ? The initial thought is
that it would be nice to access it in a standard way but I do see the
issues you noted above.

> <xx>value</xx> into <xx/> if it's 1 and <xx/> being absent if it's 0?

Is this a standard approach ? Or it saves bytes ?

thanks,
mohan

---

From: Wilmer van der Gaast <[email-masked]>
Date: Wed, 28 Sep 2011 17:31:28 -0700

> that it would be nice to access it in a standard way but I do see the
Basically what I'm suggesting is that instead of an IP address, the
user fills in a base URL. In your example on page 10 the base URL
would be "https://server_address/dns_service/". The client
implementation just glues query?name=.... to that base URL to get the
exact URL to query.

This lets me put the dns service under a different path, like for
example just /dns ... or I could have a /dns and a /dns-secure for
people who already want strict DNSSEC validation even though it may
make some names unresolvable.

> Is this a standard approach ? Or it saves bytes ?
It saves bytes, IMHO it looks clearer and also it's (again IMHO)
easier to parse; you just check if the element is present or not,
instead of finding it and evaluating it (what to do if the text value
is not 0 or 1?).

Cheers,

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 28 Sep 2011 17:40:11 -0700

> in the dnssec-deployment group recently.

Don't be dependent on the recursive server.  Just fetch it thyself iteratively, starting with the root, and be done with it.  

There are cases where this fails, but the cases are far rarer than you think, especially when using TCP as well as UDP, and FAR FAR less common than the broken proxies clients are configured to use as recursive resolvers.

> Why do you assume that the draft is not applicable for DANE use case ?

Actually, its that the draft is ONLY applicable for the DANE use case or other cases where DNSSEC is used to distribute cryptographic material...

Given you are doing a direct fetch, starting with the root and bypassing the recursive resolver.  In this case, validating DNSSEC for A-records and the like does not matter at all, because almost all adversaries who are in a position to modify the DNS reply you receive can also instead modify the protocol which USES the A record.

And the final protocol either resists a MITM (in which case, DNSSEC validation of A records doesn't matter because modifying the DNS reply doesn't help the adversary) or is vulnerable to a MITM (in which case, DNSSEC validation of A records doesn't matter because the adversary could just MITM the final application protocol).

In fact, this is my proposed policy for client validation FAILURE using existing, non-DNSSEC aware APIs:  IF DNSSEC validation fails, bypass the recursive resolver, do a direct iterative fetch, and accept whatever you get without question, since most DNSSEC validation failures will be errors, not attacks.

I also agree with the observation from Paul Hoffman that XML is way too heavyweight and that JSON is the way to go for serializing arbitrary blobs of data over HTTP.

---

From: Aki Tuomi <[email-masked]>
Date: Thu, 29 Sep 2011 07:18:34 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Nicholas Weaver
> Sent: Thursday, September 29, 2011 3:40 AM
> To: Mohan Parthasarathy
> Cc: Paul Vixie; [email-masked]
> Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt
> 
> 
> >> Have you looked at just running normal DNS recursively from the end
> host, including failover to TCP when things are obviously breaking?
> >>
> >> We don't have ALL the information yet (our test is not comprehensive
> enough), but most systems CAN do direct fetches on UDP or TCP if they
> must: non-functioning recursive resolvers should not be a problem for
> DNSSEC validation.
> >>
> >
> Don't be dependent on the recursive server.  Just fetch it thyself
> iteratively, starting with the root, and be done with it.
> 

Many corporate firewalls do not permit you to go fetch stuff yourself, but insist you use the local resolvers. Of course, corporate environments probably do not apply here in any case. But I thought I'd just mention this. 

Aki Tuomi

---

From: Tony Finch <[email-masked]>
Date: Thu, 29 Sep 2011 12:04:13 +0100

Ted Hardie <[email-masked]> wrote:
>
> Why not re-use the syntax of RFC4501 for the query? [...] It's also not
> information as set out in RFC 2540).  Even if those need updating, it's
> not clear to me what you're gaining with the use of XML here.

I agree with these suggestions and questions.

I don't understand the interoperability argument. The software that will
be producing and consuming this data is DNS software that already has
parsers for binary DNS data, and doesn't have serializers or parsers for
XML. Binary data is also much more friendly for mobile endpoints.
Interoperability with non-DNS software should be handled by a separate
gateway that doesn't put a disgustingly wasteful pessimization in the fast
path.

Is this draft going to specify how to get the complete DNSSEC validation
chain, or is that going to be specified elsewhere? Google Chrome already
implements a format for embedding validation chains in X.509 certificates
which is binary but sadly does not use standard DNS message format.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking: Southerly 4 or 5, occasionally 6 in northeast. Moderate. Mainly fair.
Good, occasionally poor.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 29 Sep 2011 13:47:04 +0200

> You can test running dns over port 80/443 using ounbound and forwarding it

Correction:
We do not run that resolver on open.nlnetlabs.nl but on restrigd.nlnetlabs.nl.
(All part of early deployment tests of a project that brings DNSSEC to 127.0.0.1 http://www.nlnetlabs.nl/projects/dnssec-trigger/ ) 

I can see some value in using a method to make sure you multiplex on port 443 some folk may also want to run other services on the same machine. 

--Olaf

________________________________________________________ 

Olaf M. Kolkman                        NLnet Labs
http://www.nlnetlabs.nl/

---

From: Ted Hardie <[email-masked]>
Date: Thu, 29 Sep 2011 09:31:30 -0700

> able to specify more than what is given in RFC 4501. Is that
What kind of extension do you need, the validation bit?

It likely is extensible if there is need, provided the existing strings
remain valid.  At worst, you'd need to mint a new URI.  If you go down that
road, though, I would suggest simply minting a URI for dns.https, where the
authority is the webserver you are querying and the path is the
domain[?CLASS=class;Type=Type;CD=1].  That makes https a "transport" for
DNS, rather than seeing this as a relayed service.  To me, it also suggests
you continue to use the DNS binary representations, since the results will
get fed to a local DNS subsystem.  With either XML or JSON, you're going
through a double translation (once on the relaying server and once in the
local subsystem pushing it to the DNS), and that seems more likely to
introduce error than to get you much benefit.

> not
As others have noted, XML parsers are common--but the interpretation of the
XML in any particular namespace has to develop interoperability on its own.

> Yes, the main use case is DNSSEC. Does it make sense to restrict to just
The advantage is really that you can tailor the return data parsers to throw
out anything that doesn't include the required DNSSEC bits.  As it is,
you're going to move from one set of issues (poor caching resolvers) to
another:  HTTP interception proxies.  Those are often not known to the end
host and their behavior is, at best, "interesting".  Mandating the use of
HTTPS will help some, but there is going to be an increased risk of HTTP
cache poisoning having an impact on the DNS if you use this--without DNSSEC,
that attack vector seems to me personally pretty bad.

regards,

Ted

> > On Wed, Sep 28, 2011 at 11:24 AM, Mohan Parthasarathy <
> [email-masked]>
> > wrote:
> >>
> >> Hi,
> >>

---

From: Mohan Parthasarathy <[email-masked]>
Date: Thu, 29 Sep 2011 12:57:05 -0700

> gateway that doesn't put a disgustingly wasteful pessimization in the fast

We started with XML and then came JSON and we have the third format
for consideration :-) We should just use the right one at the end. DNS software
is going to use a different API to retrieve the HTTP response which hopefully
will work fine when it sees a new MIME type. How about if I am using wireshark ?
Would XML/JSON make a difference until someone writes a plugin ? How about
the server side plugin that wants to encode the response ? Would one be easier
over the other. Perhaps, there are other factors.

> which is binary but sadly does not use standard DNS message format.
Very good point. As written, it just encodes a single response. But it
should be easy
to extend this ask for a "chain" and the server plugin can build a
chain (to a known
trust anchor that has to be communicated ? ) and return it. We reduce
a lot of latency.
Is that what you meant ?

-mohan

---

From: Robert Edmonds <[email-masked]>
Date: Thu, 29 Sep 2011 20:55:26 +0000 (UTC)

> gateway that doesn't put a disgustingly wasteful pessimization in the fast

hi,

i believe this is the first time i've ever posted to an IETF mailing
list, but as someone who writes DNS software and, less frequently, HTTP
software, i'd like to voice support for this point of view.

i don't believe that re-formatting DNS query messages is necessary for
transporting DNS over HTTP(S), and in fact any re-formatting is
effectively a "fork" of the DNS protocol.

i'd much rather see the thinnest possible mapping of DNS onto HTTP.  for
instance, an average DNS query packet length is around 49 octets.
simply hex-encoding the entire query message would not result in an
abnormally long URL, e.g.:

https://server/dns/00000010000100000000000100000200010000291000000080000000

here i've set the ID field to 0.  i suspect that in the majority of uses
the ID field could always be set to a fixed value, and this would aid
HTTP caching.  (speaking of which, you would also want to send a
"Cache-Control: max-age" header in the HTTP response with the max-age
set to the minimum of all RRset TTL values in the DNS response.)

the actual HTTP response payload would simply be a binary wire-format
DNS response message, possibly with a leading two byte length field like
plain TCP DNS.

-- 
Robert Edmonds
[email-masked]

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 29 Sep 2011 14:17:31 -0700

On Sep 29, 2011, at 1:55 PM, Robert Edmonds wrote:

> (speaking of which, you would also want to send a

I'd prefer to not attempt mixing HTTP caching and DNS caching in
the first version of this new beast.  I'd rather see 'no-cache'
from the server until it has been deployed for a few years and
we can make informed statements about how the two will interact.

For example, probably every HTTP caching proxy written gives
admins the ability to ignore or change cache-control directives.
HTTP caching is much more complex than DNS caching.

Duane W.

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 29 Sep 2011 23:21:34 +0200

> recursive servers etc. Here is a draft that we submitted yesterday to

First, let me say I think this an interesting proposal and I'm looking following this work.

I would prefer a RESTful API where the response data format is dependent on the HTTP accept headers. Using such an API, one could receive various formats, e.g., XML, JSON or plain old DNS wire format. A DNS client in Javascript would probably like JSON, a libresolv-like DNS library would like wire format and someone else (although I fail to see who) might prefer XML.

Regarding the XML format (if one is used), I agree with Ted Hardie on the namespace issue, and like to add a request for some XML schema definition (xsd, relax ng, relax ng compact, ...).

Also, I second the request for a DNSSEC chain mode.

	jakob

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 30 Sep 2011 09:36:11 +0300

> I would prefer a RESTful API where the response data format is dependent on the HTTP accept headers. Using such an API, one could receive various formats, e.g., XML, JSON or plain old DNS wire form…

+10000000

My claim/feelings/religious view is that JSON is so much better than XML when coming to the kind of usage we talk about.

So if _one_ format is to be used, please choose JSON and not XML.

   Patrik