DNS Architecture Considerations for Digital Emblems

DNS Architecture Considerations for Digital Emblems RTFM llp

St Andrews House Glasgow GS jim@rfc1035.com

General Internet Engineering Task Force It is expected that the Domain Name System (DNS) will be used to publish and retrieve Digital Emblems. The objective of this Internet Draft is to propose an architecture on how the DNS could be used and outline the main challenges that will require work from the diem Working Group. Publication of this document is intended to provoke discussion and analysis of how digital emblems can be deployed in the DNS.

Introduction This content-free placeholder text should be replaced with something more appropriate when the time comes.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Structuring the DIEM Name Space There are essentially two approaches to organising the name space used for digital emblems. These are not necessarily mutually exclusive. Both may be acceptible because of how digital emblems are applied to different use cases. One option would be to anchor these domain names under diem.arpa (say) and have that overseen by IANA, just like how IANA coordinates the in-addr.arpa and ip6.arpa domains for reverse lookups of IPv6 addresses. IANA delegates parts of these domains to the Regional Internet Registries who manage the distribution of IP addresses. For digital emblems, IANA could delegate parts of diem.arpa to the appropriate authorities such as humanitarian organisations or international treaty bodies. Each of them would be responsible for the oversight of subsequent delegations: for instance to the national chapters of the ICRC or to ICAO member states. An advantage of this approach is diem.arpa, a potential apex for these zones, would be notionally neutral and independent. Other top-level domains (TLDs) are in general either overseen by ICANN or the relevant country's government. The Internet Architecture Board is responsible for the .arpa top-level domain and IANA does not currently charge for operating the .arpa registry. Using .arpa would fit with the IAB guidelines that the top-level domain gets used for infrastructure resources . Digital emblems could reasonably be viewed as infrastructure resources that should be anchored somewhere under the .arpa TLD. One potential difficulty with using diem.arpa (say) is the administrative burden on IANA. It would need to identify, establish and maintain relationships with DIEM stakeholders: international humanitarian organisations and/or treaty bodies. These relationships would need to be documented and processes put in place to manage delegations in diem.arpa. There would probably need to be a hierarchical naming or numbering scheme to identify digital emblems so they can be easily mapped into domain names, This would require a global registry. It is currently unclear if such a registry exists, if one would be set up or who would have the authority to create one and pay for it. The second approach would be for each participant in digital emblems to choose the domain name(s) that best suit and have each organisation manage these independently. As an example, ICRC could anchor its DIEM entries under diem.icrc.org and take care of managing any delegations under that domain name. It would also be advisable to use discrete domain names and DNS platforms for the organisation and those used to support digital emblems. Fate-sharing could have undesirable consequences, This is why large eyeball networks separate the IT infrastructure used to run their business from the one used to provide service to its customers. This ad-hoc approach might not scale. It will also rely on DNS expertise that might not be readily available at some participants. That way well create otherwise avoidable instability and operational problems.

Discovery of DIEM domain names It is not clear how clients would decide which domain names to use whenever they make DIEM-related DNS lookups. One possibility is a client has a priori knowledge of the relevant domain name, for instance from a URL. This would probably require a diem-specific template to be added to the existing URL naming scheme. Another option might be for a client to be specially configured to lookup the domain name, eg refugee-camp.disaster-zone.relief-agency.TLD. While that could work, it does present scaling problems, This topic needs detailed analysis by the working group.

Provisioning and Managing DIEM domain names Conventional domain name registrations generally follow the well-established registry-registrar-registrant model. The registry maintains a database of domain names and runs authoritative DNS servers to publish delegation information for those domain names. The registrar updates that database on behalf of the end user, the registrant. The registar often provides tools, typically a web-based GUI, so registrants can update the contents of their registered domain names. In practice, these arrangements are much more complicated. However that operational detail does not matter here and is only of concern to pedants. As an example, the IETF is the registrant for the ietf.org domain name. It uses Cloudflare as the registrar to manage the registration data for that domain name in the .org registry which is operated by PIR. It is likely this model would be adopted when identifying the roles for managing the registration of DIEM related domain names. However these roles can be combined. As a hypothetical example, ICRC might occupy the role as the registry for the domain name used for a field hospital, an official at that hospital serves as the registrant and also fills the registrar role by using some ICRC-supplied website or smartphone app to manage the DIEM data for that field hospital's domain name. The main consideration for this document is the separation of roles and responsibilities and not the actual entities who provide those functions. Appropriate controls may be needed on how DIEM data get published in the DNS: who is authorised to add/remove DIEM-related DNS resource records, checking these are being used correctly, how long these records stay in the DNS, change management procedures, audits and so on. Some digital emblems will have protected status in international law and therefore need to be handled carefully. These controls should ensure these resource records are used correctly and the "registry" is aware who is using which DIEM-related DNS resource records and for how long. Discussion of these issues are probably out of scope for this DNS architecture document. However they should be explored by the working group.

