RFC 830
Distributed system for Internet name service
RFC 830 🎀 A Distributed System for Internet Name Service
Part 1 of 3 ✨
Okay bestie, this one is from October 1982 and it's by Zaw-Sing Su at SRI International (333 Ravenswood Avenue, Menlo Park, California 94025, phone (415) 859-4576). It's from the Network Working Group, and it's RFC 830. 🦋 It doesn't list anything it obsoletes or updates, so it's standing on its own. 💅
It's a proposal for a distributed name service for the DARPA Internet, and the whole point is to get people talking so a general consensus can form and eventually standards can happen. 💜
📦 Status box: This RFC proposes a distributed name service for DARPA Internet. Its purpose is to focus discussion on the subject. It is hoped that a general consensus will emerge leading eventually to the adoption of standards.
1. Introduction ✨
Okay so, for years the ARPANET naming convention <user>@<host> has been doing its job for mail. 📬 The <host> part also got used for other stuff like file transfer (FTP) and terminal access (Telnet). 🍓
Then networks started connecting to each other, and that naming convention needed a glow-up so it could handle internetworking. 🌈 The Internet Naming Convention [1] is that glow-up. It describes a hierarchical naming structure for Internet apps like SMTP for email, and FTP and Telnet for file transfer and terminal access. It's a core part of generalizing the network so it can handle internetworking. 👑
Making the Internet Naming Convention actually work means you need both naming authority and a name service. 🧚 In this doc, the author proposes an architecture for a distributed System for Internet Name Service (SINS). This assumes you already know [1], since that's where the Internet Naming Convention is explained. 📖
So what does Internet Name Service actually do? 🤔 It handles name resolution and resource negotiation so a source and destination application process can set up direct communication. The source process already knows the destination name. To connect, the source asks for name service. SINS turns the destination name into a network address and negotiates network resources. Once that's done successfully, the source hands the destination address to the transport service, and now they can talk directly. 🫶
2. Overview 🌸
2.1. System Organization
SINS is a distributed name service system, and it logically has two parts: the domain name service and the application interface (Figure 1). 💖 The domain name service is an application-independent network service that resolves domain names. Lots of domain name servers (DNSs) cooperate to make that happen. Every domain has an associated DNS.* The reader is referred to [2] for how a domain name server is specified. As noted in [1], a domain is administrative, not necessarily topological. It's represented on the network by its DNS, and resolving a domain name gives you the address of that DNS. 🦋
Application Application
Process Process
| |
SINS | |
-------|---------------------------------------------|----- Application
| AIP AIP | Interface
| | | | . . . . . . .
| DNS - - - DNS - - - DNS - - . . . - - DNS | Domain Name
----------------------------------------------------------- Service
Figure 1 Separation of Application InterfaceThe application interface gives you resolution beyond the destination domain, plus negotiation to make sure resources are available and compatible. 🔥 People sometimes call this negotiation the "what-can-you-do-for-me" negotiation, and it's giving very main character energy. ✨ The application interface keeps the domain name service separate from any specific application, so lots of apps can share the same domain name service. 🎀
The application interface is a set of application interface processes (AIPs), one for each endpoint domain. 🧚 For efficiency, the AIP is assumed to be combined with its associated DNS, which forms an endpoint DNS (Figure 2). 💅
Application Application
Process Process
| |
SINS | |
-------|---------------------------------------------|-------
| Endpoint Endpoint |
| DNS - - - DNS - - - DNS - - . . . - - DNS |
| |
-------------------------------------------------------------
Figure 2 Distribution of Name Service Components Among Domains* For reasons such as reliability, more than one DNS per domain may be required. 🛡️ They may be cooperating DNSs or identical for redundancy. In either case, without loss of generality, we may logically view the association as one DNS per domain. 🌈
2.2. Domain Resolution
For name service, the source application process hands its local AIP the destination name and the application service it wants. 💜 For most apps, the service the source requests is the same as the service it offers. 🍓 The destination name is assumed to be fully qualified, and it looks like this:
<local name>@<domain>.<domain>. ... .<domain>The domains in that concatenation are hierarchically related [1]. Reading left to right, the simple names go from the most specific domain to the most general one. 🌸 When you concatenate two domains like this:
... .<domain A>.<domain B>. ...domain A on the left is an immediate member (the first-generation descendant) of domain B on the right. ✨ The right-most simple name is a top-level domain, and it's a first-generation descendant of the naming universe. 👑
For domain resolution, the AIP asks the domain name service. It hands the co-located DNS the fully qualified domain specification:
<domain>.<domain>. ... .<domain>The DNSs in a resolution resolve that concatenation from the right. 🧚 The source endpoint DNS resolves the right-most simple name and acts as a hub that polls the other DNSs. It turns the right-most simple name into an address for the DNS of that top-level domain, then polls that DNS asking for further resolution. When a DNS gets polled, it resolves the next right-most simple domain name. 🔥
When a resolution succeeds, an intermediate DNS has a choice: it can return the resulting address, or it can forward the request to the next DNS so resolution keeps going. 🦋 Here's the important bit: when an intermediate DNS gets a reply from the next DNS, it must respond to the request it originally received. 💖 And to keep the domain name service protocol simple, an intermediate DNS is not allowed to act as a hub for further polling. 🙈
2.3. Application Interface
Knowing the destination endpoint domain usually isn't enough for the source application process to set up direct communication with the destination application process. 💅 You might need more addressing to get there. Addressing beyond the destination endpoint domain may be necessary when the application process's address can't be derived from the endpoint domain's address. 🎀 To make that derivation possible, you might need a permanent binding and a universal binding convention, like the TCP port number assignments. 🌈
Addressing alone is often not enough, so negotiating resource availability and compatibility is usually needed too. 🫶 The application interface gives you a "what-can-you-do-for-me" negotiation between the source and destination endpoint domains. The mechanisms in this design cover whether the transport service is available and compatible (for example TCP or UDP) and whether the application service is available and compatible (for example SMTP for mail transport). 🧚 Having this negotiation available can let binding happen dynamically and let the system design vary. ✨
The application interface also offers one integrated service for all those various "what-can-you-do-for-me" negotiation capabilities. 💜
2.4. Example
Let's say a request is made at ISID for remote file transfer using NIFTP to SRI-TSC. 📁 The domain name for ISID is D.ISI.USC.ARPA,* and the domain name for SRI-TSC is TSC.SRI.ARPA. The hierarchical relationship between those two domains is shown in Figure 3 below. 🌸 The NIFTP process (an application process) at ISID forwards the domain name TSC.SRI.ARPA to the local AIP in domain D for name service. The AIP then forwards the fully qualified domain name, TSC.SRI.ARPA, to its co-located DNS for domain resolution. 💖
ARPA is the right-most simple name, and it's assumed to designate a top-level domain. 👑 The DNS of D recognizes that simple name and resolves it into the address of the ARPA domain DNS. Then it forwards the request to that DNS, with a pointer to the next domain, SRI. 🦋 The ARPA DNS recognizes SRI as one of its subdomains, and it resolves the address of that subdomain's DNS. At this point it gets to choose: it can return this address to the source endpoint DNS, or it can forward the request to the DNS of SRI. 🔥
naming
universe
/ \
--- ARPA (DNS)
/ |
/ SRI (DNS)
/ | \
USC (DNS) TSC (DNS/AIP)
| |
| [TCP/FTP/RFT]
ISI (DNS)
|
D (DNS/AIP)
/ \
[TCP/NIFTP/RFT] [TCP/FTP/RFT]
|
user* Domain names used in the examples are for illustration purposes only. The assignment of domain names is beyond the scope of this writeup. 🙈
If the ARPA DNS returns the address, the source endpoint DNS at D keeps polling, forwarding the request to the SRI DNS. 🧚 When the DNS of SRI sees that TSC is the last domain in the concatenation, it resolves the address for the DNS at TSC and returns it to the source DNS at domain D. 💅 Once the source DNS gets a successful domain resolution, it returns the address it got to its associated AIP. ✨
Since the destination AIP is co-located at that address, the source AIP can forward a request with the service designation TCP/NIFTP/RFT for "what-can-you-do-for-me" negotiation. 🫶 The destination AIP realizes that at TSC there's no NIFTP, only FTP for remote file transfer, so it responds accordingly. 🌈 ISID also offers FTP service, so the "what-can-you-do-for-me" negotiation can wrap up successfully, and the user's file transfer request can be satisfied. 🎀🌸
I'll see you in part 2 for section 3, System Components! 💜🦋
3.1. Component Processes 🎀
okay so SINS is built from two basic distributed bits: the endpoint DNS and the intermediate DNS 💅. Every endpoint domain gets its own endpoint DNS, and an intermediate DNS shows up for any domain that doesn't have an application process attached.
The intermediate DNS is honestly kinda simple ✨. It can resolve simple names of first-generation subdomains into the addresses of their DNS, and it talks to other DNSs for domain resolution.
An endpoint DNS is made of an AIP and a source DNS 🦋. The source DNS runs the polling mechanism, acting as a hub that talks to other DNSs for polling. It can also resolve top-level domains, and it answers domain resolution requests from its local AIP (see Section 4.2.3).
The AIP is the brains of the "what-can-you-do-for-me" negotiation 🧠. A communication module handles the negotiation exchanges between the source and destination AIPs (see Section 4.2.2). Since the AIP sits between the application processes and the local DNS, it must also be able to communicate with both the DNS and the application processes 🫶.
3.2. Databases for Name Resolution 📚
Every resolution module has its own database. The database for an endpoint domain holds name-to-address correspondences for the top-level domains, which are the first-generation descendants of the naming universe 👑. This is what lets the endpoint DNS resolve the right-most simple name of a fully-qualified domain specification.
The database for an intermediate domain holds name-to-address correspondences for the first-generation subdomains of that domain. So the databases across intermediate DNSs don't overlap, and updates stay local 🌸.
We also noticed that with SINS, there's no need to standardize the database format 🙌.
3.3. Caching 💾
The component processes and resolution databases together make up the basic System for Internet Name Service. The distributed components are linked by the domain hierarchy 🌳. All the databases for endpoint domains are identical. Since they only hold top-level domain correspondences, the endpoint database should be pretty small. And because intermediate databases don't overlap, local updates are easy.
BUT, if the Internet name service had to be called for every single transaction, communications would be super inefficient 😭. The standard fix for that is caching.
Caching means reusing previous resolution results 🔁. The results get stored for future reference so connections can be set up faster. We do not make caching a standard feature of SINS. We do assume caching gets used for efficient operations, though, at each implementor's discretion 💜.
4. INTER-COMPONENT COMMUNICATIONS (THE INTERNET NAME SERVICE PROTOCOLS) 💌
In this section we give a format specification for the exchanges between component pairs. For co-located components, communication happens between processes, so the exact format matters less. For inter-host communication, this format defines a name service protocol 🖥️.
The component pairs we care about are application process/AIP, AIP/DNS, and AIP/AIP. They communicate using request/response commands. All three pairs share one single command structure, though a given pair may only use a subset of the commands. That uniformity means minimal processing and maximum code sharing when implementing 🫶.
4.1. Command Structure 🧱
The basic command structure starts with two octets, one for the command type and one for the number of items in the command. Those are followed by the indicated number of items. Each item starts with its type in its first octet, then a one-octet content length, then the item content. The required presence or absence and order of items for each component pair are specified in this section.
Command Type Number of Items
Item Indicator Content Length Item Content
.
.Command Type
This type is a binary number that says whether the command is a request, an affirmative response, or some other kind of response. Check Appendix A for the command types and their codes 🔢. The type also determines the presence or absence and the order of the items that follow.
Number of Items
This number is written in binary and tells you how many items follow. Because a command can get multiple responses, this number may vary for a particular command.
Item Indicator
This indicator defines the item type. The possible types are service, name, address, and comment. The item type tells you what its content looks like.
Content Length
This length is written in binary and tells you how many octets of content follow. The largest value is 255, so that's the maximum content length. The total length of the command can also cap it, though (see Section 4.3) 📏.
Item Content
The content depends on the item type:
- Service -- Transport protocol/service protocol/service type (ASCII). (See Appendix A for standard identifiers for service specifications.)
- Name -- Whole or partial name string according to Internet Naming Convention [1] (ASCII).
- Address -- The address is presented in binary form. In this writeup, double quotes, " ", are used around decimal values separated by a space to represent the octets of the binary form. Parsing the address is implied by the specified transport protocol. For TCP, the first four octets give the 32-bit IP address, the 5th octet is the IP-specific protocol number, and the 6th is the TCP or UDP port number for the application service 🔌.
- Comment -- This item is mostly optional. Its presence may let an intermediate server pass a comment to the end user. Error comments explaining a resolution failure are one example of its use 💬.
4.2. Command Specification 🎯
In this section we define the name service commands for each communication pair.
4.2.1. Application Process/AIP Communication 📨
From the name service point of view, the AIP doesn't need to communicate with an application process at the destination. So here we only talk about communications at the originating domain.
An application process starts a dialogue by sending a name service request to its local AIP. The request includes the application service it wants and a destination name to resolve.
REQUEST
Command Type Number of Items
Service Indicator Length Transport Protocol/Service/Service Type
Name Indicator Name Length Name StringExamples:
1 2
3 13 TCP/SMTP/mail
1 21 Postel@F.ISI.USC.ARPA
1 2
3 13 TCP/NIFTP/RFT
1 12 TSC.SRI.ARPAThe first example is a resolution request for the name "Postel@F.ISI.USC.ARPA", which is 21 octets long. The requested application service is TCP/SMTP/mail. The second example is a resolution request for the NIFTP application service at TSC.SRI.ARPA 🧐.
AFFIRMATIVE RESPONSE
Command Type Number of Items
Service Indicator Length Transport Protocol/Service/Service Type
Name Indicator Name Length Name String
Address Indicator Address Length AddressExamples:
2 3
3 13 TCP/SMTP/mail
1 21 Postel@F.ISI.USC.ARPA
2 6 "10 2 0 52 6 25"
2 4
3 13 TCP/NIFTP/RFT
1 12 TSC.SRI.ARPA
2 6 "10 3 0 2 6 47"
2 6 "39 0 0 5 6 47"An affirmative response means the destination offers the requested service. Parsing the address depends on the transport protocol. In the first example the transport protocol is TCP, so the address has three fields: the internet address ("10 2 0 52"), the protocol number ("6" for TCP [3]), and the port number ("25" for SMTP [3]). The multiple-address response in the second example shows that TSC is multi-homed on both ARPANET (net 10) and SRINET (net 39) 🌐. A multiple-resolution response is preferred, because it gives the source a choice ✨.
NEGATIVE RESPONSE
Command Type Number of Items
Service Indicator Length Transport Protocol/Service/Service Type
Name Indicator Name Length Name String
Name Indicator Name Length Partial Name String
[Comment Indicator Comment Length Comment]This means there was trouble resolving the name 🙈. Sent back with it is the left-most portion of the specified name, up to where the difficulty came up. An optional comment item may be included too.
Examples:
3 4
3 13 TCP/SMTP/mail
1 16 Postel@F.ISI.USC
1 16 Postel@F.ISI.USC
9 18 Resolution Failure
3 4
3 13 TCP/NIFTP/RFT
1 13 TSC..SRI.ARPA
1 5 TSC..
9 17 Syntactic AnomalyIn the first example, resolution failed because USC isn't a top-level domain 💀. In the second example, the syntax error from the adjacent dots is pretty obvious 🙃.
INCOMPATIBLE SERVICE
This response means there's no compatible application and/or transport service available at the destination. For example, the application service requested might be SMTP, while only FTP-mail is available at the destination 📭. The response returns the corresponding available service, if there is one, along with its address. If there's no service at all for that service type, an empty string is returned for the service specification.
Command Type Number of Items
Service Indicator Length Transport Protocol/Service/Service Type
Name Indicator Name Length Name String
Service Indicator Length Transport Protocol/Service/Service Type
[Address Indicator Address Length Address]Examples:
9 3
3 14 TCP/NIFTP/mail
1 21 Postel@F.ISI.USC.ARPA
3 0
9 5
3 13 TCP/NIFTP/RFT
1 12 TSC.SRI.ARPA
3 11 TCP/FTP/RFT
2 6 "10 3 0 2 6 21"
2 6 "39 0 0 5 6 21"4.2.2. AIP/AIP Communication 🤝
Communication between the AIPs is where the "what-can-you-do-for-me" negotiation happens 💕. The examples in this section match the ones in Section 4.2.1.
REQUEST
Command Type Number of Items
Service Indicator Length Transport Protocol/Service/Service TypeExamples:
1 1
3 13 TCP/SMTP/mail
1 1
3 13 TCP/NIFTP/RFTAFFIRMATIVE RESPONSE
Command Type Number of Items
Service Indicator Length Transport Protocol/Service/Service Type
Address Indicator Address Length AddressExamples:
2 2
3 13 TCP/SMTP/mail
2 6 "10 2 0 52 6 25"
2 3
3 14 TCP/NIFTP/RFT
2 6 "10 3 0 2 6 47"
2 6 "39 0 0 5 6 47"An affirmative response means the destination offers the same service as the originator 🙌. A multi-resolution response is possible too. Parsing the address is implied by the transport protocol. In the second example the transport protocol is TCP, so the address has three fields: the internet address (10 2 0 52), the protocol number (6 for TCP), and the port number (25 for SMTP) 🎉. Whatever address or addresses come back are passed along to the originating application process 💌.
INCOMPATIBLE SERVICE 🙈 okay so this one is the "sorry bestie, nope" response. It says there's no compatible application and/or transport service available for the destination. 💀
Command Type Number of Items
Service Indicator Length Transport Protocol/Service/Service Type
Service Indicator Length Transport Protocol/Service/Service Type
Address Indicator Address Length AddressHere's the tea ☕: SMTP might be the app service you asked for, but the destination only has NIFTP-mail running. So the response sends back the available service of that type 🎀. If there's nothing available for that service type at all, you get an empty text string back. Lowkey harsh, but at least it's clear 🥲
Examples:
9 2
3 14 TCP/NIFTP/mail
3 0
9 4
3 13 TCP/NIFTP/RFT
3 11 TCP/FTP/RFT
2 6 "10 3 0 2 6 21"
2 6 "39 0 0 5 6 21"In the first example, the destination doesn't offer any kind of mail service at all 📭. The second one is the more iconic case: no NIFTP, but FTP is available for remote file transfer at the destination 📁✨
4.2.3 AIP/DNS Communication
Okay, so the source AIP hands its associated DNS a fully qualified domain specification and asks it to resolve it 🔍. The result we're hoping for is the network address of the destination endpoint DNS 🦋. We assume there's no need for the DNS and AIP at the destination to chat with each other 🤷♀️
REQUEST 💌
Command Type Number of Items
Name Indicator Name Length Name StringExamples:
1 1
1 14 F.ISI.USC.ARPA
1 1
1 12 TSC.SRI.ARPAAFFIRMATIVE RESPONSE 💖
Command Type Number of Items
Name Indicator Name Length Name String
Service Indicator Service Length Transport Protocol
Address Indicator Address Length AddressExamples:
2 3
1 14 F.ISI.USC.ARPA
3 3 UDP
2 6 "10 2 0 52 17 42"
2 4
1 7 TSC.SRI.ARPA
3 3 UDP
2 6 "10 3 0 2 17 42"
2 6 "39 0 0 5 17 42"An affirmative response is the good news 🎉 It returns an address of the destination endpoint DNS, and that returned address is the one belonging to the destination DNS 💅. The destination transport service needs to be indicated too, because that's what guides the parsing of the destination address. Without it, the address is just vibes 🫠
NEGATIVE RESPONSE 💀
Command Type Number of Items
Name Indicator Name Length Name String
Name Indicator Name Length Partial Name String
[Comment Indicator Comment Length Comment]This is the response for when the domain name service can't resolve the destination domain name 😭. It could be caused by an unknown simple name, which might happen because of something like a misspelling 🙈. Sent back with this command is the left-most portion of the name that contains the cause of the failure, so you can see exactly where it went wrong 🔎
Example:
1 3
1 9 F.ISI.USC
1 9 F.ISI.USC
9 18 Resolution Failure4.2.4 DNS/DNS Communication
The domain name service is an application independent network service 🌐. Its whole job is resolving domain names 💫. If you want the full specification of this service, go read [2] 📖
4.3 Transport Protocol
For generality, this spec is intentionally transport protocol independent 🦋. The implications for using TCP and UDP get their own special attention though 👀
Typically, for distributed name service, a server A makes a request to a server B, and server B may need to contact other servers in turn to finish a resolution 🔄. TCP is a connection-oriented protocol 🤝. It offers reliable transport, but it also adds a certain amount of overhead for connection establishment and maintenance 😤. For most cases, the use of TCP is not recommended 🙅♀️
UDP is a datagram service with a transport capacity per datagram in excess of 500 octets 📦. That capacity should suffice for most conceivable commands in this specification ✨. The catch? It does impose a limit on the total length of a command 🥺. To boost reliability, the request is incorporated as part of every response command 💜
5 NCP TO TCP TRANSITION
The Internet Naming Convention, "<user>@<domain>. ... . <domain>" [1], is a generalization of "<user>@<host>", the ARPANET Naming Convention 🌸. It's a generalization in the sense that the ARPANET Naming Convention can be considered a partially qualified form of the subset "<user>@<host>.ARPANET". (We assume here that ARPANET is a top-level domain name 🧚.)
For the transition from NCP to TCP, we may initially treat each host name entry in the current host table as a subdomain of the top-level domain ARPANET 🏠. So, initially, there would be a very flat domain structure 🥞. This structure can be gradually changed after the transition, toward a hierarchical structure, as more and more domains and subdomains get defined and name servers get installed 🌳. During this change, the host table would be gradually converted into distributed domain tables (databases) 🗂️. For the newly created domain tables, no standard format would be required 🙌. Each individual domain table may have its own format, suited to the design of its associated domain name server 💅
REFERENCES
[1] Su, Z. and J. Postel, "The Domain Naming Convention for Internet User Applications," RFC 819, SRI International (August 1982).
[2] Postel, J., "Domains Name Server," RFC XXX, USC/Information Sciences Institute (to appear).
[3] Postel, J., "Assigned Numbers," RFC 790, USC/Information Sciences Institute (September 1981).
Appendix A CONVENTION ASSIGNMENTS 🎀
Command Types
Request 1
Affirmative Response 2
Negative Response 3
Imcompatible Service 9INDICATORS
Name Indicator 1
Address Indicator 2
Service Indicator 3
Comment Indicator 9TRANSPORT PROTOCOLS
TRANSPORT PROTOCOLS: TCP, UDP, NCP 🚀
SERVICES
Service Protocols Service Type
MTP mail
SMTP mail
FTP (FTP mail) mail
NIFTP (NIFTP mail) mail
MMDF mail
FTP RFT (remote file transfer)
Telnet RTA (remote terminal access)📦 where this page comes from
- ietf: rfc830 1982-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms