RFC 1386

The US Domain

๐Ÿ“… published December 1992, from ietf

RFC 1386: The US Domain ๐ŸŽ€

  • Network Working Group ๐Ÿ’œ Request for Comments: 1386 โœจ
  • Authors: A. Cooper and J. Postel ๐Ÿซถ
  • Date: December 1992 ๐Ÿ“…
  • Status: Informational. The memo itself says it provides information for the Internet community and does not specify an Internet standard, so it's FYI energy, not a rulebook ๐Ÿ“
  • Obsoletes / Updates: the title block doesn't list any RFCs it obsoletes or updates ๐Ÿงš

Status of this Memo ๐Ÿ’…

Okay so this memo is just giving info to the Internet community ๐Ÿ“ฃ It does not specify an Internet standard, and distribution is unlimited, so share away ๐Ÿฆ‹

Table of Contents ๐ŸŒธ

   1.  Introduction ................................................  2
       1.1  The Internet Domain Name System.........................  2
       1.2  Top Level Domains.......................................  3
       1.3  The US Domain ..........................................  4
   2.  Naming Structure ............................................  4
       2.1  State Codes ............................................  5
       2.2  City Codes or Locality Names............................  5
       2.3  Examples of Names.......................................  5
   3.  Registration ................................................  8
       3.1  Requirements ...........................................  8
       3.2  Direct Entries .........................................  9
       3.2.1   UUCP Hosts ..........................................  9
       3.2.2   Non-IP Hosts ........................................ 10
       3.3  Delegated Subdomains ................................... 12
       3.3.1   Schools ............................................. 12
       3.3.2   State Agencies ...................................... 14
       3.3.3   Federal Agencies .................................... 14
       3.3.4   Delegation Requirement............................... 14
       3.3.5   Delegation Procedures ............................... 15
       3.3.6   Subdomain Contacts................................... 18
   4.  Database Information......................................... 19
       4.1  Name Servers ........................................... 19
       4.2  Zone files ............................................. 20
       4.3  Resource Records ....................................... 21
       4.3.1   A Records ........................................... 22
       4.3.2   CNAME Records ....................................... 22
       4.3.3   MX Records .......................................... 22
       4.3.4   HINFO Records ....................................... 23
       4.3.5   PTR Records ......................................... 23
       4.4  Wildcards .............................................. 23
   5.  References .................................................. 24
   6.  Security Considerations ..................................... 25
   7.  Author's Address ............................................ 25
   Appendix-I:  US Domain Names BNF................................. 26
   Appendix-II: US Domain Questionnaire for Host Entry.............. 28

1. Introduction โœจ

1.1. The Internet Domain Name System ๐ŸŒ

Okay bestie, so the Domain Name System (DNS) is the thing that translates host names into addresses ๐Ÿงš Like, you type venera.isi.edu and it gives you back the IP address 128.9.0.32. It's literally how the Internet knows where to go ๐Ÿ’–

The DNS is a set of protocols and databases. The protocols define the syntax and semantics for a query language so you can ask questions about info stored under DNS-style names ๐Ÿ”ฅ The databases are distributed and replicated, so nobody's relying on one big central server, and every part of the database is provided by at least two servers ๐Ÿ‘‘

The 32-bit IP addresses are a separate thing, assigned by the Network Information Center (Hostmaster@NIC.DDN.MIL) ๐Ÿ“ฌ

DNS also lets you register DNS-style names for hosts you can only reach by email through gateways or mail relays ๐Ÿ’Œ The records for that kind of name point at an Internet host (one with an IP address) that acts as a mail forwarder for the registered host. For example, bah.rochester.ny.us is registered with a pointer to the mail relay relay1.uu.net, and that pointer is called an MX record ๐Ÿซถ

This gives email users one uniform mail addressing syntax, so they don't have to think about the network boundaries underneath ๐ŸŽ€

So why did DNS even happen? Growth ๐Ÿ“ˆ The NIC used to keep all the host name to address mappings in one single file, HOSTS.TXT, and every host on the Internet had to FTP it. The network population was changing: the timeshared hosts of the original ARPANET were getting replaced by local networks of workstations ๐Ÿ’ป Local orgs were managing their own names and addresses but had to wait for the NIC to change HOSTS.TXT before anyone else could see it. Orgs also wanted some local structure on the name space ๐Ÿ  Apps were getting more sophisticated and needed general purpose name service. So the idea was a hierarchical name space, roughly matching organizational structure, with names using "." to mark the boundaries between levels ๐Ÿชœ They built a distributed database with generalized resources to make it work โœจ

The domain system gives you standard formats for resource data, standard ways to query the database, and standard methods for name servers to refresh their local data from other name servers ๐Ÿ’…

1.2. Top-Level Domains ๐ŸŒ

The top-level domains in DNS are EDU, COM, GOV, MIL, ORG, INT, and NET, plus all the 2-letter country codes from the ISO-3166 country list ๐ŸŒ

The original plan was that any educational institution anywhere could register under EDU, but in practice only US ones have (with a few exceptions), and the same goes for COM (commercial) ๐Ÿ™ˆ Everywhere else just uses its 2-letter country code, often with a subdivision. For example, in Korea (KR) the second-level names are AC (academic community), CO (commercial), GO (government), and RE (research). Each country can run its own domain however it wants, and many have ๐ŸŒธ

There are no plans to put all of the organizational domains (.EDU, .GOV, .COM, etc.) under .US either ๐Ÿ™…

Some states are registered in the .GOV domain: 11 by two-letter code and 3 by full name ๐Ÿ—บ๏ธ

           ca.gov          la.gov          ohio.gov        va.gov
           co.gov          md.gov          or.gov          wa.gov
           hawaii.gov      nc.gov          sc.gov
           ia.gov          ny.gov          texas.gov

Other names sometimes show up as top-level domains too. People have made up DNS-style names without coordinating or registering with DNS management ๐Ÿ˜ฌ Common ones are .BITNET, .UUCP, and two-letter continent codes like .NA for North America (which clashes with the official Internet code for Namibia, oops ๐Ÿ’€).

For example, KA7EEJ.CO.USA.NA is used in the amateur radio network ๐Ÿ“ป These addresses aren't supposed to show up on the Internet, but they occasionally do. The amateur radio folks made their own naming scheme, and it sometimes interferes with real Internet addresses ๐Ÿ™ƒ

1.3. The US Domain ๐Ÿ‡บ๐Ÿ‡ธ

The US Domain is an official top-level domain in the DNS of the Internet community, and it's registered with the NIC. The domain administrators are Jon Postel and Ann Westine Cooper at the Information Sciences Institute of the University of Southern California (USC-ISI) ๐Ÿ‘‘

US is the ISO-3166 2-letter country code for the United States, so the US Domain is set up as a top-level domain and registered with the NIC the same way other country domains are ๐Ÿ‡บ๐Ÿ‡ธ

Because organizations in the United States mostly registered under EDU and COM, the US domain got little use at first ๐Ÿ˜ด

Back in the day, computers registered in the US Domain were mainly owned by small companies or people with computers at home ๐Ÿก But it's grown a lot. It now registers hosts from federal government agencies, state government agencies, K12 schools, community colleges, private schools, libraries, county agencies, and city utilities, to name a few ๐Ÿซ๐Ÿ›๏ธ

Administration used to be handled solely by the Domain Registrar. Because the number of hosts has exploded, though, administration of subdomains is being delegated to others ๐Ÿค

Any computer in the United States may be registered in the US Domain ๐Ÿฆ‹

2. NAMING STRUCTURE ๐Ÿ’…

okay so the US Domain hierarchy is based on political geography ๐Ÿ—บ๏ธ aka it goes by where you actually live. the namespace under .US is the state namespace, then the city namespace, then organization or computer name, and so on ๐Ÿฆ‹

for example:

          SPK.WA.US
         VANC.WA.US

and yes, there is obviously no problem with running out of names ๐Ÿ™„

the things that get named are individual computers ๐Ÿ’ป

if you register in one city and then move, the database can be updated with a new name in your new city, and a pointer can be set up from your old name to your new name. this type of pointer is called a CNAME record ๐ŸŽ€

the use of un-registered names is not effective and causes problems for other users. making up your own name and using it without registering is not a good idea ๐Ÿ™…


2.1. State Codes ๐Ÿ‡บ๐Ÿ‡ธ

the state codes are the two letter US Postal abbreviations ๐Ÿ“ฎ

2.2. City Codes or Locality Names ๐Ÿ™๏ธ

cities can be named (designated) by their full name, spelled out with hyphens replacing spaces (e.g., Los-Angeles or New-York), or by a city code. the first choice is the full city name. the second choice is a city code from Western Union's "City Mnemonics" list. the third choice is a code for your city that you pick yourself as the applicant. however, it is very desirable that all users in the same city use the same designator for the city ๐Ÿซถ

abbreviated city names are a good idea, especially when the city name is long, because there is already so much to type ๐Ÿ˜ญ one of the problems is that the city codes in the Western Union City Mnemonics list are sometimes not very good abbreviations. users tend to prefer abbreviations that are already commonly used in their region, like SF for San Francisco or MPK for Menlo Park โœจ

exceptions have been made to the abbreviations, even though this causes extra work to keep track of them. it's one abbreviation for one city. applicants are told which codes are currently in use. but if a city code isn't used yet and they would rather use a different code that's more common among the locals, then the new code is allowed. once it's registered, though, everyone else who registers in that city will have to use that code or spell out the full city name ๐Ÿ’–

some applicants have tried to get a copy of the Western Union City Mnemonics code list, but it is no longer available from Western Union. however, we do have a copy, it just isn't online. if you're requesting an abbreviated city code, let us know and we will gladly look it up for you ๐Ÿงš

2.3. Examples of Names ๐Ÿ“

for small entities like individuals or small businesses, there is usually no problem with picking a locality-based name ๐ŸŒธ

For example: Zuckys.Santa-Monica.CA.US

for large entities like big corporations with multiple facilities in several cities or states, this can seem like an unreasonable constraint, especially when you compare it with just registering directly in the .COM domain ๐Ÿ™ƒ still, a company does have a headquarters office in a particular locality, so it could register with that name ๐Ÿข

For example: IBM.Armonk.NY.US

             EXAMPLES OF THE NAMING STRUCTURE IN THE US DOMAIN

   PRIVATE (business or individual)
   ================================

   Camp-Curry.Yosemite.CA.US       <====  a business
   IBM.Armonk.NY.US                <====  a business
   Dogwood.atl.GA.US               <====  a business
   Geo-Petrellis.Culver-City.CA.US <====  a restaurant
   Zuckys-Santa-Monica.CA.US       <====  a restaurant
   Joe-Josts.Long-Beach.CA.US      <====  a bar
   Holodek.Santa-Cruz.CA.US        <====  a personal computer

   FEDERAL
   =======

   Senate.FED.US           <====  US Senate
   DOD.FED.US              <====  US Defense Dept.
   DOT.FED.US              <====  US Transportation Dept.
   USPS.FED.US             <====  US Postal Service
   VA.FED.US               <====  US Veterans Administration
   IRS.FED.US              <====  US Internal Revenue Service
   Yosemite.NPS.Interior.FED.US    <====  a federal agency

   STATE
   =====

   Senate.STATE.MN.US      <====  state Senate
   House.STATE.MN.US       <====  state House of Reps
   MDH.STATE.MN.US         <====  state Health Dept.
   HUD.STATE.CA.US         <====  state House and Urban Dev. Dept.
   DOT.STATE.MN.US         <====  state Transportation Dept.
   Caltrans.STATE.CA.US    <====  state Transportation Dept.
   DMV.STATE.CA.US         <====  state Motor Vehicles Dept.
   Culver-City.DMV.STATE.CA.US  <====  a local office of DMV
   CITY | COUNTY
   ==============

   Police.CITY.Culver-City.CA.US       <====  a city department
   Fire-Dept.CITY.Los-Angeles.CA.US    <====  a city department
   Fire-Dept.COUNTY.Los-Angeles.CA.US  <====  a county department

   REGIONAL | DISTRICT | LIBRARY
   =============================

   SCAQMD.DISTRICT.CA.US                     <====  a regional district
   Bunker-Hill-Improvement.DISTRICT.LA.CA.US <====  a local district

   Huntington.LIB.LA.US                    <====  a private library
   Venice.LA-City.LIB.CA.US                <====  a city library
   MDR.LA-County.LIB.CA.US                 <====  a county library

   K12 | CC | STATE UNIV | PRIVATE SCHOOLS
   =======================================

   Los-Angeles.UC.STATE.CA.US      <====  UCLA
   Berkeley.UC.STATE.CA.US         <====  "CAL"
   Irvine.UC.STATE.CA.US           <====  University of Calif. Irvine
   Santa-Cruz.UC.STATE.CA.US       <====  University of Calif. Santa Cruz
   Northridge.CSU.STATE.CA.US      <====  Calif. State. Univ. Northridge
   Fullerton.CSU.STATE.CA.US       <====  Calif. State. Univ. Fullerton
   Sonoma.CSU.STATE.CA.US          <====  Calif. State. Univ. Sonoma

   SMCC.Santa-Monica.CC.CA.US      <====  a public community college
   Trade-Tech.Los-Angeles.CC.CA.US <====  a public community college

   Hamilton.High.LA-Unified.K12.CA.US      <====   a public K12 school
   Sherman-Oaks.Elem.LA-Unified.K12.CA.US  <====   a public K12 school
   John-Muir.Middle.Santa-Monica.K12.CA.US <====   a public K12 school

   St-Monica.High.Santa-Monica.CA.US       <====  a private high school
   St-Monica.Elem.Santa-Monica.CA.US       <====  a private elem. school
   Crossroads-School.Santa-Monica.CA.US    <====  a private school
   Mary-Ellens.Montessori-School.LA.CA.US  <====  a private school
   Leland-Stanford-Jr-Univ.Stanford.CA.US  <====  a private school
   Loyola-Marymount-Univ.Los-Angeles.CA.US <====  a private school

when it's appropriate, subdomains get delegated and partitioned into categories, like this ๐ŸŽ€

                   K12.<state>.US   =   kindegarten thru 12th grade
                    CC.<state>.US   =   community colleges
                   LIB.<state>.US   =   libraries
                 STATE.<state>.US   =   state government agencies
                <org-name>.FED.US   =   federal government agencies

the Appendix-I has the current US Domain Names BNF, but honestly the names under these subdomains can vary depending on what the subdomain administrators decide ๐Ÿคทโ€โ™€๏ธ

some users want names tied to a bigger metro area or region, like the "Bay Area" or "Tri-Cities". the problem is that these names aren't necessarily unique within a state. the best move here is to use the larger metropolitan city in your host name. cities and, in some cases, counties get used ๐Ÿ™๏ธ


3. REGISTRATION ๐ŸŽซ

3.1. Requirements

anyone who wants to register a host in the US Domain gets sent a copy of the US Domain policy and procedure, and needs to fill out a US Domain questionnaire ๐Ÿ“‹

the US Domain template is similar to the NIC Domain template, but it's not the same ๐Ÿ‘€ to request a copy of the US Domain questionnaire, send a message to the US Domain registrar at us-domain@isi.edu ๐Ÿ’Œ

Note: If you are registering a name in a delegated zone (see Section 3.3.6), please register with the contact for that zone.

the key people need electronic mailboxes that actually work ๐Ÿ“ฌ please provide all the information requested in the "Administrator" and "Technical Contact" slots. this person is the point of contact for any administrative and policy questions about the domain ๐Ÿซก

the administrator is usually the person who manages the organization being registered. the technical contact can be the administrator too, or the systems person, or someone who knows the technical details of the Internet well ๐Ÿง  the technical contact should have a valid working e-mail address, because that's necessary in case something goes wrong ๐Ÿšจ

it's important that your "Return-Path" and "From" fields show an Internet style address ๐Ÿ’… UUCP style addresses like "host1!user" will not work. that's fine in the UUCP world, but not on the Internet. if you want people on the Internet to be able to send mail to you, your return path needs to be an Internet style address, such as host1!user@internet.gateway.host or user@internet.gateway.host ๐Ÿ’–

it's also possible to register through one of the Internet service providers that have established working relationships with the US domain administrator ๐ŸŒˆ

if everything checks out, turnaround for registering a host is usually a day or two โšก the nameservers get updated anywhere from 12 to 24 hours later โฐ

there are two ways to be registered in the US Domain: directly, or by delegation ๐Ÿฆ‹

3.2. Direct Entries

direct entry in the database of the US Domain appeals most to individuals and small companies ๐ŸŒธ fill out the application and send it directly to the US Domain administrator. if you're in an area where the zone is delegated to someone else, your request gets forwarded to the zone administrator for your registration ๐Ÿงš

3.2.1. UUCP Hosts

lots of applicants have hosts in the UUCP world ๐Ÿข some are one hop away from their "Internet Forwarder", and some are two or three hops away. this is ok โœจ what matters is getting an Internet host to be your forwarder ๐Ÿซถ if you don't already have an Internet forwarder, there are several businesses that provide this service for a fee, such as UUNET.UU.NET (postmaster@uunet.uu.net), PSI (postmaster@UU2.PSI.COM) and CERFNET (help@cerf.net) ๐Ÿ’ธ sometimes local colleges in your area are already on the Internet and might be willing to act as an Internet Forwarder ๐ŸŽ“ you'd need to work that out with the systems administrator, because we cannot make these arrangements for you ๐Ÿ™ˆ

even though we work with UUCP service providers, the Internet US Domain registration is not affiliated with the registration of UUCP Map entries ๐Ÿ—บ๏ธ the UUCP map entry doesn't give us enough information. if you don't have a copy of the US Domain questionnaire template, send a message to us-domain@isi.edu and request one. see Appendix-II ๐Ÿ“Ž

This is not an appropriate registration for the US Domain. ๐Ÿ’€
     #N starl
     #S Amiga 2500; AmigaDOS 2.04; Dillon's AmigaUUCP 1.15D
     #O Starlight BBS
     #C Stephen Baker
     #E starl!sbaker
     #T +1 305 378 1161
     #P 1107 SW 200th St #303B Miami, Fl. 33157
     #L 25 47 N / 88 10 W [city]
     #R
     #U mthvax
     #W starl!sbaker (Stephen Baker); Mon Feb 24 19:58:24 EST 1992
      starl        mthvax(DAILY)

if you're registering your host as a central site for a USENET group where other UUCP sites will feed from you, that's totally fine ๐Ÿ™Œ those UUCP sites don't need to register. however, if the other sites become a subdomain of your hostname, then we'll need to register them individually or add a wildcard record ๐Ÿƒ

          For example:          bah.rochester.ny.us
                          host1.bah.rochester.ny.us
                          host2.bah.rochester.ny.us

3.2.2 NON-IP Hosts โœจ

okay so if your host isn't an IP host, you can still use US Domain names ๐Ÿซถ but there must be a forwarder host that IS an IP host. there must also be an administrative agreement and a technical procedure for relaying mail between the non-IP host and the forwarder host ๐Ÿ“ฌ no skipping this part bestie!!

Case 1 ๐Ÿ’…

your host isn't an IP host, but it does talk directly with a host that is ๐ŸŒธ

                                              +-----------------+
+----------+            +---------+            |                 |
|your-host |---UUCP-----|forwarder|----IP/TCP--|    INTERNET     |
+----------+            +---------+            |                 |
                                              +-----------------+

the "forwarder" must be an IP host on the Internet. you have to ask "forwarder" if they're willing to be the internet forwarder for "your-host" ๐Ÿฅบ

in the US Domain of the DNS database there must be an entry like this:

"your-host"  MX  10  "forwarder"

this must be entered by the US Domain administrator ๐Ÿ‘‘

in the "forwarder" routing tables there must be info about "your-host" with a rule like: If I see mail for "your-host" I will send it via uucp by calling phone number "123-4567". โ˜Ž๏ธ

Case 2 ๐Ÿฆ‹

this time your host talks to another host that... that talks to an IP host. so in other words, there are multiple hops between your host and the Internet ๐Ÿงš

                                              +-----------------+
+----------+            +---------+            |                 |
|path-host |---UUCP-----|forwarder|----IP/TCP--|    INTERNET     |
+----------+            +---------+            |                 |
    |                                          +-----------------+
   UUCP
    |
+----------+
|your-host |
+----------+

the "forwarder" must be an IP host on the internet. you have to ask "forwarder" if they're willing to be the Internet Forwarder for "Your-Host," and you have to ask "path-host" to relay your mail ๐Ÿ’Œ

in the US Domain of the DNS DataBase there must be an entry like this:

"your-host"  MX  10  "forwarder"

this must be entered by the US Domain Administrator ๐Ÿ‘‘

in the "forwarder" routing tables there must be info about "your-host" with a rule like: If I see mail for "your-host" I will send it via UUCP to "path-host" by calling phone number "123-4567". and "path-host" must also know how to relay the mail to "your-host" ๐Ÿ“ž

Note: it is assumed that "path-host" is already MXed to "forwarder." it is not appropriate to ask to MX "your-host" to "path-host" (this is sometimes called double MXing) ๐Ÿ™ˆ the host on the right hand side of an MX entry must be a host on the Internet with an IP address (e.g., 128.9.2.32).

3.3 Delegated Subdomains ๐ŸŽ€

the administrator of the US Domain is responsible for assigning all the DNS names that end with ".US." of course, one person (or even one group) can't handle all of that in the long run, so portions of the name space get delegated to other people ๐Ÿ’œ

delegating cities, companies within cities, schools (K12), community colleges (CC), libraries (LIB), state government (STATE), and federal government agencies, departments, etc. is acceptable and practical โœจ

for a delegated portion of the namespace, like a city, no alterations can be made to that name. no abbreviations added, etc., unless it's applied for ๐Ÿ™…โ€โ™€๏ธ

sometimes there may be two people running name servers in the same city, because different portions of the name space have been delegated to them ๐Ÿ‘ฏ for example, someone may be delegated the <city>.<state>.US name space, and someone from a state government agency may have the .STATE.<state>.US portion. so Fred may run the name servers for Sacramento.CA.US, and Joe may run the name servers for STATE.CA.US in Sacramento ๐Ÿ˜ญ

if a company would like to have wildcard records added, or run their own name servers in a city that we've delegated name space to, this is ok ๐Ÿ’…

delegation of the whole State namespace is not yet implemented ๐Ÿฅฒ the delegated part of the name space is in this form:

                 .STATE.<state>.US.
                   .K12.<state>.US.
                    .CC.<state>.US.
                   .LIB.<state>.US.
     .<org-name>.<city>.<state>.US.
      .CITY.<city-name>.<state>.US.
                .<org-name>.FED.US.

3.3.1 Schools ๐Ÿซ

as schools start joining the Internet, there ought to be a consistent scheme for naming them. so a "K12" name branch has been set up in each state in the US Domain for this purpose ๐Ÿ“

public schools are usually organized by districts, which can be bigger or smaller than a city or county ๐Ÿ—บ๏ธ

districts often have the same name as a city or county, so there has to be a way to tell a public school district name apart from some other type of locality name. the keyword "K12" is used for this ๐Ÿ”‘

in some districts the same school name gets used at different levels, like Washington Elementary School and Washington High School. when it's necessary, we suggest using the keywords "Elementary", "Middle", and "High" to tell these schools apart. these keywords would only be used when they're needed. if the school's name is unique without them, don't use them ๐Ÿ™ƒ

typical K12 school names used right now look like:

IVY.PRS.K12.NJ.US
DMHS.JCPS.K12.KY.US
OHS.EUNION.K12.CA.US
BOHS.BREA.K12.CA.US

these names could be long ๐Ÿ˜… with so many schools, organizing by school district and state seems right. when there are lots of things to name, some of the names have to be long.

in some cases there may be appropriate abbreviations you can use. for example, Hamilton High School in Los Angeles could be:

Hami.Hi.LA.K12.CA.US

Some School Examples: ๐ŸŽ’

Hamilton.High.LA-Unified.K12.CA.US        <== a public school
Sherman-Oaks.Elem.LA-Unified.K12.CA.US    <== a public school
John-Muir.Middle.Santa-Monica.K12.CA.US   <== a public school
Crossroads-School.Santa-Monica.CA.US      <== a private school
SMCC.CC.CA.US                             <== a community college
Northridge.CSU.STATE.CA.US                <== a state university

if a school has a bunch of PCs, then each PC should have a name ๐Ÿ’ป suppose they're named "alpha", "beta", ... then if they belong to a school named "Lincoln.High.Lakewood.K12.CA.US", their names would be:

alpha.Lincoln.High.Lakewood.K12.CA.US.
beta.Lincoln.High.Lakewood.K12.CA.US
...

3.2.2 State Agencies ๐Ÿ›๏ธ

the US Domain namespace has been delegated to state government agencies. for example, in the State of Minnesota, the subdomain is STATE.MN.US ๐ŸŒˆ

this means the person running the nameservers for state.mn.us is responsible for naming the agencies of the state government. for example:

State Agencies: ๐Ÿข

Senate.STATE.MN.US      <== State Senate
MDH.STATE.MN.US         <== Dept. of Health
CALTRANS.STATE.CA.US    <== Dept. of Transportation
DMV.STATE.CA.US         <== Dept. of Motor Vehicles

3.3.3 Federal Agencies ๐Ÿฆ…

a federal namespace has been delegated to federal government agencies. for example, the subdomain for the Federal Reserve Bank of Minneapolis is MNPL.FRB.FED.US. more examples are listed below ๐Ÿ‘‡

Federal Government Agencies: ๐Ÿ‡บ๐Ÿ‡ธ

Senate.FED.US                   <====  US Senate
DOD.FED.US                      <====  US Defense Dept.
USPS.FED.US                     <====  US Postal Service
VA.FED.US                       <====  US Veterans Administration
IRS.FED.US                      <====  US Internal Revenue Service
Yosemite.NPS.Interior.FED.US    <====  A Federal agency

3.3.4 Delegation Requirements ๐Ÿ“‹

when a subdomain is delegated, the following requirements must be met ๐Ÿซก

  1. there must be a knowledgeable and competent technical contact, familiar with the Internet Domain Name System. this is easily satisfied if the technical contact already runs some other nameservers ๐Ÿค“
  2. organizations requesting delegations must provide at least two independent (robust and reliable) DNS name servers in physically separate locations on the Internet ๐ŸŒ
  3. the subdomain must accept all applicants on an equal basis โš–๏ธ
  4. the subdomain must provide timely processing of requests. to do this, it is helpful to have several individuals knowledgeable about the procedures, so that operations aren't delayed by one person's unavailability (for example, by being on vacation) ๐Ÿ–๏ธ

3.3.5 Delegation Procedures ๐Ÿงพ

the procedure followed when a subdomain is delegated includes the following steps ๐Ÿ’ซ

  1. evaluate the technical contact's experience with DNS. make sure there is a need for the proposed delegation. make sure the technical contact has the information about the US Domain and the suggested naming structure ๐Ÿ”
  2. note: in the past there was the concept of a "coordinator" for a group, a club, or a "Domain Park." they would coordinate the registration of all the computers used by members of the club and forward all the information for the group to the US Domain Administrator. most coordinators have moved into the position of administrator of that now-delegated subdomain ๐Ÿซถ
  3. add the new technical contact to the "us-dom-adm" mailing list for distributing updates to the US Domain policies and procedures, or other pertinent information ๐Ÿ“จ
  4. delete any hosts from our zone file that belong in the newly delegated subdomain, and make sure they now have those hosts in their zone file ๐Ÿ—‘๏ธ
  5. send them a copy of the zone file so their initial zone file is identical to ours. for example:
mil.wi.us.   86400   SOA spool.mu.edu. manager.spool.mu.edu. (
                        920904  ;serial
                        28800   ;refresh
                        14400   ;retry
                        3600000 ;expire
                        86400 ) ;minim

mil.wi.us.      86400   NS      spool.mu.edu.
spool.mu.edu.   50400   A       134.48.1.31
mil.wi.us.      86400   NS      sophie.mscs.mu.edu.

sophie.mscs.mu.edu.     50400   A       134.48.4.6
solaria.mil.wi.us.      86400   HINFO   Sun 3/60 SunOs
solaria.mil.wi.us.      86400   MX      10 spool.mu.edu.
nthomas.mil.wi.us.      86400   HINFO   386 Clone DOS
nthomas.mil.wi.us.      86400   MX      10 spool.mu.edu.
rwmke.mil.wi.us.        86400   HINFO   UNIX PC UNIX
rwmke.mil.wi.us.        86400   MX      10 spool.mu.edu.
milestn.mil.wi.us.      86400   HINFO   PC AT ENIX
milestn.mil.wi.us.      86400   MX      10 spool.mu.edu.
dawley.mil.wi.us.       86400   HINFO   386 Clone DOS
dawley.mil.wi.us.       86400   MX      10 spool.mu.edu.
...
  1. the US Domain zone file must have the following records, showing the name, address, e-mail, and phone number of the technical contact for the delegated subdomain, the name of the delegated name space, and the names of the nameservers ๐Ÿ“‡ this is the good stuff, bestie ๐ŸŒˆ

Okay so the zone-file example is next ๐Ÿ’… Here's how the delegation for .mil.wi.us looks, with two name servers and no glue records needed ๐ŸŽ€

            ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
            ;
            ;Delegated zone: .mil.wi.us
            ;Contact:  Steven Goodman
            ;          manager@spool.mu.edu
            ;          Marquette University
            ;          (414) 288-6734

            mil.wi.us.      604800  NS      SPOOL.MU.EDU.
                            604800  NS      SOPHIE.MSCS.MU.EDU.

            ; A glue record is not needed this time. Glue records are
            ; needed when the name of the server is a subdomain of the
            ; delegated domain.
            ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
  1. Next, check that the delegated subdomain name servers are up and running ๐ŸŒธ and that the delegated hosts are installed in their zone file. Then delete any hosts from the US Domain zone file that belong in the newly delegated subdomain. Clean sweep, no duplicates โœจ
  2. Let the technical contact of the newly delegated subdomain know ๐Ÿ’œ that wildcard records are allowed in the zone file under the organizational subdomain, but no wildcard records are allowed under the "city" or "state" domain. Boundaries matter, bestie ๐Ÿซถ

3.3.6. Subdomain Contacts

Around 680 individual hosts are registered ๐Ÿฆ‹, but we've delegated the following chunks of the namespace. We don't know how many hosts live under each of these subdomains, which is lowkey mysterious ๐Ÿ™ˆ

           DELEGATED ZONE             CONTACT
           ==============             =======

           TUCSON.AZ.US               leonard@arizona.edu
           SF.CA.US                   sf-hostmaster@apple.com
           PREMENOS.SF.CA.US          jenkins@premenos.sf.ca.us
           SCVL.CA.US                 sinster@scintilla.capitola.ca.us
           SANTA-CRUZ.CA.US           sinster@scintilla.capitola.ca.us
           APTOS.CA.US                sinster@scintilla.capitola.ca.us
           CAMPBELL.CA.US             sinster@scintilla.capitola.ca.us
           CAPITOLA.CA.US             sinster@scintilla.capitola.ca.us
           FELTON.CA.US               sinster@scintilla.capitola.ca.us
           ZAYANTE.CA.US              sinster@scintilla.capitola.ca.us
           BOULDER-CREEK.CA.US        sinster@scintilla.capitola.ca.us
           DARWIN.PTVY.CA.US          brian@angband.stanford.edu
           LOGAN-HS.UNIONCITY.CA.US   cjw@marmot.nersc.gov
           BOULDER.CO.US              trent@XOR.COM
           COLOSPGS.CO.US             trent@XOR.COM
           DENVER.CO.US               trent@XOR.COM
           DVR.CO.US                  trent@XOR.COM
           CHI.IL.US                  matt@oddjob.uchicago.edu
           EUGENE.OR.US               meyer@oregon.uoregon.edu
           SPRINGFIELD.OR.US          meyer@oregon.uoregon.edu
           MULTNOMAH.LIB.OR.US        brianw@polaris.admin.ogi.edu
           PGH.PA.US                  ecd@CERT.ORG
           SPK.WA.US                  root@dogear.spk.wa.us
           MIL.WI.US                  manager@spool.mu.edu
           ATL.GA.US                  charvey@gatech.gatech.edu
           Mt-PARK.GA.US              charvey@gatech.gatech.edu
           CLARKSTON.GA.US            charvey@gatech.gatech.edu
           STATE.MN.US                dfazio@mr.net
           MNPL.FRB.FED.US            dfazio@mr.net

           K12.CA.US                  mdm@NIC.CSU.NET
           CC.CA.US                   mdm@NIC.CSU.NET
           K12.MI.US                  sandra.s.waite@um.cc.umich.edu
           K12.TX.US                  bmanning@is.rice.edu
           K12.NJ.US                  becker@nisc.jvnc.net
           K12.MS.US                  fwp@msstate.edu
           dmhs.jcps.K12.KY.US        lentner@sura.net
           TIES.K12.MN.US             dfazio@mr.net

Now the MD.US counties ๐Ÿ‘‘ The following MD.US counties have been delegated to butler@brl.mil.

           AL.MD.US.       Allegany
           AA.MD.US.       Anne Arundel
           BA.MD.US.       Baltimore
           CAL.MD.US.      Calvert
           CAR.MD.US.      Caroline
           CE.MD.US.       Cecil
           CH.MD.US.       Charles
           DO.MD.US.       Dorchester
           FR.MD.US.       Frederick
           GA.MD.US.       Garrett
           HA.MD.US.       Harford
           HO.MD.US.       Howard
           KE.MD.US.       Kent
           MO.MD.US.       Montgomery
           PG.MD.US.       Prince George"s
           QA.MD.US.       Queen Anne's
           SM.MD.US.       St. Mary's
           SO.MD.US.       Somerset
           TA.MD.US.       Talbot
           WA.MD.US.       Washington
           WI.MD.US.       Wicomico
           WO.MD.US.       Worcester

4. DATABASE INFORMATION โœจ

4.1. Name Servers

okay so name servers are basically the storage units ๐Ÿ—„๏ธ of the whole domain database ๐Ÿ’…. The database gets chopped into chunks called zones, and those zones are spread across the name servers. Name servers can do a bunch of optional extra stuff and pull data from different places, but their main job is answering queries with the data in their own zones ๐ŸŽ€. Every answer can be built from local data alone. It's either the actual answer or a referral pointing you to other name servers that are "closer" to what you're hunting for ๐Ÿฆ‹.

Every zone is required to be available on at least two servers, and plenty of zones have way more backup than that ๐Ÿซถ. That's how a zone stays reachable even when a host or a communication link goes down. It's giving redundancy, and I'm obsessed ๐Ÿ˜ญ.

The US Domain is currently supported by six name servers:

venera.isi.edu
ns.isi.edu
ns.hercules.csl.sri.com
nnsc.nsf.net
ns.uu.net
adm.brl.mil

4.2 Zone Files

A "zone" is a registry of domains kept by one particular organization. A zone registry is "authoritative", which means the master copy lives with the zone organization, and by definition that copy is always up-to-date โœจ. Copies can be sent to other places and stored in caches, but those caches are not authoritative and might be out-of-date ๐Ÿ™ˆ.

Every zone has at least one node (and therefore at least one domain name) it's authoritative for, and all the nodes in a zone are connected to each other ๐Ÿงš. Because of the tree structure, every zone has a highest node, the one closest to the root compared to every other node in that zone ๐ŸŒณ. Folks often use that node's name to identify the zone. The data that describes a zone has four major parts:

  1. Authoritative data for all nodes within the zone.
  2. Data that defines the top node of the zone (can be thought of as part of the authoritative data).
  3. Data that describes delegated subzones, i.e., cuts around the bottom of the zone,
  4. Data that allows access to name servers for subzones (sometimes called "glue" data).

The zone administrator has to maintain the zones at all the name servers that are authoritative for the zone. When changes are made, they must be distributed to all of the name servers ๐Ÿ“ฌ.

Copies of the zone files are not available unless you are on the Internet. To look at the zone files, use the "dig" program of the DNS domain name system ๐Ÿ”:

dig   @nshost  host-your-checking  axfr

4.3 Resource Records

Records in the zone data files are called resource records (RRs). The standard resource records are specified in STD 13, RFC 1034 and STD 13, RFC 1035 (3,4). An RR has a standard format, and it looks like this ๐Ÿ‘€:

<name> [<ttl>] [<class>] <type> <data>

Here's the breakdown, bestie. The first field is always the name of the domain record. The second field is an optional time to live field, which specifies how long this data will be stored in the database โฐ. The third field is the address class, and the class field specifies the protocol group. Most often this is the Internet class "IN" ๐ŸŒ. The fourth field states the type of the resource record. The fields after that depend on the type of RR, and the fifth field is the data field, which is defined differently for each type and class of data ๐Ÿงฉ.

Here's a list of the current commonly used types:

SOA     Start of Authority
NS      Name Server
A       Internet Address
CNAME   Canonical Name (nickname pointer)
HINFO   Host Information
WKS     Well Known Services
MX      Mail Exchanger
PTR     Pointer

So what do the fields actually mean? ๐Ÿค” Check out this example:

foo.LA.CA.US.    604800    MX   10     Venera.ISI.EDU.
(1)              (2)       (3)  (4)    (5)
  1. domain name
  2. time to live information
  3. mail exchanger record
  4. preference value to determine (if more than one forwarder) which mailer to use first, lower number higher preference
  5. the Internet forwarding host.

4.3.1 A Records

An "A" record gives you the Internet (IP) address ๐Ÿ . The data for an "A" record is an Internet address in dotted decimal form. A sample "A" record might look like:

venera.isi.edu.          A      128.9.0.32
   (name)               (A)     (address)

The name field is the machine name, and the address is the network address. There should be only one "A" record for each address of a host ๐Ÿ’–.

4.3.2 CNAME Records

The Canonical Name resource record, CNAME, specifies an alias for a canonical name. It's essentially a pointer to the official name for the requested name, and all other RRs appear under that official name ๐Ÿ‘‘. Say a machine named FERNWOOD.MPK.CA.US wants the nickname ANTERIOR.MPK.CA.US. The RR you'd use is:

anterior.mpk.ca.us.     CNAME      fernwood.mpk.ca.us.
 (alias nickname)                   (canonical name)

Nicknames (where the name attached to the RR is the nickname) may be added for a while when a host changes its name, usually because it moves to another state ๐Ÿšš. It helps to have this CNAME pointer, because if any mail comes to the old address, it gets forwarded to the new one ๐Ÿ’Œ. There cannot be any other RRs associated with a nickname of the same class ๐Ÿ™…โ€โ™€๏ธ.

4.3.3 MX Records

Mail Exchanger records, MX, are used to specify a machine that knows how to deliver mail to a machine that is not directly connected to the Internet ๐Ÿ“ฎ. For example, venera.isi.edu is the mail gateway that knows how to deliver mail to foo.la.ca.us, but other machines on the network cannot deliver mail directly to foo.la.ca.us. Those two machines may have a private connection or use a different transport medium, such as uucp ๐Ÿ”Œ. The preference value (10) is the order a mailer should follow when there's more than one way to deliver mail to a single machine. The lower the number, the higher the preference ๐Ÿฅ‡.

foo.LA.CA.US.  604800  MX  10  Venera.ISI.EDU.
foo.LA.CA.US.  604800  MX  20  relay1.uu.net.

4.3.4 HINFO Records

Host information resource records, HINFO, are for host-specific data ๐Ÿ–ฅ๏ธ. They list the hardware and operating system running at the listed host. A space separates the hardware information from the operating system information, so if you want to include a space in the machine name, you must quote the name ๐ŸŽ€. Host information is not specific to any class, so ANY may be used for the address class. There should be one HINFO record for each host.

acb.la.ca.us.       HINFO       VAX-11/780      UNIX
                                (Hardware)      (Operating System)

The official HINFO types can be found in the latest Assigned Numbers RFC, and the most recent edition is RFC 1340 ๐Ÿ“š. The hardware type is called the Machine Name, and the software type is called the System Name.

Real talk, the information users supply here is often inconsistent or incomplete ๐Ÿ˜ฉ. So please follow the terms in the current "Assigned Numbers" ๐Ÿซถ.

4.3.5 PTR Records

A Domain Name Pointer record, PTR, lets special names point to some other location in the domain database ๐Ÿงญ. These are typically used for setting up reverse pointers in the special IN-ADDR.ARPA domain. PTR names should be unique to the zone.

0.0.9.128.in-addr.arpa     PTR    isi-net.isi.edu.
    (special name)                  (real name)

A PTR record needs to be added to the IN-ADDR.ARPA domain for every A record registered in the US Domain ๐Ÿ’…. These PTR records need to be added by the administrator of the network where the host is connected. The US Domain administration does not administer that network and cannot make these entries in the DNS database, so it's not on them ๐Ÿ™ˆ.

4.4 Wildcards

Wildcard records are of the form *.<anydomain>, where <anydomain> is any domain name ๐Ÿƒ. Wildcards potentially apply to descendants of <anydomain>, but not to <anydomain> itself.

Let's do an example. Imagine a large company in California with a big non-IP/TCP network that wants to create a mail gateway โœจ. The company is called DWP.LA.CA.US, and the IP/TCP capable gateway machine (Internet forwarder) is called ELROY.JPL.NASA.GOV. The following RRs might be entered into the .US zone:

  dwp.la.ca.us    MX      10       ELROY.JPL.NASA.GOV
*.dwp.la.ca.us    MX      10       ELROY.JPL.NASA.GOV

The wildcard record *.DWP.LA.CA.US would cause an MX query for any domain name ending in DWP.LA.CA.US to return an MX RR pointing at ELROY.JPL.NASA.GOV. The entry without the "*" is needed so the host dwp can be found ๐Ÿ”Ž.

In the US Domain, wildcard records are allowed in our zone files under the organizational subdomain (and where noted otherwise), but no wildcard records are allowed under the "City" or "State" domain ๐Ÿšซ.

Okay, the authors (hi, it's us ๐Ÿซถ) strongly believe it's in everyone's interest, and good for the Internet, for each host to be explicitly registered. Basically, we believe wildcards should not be used. We know not everyone agrees with that, though ๐Ÿคทโ€โ™€๏ธ. So we will allow wildcard records in the US Domain under groups or organizations, like *.DWP.LA.CA.US. The reason we feel single entries are the best is simple. If anyone wanted to find one of the hosts in the domain name system, it would be right there, and problems can be detected more easily ๐Ÿ•ต๏ธโ€โ™€๏ธ. When you use wildcard records, all the hosts under a subdomain are hidden ๐Ÿ‘ป.

5. REFERENCES

  • [1] Stahl, M., "Domain Administrators Guide", RFC 1032, SRI International, November 1987.
  • [2] Lottor, M., "Domain Administrators Operations Guide" RFC 1033, SRI International, November 1987.
  • [3] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, ISI, November 1987.
  • [4] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, ISI, November 1987.
  • [5] Dunlap, K., "Name Server Operations Guide for Bind, Release 4.3", UC Berkeley, SMM:11-3.
  • [6] Partridge, C., "Mail Routing and the Domain Name System", STD 14, RFC 974, BBN, January 1986.

6. SECURITY CONSIDERATIONS ๐Ÿ’€

Security issues are not discussed in this memo.

Plot twist, bestie: this memo has zero security content. Nothing here covers it, so keep that in mind ๐Ÿ˜ญ.

7. AUTHORS' ADDRESSES ๐Ÿ’Œ

Okay, the people who wrote this one! Ann Cooper and Jon Postel, both at USC/Information Sciences Institute in Marina del Rey, CA, with their contact details right here:

   Ann Cooper
   USC/Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA  90292

   Phone:  1-310-822-1511
   Email:  cooper@isi.edu


   Jon Postel
   USC/Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA  90292

   Phone:  1-310-822-1511
   Email:  postel@isi.edu

APPENDIX-I: US DOMAIN NAMES BNF ๐Ÿ—บ๏ธ

Okay bestie, this appendix is the grammar for what a US domain name is allowed to look like. It's giving very organised, very structured, very "every piece has a place" ๐Ÿงš Here it is, exactly as written:

   <us-domain-name>    ::= <us-name><dot><us>

   <us-name>           ::= <state-name><dot><state-code> |
                           <fed-name><dot><fed>

   <state-code>        ::= <the two-letter code of a state from the
                            zip code directory>

   <state-name>        ::= <local-name><dot><locality> |
                           <state-agency-name><dot><state> |
                           <regional-agency-name><dot><agency>

   <fed-name>          ::= <the dotted hierarchical name of a US
                            federal government agency>

   <locality>          ::= <the full name of a city from the
                             zip code directory> |
                           <a short code name for a city> |
                           <the full name of a county, township,
                            or parish> |
                           <other well known and commonly used
                            locality name>

   <local-name>        ::= <entity-name> |
                           <city-name><dot><city> |
                           <county-name><dot><county> |
                           <local-agency-name><dot><agency>

   <state-agency-name> ::= <the dotted hierarchical name of a state
                            government agency>

   <regional-agency-name> ::= <the dotted hierarchical name of a special
                            agency or district not an element of the
                            state government and typically larger than
                            a single city or county, for example, the
                            Southern California Air Quality Management
                            District>

   <entity-name>       ::= <the dotted hierarchical name of an entity
                            within a city, for example: a company,
                            business, private school, club, organization,
                            or individual>

   <city-name>         ::= <the dotted hierarchical name of a city
                            government agency>

   <county-name>       ::= <the dotted hierarchical name of a county,
                             township, or parish government agency>

   <local-agency-name> ::= <the dotted hierarchical name of a special
                            agency or district not an element of a
                            city or county government and typically
                            equal or smaller than a single city or
                            county, for example, the Bunker Hill
                            Improvement District>


   <city> ::= "CITY"

   <county> ::= "COUNTY" | "TOWNSHIP" | "PARISH"

   <dot> ::= "."

   <fed> ::= "FED"

   <agency> ::= "AGENCY" | "DISTRICT" | "K12" | "CC" | "LIB"

   <state> ::= "STATE" | "COMMONWEALTH"

   <us> ::= "US"

Now the spicy bits ๐ŸŒถ๏ธ Notes on the grammar: "K12" may be used for public school districts, only. And "CC" may be used only for public community colleges, and "LIB" can only be used by libraries. So no sneaking in a library label if you're not one, periodt ๐Ÿ“š๐Ÿ’…

APPENDIX-II: US DOMAIN QUESTIONNAIRE FOR HOST ENTRY ๐Ÿ“‹

Okay this is the checklist you fill out to get a host registered in the US domain, and it is SO detailed. To register a host in the US domain, the following information must be sent to the US Domain Registrar at Us-Domain@ISI.EDU. You can send questions by email to that same address, or call Ann Cooper at 310-822-1511 ๐Ÿ“ž

(1) The name of the top-level domain to join.

For example: US

(2) The name of the administrative head of the organization, including title, mailing address, phone number, organization, and network mailbox. This is the contact point for administrative and policy questions about the domain. If it's a research project, this should be the principal investigator ๐ŸŽ“

For example:

      Administrator

         Organization  The NetWorthy Corporation
         Name          Penelope Q. Sassafrass
         Title         President
         Mail Address  The NetWorthy Corporation
                       4676 Andrews Way, Suite 100
                       Santa Clara, CA 94302-1212
         Phone Number  (415) 123-4567
         Net Mailbox   Sassafrass@ECHO.TNC.COM

(3) The name of the technical contact for the entry, including title, mailing address, phone number, organization, and network mailbox. This is the contact point for problems concerning the domain or zone, as well as for updating information about the domain or zone ๐Ÿ› ๏ธ

For example:

      Technical Contact

         Organization  The NetWorthy Corporation
         Name          Ansel A. Aardvark
         Title         Executive Director
         Mail Address  The NetWorthy Corporation
                       4676 Andrews Way, Suite 100
                       Santa Clara, CA. 94302-1212
         Phone Number  (415) 123-6789
         Net Mailbox   Aardvark@ECHO.TNC.COM

(4) The name of the host. This is the name that will be used in tables and lists associating the domain with the domain server addresses. [Real talk: domain names can get SUPER long if you want them to (programmers, beware ๐Ÿ‘€), but shorter names are way easier for people to cope with.]

For example: NetWorthy.Santa-Clara.CA.US

Or: Alpha.NetWorthy.Santa-Clara.CA.US and Beta.NetWorthy.Santa-Clara.CA.US

(5) If this machine is not directly on the internet, how does it communicate with the Internet. Through UUCP, CREN, etc? Which forwarding host? ๐ŸŒ

For example:

      The host "Networthy.Santa-Clara.CA.US" uses UUCP
      to connect to "RELAY.ISI.EDU" which is an Internet host.

The administrator of RELAY.ISI.EDU must agree to be the forwarding host for Networthy.Santa-Clara.CA.US, and the forwarding host must know a delivery method and route to it. No double MXing ๐Ÿ™…โ€โ™€๏ธ

If you're requesting an indirect connection, that is, a Mail Exchanger (MX) record, you need to give the name and mailbox of the administrator of the forwarding host.

For example:

John Smith
js@RELAY.ISI.EDU

(6) Please describe your organization briefly. ๐ŸŽ€

For example:

The NetWorthy Corporation is a consulting
organization of people working with UNIX and the C language in an
electronic networking environment.  It sponsors two technical
conferences annually and distributes a bimonthly newsletter.

(7) What Domain Name System (DNS) Resource Records (RR) and values are to be entered. Here are the options, bestie ๐Ÿ“

a.  A       Internet Address (internet hosts only)
b.  HINFO   Host Information, Machine System
c.  WKS     Well Known Services, Protocols, Ports (internet hosts only)
d.  MX      Mail Exchanger (required for UUCP, and CREN hosts)

An example of RRs for an internet host:

   NetWorthy.Santa-Clara.CA.US   IN   A       128.9.3.123
                              IN   HINFO   SUN-3/11OC UNIX
                              IN   MX      10  ISI.EDU
                              IN   WKS     128.9.3.123. UDP (echo
                                                             tftp)
                              IN   WKS     128.9.3.133. TCP (telnet
                                                             ftp
                                                             tftp
                                                             finger)

An example of RRs for a non-internet host:

   Beta.NetWorthy.Santa-Clara.CA.US   MX      10   RELAY.ISI.EDU
                                      HINFO   SUN-3/11OC UNIX

(8) Where is the IN-ADDR pointer record to be entered. (For internet hosts only.) This one's on you, babe ๐Ÿซถ It is your responsibility to see that this is done. Contact the administrator of the IP network your host is on. The US Domain administration does not administer the network and cannot make these entries in the DNS database, so don't look at them for this one ๐Ÿ™ˆ

For example:

   123.3.9.128.IN-ADDR.ARPA.    PTR  NetWorthy.Santa-Clara.CA.US

Who is the contact for the zone of the IN-ADDR.ARPA data, where this record will be entered?

(9) What Time to Live (TTL)? TTL is the time (in seconds) that a resolver will use the data it got from the domain server before it asks it again for the data. A typical TTL is One Week 604800. (NOTE: TTL is not applicable to non-Internet hosts.) โณ

For example:

   One Week   604800
๐Ÿ“ฆ where this page comes from