Differences between version 10 and predecessor to the previous major change of ResourceRecord.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 10 | Last edited on Sunday, November 28, 2004 11:38:44 am | by AristotlePagaltzis | Revert |
| Older page: | version 8 | Last edited on Saturday, November 27, 2004 4:49:22 am | by AristotlePagaltzis | Revert |
@@ -1,20 +1,126 @@
-The smallest unit of queriable data in the [DNS], commonly referred
to by
its [Acronym | WLUG:Acronym] [RR]
.
+The smallest unit of queriable data in the [DNS]. Each ResourceRecord has a type which gives particular meaning
to its payload
. These types include:
-Each ResourceRecord has a type which gives particular meaning to its payload
. These types include
:
+__<tt>A</tt>__:
+ Short for "address"
. An [IPv4] address. Specified in RFC
:1035. Example:
+ <verbatim>
+ foo.example.org A 1.2.3.4
+ </verbatim>
-* [
A]
, [AAAA] and [A6]
-* [CNAME]
-* [DNAME]
-* [LOC] (to find the [GPS] location of a machine or site)
-* [MX] (to find
an [SMTP
] server for a domain)
-* [NS] (
to find a NameServer for domain)
-* [PTR] (for doing a ReverseLookup)
-* [SOA]
-* TXT
+__<tt>AAAA</tt>__:
+ Like <tt>
A</tt>
, but stores
an [IPv6
] address;
to be obsoleted by <tt>A6</tt>. Specified in RFC:1886. Example:
+ <verbatim>
+ foo.example.org AAAA 2002:c000:0200::1
+ </verbatim>
-A more comprehensive list of ResourceRecord~s is at: http
://www
.dns
.net/dnsrd/rr
.html
+__<tt>A6</tt>__
:
+ Supposed to obsolete <tt>AAAA<
/tt> for [IPv6] addresses.
+ Many people continue using <tt>AAAA<
/tt> due to the complexity of A6, see [AAAAvsA6]
.
+ Specified in RFC:2874
. Example:
+ <verbatim>
+ $ORIGIN X
.EXAMPLE.
+ N A6 64 ::1234:5678:9ABC:DEF0 SN-1.IP6
+ SN-1.IP6 A6 48 :::1:: IP6
+ IP6 A6 48 ::0 CUST-X.IP6.A.NET.
+ IP6 A6 48 ::0 CUST-X.IP6.B.NET.
+ </verbatim>
-''InNeedOfRefactor
: fold all the pages
for individual ResourceRecord
types into
this one; none
of them
is long
, and using "
an A ResourceRecord
" gives
__much
__ better context
for links than "
an [A
] record"
, while
"an
[A
] [RR
]"
is redundant
.''
+__<tt>CNAME</tt>__
:
+ Short
for Canonical Name, an alias for a hostname.
+ Often used for well known services so that <tt>www.example.com</tt> points to <tt>arthur.example.com</tt>.
+ Specified in RFC:1035. Example:
+ <verbatim>
+ www.xtra.co.nz CNAME xtra.co.nz
+ xtra.co.nz A 202.27.184.102
+
+ mail.xtra.co.nz CNAME mta.xtra.co.nz
+ mta.xtra.co.nz A 203.96.92.132
+ </verbatim>
+ Some record
types in [DNS] are not allowed to be <tt>CNAME</tt>s. Similar to <tt>DNAME</tt>. See the NamedNotes page for more details.
+
+__<tt>DNAME</tt>__:
+ Basically a <tt>CNAME</tt> for an entire domain. Specified in RFC:2672. Example:
+ <verbatim>
+ test.meta.net.nz. IN DNAME wlug.org.nz.
+ </verbatim>
+ With
this in place <tt>[www.test.meta.net.nz|http://www.test.meta.net.nz/]</tt> resolves to <tt>www.wlug.org.nz</tt>.
+
+ Support for this feature is spotty. DanBernstein refuses to implement it and it doesn't seem to be mentioned at all in MicrosoftWindows (as
of 2004-07-14).
+ Only [BIND] seems to support it, but since it will also serve you a <tt>CNAME</tt>, most resolvers should deal with it properly:
+ <verbatim>
+ test.meta.net.nz. 86400 IN DNAME wlug.org.nz.
+ www.test.meta.net.nz. 0 IN CNAME www.wlug.org.nz.
+ www.wlug.org.nz. 80464 IN CNAME hoiho.wlug.org.nz.
+ hoiho.wlug.org.nz. 80464 IN A 203.97.10.50
+ </verbatim>
+ MicrosoftWindows still seems to get confused however.
+
+__<tt>LOC</tt>__:
+ [GPS] location of the machine or site. Specified in RFC:1876. Example:
+ <verbatim>
+ waikato.ac.nz. LOC 37 48 30.000 S 175 17 36.000 E 66.00m 3000m 30m 10m
+ </verbatim>
+ This means 37 deg 48' 30" South (latitude), 175 deg 17' 36" East (longitude), and 66 metres about sea level.
+ The last two numbers appear to mean that the whole site
is within 3000 metres of the given point.
+ The point is accurate to about 30 metres
, although this interpretation may be wrong.
+ (It will be in the appropriate [RFC] if anyone can be bothered looking it up.)
+
+ xtraceroute(1) will use these records if it can find them. Unfortunately not many sites use them.
+
+__<tt>MX</tt>__:
+ MailExchanger. Identifies the [SMTP] MailServer(s) responsible for the domain.
+ When no <tt>MX</tt> record exists
and an <tt>
A</tt> record does, the <tt>A</tt> record is chosen to take mail.
+ Specified in RFC:1035. Example:
+ <verbatim>
+ foo.com. IN MX 10 mail.foo.com.
+ </verbatim>
+ The
"10" is the priority. Delivery will be attempted to MailServer~s in order of ascending priority value.
+
+
__Note:
__ the data
for an <tt>MX</tt> record is a host name, __NOT__
an [IP
] address. The following will __NOT__ work:
+ <verbatim>
+ foo.com. IN MX 10 130.123.7.10
+ </verbatim>
+
+ Also, the host name (<tt>mail.foo.com</tt> in the example) __MUST__ have an <tt>A</tt>
record, __NOT__ a <tt>CNAME</tt> record.
+
+__<tt>NS</tt>__:
+ Authoritative NameServer for a domain. Specified in RFC:1035.
+
+__<tt>PTR</tt>__:
+ A pointer. Used for a ReverseLookup. Specified in RFC:1035. Example:
+ <verbatim>
+ 192 PTR hostname.domain.
+ </verbatim>
+ __Note:__ don't forget the trailing fullstop!
+
+__<tt>SOA</tt>__:
+ Start of Authority. Defines information about a domain (called a zone, defined in a ZoneFile), such as a serial number defining the 'version' of the zone, and various timeout and caching values that should be used when records from a given zone are retrieved. The format <tt>name <ttl> class rr name-server email-address (serial refresh retry expire negttl)</tt>. Specified in RFC:1035. Example:
+ <verbatim>
+ $TTL 604800
+ $ORIGIN ethernal.tla.
+ @ IN SOA ns1.ethernal.tla. root.ethernal.tla. (
+ 2004111901 ; Serial
+ 604800 ; Refresh (7 days)
+ 86400 ; Retry (24 hours)
+ 2419200 ; Expire (28 days)
+ 604800 ) ; Neg TTL (7 days)
+ </verbatim>
+ The name is given as
"<tt>@</tt>", since that is the shorthand for the value of <tt>$ORIGIN</tt>.
[TTL
] is missing from this example, as it takes the zone default defined above as <tt>$TTL</tt>. The name-server field is basically the
[FQDN
] of the PrimaryNameServer for the domain (don't forget the trailing fullstop!). The email-address field
is the address of the person responsible for the domain -- the first dot should be read as an <tt>@</tt>, so above should be read as <tt>root@ethernal
.tla</tt>. The values in parenthesis are described below:
+
+ Serial number::
+ Generally given in YYYYMMDDXX format, giving 100 possible revisions of any given zone in a day (Usually more than enough).
+ Refresh::
+ Defines the number of seconds before a SecondaryNameServer will refresh its copy of the zone by requesting a ZoneTransfer from the PrimaryNameServer.
+ Retry::
+ Defines the number of seconds for a SecondaryNameServer to wait before retrying a zone refresh, after a failure.
+ Expire::
+ Defines the number of seconds for a SecondaryNameServer to keep zone records, and answer authoritatively with them if it can
't contact the PrimaryNameServer. (so, if the above refresh fails, and it
's been retrying for this long).
+ Neg TTL::
+ Defines the number of seconds that a client should remember that a negative response was received from this server. So, if a remote server asks us what the address for <tt>foo.ethernal.tla</tt> is but it doesn't exist, it will cache the negative answer we gave it for this many seconds, even if we add that name to the zone a couple of seconds later.
+
+__<tt>TXT</tt>__:
+ Up to 255 bytes of arbitrary binary data. Specified in RFC:1035.
+
+A more comprehensive list of ResourceRecord~s is at: http://www.dns.net/dnsrd/rr.html
----
CategoryDns
