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

[Nicholas Weaver <[e-mail]>]

On Oct 1, 2011, at 6:04 PM, Brian Dickson wrote:

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

There is actually two cases that this seems to want to address:

a)  The amazingly borken middlebox at a consumer/hotspot.  In this case, DNS over TCP is likely to work (they don't get it), and DNS over TCP on a high port is really likely to work.  

The network is probably not trying to restrict DNS AFTER login anyway.


b)  A corporate network with a vicious firewall.  In this case, well, its less clear that THIS proposal would work if the network administrator doesn't want it to work.  These networks sometimes do proxy HTTPS as well as HTTP, by having an additional certificate installed in the client.

EG, I've seen Netalyzr runs from corporate networks that block EVERYTHING out (and I mean EVERYTHING), routing ALL traffic through HTTP/HTTPS proxies and blocking everything else.


So for a:  (which is mostly ignorant network), having a few global recursive resolvers with high ports is probably sufficient.

For b:  (which is the deliberate corporate network), I don't think this proposal is guarenteed to work.

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