Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Networking - DNS - Zone Transfers (AXFR request) ======

Zone transfers are done by secondary nameservers to retrieve the latest and updated zone information for domain from the master or primary nameserver.

Zone transfers should only be made available to secondary nameservers and not to the open world as it is a big security risk and may expose the internals of your network to the attacker.

To request a zone transfer for example.com we need to ask the master nameserver first.  See the below example with dig.

<code bash>
dig @ns1.example.com example.com
</code>

If you see the output with full zone file, then you have to disable the zone transfer.  In most cases you will see connection failed or REFUSED which means zone transfer is not allowed and its a good thing.

----

===== Common DNS Errors in Zone file Writing =====

1. No CNAME pointing to NS records

<code bash>
domain.com.     IN    NS     ns1.domain.com.
domain.com.     IN    NS     ns2.domain.com.
domain.com.     IN    CNAME  ns9.example-server.net -----> WRONG
</code>

Placing CNAME along with NS the all of namservers will fail and will result in lame delegation. Don't do that!

Refer to RFC1912 2.4 [http://tools.ietf.org/html/rfc2181] and RFC2181 10.3 [http://tools.ietf.org/html/rfc1912].

 
2. Avoid running DNS servers on IPs on same subnet (/24) or on same server.

The whole purpose of DNS is for nameservers to be spread over different geographical locations so that if one dns fails the other would work.  Although it is very common practice to run both nameservers on same server or subnet, it would not provide fault tolerance.  If the server fails your nameservers will fail and your site wont load.

<code bash>
ns1 IN A 75.33.22.xx -----> same subnet /24
ns2 IN A 75.33.22.xx -----> same subnet /24
</code>
 
3. Proper GLUE

Always add glue to your NS records to the IP addresses using A record, failing which one of your nameservers will fail.

<code bash>
domain.com. IN NS ns1.domain.com.
domain.com. IN NS ns2.domain.com.

ns1 IN A 1.2.3.4 -----> GLUE
ns2 IN A 2.4.6.9 -----> GLUE
</code>

Refer to RFC1912 [http://tools.ietf.org/html/rfc1912].

 
4. No duplicate MX records

<code bash>
domain.com. IN MX mail.domain.com.
domain.com. IN MX mail.domain.com  ----> DUPLICATE
</code>

 
5. Allow Port 53 for both UDP and TCP connections

If you use firewall make sure you do not block port 53 for DNS tcp and udp requests.  By default dns lookups use UDP protocol while zone transfers and notifications use TCP protocol of port 53.

<code bash>
Port 53 UDP = Dns Requests
Port 53 TCP = Zone transfers
</code>

 
6. CNAMEs cannot co-exist with MX hosts.

Do not specify CNAME or aliases pointing to MX records.

<code bash>
domain.com. IN MX 10 mail.domain.com.
mail        IN CNAME domain.com.  ----------> WRONG
</code>

Instead use A record to map directly to IP address.

<code bash>
mail IN A 11.33.55.77 ---> CORRECT
</code>

Refer to RFC1912 [http://tools.ietf.org/html/rfc1912].

 
7. MX Records should not contain IP addresses

<code bash>
domain.com. IN 10 MX mail.domain.com. ----> CORRECT
domain.com. IN 20 MX 11.22.33.44  -----> WRONG
</code>

The correct way of doing this is glue the MX host to A record.

<code bash>
domain.com. IN MX 10 mail.domain.com. -----> CORRECT
mail IN A 11.33.55.77 ----------> CORRECT
</code>
 
8. NS records should NOT contain IP address

Always specify nameservers for your domain with NS records.  It should be a name and not IP address.

<code bash>
domain.com. IN NS dns0.domain.com. -----> CORRECT
domain.com. IN NS  75.xx.xx.xx -----------> WRONG
</code>