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

[Mohan <[e-mail]>]

On Oct 3, 2011, at 7:55 PM, Mark Andrews <[e-mail]> wrote:

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

Why does a validating stub resolver care ? If there was spoofing or other problems, it can find out itself. It is much easier to set CD=1 always. 

-mohan

> 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