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

[Mohan Parthasarathy <[e-mail]>]

On Mon, Oct 3, 2011 at 9:02 PM, Mark Andrews <[e-mail]> wrote:
>
> In message <[e-mail]>om>, Mohan writes:
>>
>>
>> On Oct 3, 2011, at 7:55 PM, Mark Andrews <[e-mail]> wrote:
>>
>> >
>> > In message <CACU5sD=[e-mail]=
>> il.com>
>> > , Mohan Parthasarathy writes:
>> >> On Mon, Oct 3, 2011 at 5:15 PM, Mark Andrews <[e-mail]> wrote:
>> >>>
>> >>> In message <[e-mail]=
>> i=
>> >> l.com>, Mohan Parthasarathy writes:
>> >>>> On Mon, Oct 3, 2011 at 10:32 AM, Ted Hardie <[e-mail]> wrote:=
>>
>> >>>>> On Mon, Oct 3, 2011 at 10:21 AM, Paul Hoffman <[e-mail]> =
>> 3D=
>>
>> >> wro=
>> >>>> te:
>> >>>>>>
>> >>>>>> +1. The slight increase in programming difficulty of using POST vs. G=
>> =
>> >> ET
>> >>>>>> buys you a huge amount of flexibility in queries. It's not just about=
>>
>> >>>>>> cache-prevention.
>> >>>>>>
>> >>>>>
>> >>>>> All silver linings have their clouds...  The only unfortunate th=
>> in=
>> >> g abo=
>> >>>> ut
>> >>>>> POST, in my view, is that the flexibility can trend you away from
>> >>>>> interoperability as people add and change things at  different=
>> =
>> 3DA=
>> >> 0 speed=
>> >>>> s at
>> >>>>> different hosts.  If you want standard behavior the descending l=
>> is=
>> >> t goe=
>> >>>> s:
>> >>>>> New Method, GET, POST, at least in my view.
>> >>>>>
>> >>>>> Since new methods are notoriously hard to get deployed, POST seems lik=
>> =
>> >> e t=
>> >>>> he
>> >>>>> best choice if you want something that can handle any DNS operation.=
>> =
>>
>> >>   I=
>> >>>> f it
>> >>>>> is meant to be only retrieval, then I would personally say that keepin=
>> =
>> >> g it
>> >>>>> within GET is the best choice.
>> >>>>>
>> >>>>> I'm also increasingly of the opinion that this should have the validat=
>> =
>> >> ion
>> >>>>> bits sets by default.  Allowing a web site to update the local D=
>> NS=
>> >> cach=
>> >>>> e for
>> >>>>> a client system by including a reference and a DNS result for the refe=
>> =
>> >> ren=
>> >>>> ce
>> >>>>> causes my paranoia to ratchet up a few notches.  The only other d
>> =
>> e=
>> >> fense
>> >>>>> against it I see is using Web results only in same-origin web contexts=
>> =
>> >> , a=
>> >>>> nd
>> >>>>> that's going to be very hard to make work.
>> >>>>>
>> >>>>
>> >>>> I am not sure I understand this concern fully. I guess you mean that
>> >>>> you want to use this only with CD =1 which also implies that you w
>> =
>> an=
>> >> t
>> >>>> to use only with DNSSEC . Though this is the primary use case that
>> >>>> this draft is trying to address, should we restrict it ? Previously,
>> >>>> your concern was cache poisoning of the HTTP proxies having an impact
>> >>>> on DNS. If we require HTTPS and POST, is this still a concern ?
>> >>>
>> >>> DO=1 implies DNSSEC.  Stubs/forwarders SHOULD NOT set CD=1. =
>> 3D=
>> A0The
>> >>> upstream validator needs to filter out the spoofed responses
>> >>> on behalf of the stub/forwarder.
>> >>>
>> >>> Also it is just a "DNS message". UDP/TCP/HTTP/HTTPS is just the
>> >>> transport for the DNS message.
>> >>>
>> >>
>> >> If a validating stub resolver can set CD = 1 for UDP/TCP why not for
>> >> HTTP or HTTPS ?
>> >
>> > A validating stub resolver really doesn't want to set CD=1, by
>> > default.  If it gets SERVFAIL back to a CD=0 query then resending
>> > with CD=1, may help if the SERVFAIL was a validation failure caused
>> > by a bad clock on the recursive server / out of date trust anchors.
>> > A stub resolver *needs* the upstream server to weed out the bogus
>> > responses due to spoofing or, more likely, operational stuff ups
>> > and only pass through those that pass validation.  Remember a stub
>>
>> Why does a validating stub resolver care?
>
> Say example.com is served by a DNSSEC aware authoritative server
> (D) and a DNSSEC unaware authoritative server (P).  The stub resolver

Isn't this a broken configuration ? Why do we end up with this configuration ?

> asks for www.example.com/DO=1/CD=1.  The validating recurive server
> get a answer from P (without DNSSEC records) and passes it on.
> Validation fails.  The stub resolver asks for www.example.com/DO=1/CD=1
> again and it gets the same answer (from thout DNSSEC records) the
> CD=1 cache and again fails.  Rince, lather, repeat.
>
> Now if the stub asks for www.example.com/DO=1/CD=0 the validating
> resolver will reject any answers from P and only pass on answers
> from D (with DNSSEC record) which should then validate.
>
So, this is a validating resolver, sets CD=0 (ignoring what is said in
RFC 4035), gets the "proper" responses, ignores the AD bit,
validates the responses. Is this discussed in any document ?

> Now if the recursive server doesn't validate or it validates as
> insecure you are left with first senario hoping that you are getting
> answers from the DNSSEC aware authoritative server.
>
> What would help would be a EDNS option to send to the recursive
> server the closest trust anchor(s) and current time so that it can
> validate responses in a consistant manner to the stub resolver.
>

This seems complex to me. Perhaps, the operational document should say
that a dnssec signed zone should be served only by dnssec aware
authoritative servers. If there is still an operational error, the
validating resolver should just give up. For example, if i set
DO=1/CD=1 and there are no RRSIGS, then abort and declare insecure.

-mohan

> Mark
>
>> If there was spoofing or other problems, it can find out itself.
>> It is much easier to set CD=1 always.
>>
>> -mohan
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]                 INTERNET: [e-mail]
>
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext