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

[Mark Andrews <[e-mail]>]

In message <CACU5sDnCB62cbBYW_E26fcmGuKU0+V_-BSeF=[e-mail]>, Mohan Parthasarathy writes:
> On Mon, Oct 3, 2011 at 9:02 PM, Mark Andrews <[e-mail]> wrote:
> >
> > In message <[e-mail]>, Mohan writes=
> :
> >>
> >>
> >> On Oct 3, 2011, at 7:55 PM, Mark Andrews <[e-mail]> wrote:
> >>
> >> >
> >> > In message <CACU5sD=2HSCi4VKT235APU7aS7bqk_Czzf_CmdN9fXpEF61s0A@mail=
> .gma=
> >> il.com>
> >> > , Mohan Parthasarathy writes:
> >> >> On Mon, Oct 3, 2011 at 5:15 PM, Mark Andrews <[e-mail]> wrote:
> >> >>>
> >> >>> In message <CACU5sDmurSriLgrD9Pn_xAarfBxrjY0x9sRdJPrdkvJiJ6FJZQ@mail=
> .gma=
> >> i=
> >> >> l.com>, Mohan Parthasarathy writes:
> >> >>>> On Mon, Oct 3, 2011 at 10:32 AM, Ted Hardie <[e-mail]> wr=
> ote:=
> >>
> >> >>>>> On Mon, Oct 3, 2011 at 10:21 AM, Paul Hoffman <paul.hoffman@vpnc.o=
> rg> =
> >> 3D=
> >>
> >> >> wro=
> >> >>>> te:
> >> >>>>>>
> >> >>>>>> +1. The slight increase in programming difficulty of using POST v=
> s. G=
> >> =
> >> >> ET
> >> >>>>>> buys you a huge amount of flexibility in queries. It's not just a=
> bout=
> >>
> >> >>>>>> 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 operatio=
> n.=
> >> =
> >>
> >> >>   I=
> >> >>>> f it
> >> >>>>> is meant to be only retrieval, then I would personally say that ke=
> epin=
> >> =
> >> >> g it
> >> >>>>> within GET is the best choice.
> >> >>>>>
> >> >>>>> I'm also increasingly of the opinion that this should have the val=
> idat=
> >> =
> >> >> 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 cont=
> exts=
> >> =
> >> >> , 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 tha=
> t
> >> >>>> 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 impa=
> ct
> >> >>>> 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 fo=
> r
> >> >> 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 configuratio=
> n ?

Because people make mistakes.  I've definitely seen this sort of
configuration error. Remember this misconfiguration is indistigishable
from a spoof attack.  Validators are expected to cope with spoof
attacks.  They are not expected to cope with MITM attacks other
than to reject the bogus answers.

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

No, its not ignoring what is said in RFC 4035, CD=1 is a SHOULD
(4.9.2).  In this case I'm recommending that defaulting to CD=0 as
the default is what should be done and falling back to CD=1 in
SERVFAIL is what should be done.  AD should be ignored by a validating
stub resolver.  It's for stubs that trust the resolver, not stubs
that validate.

As for whether this is documented anywhere, apart from the archive
of this list and dns/dnssec lists I doubt it.  I've definitely
mentioned this before.  Mike St John's discussion of CD/DO setting
is similar in nature if I'm remembering it correctly.

Remember when RFC 4035 was written there was very little experience
with validating stub resolvers.  There still isn't much but defaulting
to CD=1 is clearly wrong.  Making stub validating resolvers work
well may still require more work or what we have may be "good
enough".

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

Except you can't do that most of the time because there could be a
zone cut that makes that name insecure.

Mark

> -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]   =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is=
> c.org
> >
-- 
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