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

[Nicholas Weaver <[e-mail]>]

On Sep 28, 2011, at 4:48 PM, Mohan Parthasarathy wrote:

> On Wed, Sep 28, 2011 at 2:16 PM, Nicholas Weaver
> <[e-mail]> wrote:
>> 
>> On Sep 28, 2011, at 2:07 PM, Mohan Parthasarathy wrote:
>>> 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.
>> 
>> 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.
>> 
> 
> 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.

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.


>> 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)
>> 
>> 
> 
> 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.

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