RFC 4892

RFC 4892: Requirements for a Mechanism Identifying a Name Server Instance 🎀

Title block, bestie:

• RFC number: 4892
• Title: Requirements for a Mechanism Identifying a Name Server Instance
• Authors: S. Woolf (Internet Systems Consortium, Inc.) and D. Conrad (ICANN) 💖
• Category: Informational (so this is guidance, not a standard, okay?)
• Date: June 2007
• Obsoletes/Updates: the title block doesn't list anything it obsoletes or updates ✨

---

Status of This Memo 📜

This memo gives information to the Internet community. It is not an Internet standard of any kind 🙈 Distribution is unlimited, so share away 💅

Copyright Notice ©️

Copyright (C) The IETF Trust (2007). That's the legal bit, but it's cute that it's there 🌸

Abstract ✨

Okay so, DNS anycast, load balancing, and other setups let more than one DNS name server share a single IP address. That's amazing for reliability, but it makes it kinda hard to tell which server in the pool actually answered your query 😭 A standard way to find out the identity of the responding name server would be super useful, especially as a diagnostic tool for admins 🔥

The problem is that the ad hoc ways people currently use have some shortcomings. The biggest one is that nobody did the prior analysis of how such a mechanism should be designed and deployed 💀 This document describes the existing convention that several widely deployed DNS implementations use, including its advantages and disadvantages, and talks about some attributes of an improved mechanism 🦋

1. Introduction and Rationale 🧚

Knowing which name server is answering queries is really useful, especially when you're trying to debug name server trouble 🔍 It's most obviously helpful for authoritative name servers, where you want to figure out where inaccurate data is coming from or how common it is. It can also be useful for caching resolvers in similar and other situations 🌈 And as DNS has become more critical to more Internet users, and as server deployment topologies have gotten more complicated, being able to identify the responding server has only become more useful 💜

Traditionally, the way to figure out which of several servers answered a query has been to use the server's IP address as a unique identifier. But the modern Internet has deployed a bunch of load balancing, fault-tolerance, and attack-resistance schemes, like shared use of unicast IP addresses as documented in [RFC3258]. Honestly, that's where things get messy 😩 Using IP addresses as identifiers for DNS (or any other) service gets kinda problematic. Multiple dedicated DNS queries sent to the same IP address may not reach the same server. Non-DNS methods like ICMP ping, TCP connections, or non-DNS UDP packets (such as the ones generated by tools like "traceroute") are even less certain to reach the same server that receives the DNS queries 🙃

There's a well-known, frequently used technique for getting an identity for a name server that's more specific than the possibly-non-unique "server that answered the query I sent to IP address A.B.C.D" 👀 Because people use this existing convention so much, it suggests there's a need for a documented, interoperable way to query the identity of a name server that might be part of an anycast or load-balancing cluster 🫶 But it also has some drawbacks, which argue against standardizing it the way it's been practiced so far 🥲

2. Existing Conventions 💅

For a while now, the widely deployed Berkeley Internet Name Domain (BIND) implementation of the DNS protocol suite, from the Internet Systems Consortium [BIND], has supported a way to identify a particular server using a standards-compliant (if kinda unusual) DNS query 🧁 Specifically, sending a query to a recent BIND server for a TXT resource record in class 3 (CHAOS) for the domain name HOSTNAME.BIND. returns a string that the name server administrator can configure to give a unique identifier for the responding server ✨ (The value defaults to the result of a gethostname() call.) This mechanism extends the BIND convention of using CHAOS class TXT RR queries to sub-domains of the BIND. domain for version information, and several name server vendors have copied it 🌸

A refinement to the BIND-based mechanism dropped the implementation-specific label and replaces BIND. with SERVER.. So the query label to learn a server's unique name can look like ID.SERVER. 🎀

