The Internet Engineering Task Force (IETF) is the organization where development of the Domain Name System (DNS) protocol takes place. Work takes place within Working Groups that each have a mailing list, and you can see archives on the IETF Datatracker, along with the agenda and presentations from meetings that take place three times a year.<\/p>\n
During July\u2019s IETF 126 hybrid meeting there were lots of DNS-related discussions across multiple Working Groups. I\u2019ve picked some related to specific Internet Drafts that are the \u201cunit of work\u201d discussed within the IETF. There are three related to the operations of DNS and one related to digital emblems for organizations such as the Red Cross.<\/p>\n
The DNS Operations (DNSOP) Working Group focuses on the operational aspects of the DNS and protocol standards work related to DNS itself.<\/p>\n
Keeping Parents and Children in Step<\/strong><\/p>\n DNS scales because the management of domains is delegated from one organization to another. Verisign looks after the .com top-level domain (TLD) and the domain you register below this for your organization is managed by you. You could do this on your own public authoritative DNS services, use a service provider or a mixture. When you register the domain, you tell the parent what the name servers are, and you configure the same information on your authoritative servers. A long-standing problem, leading to operational problems and security vulnerabilities, is that the parent and child DNS records associated with the delegation must be kept in step when they change. When they are not it can cause issues such as some of those highlighted in this paper<\/strong><\/a>.<\/p>\n There have been proposals aimed at removing the need for manual synchronization, and one discussed at the IETF meeting was Automating DNS Delegation Management via DDNS<\/strong><\/a>. This document proposes an automated mechanism for child zones to notify and update their parent zones using DNS Dynamic Updates (DDNS) secured with SIG(0) transaction signatures. The approach is intended to address the drawbacks of the parent zone operator needed to scan for changes in all its child zones, which require DNS security extensions (DNSSEC)-signed child zones and impose operational complexity on parent zone operators. By shifting the responsibility for initiating changes to the child zone owner, the mechanism is applicable to both signed and unsigned child zones. Discovery of the appropriate update target is achieved using the DSYNC record defined in RFC 9859, and the document addresses the authentication process.<\/p>\n For domain owners this would mean being able to automatically notify a parent domain, such as a registry, of any changes in name servers of the domains they manage. This would go some way to mitigating risks with lame delegation.<\/p>\n Operational Improvements for Signing Zones<\/strong><\/p>\n DNSSEC are an implementation of public key infrastructure (PKI), intended to provide data origin authentication and data integrity by signing DNS records. In other words, your organization\u2019s DNS resolver can validate it received an answer from a legitimate source, and the answer was not tampered with in transit. Tools are available for key management, and processes include changing keys over a period of time. This can go wrong, which is not a DNS problem per se, as it\u2019s typically a change management process gone awry. It can have a large impact, though, depending on the scope of the signed domain, affecting anything from an organizational domain to a TLD problem impacting a country.<\/p>\n One draft looking at mitigating the impact of this is DNSSEC Key Restore<\/strong><\/a>. This document provides operational guidance for recovering DNSSEC signing capability when a private key becomes inoperable, for example, in the case of operator error. This is based on the process that would normally be used to change the key, known as a key rollover. Developing this draft will provide guidance to organizations so that they can prepare for, and practice, a disaster recovery type process to implement when the brown stuff collides with the air conditioning.<\/p>\n A draft that\u2019s also related to what can be done when the zone signing process has gone wrong is Disclosure of Negative Trust Anchors in DNS Responses<\/strong><\/a>. Operators of DNS resolvers, which could be your organization in addition to the well-known large open resolvers, can add a Negative Trust Anchor (NTA) to configure their resolvers to ignore validating records for a domain if it\u2019s known that an operational incident has impacted the DNSSEC chain of trust. This document defines a new Extended DNS Error (EDE) code that a resolver can include in responses to signal to clients that the response was delivered under an active NTA. The mechanism complements existing recommendations that operators disclose their NTAs out-of-band by providing a corresponding in-band signal, improving transparency for end users and applications.<\/p>\n Proposed improvements to operational processes are to be welcomed, especially when a DNSSEC validation issue can have such a wide impact. While these might seem to be issues that are primarily of interest to the operators of large-scale resolver services and TLDs, enterprise DNS operators should follow standards in this area to understand how this might look if their organizations are impacted, and for any lessons that can be learned for their own DNS services.<\/p>\n The Digital Emblems (DIEM) working group is developing standards for an architecture that enables digital emblems to be presented and validated across applications and platforms. Emblems such as the Red Cross, Red Crescent, Red Crystal and Blue Shield carry legal protection status under International Humanitarian Law and similar normative frameworks, but there is currently no interoperable mechanism to extend these protections to digital and network-connected assets. The DIEM working group is developing an initial DNS-based discovery mechanism for digital emblems that identify their bearer by a Fully Qualified Domain Name, along with associated validation procedures.<\/p>\n The first part of this is the draft Digital Emblems \u2014 Use Cases and Requirements<\/strong><\/a>. This document catalogs the use cases and requirements that a digital emblem architecture must accommodate. A digital emblem is described as a mechanism by which an asset\u2014physical or digital\u2014signals to validating entities that it should be protected or treated in a specific way under some normative framework. Use cases are drawn from international law and treaty frameworks include protective emblems under the Geneva Conventions, diplomatic pouch protections under the Vienna Convention, chemical and nuclear materials regulated by the Organisation for the Prohibition of Chemical Weapons and The International Atomic Energy Agency, civil aviation protections under International Civil Aviation Organization, press protections in conflict zones and markings for UN peacekeepers, among others.<\/p>\n At Infoblox we see lookalike domains registered and exploited for criminal activity related to humanitarian issues. Being able to validate that a domain is owned by an agency such as the Red Cross would be a useful tool in combating fraud and scams.<\/p>\n You can support the objective of the DIEM working group by reviewing and commenting on the draft, even simply indicating your support for work to continue in this area, by signing up to the diem@ietf.org<\/strong><\/a> mailing list and leaving your thoughts.<\/p>\nDIEM\u2014Digital Emblems Working Group<\/h3>\n