On Tue, 20 Jan 2015, Paul Vixie wrote:
my input is not a direct answer to either question, but, may be relevant.
my view is: we can't reliably signal this capability, so any option we
pursue will create a DoS vector for either new or old initiators or
responders, and the right answer is to pursue DNS-over-HTTP as an
alternate transport that already has TCP persistence built into it. i
also note that we've got a JSON layout for DNS messages now, thanks to
bortzmeyer and hoffman; and we've got a reasonably portable and high
quality DNS shim layer now, thanks to the getdns team. so: adding
DNS-over-HTTP would happen faster than revising TCP/53.
It would be really sad to relegate all ports but 80/443 to the realm of CHAOS.
And inevitably, the transparancy of port 80/443 would suffer as it
becomes the default demuxing point. But I know you know this, and still
you think it is the best way, so therefor sad.
tcp/53 is already out there and working on the recursors. Adding client
side support that proactively uses this should, for example in unbound
and bind, should be easier than implementing dns-in-xml-over-port-80-in-new-api
(just like I'm not a fan of dns-over-dbus-into-your-vm-and-back approach
of systemd-resolved)
I also think that draft-ietf-edns-querychain is a much simpler api than
the new getdns api, but I'm biased. And speaking of that draft, I will
process the reviews received on it and push out a an updated version.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
