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

[Nicholas Weaver <[e-mail]>]

On Sep 30, 2011, at 9:58 PM, Paul Vixie wrote:
> I like the binary format first proposed here by Edmonds.  I'm not as sure 
> about Jakob's "use the accept headers to determine the format" idea since the 
> only reason I wanted a printable format was so I could debug with "telnet".  
> All clients, even those written in javascript, already know how to handle 
> "plain old DNS wire format".  I truly do only expect this transport to be used 
> when the normal UDP/53 and TCP/53 paths are middlebox-corrupted.
> 
> Assuming that Mohan agrees with me on "just use wire format" in the response, 
> my observation is, we should not be using GET at all, nor should we be 
> encoding the query into the URI.  We should use POST and our request body 
> should be in DNS wire format.  This would defeat web caches but I think that's 
> fine since I worry about web caches that don't understand DNS TTL and I worry 
> even more about web caches that are intercepting rather than explicit.  POST 
> is presumed by web caches to be unique data to which a unique response will be 
> needed.
> 
> A side benefit of this is, the UPDATE opcode gets easy.
> 
> Feel free to respond 1x1, I would summarize.

Use GET, but if you want it to get through the most busted of web caches, do the following:

In the fetch, include cache-busters in the URL:  rather than things that translate to get http://dns_server/name/rtype use things like get http;//dns_server/name/rtype/NONCE


Web caches don't work.  In our experience, nearly 50% of those in Netalyzr tests cache things they shouldn't, so if the worry is cache-staleness, include a cache-buster. But you don't need to use POST to get through the bustedness if the URLs can have nonces in them.



And I'd have the return value be JSON rather than raw DNS on the wire.  Why?

Because since the point is validating DNSSEC, the HTTP-server should not just return the record asked for, but the whole signature chain that it has.  Since this is more information than a normal DNS reply, it might benefit from a new encoding.

And if you are going to do a new encording, JSON is the way to go:  it is FAR far easier to parse than any specialized format.


The other alternative is to say its "OK to put the whole signature chain in the additional field", in which case this would be DNS wire format, but that might be a good policy for ALL resolvers to support: why shouldn't a DNSSEC aware resolver provide the whole signature chain that it has in a reply?

_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext