RFC 1034:DOMAIN NAMES - CONCEPTS AND FACILITIES
RFC-Ref

node


Click on the red underlined text to get to the source

... tree structured name space and data associated with the names. Conceptually, each node and leaf of the domain name space tree ...


... The domain name space is a tree structure. Each node and leaf on the tree corresponds to a resource set (which may be empty). The domain ...
... tree corresponds to a resource set (which may be empty). The domain system makes no distinctions between the uses of the interior nodes and leaves, and this memo uses the term "node" to refer to both. ...
... system makes no distinctions between the uses of the interior nodes and leaves, and this memo uses the term "node" to refer to both. ...
... Each node has a label, which is zero to 63 octets in length. Brother nodes may not have the same label, although the same label can be used for ...
... Each node has a label, which is zero to 63 octets in length. Brother nodes may not have the same label, although the same label can be used for nodes which are not brothers. One label is reserved, and that is ...
... has a label, which is zero to 63 octets in length. Brother nodes may not have the same label, although the same label can be used for nodes which are not brothers. One label is reserved, and that is the null (i.e., zero length) label used for the root. ...
... The domain name of a node is the list of the labels on the path from the node to the root of the ...
... The domain name 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 ...
... order zero bit. This means that you are free to create a node with label "A" or a node with label "a", but not both as brothers; you could ...
... create a node with label "A" or a node with label "a", but not both as brothers; you could refer to either using "a" or "A". When you receive a domain name or ...
... provide branching at the top of the domain so that the eventual decomposition can be done without renaming. Node labels which use special characters, leading digits, etc., are likely to break older software which depends on more restrictive choices. ...
... A domain name identifies a node. Each node has a set of resource information, which may be empty. The set of resource information ...
... A domain name identifies a node. Each node has a set of resource information, which may be empty. The set of resource information associated with a particular name is composed of separate resource records ...
... structures for the name space, and chain RRs off nodes. The remaining RR parts are the fixed header (type, ...
... RR. If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases ...


... class, and by "cuts" made in the name space between nodes. ...
... namespace trees. Note that the data attached to nodes will be different for these different parallel classes. The most common reasons for creating a new class ...
... class, "cuts" in the name space can be made between any two adjacent nodes. After all cuts are made, each group of connected name space is a separate zone. The zone is said to be authoritative for all ...
... These rules mean that every zone has at least one node, and hence domain name, for which it is authoritative, and all of the nodes in a ...
... These rules mean that every zone has at least one node, and hence domain name, for which it is authoritative, and all of the nodes in a particular zone are connected. Given, the tree structure, every zone ...
... particular zone are connected. Given, the tree structure, every zone has a highest node which is closer to the root than any other node in ...
... has a highest node which is closer to the root than any other node in the zone. The name of this node is often used to identify the zone. ...
... root than any other node in the zone. The name of this node is often used to identify the zone. ...
... name space so that each domain name was in a separate zone or so that all nodes were in a single zone. Instead, the database is partitioned at points where a particular organization wants to take over control of ...
... tree sections connected to the zone, delete existing nodes, or delegate new subzones under its zone. ...
... Authoritative data for all nodes within the zone. ...
... Data that defines the top node of the zone (can be thought of as part of the authoritative data). ...
... The authoritative data for a zone is simply all of the RRs attached to all of the nodes from the top node of the zone down to leaf nodes or ...
... RRs attached to all of the nodes from the top node of the zone down to leaf nodes or nodes above cuts around the bottom ...
... all of the nodes from the top node of the zone down to leaf nodes or nodes above cuts around the bottom edge of the zone. ...
... from the top node of the zone down to leaf nodes or nodes above cuts around the bottom edge of the zone. ...
... Though logically part of the authoritative data, the RRs that describe the top node of the zone are especially important to the zone's management. These RRs are of two types: ...
... NS RRs that name the servers for the subzones. Since the cuts are between nodes, these RRs are NOT part of the authoritative data of the zone, and should ...
... RRs are NOT part of the authoritative data of the zone, and should be exactly the same as the corresponding RRs in the top node of the subzone. Since name servers are always associated with zone boundaries, NS ...
... subzone. Since name servers are always associated with zone boundaries, NS RRs are only found at nodes which are the top node of some zone. In the data that makes up a zone, NS ...
... NS RRs are only found at nodes which are the top node of some zone. In the data that makes up a zone, NS RRs ...
... the data that makes up a zone, NS RRs are found at the top node of the zone (and are authoritative) and at cuts around the bottom of the zone (where they are not authoritative), but never in between. ...
... If the whole of QNAME is matched, we have found the node. ...
... If the data at the node is a CNAME, and QTYPE doesn't match CNAME ...
... If a match would take us out of the authoritative data, we have a referral. This happens when we encounter a node with NS RRs marking cuts along the bottom of a ...
...

If the "*" label does not exist, check whether the name we are looking for is the original QNAME in the query or a name we have followed due to a CNAME. If the name is original, set an authoritative name error in the response and exit. Otherwise just exit.

If the "*" label does exist, match RRs at that node against QTYPE. If any match, copy them into the answer section, but set the owner of the RR ...
... section, but set the owner of the RR to be QNAME, and not the node with the "*" label. Go to step 6. ...
... may cause an error, such as refused, but normally is answered by a sequence of response messages. The first and last messages must contain the data for the top authoritative node of the zone. Intermediate messages carry all of the other RRs from the zone, including both ...


... Four RRs are attached to the root node: the SOA which describes the root zone and the 3 NS ...



Google
Web
RFC-Ref