The DNS Working Group of the IETF is continuing to expand the DNS code base with both new features and enhancements to previous features. In the latest session, a proposal on private space in the DNS with two letter codes received mixed comments, while the policy-heavy work on the operational fall-out of DoH is still not welcome.
All those failed DNS queries
Under the current technical specifications for the DNS, receiving an error message in response to a DNS query can mean any number of things. The new RFC 8914 on Extended Error Codes proposes to change this, so that administrators will at least be able to know the specifics of an error.
Among the different problems a query could run into, and that an administrator might need to be aware of in order to take the right countermeasures, are issues with DNSSEC certificates (such as expired certificates, signatures that are not yet valid or even unsupported crypto algorithms), network problems or upstream issues with the authoritative servers of the domain. Queries can also fail due to policy reasons, for instance if a resolver or authoritative server is based in a jurisdiction which places blocking, filtering or prohibition requirements on the resolution of queries. The list of 26 error codes in RFC 8914 carefully differentiates between these cases.
But no sooner was the electronic ink dry for RFC 8914 than a group of editors from McAfee, Open-Xchange, Citrix and Orange asked for additional transparency with regard to the “filtering and blocking category”.
Under the current error code list, users do not know why a domain was filtered or blocked, Tirumaleswar Reddy explained during the DNSOP session at IETF 109. Reddy and his co-authors propose an extended DNS (EDNS(0)) option that would return a Uniform Resource Identifier (URI) that explains the reason a DNS query was filtered. Foreseen benefits include an ability for end-users to send timely objections to responsible parties when content that should be available is made unavailable.
However, the proposed solution comes with considerable security issues, notably the malignant injection of an error page by an attacker. Reddy, whose draft already identifies this issue, promised the draft would try solving this by making DNS encryption mandatory and also by forcing a rejection of any displayed URI EDNS(0) options that are provided by unauthenticated origins.
With such limitations, the implementation of transparent filter messages risks becoming pretty restricted, US academic Wes Hardaker noted, and he recommended waiting to see whether the Extended Error Codes from RFC 8914 would see a greater adoption before taking any further steps. He also proposed that a free text field – while limited in length – could be used to signal the URI of an explanatory error page in the meantime.
Signaling errors into the other direction
Two ICANN employees, Roy Arends and Matt Larson, would also like to signal errors towards the authoritative name server experiencing the problem.
A reporting agent for the authoritative domain, specified in the EDNS(0) option received from the authoritative server, could receive indications of the error-related queries from the recursive resolvers, Arends proposed.
The proposal raises similar security concerns as the one by Reddy et al, but Arends seems intent on going ahead. After discussions in the DNSOP working group, he noted that the IETF document is currently listed as an independent submission which the working group would not need to adopt.
Private zones by name and not only by number
As previously reported in the CENTR Tech Trends Watch Q2/2020, Arends has also proposed – together with Joe Ably – the creation of an IETF-managed list of two-letter private namespaces following existing two-letter codes in ISO 3166-1. This proposal has generated heavy e-mailing list traffic since Q1, and now made it to the DNSOP meeting. Working group members such as Ted Hardie, former IAB Chair, warned that this issue had to be discussed between ICANN and ISO.
Fight over – new edition in DNSOP?
With the DoH WG being closed the authors of a draft on guidelines for operators are desperately looking for a new space to place their work. But the DNSOP Chairs certainly want to keep the policy-heavy discussion out of their WG as good as they can. For the ongoing dispute on DoH, discovery and the related privacy issues – stay tuned for the next CENTR blog post.
***
This article was written for CENTR by Monika Ermert. Monika has been working as an IT journalist for over 20 years. She has covered the evolving internet governance landscape, EU and worldwide attempts to regulate and the risks and fun of technology. She holds an M.A. in Chinese/Media Studies from the University of Tuebingen and lives and works in Munich, Germany.
