On 24 Apr 2014, at 10:53, Phillip Hallam-Baker <hal...@gmail.com> wrote:
> If you want to use TLS with DNS then use port 443. One of the effects > of firewalls is that we now only have three ports for all protocols: > > Port 80/UDP: Non SSL traffic > Port 443/TCP: SSL traffic > Port 53/UDP: DNS I think it's important to frame the problem space. I suspect that the firewall challenges you cite most often apply to communications between stub resolvers and recursive resolvers, for hosts that are using an off-net resolver (directly, or via a proxy). I also suspect that any ISP who has ever decided to install firewalls or other packet-mangling middleware in front of their resolver service (and is still in business) has by now collected many reasons not to do that, and that the network path between ISP resolver and authority servers is very likely to be clean. For ISP, read campus, enterprise, etc as appropriate. I have no science to back up my suspicions, here. Given that others apparently have different suspicions, equally plausible, perhaps science is needed. However, I'll note that the conversations surrounding the problem statement in London all seemed to support separating these two uses of the protocol. I don't think it's worth butchering the protocol if it turns out that we have an easy and clean solution that works for a significant part of the problem space (resolvers talking to authority servers), which is what t-dns/draft-hzhwm-start-tls-for-dns looks like to me. This compartmentalisation of the problem space reminds me of RFC 4409, and makes me wonder whether there's a way to replace stub-resolver communications with something new without breaking everything. After all, in a very real sense we really only have two edge platforms to worry about (Android and iOS). Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
