Did you know that Authoritative DNS servers consist of primary and one or more backup or secondary servers? Did you also know that they are supposed to be in sync?
It is important that the servers be in sync. Why? a record in the primary may be very different from the same record in the secondary - especially if it was just changed. A query might get the wrong information (like an IP) if the secondary returns the record instead of the primary. That's why it is important to sync them fairly quickly.
The DNS servers are listed when you do a 'whois' query for a domain. Most domains have only two, a primary and secondary. When changes are made to the primary, then they are migrated to the secondary so that if for some reason the primary does not respond to DNS queries, the secondary may continue to do so.
It is important to know if those primary and secondary servers are in sync. You can look at the SOA serial field to find out. Normally they are identical for all DNS servers. If they are not, then that indicates a problem. You can use NSLOOKUP to retrieve the SOA records from each DNS (primary and secondary). This is a tedious process if there are more than two servers to look at.
We have a tool in NetScanTools Pro that simplifies this process by doing the queries for you very quickly. That way you can see a quick snapshot of the DNS update situation. It is part of the DNS Tools - Advanced and it is called "Auth Serial Check".
Here in this example for our domain showing matching serials. Note that the program looks that them to make sure they are OK:
[Start Query]
Authoritative DNS Serial Check
Starting Timestamp: 04/21/10 17:00:28
Query: netscantools.com
NS: ns2.webnethost.net -- Serial: 2010020400
NS: ns1.webnethost.net -- Serial: 2010020400
Analysis: All serial numbers are identical, no problems detected.
[End Query]
And now here is a query showing microsoft.com's DNS serials. Note that certain DNS servers are out of date with others. "ns1" is the primary and the others are backup.
[Start Query]
Authoritative DNS Serial Check
Starting Timestamp: 04/21/10 16:44:23
Query: microsoft.com
NS: ns3.msft.net -- Serial: 2010042102
NS: ns5.msft.net -- Serial: 2010042101
NS: ns1.msft.net -- Serial: 2010042102
NS: ns4.msft.net -- Serial: 2010042102
NS: ns2.msft.net -- Serial: 2010042101
Analysis: One or more serial numbers are out of sync with the other serial numbers.
[End Query]
I checked again 15 minutes later and found that all DNS serials in the microsoft.com listing were the same. This is probably normal for a domain of this size because it may take awhile to transfer the zone updates from the primary to the secondaries. I checked the SOA record and I could see that the refresh interval is 5 minutes and the retry interval is 10 minutes, so their DNS should not be out of sync for long. It's unusual to see this, so I thought it would make a good example.
A note about the serial field formatting. These both conform to what is now recommended where the serial is human readable. In the case of microsoft.com, you can see that it is April 21 2010, update numbers 1 and 2. In the case of netscantools.com, you can see that the serial has not changed since February 4, 2010. Not all serials conform to this method. Some are just straight incremental numbers.
You can try out the Auth Serial Check tool in the NetScanTools Pro Demo at our website.
Showing posts with label AXFR. Show all posts
Showing posts with label AXFR. Show all posts
Wednesday, April 21, 2010
Thursday, December 4, 2008
Specialized DNS Tools
Authoritative DNS servers are databases that contain all the records describing a domain in what are called 'zones'. When you do an IP address lookup of a hostname within a domain, that query may end up going all the way to the authoritative servers using a process known as recursion or it may come from a cached record along the way.
There are usually two authoritative servers, but sometimes more servers are used in the case of a large company with a distributed network. In some DNS implementations, the DNS maintainer changes a record like an MX record defining which machine handles SMTP email by hand and at the same time changes the serial number to show that the zone was altered. This serial number change is automated in other implementions.
The secondary servers get zone information from the primary server when they see that the serial number in SOA record in the primary server is different than the serial number currently in the secondary server. If the serial numbers are not the same, then a "zone transfer" is initiated either using a full zone AXFR or an incremental zone IXFR transfer.
As a side note, zone serial numbers are usually in one of two formats, the first being the most common: YYYYMMDDNN format, where YYYY is the year (four digits), MM is the month (two digits), DD is the day of month (two digits) and nn is the version per day (two digits); the second format is unix time, ie. the number of seconds since Jan 1, 1970. Some DNS maintainers use a simple incrementing number like a revision number.
If there is a breakdown in the process of replicating data between the primary and secondary servers (some DNS software can use methods other than zone transfers), the serial numbers may end up out of sync--especially if the serial number is maintained by hand. To check this, a DNS maintainer would have to individually query each authoritative DNS for its current serial number using NSLOOKUP or DIG to verify that they are all in sync.
To help speed up this process, I have created a new tool that finds the authoritative servers for a domain, then it quickly checks each authoritative server for serial number mismatches. It analyzes the results and tells you if there is a problem -- and since we show each authoritative server with its serial number for the zone, you can quickly see the results yourself. This new tool is tentatively called "Auth Serial Check" and it appears in the new DNS Tools - Advanced window in NetScanTools Pro 10.8 (which is not out yet -- be patient).
There are usually two authoritative servers, but sometimes more servers are used in the case of a large company with a distributed network. In some DNS implementations, the DNS maintainer changes a record like an MX record defining which machine handles SMTP email by hand and at the same time changes the serial number to show that the zone was altered. This serial number change is automated in other implementions.
The secondary servers get zone information from the primary server when they see that the serial number in SOA record in the primary server is different than the serial number currently in the secondary server. If the serial numbers are not the same, then a "zone transfer" is initiated either using a full zone AXFR or an incremental zone IXFR transfer.
As a side note, zone serial numbers are usually in one of two formats, the first being the most common: YYYYMMDDNN format, where YYYY is the year (four digits), MM is the month (two digits), DD is the day of month (two digits) and nn is the version per day (two digits); the second format is unix time, ie. the number of seconds since Jan 1, 1970. Some DNS maintainers use a simple incrementing number like a revision number.
If there is a breakdown in the process of replicating data between the primary and secondary servers (some DNS software can use methods other than zone transfers), the serial numbers may end up out of sync--especially if the serial number is maintained by hand. To check this, a DNS maintainer would have to individually query each authoritative DNS for its current serial number using NSLOOKUP or DIG to verify that they are all in sync.
To help speed up this process, I have created a new tool that finds the authoritative servers for a domain, then it quickly checks each authoritative server for serial number mismatches. It analyzes the results and tells you if there is a problem -- and since we show each authoritative server with its serial number for the zone, you can quickly see the results yourself. This new tool is tentatively called "Auth Serial Check" and it appears in the new DNS Tools - Advanced window in NetScanTools Pro 10.8 (which is not out yet -- be patient).
Subscribe to:
Posts (Atom)