The DIEM Resource Record Digital emblems SHOULD be stored in the DNS in the as-yet undefined DIEM resource record type (RRtype). Once this is documented, the lightweight expert review process defined in Section 3.1 of will be used to obtain a formal RRtypecode and update the appropriate IANA database. Digital emblems SHOULD NOT be stored as TXT records because these are already widely used for a diverse range of purposes: SPF data, version control information, publishing DMARC policy, nonce challenge-response strings and so on. Overloading TXT records with yet another use case would be unwise because it adds undesirable complexity for DNS administrators and the tools used to manage zone files. A lookup for a domain name's TXT records would return all of these records, forcing the client to process all of them to find the one(s) which contain digital emblem data. An additional concern is the possibility of truncated DNS responses, forcing retried queries over TCP when the amount of data in those TXT records is "too large" for a standard UDP responseq. Using a dedicated RRtypecode for DIEM records is cleaner and simpler. The content of the proposed DIEM resource record has still to be decided. It will probably be some blob of structured text in CBOR or JSON format. This would allow the content of DIEM records to be extended whenever elements get added, updated or removed without needing a new typecode allocation. The HHIT and BRID resource records described in DRIP Entity Tags provide an example of this approach.

IANA Considerations IANA will be expected to issue a DNS RRtype code for the currently undefined and undocumented DIEM record. It may be necessary for IANA to operate a registry and the supporting DNS infrastructure for the diem.arpa domain as outlined above.

Security Considerations The main security concerns for DNS-based digital emblems are data validation, data authentication and client anonymisation. Validation issues can be addressed by using Secure DNS, DNSSEC . When DIEM resource records are signed, validating DNSSEC-aware resolving servers can check the signatures on these responses and detect spoofed or tampered replies. They can also detect failures caused by DNSSEC signing errors such as incorrect or out of date keys. In short, clients receiving DNSSEC-signed responses can verify the replies exactly contain the data sent by the authoritative name servers that publish DIEM records. Secure DNS offers provable non-repudiation as well as validation of DNS data. Though this DNSSEC feature is not widely appreciated. The private key used to sign DNS data implicitly identifies the signer and there is a chain of trust which terminates at the private key used to sign the DNS root. In simple terms, the private key for the domain name a.b.c is signed by the private key for b.c which in turn is signed by the private key for c which is signed by the DNS root's private key. In principle, this means it can be proven who signed DIEM-related resource records. Provided the relevant private keys are kept secret, impostors and other bad actors cannot sign those resource records. Similarly, the identity of the entity who does sign these resource records can be proven and they cannot claim otherwise. ie It can be shown a DNSSEC-signed DIEM record for (say) some ICRC resource was signed by the genuine authority for that resource and it could not have been signed by anyone else. This would prove there was a chain of trust showing that ICRC had responsibility for issuing that DIEM record and its accompanying DNSSEC signature(s). The DNS provides serveral mechanisms to anonymise the source of DNS queries. However there is an unavoidable limitation. The client making the query usually sends the fully qualified domain name (FQDN) to its resolving DNS server. So that resolving server is aware which clients query for specific FQDNs. A client could make label-by-label iterative queries. Though this is unlikely. It wouldn't help anonymisation because the resolving server would still in principle be able to assemble the FQDN from that client's iterative queries. Query minimisation improves privacy for DNS clients and is widely supported in resolving servers. When this is used, the resolving server does label-by-label iterative queries instead of sending the FQDN for each step of the resolution. ie Instead of sending the FQDN a.b.c.d to the authoritative servers for the d, c.d and b.c.d domains, the resolver sends a query for c.d to the authoritative servers for d, then a query for b.c.d to c.d's authoritative servers and then queries b.c.d's authoritative servers for a.b.c.d. Thus, the FQDN is ony visible to the resolving server and the authoritative server(s) for the b.c.d domain. It should be noted that most resolving servers support Client Subnet in DNS Queries . This discloses details about the source IP address of a DNS client to authoritative servers. [The rationale was so authoritative servers for a CDN could respond with the IP address of the CDN node that was optimal for the client making the initial query.] Clearly, this can have unfortunate privacy implications. When this feature is used, authoritative DNS servers may be able to identify the initiating client or at least get a reasonable indication of that client's identity. Encrypted DNS transports provide a degree of anonimity, mostly by preventing eavesdropping and traffic interception. DNS over TLS , DNS over HTTPS and DNS over QUIC all use Transaction Layer Security to encrypt DNS queries and responses between clients and servers. Oblivious DNS is another possibility for improving client anonimity. This introduces a proxy which forwards encrypted DNS messages between a client and server. The proxy has no visibility of these messages and the server only receives the query and the source IP address of the query. Choosing between these DNS capabilities and features is out of scope for this document because those are largely policy-based decisions that will depend on the prevailing local circumstances.

References Normative References

Acknowledgements Fill this in when anyone needs to be acknowledged