View Source: ResourceRecord - Waikato Linux Users Group

Edit PageHistory Diff Info LikePages
The smallest unit of queriable data in the [DNS]. 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>

__<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>

__<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  0:0:0:1:: IP6
    IP6       A6  48  0::0 CUST-X.IP6.A.NET.
    IP6       A6  48  0::0 CUST-X.IP6.B.NET.
    </verbatim>

__<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>__:
    In the initial part of a ZoneFile, indicates the NameServer~s which are [authoritative|AuthoritativeNameServer] for this domain. Elsewhere, indicates that a [subdomain|DomainName] is being [delegated|Delegation] to another set of NameServer~s. 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). __Always remember to increment this when editing the ZoneFile__, since a change to the serial number is what triggers ZoneTransfer~s by SecondaryNameServer~s.
    Refresh::
       Defines the interval in seconds between checks by a SecondaryNameServer as to whether the serial number has changed. When a change is detected, this means it needs to 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>[SRV]</tt>__

__<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
14 pages link to ResourceRecord:
Last edited on Tuesday, January 2, 2007 10:33:27 pm by LawrenceDoliveiro
Edit PageHistory Diff Info LikePages