RFC 2937

RFC 2937: The Name Service Search Option for DHCP ✨

Okay bestie, here's the title block 🎀

• Number: RFC 2937
• Title: The Name Service Search Option for DHCP
• Author: Carl Smith (listed as C. Smith) at Sun Microsystems, Inc. 🧚
• Category: Standards Track
• Date: September 2000
• Obsoletes / Updates: none listed in the title block

---

Status of This Memo 🌸

This document is an Internet standards track protocol for the Internet community, and it's open for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited.

Copyright Notice 💅

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract 💖

This doc defines a brand new Dynamic Host Configuration Protocol (DHCP) option. The DHCP server sends it to the DHCP client to say what order name services should be checked in when resolving hostnames and other info. It's giving organization ✨

Introduction 🦋

DHCP[1] gives hosts on a TCP/IP network a framework for getting their configuration info. RFC 2132 [2] lets DHCP servers pass along config info for different kinds of name services to clients. Lots of clients already use multiple name services, and they've come up with their own conventions for showing the order they look things up in. The thing is, there was no way to specify a search order through DHCP 😭

So this doc lets DHCP servers set the search order that DHCP clients use. We don't need to invent and maintain a separate name space for it, because we rely on DHCP options that already exist. Those options give the IP address(es) of the servers for each name service whose order we want to express. Iconic reuse 👑

Definitions 🔥

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. This doc also uses these terms:

• "DHCP client": A DHCP client, or "client," is an Internet host that uses DHCP to get configuration parameters like a network address.
• "DHCP server": A DHCP server, or "server," is an Internet host that sends configuration parameters back to DHCP clients.

Name Service Search Option Format 🎀

The code for this option is 117, and its minimum length is 2 bytes. A DHCP server SHOULD return, in its preferred order, the 16-bit, network byte order (big-endian [4]) integer option code for each name service. The earlier a name service is in the list, the more preferred it is. Main character energy 🌟

   Code            Length      Name Service Search Order in Sequence
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     117       |     Len       |             ns1               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             ns2               |             ...               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In that diagram, ns1 and ns2 are 16-bit integers. Each one matches a DHCP option that gives the IP addresses of a different type of name server. The current list of name services and their DHCP option codes, taken from RFC 2132, looks like this 🍓

Name Service                                  Value

Domain Name Server Option                       6
Network Information Servers Option             41
NetBIOS over TCP/IP Name Server Option         44
Network Information Service+ Servers Option    65

A name service option code of 0 means the client should look at local naming information, like an /etc/hosts file on a UNIX machine.

Say a DHCP server wants a client to search DNS first, then NIS+. It would send this 💖

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     117       |      4        |              6                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              65               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

DHCP Client Behavior 🧚

The DHCP client uses this option to build a search list for name resolution. It may get name services in this option that it doesn't support or hasn't been set up to access. On the flip side, a client may get an option that lists name services with no matching DHCP option supplied. Clients interpret this option in a system-specific way, and that spec is outside the scope of this document. It's a lot, but that's the vibe 🫶

---

Security Considerations 🙈

DHCP currently provides no authentication or security mechanisms. Potential exposures to attack are discussed in section 7 of the DHCP protocol specification [1]. This is serious, bestie. Read section 7 of [1] before you ship anything 💀

IANA Considerations 🌈

IANA has assigned a value of 117 for the DHCP option code described in this document. ✨

References 📚

• [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
• [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
• [3] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
• [4] Cohen, D., "On Holy Wars and a Plea for Peace", Computer, IEEE, October 1981.

Author's Address 🎀

Carl Smith
Sun Microsystems, Inc.
901 San Antonio Road
Palo Alto, CA 94043

EMail:  cs@Eng.Sun.COM

Full Copyright Statement 💜

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

Acknowledgement 🦋

Funding for the RFC Editor function is currently provided by the Internet Society.