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

[Mark Andrews <[e-mail]>]

In message <CACU5sD=[e-mail]>
, Mohan Parthasarathy writes:
> On Mon, Oct 3, 2011 at 5:15 PM, Mark Andrews <[e-mail]> wrote:
> >
> > In message <[e-mail]=
> 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]> =
> wro=3D
> >> 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...=3DA0 The only unfortunate thin=
> g abo=3D
> >> ut
> >> > POST, in my view, is that the flexibility can trend you away from
> >> > interoperability as people add and change things at=3DA0 different=3DA=
> 0 speed=3D
> >> s at
> >> > different hosts.=3DA0 If you want standard behavior the descending lis=
> t goe=3D
> >> s:
> >> > New Method, GET, POST, at least in my view.
> >> >
> >> > Since new methods are notoriously hard to get deployed, POST seems lik=
> e t=3D
> >> he
> >> > best choice if you want something that can handle any DNS operation.=
> =3DA0 I=3D
> >> 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.=3DA0 Allowing a web site to update the local DNS=
>  cach=3D
> >> e for
> >> > a client system by including a reference and a DNS result for the refe=
> ren=3D
> >> ce
> >> > causes my paranoia to ratchet up a few notches.=3DA0 The only other de=
> fense
> >> > against it I see is using Web results only in same-origin web contexts=
> , a=3D
> >> 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 =3D3D1 which also implies that you wan=
> 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=3D1 implies DNSSEC. =A0Stubs/forwarders SHOULD NOT set CD=3D1. =A0The
> > upstream validator needs to filter out the spoofed responses
> > on behalf of the stub/forwarder.
> >
> > Also it is just a "DNS message". =A0UDP/TCP/HTTP/HTTPS is just the
> > transport for the DNS message.
> >
> 
> If a validating stub resolver can set CD =3D 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
resolver does not have access to multiple authoritative sources,
only the recursive server does.  If you are willing to bet that
every response you get back is good then always set CD=1 otherwise
CD=1 should only be set if the CD=0 lookup fails.

> -mohan
> 
> >> -mohan
> >>
> >> > Ted
> >> >
> >> > _______________________________________________
> >> > dnsext mailing list
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/dnsext
> >> >
> >> >
> >> _______________________________________________
> >> dnsext mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dnsext
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: [phone] =A0 =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