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

[Mark Andrews <[e-mail]>]

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

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.

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