RR
Click on the red underlined text to get to the source
... services through
the introduction of new resource record (RR) types. In practice,
deploying a new RR type currently requires changes to the name server ...
... resource record (RR) types. In practice,
deploying a new RR type currently requires changes to the name server
software not only at the authoritative DNS server ...
... services has never been
fully realized. This memo proposes changes to name servers and to
procedures for defining new RR types aimed at simplifying the future
deployment of new RR ...
... RR types aimed at simplifying the future
deployment of new RR types.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
...
... range reserved in that section for assignment only to
QTYPEs and Meta-TYPEs. Such an RR cannot be converted to a type-
specific text format, compressed, or otherwise handled in a type-
specific way.
...
... In the case of a type whose RDATA format is class specific, an RR is
considered to be of unknown type when the RDATA format for that
...
...
To enable new RR types to be deployed without server changes, name
servers and resolvers MUST handle RRs of unknown type transparently.
...
... To enable new RR types to be deployed without server changes, name
servers and resolvers MUST handle RRs of unknown type transparently.
That is, they must treat the RDATA section of such RRs ...
... RRs of unknown type transparently.
That is, they must treat the RDATA section of such RRs as
unstructured binary data, storing and transmitting ...
... and of the DNSSEC canonical form (section 7) when an RR type is known
to some but not all of the servers involved, servers MUST also
exactly preserve the RDATA ...
... to some but not all of the servers involved, servers MUST also
exactly preserve the RDATA of RRs of known type, except for changes
due to compression or decompression where allowed by section 4 of
...
... RFC1123] without defining the
term "well-known"; it is hereby specified that only the RR types
defined in [RFC1035] are to be considered "well-known ...
... well-known".
The specifications of a few existing RR types have explicitly allowed
compression contrary to this specification: [RFC2163 ...
... SIG RRs and NXT RRs records. Since this specification disallows
compression in these cases, it is an update ...
... Receiving servers MUST decompress domain names in RRs of well-known
type, and SHOULD also decompress RRs ...
... NXT, NAPTR, and SRV (although the current specification of the SRV RR
in [RFC2782] prohibits compression ...
... servers following that earlier specification are still in use).
Future specifications for new RR types that contain domain names
within their RDATA ...
...
In the "type" field of a master file line, an unknown RR type is
represented by the word "TYPE" immediately followed by the decimal RR
...
... In the "type" field of a master file line, an unknown RR type is
represented by the word "TYPE" immediately followed by the decimal RR
type number, with no intervening whitespace. In the "class" field,
...
...
The RDATA section of an RR of unknown type is represented as a
sequence of white space separated words as follows:
...
... token and the single zero representing the length.
An implementation MAY also choose to represent some RRs of known type
using the above generic representations for the type, class and/or
...
... portable to servers where these types are unknown. Using the generic
representation for the RDATA of an RR of known type can also be
useful in the case of an RR type where the text format varies
...
... RDATA of an RR of known type can also be
useful in the case of an RR type where the text format varies
depending on a version, protocol, or similar field (or several)
...
... embedded in the RDATA when such a field has a value for which no text
format is known, e.g., a LOC RR [RFC1876] with a VERSION other than
...
... 0.
Even though an RR of known type represented in the \# format is
effectively treated as an unknown type for the purpose of parsing the
RDATA ...
... canonicalization, etc.
The following are examples of RRs represented in this manner,
illustrating various combinations of generic and type-specific
encodings ...
... DNS protocols, notably Dynamic Update [RFC2136], require RRs
to be compared for equality. Two RRs of the same unknown type are
...
... RFC2136], require RRs
to be compared for equality. Two RRs of the same unknown type are
considered equal when their RDATA is bitwise equal. To ensure that
...
... RDATA is bitwise equal. To ensure that
the outcome of the comparison is identical whether the RR is known to
the server or not, specifications for new RR types MUST NOT specify
...
... comparison is identical whether the RR is known to
the server or not, specifications for new RR types MUST NOT specify
type-specific comparison rules.
...
... comparison, are compared in a case-sensitive manner.
As a result, when a new RR type contains one or more embedded domain
names, it is possible to have multiple RRs owned by the same name
...
... As a result, when a new RR type contains one or more embedded domain
names, it is possible to have multiple RRs owned by the same name
that differ only in the character case of the embedded domain
name(s). This is similar to the existing possibility of multiple TXT
...
... DNSSEC defines a canonical form and ordering for RRs [RFC2535]
(section 8.1). In that canonical form ...
... To ensure continued consistency of the canonical form of RR types
where compression is allowed, and for continued interoperability ...
... RFC2535]
canonical form and apply it to their known RR types, the canonical
form remains unchanged for all RR types whose whose initial
...
... canonical form and apply it to their known RR types, the canonical
form remains unchanged for all RR types whose whose initial
publication as an RFC was prior to the initial publication of this
specification as an RFC (RFC 3597prop ...
... As a courtesy to implementors, it is hereby noted that the complete
set of such previously published RR types that contain embedded
domain names, and whose DNSSEC ...
... downcasing according to the DNS rules for character comparisons,
consists of the RR types NS, MD, MF ...
... DNAME, and A6.
This document specifies that for all other RR types (whether treated
as unknown types or treated as known types according to an RR type
definition ...
... This document specifies that for all other RR types (whether treated
as unknown types or treated as known types according to an RR type
definition RFC more recent than RFC 3597prop), the canonical form ...
... Note that the owner name is always set to lower case according to the
DNS rules for character comparisons, regardless of the RR type.
The DNSSEC ...
...
The DNSSEC canonical RR ordering is as specified in [RFC2535] section
8.3, where the octet sequence is the canonical form ...
...
Unknown RR types cause no additional section processing. Future RR
type specifications MAY specify type-specific additional section
...
...
Unknown RR types cause no additional section processing. Future RR
type specifications MAY specify type-specific additional section
processing rules ...
... processing rules, but any such processing MUST be optional as it can
only be performed by servers for which the RR type in case is known.
...
... Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052(-> 2782prop) ...
... Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782prop ...