Filter ideas for all kinds of content have become indispensable on the political agenda, for example in the EU. Technology is now following suit for DNS filters. The Internet Engineering Task Force (IETF) wants to try to make the reason for failed DNS requests more transparent. To this end, the organization has issued a new RFC specification (Request For Comment). In the next step, a small group wants to go one step further and provide the option of displaying the filtering institution using its own URI.
The list of reasons why a DNS request can fail and why certain pages in the network cannot be reached is long. So long that the general error message “ServFail” can mean anything, from the expired or incorrect DNSSEC key or an unsupported DNSSEC crypto algorithm, to problems with the DNS server that is responsible for a domain (authoritative DNS server) to the content that has been intentionally blocked for various reasons.
The new one carries a total of 24 new error codes RFC 8914 one and on top of that one for “other errors”, DNS error code 0. A fine distinction is made in the error codes between blocked domain requests, censored domains, filtered domains and forbidden domains.
Clear error messages
The authors understand “blocked” domains that the operator of the DNS resolver or forwarder has blacklisted, for example because of their own security guidelines. In the case of a “censored” domain, the blockage occurs because of third party regulations, for example because of government filter lists or specific court orders. “Filtered” domains are designated that are on a blacklist at the request of the user. Users receive such messages, for example, if they have set up child protection filters.
One advantage of the more precise error messages is immediately obvious: Technically justified errors can be identified more easily and reported to those responsible. But that might not be enough, says a group of authors from McAfee, Citrix and OpenXchange. At the most recent meeting of the IETF, the group therefore made another proposal.
RFC 8914 already provides a separate text field for comments, which could also contain a URI. But the field length is limited. Such a field shouldn’t be too long either, because comments that are too long exceed the upper limit of DNS packets and can lead to undesirable fragmentation of the response packets, explains Vittorio Bertola from OpenXChange, explaining the motive for the new proposal.
A supplementary RFC with the working title DNS Access Denied therefore specifies an additional resource record for a specially sent URI. This additional DNS database element is intended to reveal to the inquirer what and who is behind the blockage. Users could also be offered various complaint options on the found website. For example, you could report if you believe that a page is being wrongly blocked. The extra URI also allows the stored information to be changed dynamically more easily, says Bertola.
Hooks and eyes
But the idea of transparent filtering generally has a technical catch. The extended error messages and even more the customized URIs could be used by attackers as a gateway for phishing or other attacks. Chrome developers have therefore already announced that they will only accept RFC 8914 with encrypted DNS queries, explains Bertola.
Only through consistent encryption can it be prevented that surfers divert “wrong diversion signs” from the correct routes to their websites. Such Precautions McAfee developer Tirumaleswar Reddy also promised for the new URI proposal “Access Denied”. Encrypted DNS should be mandatory and a URI without HTTPS protection should be discarded. In view of the long list of restrictions, the scope of the concept could be limited, complained Participants of the Working Group DNS Operations. You advise first to wait for the acceptance of RFC 8914.
Facebook has one too suggestion on the subject of DNS. According to the draft, the DNS data streams of recursive resolvers should be better sorted. The recursive resolvers should use TXT or HTTPS entries to indicate which IP prefixes they are using and where they are geographically located. As a result, latencies in large networks could be shorter, said Manu Bretelle, DNS developer at Facebook. Could this specification also facilitate different responses to DNS queries in different countries?
Bertola admits that it could well be that some of these ideas help set up borders on the Internet or promote national policy preferences. But if the pendulum does not swing too far in the direction of “nationalism”, the development could be positive. “We need a reasonable balance between ‘no rules’ and ‘too much fragmentation’ as a result of incompatible rules,” says Bertola. The working group is still pondering whether to make the final proposals on the IETF specifications.