There were many interesting drafts discussed during the DNSOP session at IETF 99, two of which relate to better signalling from servers about problems: EDNS0 error response codes, to detail why a server said ‘no’; and EDNS0 client signalling, for clients to send information about what they can (or can’t) do in ‘modern’ DNSs.
A long time ago, Shane Kerr and I proposed the latter, but never formalized a proper draft exploring the idea. I think we both realized it required time and effort (which neither of us had) to come up with a viable model.
But here we are in 2017, with emerging risks relating to the change in DNSSEC keys, where we know what clients can do, what resolvers can do, but with no way to know what is going on.
So, it comes as no surprise that both documents are exposing real problems and are therefore, in principle, a good thing. Of course, problems will abound, and the IETF is nothing if not expert at picking apart drafts. But I do like them and I hope they get adopted and proceed to working group last calls.
Client privacy and the DNS
One last draft that caught my eye during this session documents current code that implements EDNS0 client identity. This is something that can be used to run CDN delivery, or limit corporate DNS responses or even do child-friendly content controls. However, it is also a huge risk in Personally Identifiable Information (PII) and a risk to privacy in the DNS. The questions we need to ask ourselves about this draft are:
- Do we adopt this document and note what is being done already in a pre-standard way?
- Do we deprecate it, and move on to a more opaque sense of client privacy?
I think (and said so) that we should put this out to a wider community review, as deciding what we want to do about client privacy is a big issue.
The DNS is fundamental infrastructure underneath almost all other protocol activity inside the Internet, above TCP, UDP and IP specified work — it’s how we find things to do over Internet Protocol.
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.
In this draft, Client-id appears to refer to specific pieces of hardware. Does it make sense to identify the s/w entities making requests based on the hardware that the s/w entity happens to be running on at a particular moment in time?
In my experience with enterprise scale, let alone species scale security management, mixing identities that relate to the IT and the real world (eg security principals and compute nodes), almost always leads to security management fragmentation and hence, failure.
[I’m content to discuss alternative points of view 🙂 ]