Differences between version 9 and predecessor to the previous major change of ResourceRecord.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 9 | Last edited on Sunday, November 28, 2004 11:29:51 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 AAAA 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 CNAMEs. Similar to DNAME. 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 [CNAME], 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 MX record exists
and an A record does, the A 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 MX 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 class will usually always be IN,
[RR] should be obvious :). The name-server field
is bascally the [FQDN] of the PrimaryNameServer for the domain (don't forget the trailing '
.'!). 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
