DNS Help and Explications.
What is A RECORD?
The address record (A record) maps a hostname and fully qualified domain name with an IP address.
To add the host chef with IP address 192.168.5.100 to the domain demo.com. in the zone file for demo.com, use the following format:
chef.demo.com. IN A 192.168.5.100
Please note the period following the domain name in the record. This is critical beacuse it tells BIND that the domain name is attached and complete (fully qualified). Without this period, BIND will add the domain name associated with the zone file to the end of this to create a record for chef.demo.com.demo.com. which is not what we want.
Because of this behavior, it is possible to use shorthand:
chef IN A 192.168.5.100
Whenever you add an address record (what could be called a forward lookup
record) it is usually appropriate to add a this recipe describes creating a zone
file.
Name Server Record (NS)
Defined in RFC 1035. NS RRs appear in two places. Within the zone file,
in which case they are authoritative records for the zone's name servers. At the
point of delegation for either a subdomain of the zone or in the zone's parent.
Thus the zone example.com's parent zone (.com) will contain non-authoritative NS
RRs for the zone example.com at its point of delegation and
subdomain.example.com will have non-authoritative NS RSS in the zone example.com
at its point of delegation. NS RRs at the point of delegation are never
authoritative only NS RRs for the zone are regarded as authoritative. While this
may look a fairly trivial point, is has important implications for DNSSEC.
NS RRs are required because DNS queries respond with an authority section listing all the authoritative name servers, for sub-domains or queries to the zones parent where they are required to allow referral to take place.
Format
name
ttl class rr
name
example.com.
IN NS
ns1.example.com.
By convention name servers are defined immediately after the
SOA record but can be defined anywhere convenient in the zone file. The
requirement is that at least two name servers are defined for each public domain
(private domains may use only one if required) - there will always be at least
two NS RRs in each zone file. There is no requirement that any name servers are
within the domain for which they are authoritative. If the name server does lie
within the domain it should have a corresponding A record. The A RRs which
define name server that lie within the domain are frequently called glue
records. Strictly glue records are essential only with referrals which include
name servers within the domain being queried. In practice glue records are used
for two purposes:
To speed up queries - and consequently reduce DNS load - by providing the name and IP addresses (the glue) for all authoritative name servers, both within and external to the domain. The root and TLD servers for example provide this information in all referrals. In the case of the TLD servers the glue data is not obtained from the domain zone file but from the Registrar when the domain name is registered.
To break the query deadlock for referrals which return name servers within the domain being queried. Assume a query for a domain, say the A RR for www.example.com, returns a referral containing the name but not the IP address of a name server, say ns1.example.com, which lies within the domain example.com. Since the IP address of the name server is not known this will naturally result in a query for the A RR of ns1.example.com which will return, again, a referral with the name but not the IP of ns1.example.com! When the glue record is provided this problem does not occur.
When dealing with a SLD (Second Level Domain) zone file the A RRs for the name servers that lie within the domain are not strictly glue records, they are conventional A RRs, but if a sub-domain is defined in the SLD zone file the AA RRs for the sub-domain name servers that lie inside the sub-domain are glue records and are absolutely essential. This is illustrated below in the example fragments. The name server defined in the SOA record, the so called primary master, requires a corresponding NS RR.
The name field can be any of:
A Fully Qualified Domain Name (FQDN) e.g. example.com. (ends with a dot)
An unqualfied name (does not end with a dot)
An '@' (substitutes the current value of $ORIGIN)
a
'space' or 'blank' (tab) - this is replaced with the previous value of the name
field. If no name has been previously defined this may result in the value of
$ORIGIN.
Examples & Variations
; zone fragment for example.com
;
name servers in the same zone
$TTL 2d; zone TTL default = 2 days or 172800
seconds
$ORIGIN example.com.
@
IN SOA ns1.example.com.
hostmaster.example.com.
(
2003080800 ; serial
number
3h ; refresh = 3 hours
15M ; update retry = 15
minutes
3W12h ; expiry = 3 weeks + 12
hours
2h20M ; minimum = 2 hours + 20
minutes
)
IN NS ns1 ;
unqualified name
; the line above is functionally the same as the line
below
; example.com. IN
NS ns1.example.com.
; at least two name servers must
be
defined
IN NS ns2
; the in-zone
name server(s) have an A record
ns1
IN A
192.168.0.3
ns2
IN A
192.168.0.3
This fragments shows where neither of two name servers lie within
the domain:
; zone fragment for example.com
; name servers not in the zone
$TTL 2d;
zone TTL default = 2 days or 172800 seconds
$ORIGIN
example.com.
example.com. IN SOA
ns1.example.net. hostmaster.example.com.
(
2003080800 ; serial
number
3h ; refresh = 3
hours
15M ; update retry = 15
minutes
3W12h ; expiry = 3 weeks + 12
hours
2h20M ; minimum = 2 hours + 20
minutes
)
; name servers not in zone - no A records
required
IN NS
ns1.example.net.
IN NS
ns1.example.org.
The following fragments shows the delegation of sub-domain
and the use of the glue records:
; zone fragment for example.com
; name servers in the same zone
$TTL 2d
; default TTL is 2 days
$ORIGIN
example.com.
@
IN SOA ns1.example.com.
hostmaster.example.com.
(
2003080800 ; serial
number
2h ; refresh = 2 hours
15M ; update retry = 15
minutes
3W12h ; expiry = 3 weeks + 12
hours
2h20M ; minimum = 2 hours + 20
minutes
)
; main domain name
servers
IN NS
ns1.example.com.
IN NS
ns2.example.com.
; mail domain mail
servers
IN MX
mail.example.com.
; A records for name servers above
ns1
IN A
192.168.0.3
ns2
IN A
192.168.0.4
; A record for mail server above
mail
IN A
192.168.0.5
....
; sub-domain definitions
$ORIGIN us.example.com.
; we define two name
servers for the
sub-domain
@
IN NS
ns3.us.example.com.
; the record above could have been written without the
$ORIGIN as
; us.example.com. IN NS ns3.us.example.com.
; OR as
simply
; IN NS ns3
; the next
name server points to ns1
above
IN NS
ns1.example.com.
; address record for sub-domain name server - essential glue
record
ns3
IN A 10.10.0.24 ;
'glue' record
; the record above could have been written as
;
ns3.us.example.com. A 10.10.0.24 if it's less confusing
What is CNAME Record?
A single host may have multiple personalities: web server (www), mail server (mail, mx), dns server (ns), ftp server (ftp). Rather than assign each of these names an address (A) record pointing to the same IP address, all of which would need to be changed if the IP address changed, one name can be associated with an address record and the remaining names can be aliases for that name. The CNAME record simplifies DNS management, and who doesn’t want that?
Given the following address record:
chef.demo.com. IN A 192.168.5.100
To add host aliases ftp and www pointing to chef, use the following resource records:
ftp.demo.com. IN CNAME chef.demo.com.
www.demo.com. IN CNAME chef.demo.com.
Within the same domain name which is the same domain associated with the zone file, these can be shortened to:
chef IN A 192.168.5.100
ftp IN CNAME chef
www IN CNAME chef
Pointer Record (PTR)
Pointer records are the opposite of A and AAAA RRs and are used in Reverse Map zone files to map an IP address (IPv4 or IPv6) to a host name.
Format
name ttl class rr name 15 IN PTR www.example.com.
The number '15' (the base IP address) in the above example is actually a name and because there is no 'dot' BIND adds the $ORIGIN. The example below which defines a reverse map zone file for the Class C address 192.168.23.0 should make this clearer:
$TTL 2d ; 172800 secs
$ORIGIN 23.168.192.IN-ADDR.ARPA.
@ IN SOA ns1.example.com. hostmaster.example.com. (
2003080800 ; serial number
12h ; refresh
15m ; update retry
3w ; expiry
3h ; minimum
)
IN NS ns1.example.com.
IN NS ns2.example.com.
; 2 below is actually an unqualified name and becomes
; 2.23.168.192.IN-ADDR.ARPA.
2 IN PTR joe.example.com. ; FDQN
....
15 IN PTR www.example.com.
....
17 IN PTR bill.example.com.
....
74 IN PTR fred.example.com.
....
Because the $ORIGIN reflects the reverse map domain all right-hand names must use an FQDN format (they end with a dot). If the terminating dot on joe.example.com above were omitted in error it would become joe.example.com.23.168.192.IN-ADDR.ARPA - not the desired result!.
An IP address in a reverse can be defined only once - unlike a forward-mapped zone. If multiple names are assigned to a host using CNAME RRs, A RRs or AAAA RRs then only one can appear in the reverse map. Which one you select is a matter of operational usage. Thus if a mail server (mail.example.com) and a web server (www.example.com) both have the same IP address then since mail systems frequently use reverse lookups as a trivial security check it would be sensible to define the reverse map to use mail.example.com.
It is not essential, but considered good practise, to define all assigned IPs in the reverse map.
It is sensible to define the reverse map in order of IP addresses or some other fixed order to avoid subsequent errors or to simplify searching for a particular value.
PTR and IPv6
IPv6 and IPv4 addresses cannot be mixed in the same zone file as they can for forward-map zones. IPv6 addresses are reverse mapped under the domain IP6.ARPA whereas IPv4 addresses are mapped under the IN-ADDR.ARPA domain. IPv6 reverse-maps use a nibble domain name format defined in Chapter 3. The following fragment illustrates the use of the PTR RR to reverse-map the IPv6 addresses 2001:db8:0:1::1, 2001:db8:0:1::1, 2001:db8:0:2::1 and 2001:db8:0:1::1:
; reverse IPV6 zone file for example.com
$TTL 2d ; default TTL for zone 172800 secs
$ORIGIN 0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA.
@ IN SOA ns1.example.com. hostmaster.example.com. (
2003080800 ; sn = serial number
12h ; refresh = refresh
15m ; retry = update retry
3w ; expiry = expiry
2h ; min = minimum
)
; name servers Resource Recordsfor the domain
IN NS ns1.example.com.
; the second name servers is
; external to this zone (domain).
IN NS ns2.example.net.
; PTR RR maps a IPv6 address to a host name
; hosts in subnet ID 1
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0 IN PTR ns1.example.com.
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0 IN PTR mail.example.com.
; hosts in subnet ID 2
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR joe.example.com.
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR www.example.com.
Notes: The IPv6 range 2001:db8:: is reserved for documentation purposes only by the great and mighty.
Mail Exchange Record (MX)
Defined in RFC 1035. Specifies the name and relative preference of mail servers (mail exchangers in the DNS jargon) for the zone.
Format
name ttl class rr pref name example.com. IN MX 10 mail.example.com.
The Preference field is relative to any other MX record for the zone (value 0 to 65535). Low values are more preferred. The preferred value 10 you see all over the place is just a convention you can use any number you wish. Any number of MX records may be defined. If the mail server lies within the domain it requires an A record. MX records do not need to point to a host in this zone. MX records should not point to CNAME RRs (but frequently do, see the discussion on this topic). Defining MX records for subdomains.
Examples & Variations
; zone fragment example.com
; mail servers in the same zone
$TTL 2d ; zone default = 2 days or 172800 seconds
$ORIGIN example.com.
example.com. IN SOA ns1.example.com. root.example.com. (
2003080800 ; serial number
3h ; refresh = 3 hours
15M ; update retry = 15 minutes
3W12h ; expiry = 3 weeks + 12 hours
2h20M ; minimum = 2 hours + 20 minutes
)
IN MX 10 mail ; short form
; the line above is functionally the same as the line below
; example.com. IN MX 10 mail.example.com.
; any number of mail servers may be defined
IN MX 20 mail2.example.com.
; use an external back-up
IN MX 30 mail.example.net.
; the local mail server(s) need an A record
mail IN A 192.168.0.3
mail2 IN A 192.168.0.3
No mail servers in zone:
; zone fragment for example.com
; mail servers not in the zone
$TTL 2d ; zone default = 2 days or 172800 seconds
$ORIGIN example.com.
example.com. IN SOA ns1.example.com. root.example.com. (
2003080800 ; serial number
3h ; refresh = 3 hours
15M ; update retry = 15 minutes
3W12h ; expiry = 3 weeks + 12 hours
2h20M ; minimum = 2 hours + 20 minutes
)
; mail servers not in zone - no A records required
IN MX 10 mail.foo.com.
IN MX 20 mail2.foo.com.
Subdomain MX records
You can define subdomains (aka subzones) as being fully delegated (uses a separate zone file) or as what we call virtual (or pseudo) sub-domains (uses a single zone file). The following example uses a virtual subdomain (all the definitions are contained in a single zone file).
; zone fragment for example.com
; name servers in the same zone
$TTL 2d ; zone default = 2 days or 172800 seconds
$ORIGIN example.com.
example.com. IN SOA ns1.example.com. hostmaster.example.com. (
2003080800 ; serial number
2h ; refresh = 2 hours
15M ; update retry = 15 minutes
3W12h ; expiry = 3 weeks + 12 hours
2h20M ; minimum = 2 hours + 20 minutes
)
; mail server for main domain
IN MX 10 mail.example.com.
; A record for mail server above
mail IN A 192.168.0.5
; other domain level hosts and services
....
; sub-domain definitions
$ORIGIN us.example.com.
IN MX 10 mail
; record above could have been written as
; us.example.com. IN MX 10 mail.us.example.com.
; optional - define the main mail server as backup
IN MX 20 mail.example.com.
; A record for subdomain mail server
mail IN A 10.10.0.29
; the record above could have been written as
; mail.us.example.com. A 10.10.0.29 if it's less confusing
....
; other subdomain definitions as required
An alternate way of defining the above (which we think is confusing) is shown below:
; zone fragment for example.com
; name servers in the same zone
$TTL 2d ; zone default = 2 days or 172800 seconds
$ORIGIN example.com.
example.com. IN SOA ns1.example.com. root.example.com. (
2003080800 ; serial number
2h ; refresh = 2 hours
15M ; update retry = 15 minutes
3W12h ; expiry = 3 weeks + 12 hours
2h20M ; minimum = 2 hours + 20 minutes
)
; mail server for main domain
IN MX 10 mail.example.com.
; mail server for subdomain 'us'
us IN MX 10 mail.us.example.com.
us IN MX 20 mail.example.com.
; A record for main mail server above
mail IN A 192.168.0.5
; other domain level hosts and services
....
; sub-domain definitions
$ORIGIN us.example.com.
; A record for subdomain mail server
mail IN A 10.10.0.29
; the record above could have been written as
; mail.us.example.com. A 10.10.0.28 if it's less confusing
....
; other subdomain definitions as required
Extensible Provisioning Protocol
The Extensible Provisioning Protocol (EPP) is a flexible protocol designed for allocating objects within registries over the Internet.
The motivation for the creation of EPP was to create a robust and flexible protocol that could provide communication between domain name registries and domain name registrars. These transactions are required whenever a domain name is registered or renewed, thereby also preventing Domain hijacking. Prior to its introduction, registries had no uniform approach, and many different proprietary interfaces existed.
While its use for domain names was the initial driver, the protocol is designed to be usable for any kind of ordering and fulfilment system.
The EPP protocol is based on XML - a structured, text-based format. The underlying network transport is not fixed, although the only currently specified method is over TCP. The protocol has been designed with the flexibility to allow it to use other transports such as BEEP, SMTP, or SOAP.
The protocol is the result of the IETF Provisioning Registry (provreg) working group, and was finalised in 2004.
The protocol has been adopted by a number of domain name registries, such as .fr .info, .org, .aero, .mobi, .ag, .au, .br, .bz, .cz, .eu, .gi,
.gr, .hn, .in, .me, .mn, .pl, .ro, .sc, .uk and .vc, as well as ENUM registries such as those operating the +43, +44, +41 and +31 country codes.
EPP "codes" or "keys" are also required in the transfer of generic top-level domain names between registrars (.com, .net, .org, .biz, .info). .com and .net domain names only began requiring the EPP key from fourth quarter 2006.