2013. május 10., péntek

using reverse IP entries is the recommended practice

This is a blog just to confirm my findings on the necessity on reverse IP addresses. On the contrary to recommendations of Chris Skretowski @ Flybe, registering reverse IP addresses  (along with forward entry) is the recommended way when setting up a DNS host entry. See RFC 1033, at "Adding a host" section,

 To add a new host to your zone files:

         Edit the appropriate zone file for the domain the host is in.

         Add an entry for each address of the host.

         Optionally add CNAME, HINFO, WKS, and MX records.

         Add the reverse IN-ADDR entry for each host address in the
         appropriate zone files for each network the host in on.

Told you! :-) The reverse DNS lookup looks for a PTR entry in the DNS database in the in-addr.arpa zone for IPv4 addresses.

2013. május 9., csütörtök

dig a little deeper into root servers' with dig

Here's an interesting thing I just figured out today after some inconsistencies with a company DNS records where my expertise was requested. The differing data was between the authoritative TLD servers and the company NS records. The glue records are provided by the TLD servers, in the ADDITIONAL SECTION. These are the IP addresses of the DNS servers. They've got a TTL set to 172800. That means two days. That means, if the zone is updated with the NS records containing glue records, some DNS servers might still contain the old IP addresses for NS servers until their TTL expires. So our local DNS servers still had the timeout value of 61476, showing the outdated IP address value for the secondary DNS server as well as the TLD DNS servers. 

[miklos.quartus@miklos-mac: ~]$ dig +norec @b.gtld-servers.net sdgtl.net NS

; <<>> DiG 9.8.3-P1 <<>> +norec @b.gtld-servers.net sdgtl.net NS
; (1 server found)
;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- 17165="" font="" id:="" noerror="" opcode:="" query="" status:="">

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;sdgtl.net. IN NS

sdgtl.net. 172800 IN NS ns1.sdgtl.net.
sdgtl.net. 172800 IN NS ns4.sdgtl.net.

ns1.sdgtl.net. 172800 IN A
ns4.sdgtl.net. 172800 IN A

;; Query time: 37 msec
;; WHEN: Thu May 9 17:51:22 2013
;; MSG SIZE rcvd: 95

[miklos.quartus@miklos-mac: ~]$

As you see above, the TLD responds with the TTL value of 172800, which is exactly two days. However, our DNS servers lagging behind due to their TTL value is still active and not yet expired. See below the query result of our servers. 


[miklos.quartus@miklos-mac: ~]$ host -v ns4.sdgtl.net 10.Z.X.Y
Trying "ns4.sdgtl.net"

Using domain server:
Name: 10.Z.X.Y
Address: 10.Z.X.Y#53

;; ->>HEADER<<- 32901="" font="" id:="" noerror="" opcode:="" query="" status:="">

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;ns4.sdgtl.net. IN A

ns4.sdgtl.net. 61476 IN A

Received 47 bytes from 10.Z.X.Y#53 in 38 ms

Look above: the current value is 61476 seconds! I figured out that our DNS servers still have the old IP address value ( is the old value, correct value is and need about cca. 17 hours to have their TTL expire. In the meantime, I found out how to query any TLD domain's authoritative NS servers. Let's take for e.g. the .net domain. 

[miklos.quartus@miklos-mac: ~]$ dig +short net. NS

Voila! The above list shows the list of authoritative name servers for the .net TLD. Anyway. If the domain registrar's settings are wrongly containing the DNS server IP addresses, they continue to provide the wrong, outdated values for glue records, despite the right values are inside the authoritative domain zone. Solution: fix the domain registrar's values so that the correct IP address should be registered for the NS servers.