Have you needed to find the root DNS servers for a particular top level domain?
Applies to: NetScanTools Pro, NetScanTools LE, NetScanTools Basic, NetScanTools Standard (obsolete).
It’s actually pretty easy, but how you enter the top level domain makes all the difference in the world. Examples of a top level domain are: .uk, .com, .nu, .se, .ca etc.
How to do it:
1. Switch to the DNS Tools – Core tool or on older software, the Name Server Lookup tool.
2. Enter the DNS you are going use under Advanced Query.
3. Select the NS record type, you may have to go into AQ Setup or Setup to do this.
4. Enter the top level extension in the IP/host/domain entry area. The correct method is to enter the extension followed by a period: ca. or uk. or com. –if you leave off the period or put the period before the extension, the query will fail.
5. Press NSLOOKUP.
Results will look like these two examples, the first for .ca (Canada) and the second for .se (Sweden):
[Start Query]
NSLOOKUP Starting Timestamp: 02/24/11 14:49:37
Command line equivalent: "nslookup -recurse -type=NS ca."
Looking up [ca.]
DNS Name: 4.2.2.2
IP Address: 4.2.2.2
Non-authoritative answer:
ca NS nameserver = f.ca-servers.ca
ca NS nameserver = e.ca-servers.ca
ca NS nameserver = j.ca-servers.ca
ca NS nameserver = a.ca-servers.ca
ca NS nameserver = c.ca-servers.ca
ca NS nameserver = m.ca-servers.ca
ca NS nameserver = l.ca-servers.ca
ca NS nameserver = z.ca-servers.ca
ca NS nameserver = k.ca-servers.ca
ca NS nameserver = sns-pb.isc.org
Server Response Time = 0.117 seconds
[End Query]
[Start Query]
NSLOOKUP Starting Timestamp: 02/24/11 14:54:34
Command line equivalent: "nslookup -recurse -type=NS se."
Looking up [se.]
DNS Name: 4.2.2.2
IP Address: 4.2.2.2
Non-authoritative answer:
se NS nameserver = d.ns.se
se NS nameserver = e.ns.se
se NS nameserver = c.ns.se
se NS nameserver = a.ns.se
se NS nameserver = b.ns.se
se NS nameserver = g.ns.se
se NS nameserver = h.ns.se
se NS nameserver = i.ns.se
se NS nameserver = f.ns.se
se NS nameserver = j.ns.se
Server Response Time = 0.430 seconds
[End Query]
What you see in the two examples above are the authoritative name servers for the root domains.
Showing posts with label nslookup. Show all posts
Showing posts with label nslookup. Show all posts
Thursday, March 3, 2011
Monday, November 15, 2010
looking at top level domains
Here is a cool thing you can do with NetScanTools Pro. Have you ever needed to look at a top level domain to see name servers or SOA records? It's actually pretty simple and can have some pretty spectacular results.
The other day I wanted to look at the 'bs' domain - really, no kidding. I went to DNS Tools - Core, then entered 'bs.' (the trailing period is REQUIRED), set the name server and set the record type to ANY and pressed NSLOOKUP. Here is what I got back:
[Start Query]
NSLOOKUP Starting Timestamp: 11/15/10 22:35:06
Command line equivalent: "nslookup -recurse -vc -type=ANY bs."
Looking up [bs.]
DNS Name: 4.2.2.2
IP Address: 4.2.2.2
Non-authoritative answer:
bs SOA
SOA origin = DNS.NIC.bs
mail addr = BSADMIN.COB.EDU.bs
serial = 2010111200
refresh = 7200 (2 hours)
retry = 3600 (1 hour)
expire = 3600000 (41 days 16 hours)
min ttl = 86400 (1 day)
bs RRSIG
TTL = 42797 (11 hours 53 mins 17 secs)
NSEC (Next Secure)
Labels = 1
Original TTL = 86400 (1 day)
Signature Expiration = Sun Nov 21 16:00:00 2010
Time Signed = Sun Nov 14 15:00:00 2010
Key Tag = 40288
Signer's Name:
Signature Length: 128 bytes
Signature:
54 0D 4E 76 3B B5 59 45 74 15 AF B1 6F 9A D1 5B
ED FD 19 8A 78 6A D7 70 D5 C9 91 8B 2D 70 B1 E3
21 6D CA 08 A0 28 CF CC 93 63 91 92 FA EC 57 E3
2C 3C DB F9 DD F9 43 2B 90 C6 65 64 7F A0 D3 CA
6B 26 4C 7C 7D 24 1E FE D1 2B 5A F4 17 62 39 C6
C4 AD 2E 37 DD D0 AC 3C E8 53 43 89 AF F3 6D 14
98 F8 DC 1C EC DC 4E 24 B9 8A 2E 06 6E 92 75 F8
18 6E DD 12 63 0E 9D 2D 0A B7 94 3E AF 1D CF 96
bs NSEC
TTL = 42797 (11 hours 53 mins 17 secs)
Next Domain Name: bt
RR Types in Bitmap: NS RRSIG NSEC
bs NS nameserver = DNS.NIC.bs
bs NS nameserver = ANYNS.PCH.NET
bs NS nameserver = UPR1.UPR.CLU.EDU
Server Response Time = 0.233 seconds
[End Query]
As you can see I got back the SOA record, the list of authoritative name servers and the security signature records. Notice how for a top level domain, the authoritative server has mirrors around the world, not just in Bahamas. In fact, there are only three mirrors showing - most top level domains have a lot more than that - the UK has 11. Notice also the domain security record - since last May most top level domains have those records in order to ensure the accuracy of the root data.
You can use the NSLOOKUP tool to inspect the records for any top level domain by following the procedure I outlined above.
The other day I wanted to look at the 'bs' domain - really, no kidding. I went to DNS Tools - Core, then entered 'bs.' (the trailing period is REQUIRED), set the name server and set the record type to ANY and pressed NSLOOKUP. Here is what I got back:
[Start Query]
NSLOOKUP Starting Timestamp: 11/15/10 22:35:06
Command line equivalent: "nslookup -recurse -vc -type=ANY bs."
Looking up [bs.]
DNS Name: 4.2.2.2
IP Address: 4.2.2.2
Non-authoritative answer:
bs SOA
SOA origin = DNS.NIC.bs
mail addr = BSADMIN.COB.EDU.bs
serial = 2010111200
refresh = 7200 (2 hours)
retry = 3600 (1 hour)
expire = 3600000 (41 days 16 hours)
min ttl = 86400 (1 day)
bs RRSIG
TTL = 42797 (11 hours 53 mins 17 secs)
NSEC (Next Secure)
Labels = 1
Original TTL = 86400 (1 day)
Signature Expiration = Sun Nov 21 16:00:00 2010
Time Signed = Sun Nov 14 15:00:00 2010
Key Tag = 40288
Signer's Name:
Signature Length: 128 bytes
Signature:
54 0D 4E 76 3B B5 59 45 74 15 AF B1 6F 9A D1 5B
ED FD 19 8A 78 6A D7 70 D5 C9 91 8B 2D 70 B1 E3
21 6D CA 08 A0 28 CF CC 93 63 91 92 FA EC 57 E3
2C 3C DB F9 DD F9 43 2B 90 C6 65 64 7F A0 D3 CA
6B 26 4C 7C 7D 24 1E FE D1 2B 5A F4 17 62 39 C6
C4 AD 2E 37 DD D0 AC 3C E8 53 43 89 AF F3 6D 14
98 F8 DC 1C EC DC 4E 24 B9 8A 2E 06 6E 92 75 F8
18 6E DD 12 63 0E 9D 2D 0A B7 94 3E AF 1D CF 96
bs NSEC
TTL = 42797 (11 hours 53 mins 17 secs)
Next Domain Name: bt
RR Types in Bitmap: NS RRSIG NSEC
bs NS nameserver = DNS.NIC.bs
bs NS nameserver = ANYNS.PCH.NET
bs NS nameserver = UPR1.UPR.CLU.EDU
Server Response Time = 0.233 seconds
[End Query]
As you can see I got back the SOA record, the list of authoritative name servers and the security signature records. Notice how for a top level domain, the authoritative server has mirrors around the world, not just in Bahamas. In fact, there are only three mirrors showing - most top level domains have a lot more than that - the UK has 11. Notice also the domain security record - since last May most top level domains have those records in order to ensure the accuracy of the root data.
You can use the NSLOOKUP tool to inspect the records for any top level domain by following the procedure I outlined above.
Wednesday, April 21, 2010
Checking Authoritative DNS Serial Numbers
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.
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.
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)