There’s three easy ways to get a smile out of an IETF attendee.
1. Propose ‘putting it in the DNS’
At some time, almost every other protocol out there on the net looks for a way to distribute information, and the DNS stands up, sighs and says “yeah, I could do that but…”.
We’ve had password files in DNS, geolocation in DNS, email service and fax numbers in DNS, certificate identity and pinning for TLS in DNS. We’ve even had domain names in the DNS, but don’t tell anyone, they might worry we’re using the DNS too much.
2. Talk about how you could send the DNS over different transports
This also has been discussed many times — its roots lie in 512-byte UDP packets — and many fine lunches and dinners have been had, discussing how to fit names into this little space — some of the first compression methods invented were used to pack the individual labels in the DNS name into less space; then bigger UDP packets; then TCP packets.
Then we became aware of security issues in the DNS and so developed DNSSEC. Suddenly, little DNS messages are bigger and bigger. And now we need to think about privacy of the DNS not just the security inside the DNS. So we have DNS over TLS. We have DNS over QUIC. We have DNS over HTTPS? Sure we do.
DNS over HTTP has questions to answer about: How can you manage the complex DNS state called split-DNS, which demands different answers inside and outside? How can you manage the security credentials to pick a safe HTTPS carrier to put your DNS in? What is the best encoding to use? (we have a million different ways to say things in HTTP protocol, so just picking one is actually quite hard). To answer these the logical step is to form a working group and work it out.
Which brings me to the third way to get a smile out of an IETF attendee:
3. Pick a really good, killer name for your working group
Life’s too short to call this HTTP carrying DNS so, HCD is not going to cut it. But DNS over HTTP (DOH) is just what we need…
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.