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

[Brian Dickson <[e-mail]>]

On Sat, Oct 1, 2011 at 5:26 PM, David Conrad <[e-mail]> wrote:
> On Oct 1, 2011, at 11:08 AM, Nicholas Weaver wrote:
>> Since thats likely to the the same sort of network where you can't bypass the DNS borkenness by TCP or UDP port 53, this could be a problem.
>
> This succinctly captures my ill-ease about this proposal.
>
> Pretending (in effect) HTTP{,S} is IPv7 will work until the network administrators/middlebox vendors decide they want to block/intercept that traffic. Then what?  How many levels of turtles are we willing to go down?

Including this, depending on how you count, one, or two if you treat
http and https in this proposal as two turtles instead of one.

Here's why:

Intercept precludes https (since the "s" means end-to-end TLS).
And blocking https requires some way of determining what to block, on
a destination basis alone, for the same reason. The http component is
opaque in an https connection, protected by the TLS connection.

So, in the case of the middlebox vendors or network administrators not
reacting to the use of DNS over HTTP(S), problem solved. Otherwise, it
then becomes baby+bathwater for those trying to block this, based only
on IP addresses. Name-based HTTP servers that support this (on 80 or
443) on shared infrastructure (web hosting etc.), plus popularity of
use (large numbers of sites and/or well known large sites), including
phone-home use with client-authentication by HTTPS servers, means
there will be significant benefit to this, and significant pressure to
not try to break it (at least in the HTTPS case).

Where practical to do so, eg for business enterprise employees away
from the office, having server running on both 80 and 443 is ideal. If
80 works, there is low cost for doing this. If 80 does not (ie blocked
or mangled), 443 should. Blocking 443 on a given IP is particularly
ill-advised for hot-spot operators and hotels.

As for encoding, I definitely support wire-format over XML.

Brian
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext