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

[Mohan Parthasarathy <[e-mail]>]

On Mon, Oct 3, 2011 at 5:15 PM, Mark Andrews <[e-mail]> wrote:
>
> In message <[e-mail]>om>, 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=
>> te:
>> >>
>> >> +1. The slight increase in programming difficulty of using POST vs. GET
>> >> buys you a huge amount of flexibility in queries. It's not just about
>> >> cache-prevention.
>> >>
>> >
>> > All silver linings have their clouds...=A0 The only unfortunate thing abo=
>> ut
>> > POST, in my view, is that the flexibility can trend you away from
>> > interoperability as people add and change things at=A0 different=A0 speed=
>> s at
>> > different hosts.=A0 If you want standard behavior the descending list goe=
>> s:
>> > New Method, GET, POST, at least in my view.
>> >
>> > Since new methods are notoriously hard to get deployed, POST seems like t=
>> he
>> > best choice if you want something that can handle any DNS operation.=A0 I=
>> f it
>> > is meant to be only retrieval, then I would personally say that keeping it
>> > within GET is the best choice.
>> >
>> > I'm also increasingly of the opinion that this should have the validation
>> > bits sets by default.=A0 Allowing a web site to update the local DNS cach=
>> e for
>> > a client system by including a reference and a DNS result for the referen=
>> ce
>> > causes my paranoia to ratchet up a few notches.=A0 The only other defense
>> > 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 =3D1 which also implies that you want
>> 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.  The
> 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 ?

-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]                 INTERNET: [e-mail]
>
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext