root
Click on the red underlined text to get to the source
... for nodes which are not brothers. One label is reserved, and that is
the null (i.e., zero length) label used for the root.
...
... of a node is the list of the labels on the path from the
node to the root of the tree. By convention, the labels that compose a
domain name are printed or read left to right, from the most specific
...
... . By convention, the labels that compose a
domain name are printed or read left to right, from the most specific
(lowest, farthest from the root) to the least specific (highest, closest
to the root).
...
... as sequences of labels, where each label is a length octet followed by
an octet string. Because all domain names end at the root, which has a
null string for a label, these internal representations can use a length
byte of zero to terminate a domain name ...
... , the length of each label is
omitted and the labels are separated by dots ("."). Since a complete
domain name ends with the root label, this leads to a printed form which
ends in a dot. We use this property to distinguish between:
...
... relative to a single origin domain name. The most common interpretation
uses the root "." as either the single origin or as one of the members
of the search list, so a multi-label relative name is often one where
...
...
In this example, the root domain has three immediate subdomains: MIL,
EDU, and ARPA. The LCS.MIT ...
... tree structure, every zone
has a highest node which is closer to the root than any other node in
the zone. The name of this node ...
... server is likely to be the best one to try next. The
zone name equivalent is a match count of the number of
labels from the root down which SNAME has in common with
the zone being queried; this is used as a measure of how
"close" the resolver is to SNAME. ...
... starting at SNAME, then the parent domain name of SNAME, the
grandparent, and so on toward the root. Thus if SNAME were
Mockapetris.ISI.EDU, this step would look for NS RRs ...
... idea what servers to ask, it should use information from a configuration
file that lists several servers which are expected to be helpful.
Although there are special situations, the usual choice is two of the
root servers and two of the servers for the host's domain. The reason
...
... domain. The reason
for two of each is for redundancy. The root servers will provide
eventual access to all of the domain space. The two local servers will
...
... In our sample domain space, suppose we wanted separate administrative
control for the root, MIL, EDU, MIT.EDU and ISI.EDU zones. We might
allocate name servers as follows:
...
... ARPA. and C.ISI.EDU. Note that servers
may have zones which are contiguous or disjoint. In this scenario,
C.ISI.EDU has contiguous zones at the root and EDU domains. A.ISI.EDU
has contiguous zones at the root ...
... root and EDU domains. A.ISI.EDU
has contiguous zones at the root and MIL domains, but also has a non-
contiguous zone at ISI.EDU.
...
... Four RRs are attached to the root node: the SOA which describes the root
zone and the 3 NS RRs ...
... zone and the 3 NS RRs which list the name servers for the root. The
data in the SOA RR describes the management ...
... RRs for the MIL and EDU domains mark the boundary between the
root zone and the MIL and EDU zones. Note that in this example, the
lower zones happen to be supported by name servers which also support
the root ...
... root zone and the MIL and EDU zones. Note that in this example, the
lower zones happen to be supported by name servers which also support
the root zone.
...
... RRs for the domains ISI.EDU, EDU,
and the root. These searches of the cache would also fail. As a last
resort, the resolver would use the information from the SBELT, copying
...