(FYI, the other well-known name used by recent versions of BIND in the CHAOS class BIND. domain is VERSION.BIND.. A CHAOS TXT RR query for this name returns an administratively defined string that defaults to the software version of the responding server. Other vendors don't generally implement this one 🙈)

2.1. Advantages 🌟

There are several valuable attributes to this mechanism, and they're the reason it's so useful 👑

1. The HOSTNAME.BIND. or ID.SERVER. query response mechanism lives within the DNS protocol itself. A mechanism that relies on the DNS protocol is more likely to succeed (though not guaranteed) at reaching the same system as a "normal" DNS query 💖
2. Because the identity information is requested and returned within the DNS protocol, it doesn't need any other query mechanism to be allowed to the server, like holes in firewalls for otherwise-unallowed ICMP Echo requests 🔥 So it's likely to reach the same server over a path subject to the same routing, resource, and security policy as the query, with no special exceptions to site security policy 🦋
3. It's simple to configure. An administrator can easily turn this feature on and control the results of the relevant query 🍓
4. It lets the administrator have complete control over what information is given out in the response, which minimizes passive leakage of implementation or configuration details 🙌 Infrastructure operators often consider those details sensitive, so this is a big deal 🔐

2.2. Disadvantages 🥀

Still, the CHAOS/TXT query mechanism has some serious drawbacks, and they argue against standardizing it the way it currently operates 😬

1. It requires an additional query to correlate the answer to a DNS query under normal conditions with the supposed identity of the server that received it. There are a number of situations where this simply isn't reliable 💀
2. It reserves an entire class in the DNS (CHAOS) for what amounts to one zone. CHAOS class is defined in [RFC1034] and [RFC1035], but it's not clear that supporting it solely for this purpose is a good use of the namespace or of implementation effort 🤔
3. The initial, still-common form, using BIND., is implementation specific. BIND is one DNS implementation, and at the time of this writing it's probably most prevalent for authoritative servers. That doesn't justify standardizing on its ad hoc solution to a problem shared across many operators and implementors 🙅‍♀️ Meanwhile, the refinement mentioned above changes the query label but keeps the ad hoc CHAOS/TXT mechanism 😤
4. There's no convention or shared understanding of what information an answer to such a server identity query could or should contain, including a possible encoding or authentication mechanism 🌫️
5. Hypothetically, since DNSSEC has been defined to cover all DNS classes, the TXT RRs returned in response to the ID.SERVER. query could be signed, which would have the advantages described in [RFC4033]. However, DNSSEC deployment for the CHAOS class is neither existent nor foreseeable, and since the ID.SERVER. TXT RR is expected to be unique per server, this would be impossible in practice 😭

The first of the listed disadvantages may be technically the most serious 🚨 It argues for an attempt to design a good answer to the problem, "I need to know what nameserver is answering my queries," rather than just a convenient one ✨

3. Characteristics of an Implementation Neutral Convention 🧚‍♀️

The discussion above of the advantages and disadvantages of the HOSTNAME.BIND. mechanism suggests some requirements for a better solution to the server identification problem 💜 These are summarized here as guidelines for any effort to provide appropriate protocol extensions:

1. The mechanism adopted must be in-band for the DNS protocol. That is, it needs to allow the query for the server's identifying information to be part of a normal, operational query. It should also permit a separate, dedicated query for the server's identifying information. But it should preserve the ability of the CHAOS/TXT query-based mechanism to work through firewalls and in other situations where only DNS can be relied upon to reach the server of interest 🔥
2. The new mechanism should not require dedicated namespaces or other reserved values outside of the existing protocol mechanisms for these, i.e., the OPT pseudo-RR 🎀 In particular, it should not carry forward the existing drawback of requiring support for a CLASS and top level domain in the authoritative server (or the querying tool) to be useful 🙄
3. Support for the identification functionality should be easy to implement and easy to enable. It must be easy to disable, and it should lend itself to access controls on who can query for it 🔐
4. It should be possible to return a unique identifier for a server without exposing information that may be non-public and considered sensitive by the operator, such as a hostname or unicast IP address maintained for administrative purposes 🙈
5. It should be possible to authenticate the received data by some mechanism analogous to those provided by DNSSEC. In this context, the need could be met by including encryption options in the specification of a new mechanism 🧁
6. The identification mechanism should not be implementation-specific 🌈

4. IANA Considerations 📚

This document proposes no specific IANA action. Protocol extensions, if any, to meet the requirements described here are out of scope for this document. A proposed extension, specified and adopted through the normal IETF process, is described in [NSID], including the relevant IANA action 💖

5. Security Considerations 🔥

okay bestie, this section is SERIOUS 😭 Telling people which server answered a query from a particular spot on the internet can count as information leakage, and that's a real security risk 💀. That's why the suggestion above says a new server identification mechanism should let the admin switch the whole thing off or only partly restrict who can access the data 🫶. It also says the server identification data shouldn't be easily correlated with a hostname or unicast IP address that the nameserver operator treats as private to their management infrastructure 🙈.

Propagating protocol or service metadata can sometimes expose the application to denial of service or other attacks 😬. DNS is a critically important infrastructure service for the production Internet, so designers, implementors, and operators of a new server identification mechanism need to take extra care with this risk 💅.

Both authentication and confidentiality of server identification data may matter to administrators. Operators may want that data available and reliable to themselves and their chosen associates only 🔐. That means they need to be able to authenticate it to themselves and keep it private from arbitrary other parties, which is why this leads to characteristics 4 and 5 of an improved solution ✨.

6. Acknowledgements 🌸

the technique for host identification in this document was first implemented by Paul Vixie of the Internet Software Consortium in the Berkeley Internet Name Daemon package 🧚. Comments and questions on earlier versions came from Bob Halley, Brian Wellington, Andreas Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the ICANN Root Server System Advisory Committee 💜. The newest version goes in a significantly different direction from earlier ones, thanks to discussion among DNSOP working group contributors and others, especially Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam Weiler, and Rob Austein 👑.

7. References 📚

7.1. Normative References

[RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
           STD 13, RFC 1034, November 1987.

[RFC1035]  Mockapetris, P., "Domain Names - Implementation and
           Specification", STD 13, RFC 1035, November 1987.

[RFC3258]  Hardie, T., "Distributing Authoritative Name Servers via
           Shared Unicast Addresses", RFC 3258, April 2002.

7.2. Informative References

[BIND]     ISC, "BIND 9 Configuration Reference".

[NSID]     Austein, R., "DNS Name Server Identifier Option (NSID)",
           Work in Progress, June 2006.

[RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
           Rose, "DNS Security Introduction and Requirements", RFC
           4033, March 2005.

Authors' Addresses 🎀

Suzanne Woolf
Internet Systems Consortium, Inc.
950 Charter Street
Redwood City, CA  94063
US

Phone: +1 650 423-1333
EMail: woolf@isc.org
URI:   http://www.isc.org/


David Conrad
ICANN
4676 Admiralty Way
Marina del Rey, CA  90292
US

Phone: +1 310 823 9358
EMail: david.conrad@icann.org
URI:   http://www.iana.org/

Full Copyright Statement ©️

the IETF Trust holds the copyright for 2007 💖. This document is subject to the rights, licenses and restrictions in BCP 78, and except as set out there, the authors keep all their rights 🦋. The document and the information in it are provided "AS IS", and the disclaimer below applies ⚠️.

THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🧾

the IETF doesn't take a position on whether any Intellectual Property Rights or other rights that might be claimed for the technology in this document are valid or in scope, or whether any license under those rights is available 🤷‍♀️. It also doesn't say it has independently checked for such rights. You can find the rules on rights in RFC documents in BCP 78 and BCP 79 📖.

Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that will be made available, and the results of any attempt to get a general license or permission for implementers or users are available from the IETF's online IPR repository at http://www.ietf.org/ipr 💻. The IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 📬.

Acknowledgement 💜

funding for the RFC Editor function is currently coming from the Internet Society 🌈✨