RFC 1183
New DNS RR Definitions
RFC 1183: New DNS RR Definitions 💖
Okay bestie, RFC 1183 is titled "New DNS RR Definitions" 🎀 It was written in the Network Working Group by C. Everhart (Transarc), L. Mamakos (University of Maryland), R. Ullmann (Prime Computer), and P. Mockapetris (ISI), who is the editor 🧚 It's dated October 1990 and it's Experimental. It updates RFCs 1034 and 1035, and it doesn't list anything it obsoletes ✨
Status of this Memo 🌸
So this memo defines five new DNS types, but only for experiments 🧪 It's an Experimental Protocol for the Internet community, and they're literally asking for discussion and ideas on how to make it better 💅 Distribution of this memo is unlimited.
Table of Contents 📚
Introduction.................................................... 1
1. AFS Data Base location....................................... 2
2. Responsible Person........................................... 3
2.1. Identification of the guilty party......................... 3
2.2. The Responsible Person RR.................................. 4
3. X.25 and ISDN addresses, Route Binding....................... 6
3.1. The X25 RR................................................. 6
3.2. The ISDN RR................................................ 7
3.3. The Route Through RR....................................... 8
REFERENCES and BIBLIOGRAPHY..................................... 9
Security Considerations......................................... 10
Authors' Addresses.............................................. 11Introduction 🌈
This RFC defines the format of new Resource Records (RRs) for the Domain Name System (DNS), and it reserves matching DNS type mnemonics and numerical codes 💖 There are three independent sections: (1) location of AFS database servers, (2) location of responsible persons, and (3) representation of X.25 and ISDN addresses and route binding. Everything in here is experimental 🧪
You need to already know the DNS [3,4] to vibe with this, okay? 🤓 Also, the data shown is just for teaching. It doesn't necessarily reflect the real Internet, so don't panic if your own network looks different 🙈
1. AFS Data Base location ✨
This section extends the DNS so you can find servers for AFS (AFS is a registered trademark of Transarc Corporation) and for the Open Software Foundation's (OSF) Distributed Computing Environment (DCE) authenticated naming system, which uses HP/Apollo's NCA. Both are supposed to be components of the OSF DCE 👑 It assumes you already know AFS [5] and NCA [6].
Okay so AFS (originally the Andrew File System) uses the DNS to go from a domain name to the name of an AFS cell database server 🦋 The DCE Naming service does something similar: it maps the domain name of a cell to authenticated name servers for that cell 💅 The method uses a new RR type with the mnemonic AFSDB and a type code of 18 (decimal).
The AFSDB format looks like this:
<owner> <ttl> <class> AFSDB <subtype> <hostname>Both RDATA fields are required in every AFSDB RR 🫶 The <subtype> field is a 16 bit integer. The <hostname> field is a domain name for a host that runs a server for the cell named by the RR's owner name.
The AFSDB RR is class insensitive. AFSDB records cause type A additional section processing for <hostname>, and that's honestly the whole reason they got a new type code instead of being faked with TXT RRs 🔥
Also, AFSDB looks identical to MX in a master file ✨ For the DNS itself, the subtype is just an integer. The subtype meanings below are the current ones, but they can change and will be announced in later RFCs 🌈
With subtype 1, the host runs an AFS version 3.0 Volume Location Server for the named AFS cell. With subtype 2, the host is an authenticated name server holding the cell-root directory node for the named DCE/NCA cell 💜
Why subtypes at all? Two reasons, bestie 💅 First, the space of DNS RR types is limited. Second, the services are so different that a client connecting to a cell's servers with the protocol for one service would get confused if the cell only offered the other service 😭
Here's a fun example. Toaster Corporation has deployed AFS 3.0 but not (yet) the OSF's DCE 🍞 Their cell, toaster.com, has three "AFS 3.0 cell database server" machines: bigbird.toaster.com, ernie.toaster.com, and henson.toaster.com. Those three machines get listed in three AFSDB RRs, which might look like this in a master file:
toaster.com. AFSDB 1 bigbird.toaster.com.
toaster.com. AFSDB 1 ernie.toaster.com.
toaster.com. AFSDB 1 henson.toaster.com.Another example: Femto College (domain name femto.edu) has deployed DCE 🎓 Their DCE cell root directory is served by processes running on green.femto.edu and turquoise.femto.edu. Their DCE file servers also run AFS 3.0-compatible volume location servers, on the hosts turquoise.femto.edu and orange.femto.edu. These machines get listed in four AFSDB RRs, which might look like this in a master file:
femto.edu. AFSDB 2 green.femto.edu.
femto.edu. AFSDB 2 turquoise.femto.edu.
femto.edu. AFSDB 1 turquoise.femto.edu.
femto.edu. AFSDB 1 orange.femto.edu.2. Responsible Person 🫶
The point of this section is to give you a standard way to attach responsible person info to any name in the DNS 💜
The DNS is a distributed database holding lots of different kinds of info 🌸 For a given name or host, you can look up its Internet address, its mail forwarding info, its hardware type and operating system, and more 🤓
Here's the key thing: the tree-shaped namespace can be split into pieces called zones, so control and responsibility can be distributed 🍰 The responsible person for zone database purposes is named in the SOA RR for that zone. This section adds an extension that lets you specify different responsible persons for different names inside a zone 👑
2.1. Identification of the guilty party 🙈
Sometimes you really need to know who's responsible for a particular host 😭 When that host is down or acting up, it's hard to reach the people who could fix it. Mail to POSTMASTER might not reach anyone in a timely way. And if the host is one of a bunch of workstations, there might not be any responsible person you can contact on that host at all 💀
The POSTMASTER mailbox on that host is still a good contact for mail problems, and the zone contact in the SOA record is still the one for database problems 💅 But the RP record lets us link a mailbox to things that don't get mail, or that aren't directly connected (namespace-wise) to the problem. For example, GATEWAY.ISI.EDU might want to point at HOTLINE@BBN.COM, because GATEWAY doesn't get mail, and the ISI zone administrator has no clue how to fix gateways 🙃
2.2. The Responsible Person RR 🎀
The method uses a new RR type with the mnemonic RP and a type code of 17 (decimal) 🦋
RP looks like this:
<owner> <ttl> <class> RP <mbox-dname> <txt-dname>Both RDATA fields are required in every RP RR 🫶
The first field, <mbox-dname>, is a domain name that names the mailbox for the responsible person. In master files it uses the same DNS mailbox encoding as the RNAME mailbox field in the SOA RR. You can put the root domain name (just .) in <mbox-dname> to say that no mailbox is available 🙅♀️
The second field, <txt-dname>, is a domain name where TXT RRs exist. You can run a later query to get the associated TXT resource records at <txt-dname> 💖 This adds a layer of indirection, so the entity can be referred to from lots of places in the DNS. You can put the root domain name (just .) in <txt-dname> to say that TXT_DNAME is absent and there's no associated TXT RR 🌈
The RP RR is class insensitive, and RP records cause no additional section processing. (TXT additional section processing for <txt-dname> is allowed as an option, but only if it's turned off for the root, i.e., ..) 🧠
The Responsible Person RR can hang off any node in the Domain Name System hierarchy, not just the leaves of the tree 🌳
The TXT RR at the TXT_DNAME holds free format text meant for humans. Check out [4] for more on the TXT RR 📖
You can have multiple RP records at one name in the database. They should have identical TTLs ⏰
EXAMPLES 🧁
Here are some examples of how the RP record might be used 🍓
sayshell.umd.edu. A 128.8.1.14
MX 10 sayshell.umd.edu.
HINFO NeXT UNIX
WKS 128.8.1.14 tcp ftp telnet smtp
RP louie.trantor.umd.edu. LAM1.people.umd.edu.
LAM1.people.umd.edu. TXT (
"Louis A. Mamakos, (301) 454-2946, don't call me at home!" )In this example, the responsible person's mailbox for the host SAYSHELL.UMD.EDU is louie@trantor.umd.edu 📬 The TXT RR at LAM1.people.umd.edu gives extra info and advice, and honestly it's giving "don't call me at home" energy 💀
TERP.UMD.EDU. A 128.8.10.90
MX 10 128.8.10.90
HINFO MICROVAX-II UNIX
WKS 128.8.10.90 udp domain
WKS 128.8.10.90 tcp ftp telnet smtp domain
RP louie.trantor.umd.edu. LAM1.people.umd.edu.
RP root.terp.umd.edu. ops.CS.UMD.EDU.
TRANTOR.UMD.EDU. A 128.8.10.14
MX 10 trantor.umd.edu.
HINFO MICROVAX-II UNIX
WKS 128.8.10.14 udp domain
WKS 128.8.10.14 tcp ftp telnet smtp domain
RP louie.trantor.umd.edu. LAM1.people.umd.edu.
RP petry.netwolf.umd.edu. petry.people.UMD.EDU.
RP root.trantor.umd.edu. ops.CS.UMD.EDU.
RP gregh.sunset.umd.edu. .
LAM1.people.umd.edu. TXT "Louis A. Mamakos (301) 454-2946"
petry.people.umd.edu. TXT "Michael G. Petry (301) 454-2946"
ops.CS.UMD.EDU. TXT "CS Operations Staff (301) 454-2943"This set of records has two hosts, TRANTOR.UMD.EDU and TERP.UMD.EDU, plus a bunch of TXT RRs 🌸 Both TERP.UMD.EDU and TRANTOR.UMD.EDU point at the same pair of TXT resource records, even though their mailbox names (root.terp.umd.edu and root.trantor.umd.edu) are different 🦋
Here we obviously care a lot more if the machine flakes out, since four persons might want to be notified of problems or other events involving TRANTOR.UMD.EDU 😭 In this example, the last RP RR for TRANTOR.UMD.EDU names a mailbox (gregh.sunset.umd.edu) but has no associated TXT RR 🫶
3. X.25 and ISDN addresses, Route Binding ✨
okay bestie, section 3 is where it gets spicy 🌶️ We're looking at an experimental way to put X.25 and ISDN addresses in the DNS, plus a route binding method that's basically the MX idea for mail, but for routing on really, really huge networks 🌍💅
There are a few possible uses, and they're all still experimental 🧪 First, the RRs work as a cute cheat sheet of the right addresses for static setups of IP/X.25 [11] and SMTP/X.25 [12] 📝
The RRs could also be used automatically by an internet network-layer router, usually IP 🤖 The flow goes like this: start with an IP address, map it to a domain name, go to the canonical name if you need to, follow the RT records, and then try an IP/X.25 call to the address you land on 📞 Or, if you want something more static, you can resolve configured domain names to figure out the IP to X.25/ISDN bindings and keep a routing table that gets refreshed every so often 🔄
This is giving ARP vibes but for wide area non-broadcast networks 🦋 and it should scale really well to a network with hundreds of millions of hosts 🌏
Also, a standard address binding reference makes other X.25 and ISDN experiments way easier, especially serious inter-operability testing 🧑💻 Most of the work in a test like that is filling in the n-squared entries in static tables 😩
Finally, the RRs are meant for a proposal [13] by one of the authors for a possible next-generation internet 👑
3.1. The X25 RR 🎀
The X25 RR is the one with mnemonic X25 and type code 19 (decimal) 💖
X25 has the following format:
<owner> <ttl> <class> X25 <PSDN-address><PSDN-address> is required in all X25 RRs.
<PSDN-address> is the PSDN (Public Switched Data Network) address in the X.121 [10] numbering plan tied to <owner>. In master files it's a <character-string>, syntactically the same as what TXT and HINFO use ✨
The format of X25 is class insensitive. X25 RRs cause no additional section processing 🙅♀️
The <PSDN-address> is a string of decimal digits that begins with the 4 digit DNIC (Data Network Identification Code), as specified in X.121. National prefixes (such as a 0) MUST NOT be used. 🚫
For example:
Relay.Prime.COM. X25 3110617009563.2. The ISDN RR 📱
The ISDN RR is the one with mnemonic ISDN and type code 20 (decimal) 🌸
An ISDN (Integrated Service Digital Network) number is simply a telephone number 📞 The CCITT crowd wants to upgrade all telephone and data network service into one common service 🌈
The numbering plan (E.163/E.164) is the same as the familiar international plan for POTS (an un-official acronym, meaning Plain Old Telephone Service) 💀 In E.166, CCITT says "An E.163/E.164 telephony subscriber may become an ISDN subscriber without a number change." 🫶
ISDN has the following format:
<owner> <ttl> <class> ISDN <ISDN-address> <sa>The <ISDN-address> field is required; <sa> is optional.
<ISDN-address> identifies the ISDN number of <owner> and DDI (Direct Dial In) if any, as defined by E.164 [8] and E.163 [7], which is the ISDN and PSTN (Public Switched Telephone Network) numbering plan. E.163 defines the country codes, and E.164 defines the form of the addresses. In master files it's a <character-string>, syntactically identical to what TXT and HINFO use 💜
<sa> specifies the subaddress (SA). In master files, its format is a <character-string>, syntactically identical to what TXT and HINFO use 🎀
The format of ISDN is class insensitive. ISDN RRs cause no additional section processing 🙅♀️
The <ISDN-address> is a string of characters, normally decimal digits, that begins with the E.163 country code and ends with the DDI if there is one. Note that ISDN, in Q.931, permits any IA5 character in the general case 👀
The <sa> is a string of hexadecimal digits. For digits 0-9, the concrete encoding in the Q.931 call setup information element is identical to BCD 🧠
For example:
Relay.Prime.COM. IN ISDN 150862028003217
sh.Prime.COM. IN ISDN 150862028003217 004(Note: "1" is the country code for the North American Integrated Numbering Area, i.e., the system of "area codes" familiar to people in those countries. 🇺🇸)
The RR data is the ASCII representation of the digits. It gets encoded as one or two <character-string>s, i.e., a count followed by the characters 🔢
CCITT recommendation E.166 [9] defines prefix escape codes for representing ISDN (E.163/E.164) addresses in X.121, and PSDN (X.121) addresses in E.164. It says the exact codes are a "national matter", i.e., they differ between networks 🌍 A host connected to the ISDN may be able to use both the X25 and ISDN addresses, with the local prefix added ✨
3.3. The Route Through RR 🦋
The Route Through RR is the one with mnemonic RT and type code 21 (decimal) 💅
The RT resource record provides a route-through binding for hosts that don't have their own direct wide area network addresses. It's used in much the same way as the MX RR 💌
RT has the following format:
<owner> <ttl> <class> RT <preference> <intermediate-host>Both RDATA fields are required in all RT RRs.
The first field, <preference>, is a 16 bit integer that represents the preference of the route. Smaller numbers mean more preferred routes 🏆
<intermediate-host> is the domain name of a host that will serve as an intermediate for reaching the host specified by <owner>. The DNS RRs associated with <intermediate-host> are expected to include at least one A, X25, or ISDN record 🌉
The format of the RT RR is class insensitive. RT records cause type X25, ISDN, and A additional section processing for <intermediate-host> 🧩
For example:
sh.prime.com. IN RT 2 Relay.Prime.COM.
IN RT 10 NET.Prime.COM.
*.prime.com. IN RT 90 Relay.Prime.COM.When a host is looking up DNS records to route a datagram, it first looks for RT records for the destination host. Those point to hosts with address records (A, X25, ISDN) that are compatible with the wide area networks available to the host 🔍 If the host is itself in the set of RT records, it throws out any RTs with preferences higher than or equal to its own. If there are no (remaining) RTs, it can then use the address records of the destination itself 🫶
Wild-card RTs are used exactly as wild-card MXs are. RT's do not "chain"; that is, it is not valid to use the RT RRs found for a host referred to by an RT. Don't do it, bestie 🙅♀️💀
The concrete encoding is identical to the MX RR 💖
REFERENCES and BIBLIOGRAPHY 📚
[1] Stahl, M., "Domain Administrators Guide", RFC 1032, Network Information Center, SRI International, November 1987.
[2] Lottor, M., "Domain Administrators Operations Guide", RFC 1033, Network Information Center, SRI International, November, 1987.
[3] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, USC/Information Sciences Institute, November 1987.
[4] Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, USC/Information Sciences Institute, November 1987.
[5] Spector A., and M. Kazar, "Uniting File Systems", UNIX Review, 7(3), pp. 61-69, March 1989.
[6] Zahn, et al., "Network Computing Architecture", Prentice-Hall, 1989.
[7] International Telegraph and Telephone Consultative Committee, "Numbering Plan for the International Telephone Service", CCITT Recommendations E.163., IXth Plenary Assembly, Melbourne, 1988, Fascicle II.2 ("Blue Book").
[8] International Telegraph and Telephone Consultative Committee, "Numbering Plan for the ISDN Era", CCITT Recommendations E.164., IXth Plenary Assembly, Melbourne, 1988, Fascicle II.2 ("Blue Book").
[9] International Telegraph and Telephone Consultative Committee. "Numbering Plan Interworking in the ISDN Era", CCITT Recommendations E.166., IXth Plenary Assembly, Melbourne, 1988, Fascicle II.2 ("Blue Book").
[10] International Telegraph and Telephone Consultative Committee, "International Numbering Plan for the Public Data Networks", CCITT Recommendations X.121., IXth Plenary Assembly, Melbourne, 1988, Fascicle VIII.3 ("Blue Book"); provisional, Geneva, 1978; amended, Geneva, 1980, Malaga-Torremolinos, 1984 and Melborne, 1988.
[11] Korb, J., "Standard for the Transmission of IP datagrams Over Public Data Networks", RFC 877, Purdue University, September 1983.
[12] Ullmann, R., "SMTP on X.25", RFC 1090, Prime Computer, February 1989.
[13] Ullmann, R., "TP/IX: The Next Internet", Prime Computer (unpublished), July 1990.
[14] Mockapetris, P., "DNS Encoding of Network Names and Other Types", RFC 1101, USC/Information Sciences Institute, April 1989.
Security Considerations 🔒
🚨 Security issues are not addressed in this memo. 🚨
Authors' Addresses 🎀
Craig F. Everhart
Transarc Corporation
The Gulf Tower
707 Grant Street
Pittsburgh, PA 15219
Phone: +1 412 338 4467
EMail: Craig_Everhart@transarc.com
Louis A. Mamakos
Network Infrastructure Group
Computer Science Center
University of Maryland
College Park, MD 20742-2411
Phone: +1-301-405-7836
Email: louie@Sayshell.UMD.EDU
Robert Ullmann 10-30
Prime Computer, Inc.
500 Old Connecticut Path
Framingham, MA 01701
Phone: +1 508 620 2800 ext 1736
Email: Ariel@Relay.Prime.COM
Paul Mockapetris
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: 213-822-1511
EMail: pvm@isi.edu📦 where this page comes from
- ietf: rfc1183 1990-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms