Problem Querying ru. Name Servers

Jan 06, 2009 | 4 minutes read
Share this:

Tag: Network

In a previous position, I encounter a rather strange problem I would like to share here. It has to do with DNS resolution. From the internal network of a company it was not possible to get the IP address of the host name.

We determined that the name servers which manage the domain are and In the same time, we saw that for the domain name, the managing name servers are and Interestingly, it was possible to resolve using, but not from More, we noted that the reverse resolution for the name servers and are not correct, translated to and, respectively. So, it is worth to mention that nothing was wrong when querying the name server

# host -t a has address
# host -t a has address
# host -t ptr domain name pointer
# host -t ptr domain name pointer

The error from the DNS query seems to be related to an incomplete answer from the server (the truncated flag was set to 1 in the network trace) when the query is made over UDP. In this case, an automatic fallback over TCP must be used, certainly prohibited from the company's network security policy. This may say that the answer is larger than 512 bytes long, too. So, we tried to advertise different sizes of the UDP message buffer, but without being confident that this message went through network devices properly. Nonetheless it would seem curious to get an answer larger that 120 bytes long.

Last, we can note that the complexity of the network layout (DMZ, firewalls, NAT, etc.) may badly interact and hamper DNS queries, at least in certain circumstances.

After more investigation from the network team, they decided to permit TCP DNS queries. And it worked. It worked letting the internal DNS servers doing their job themselves...

# dig +trace -t a
; <<>> DiG 9.3.4-P1 <<>> +trace
;; global options:  printcmd
.                       449798  IN   NS   L.ROOT-SERVERS.NET.
.                       449798  IN   NS   M.ROOT-SERVERS.NET.
.                       449798  IN   NS   A.ROOT-SERVERS.NET.
.                       449798  IN   NS   B.ROOT-SERVERS.NET.
.                       449798  IN   NS   C.ROOT-SERVERS.NET.
.                       449798  IN   NS   D.ROOT-SERVERS.NET.
.                       449798  IN   NS   E.ROOT-SERVERS.NET.
.                       449798  IN   NS   F.ROOT-SERVERS.NET.
.                       449798  IN   NS   G.ROOT-SERVERS.NET.
.                       449798  IN   NS   H.ROOT-SERVERS.NET.
.                       449798  IN   NS   I.ROOT-SERVERS.NET.
.                       449798  IN   NS   J.ROOT-SERVERS.NET.
.                       449798  IN   NS   K.ROOT-SERVERS.NET.
;; Received 512 bytes from in 0 ms

ru.                   172800  IN   NS
ru.                   172800  IN   NS
ru.                   172800  IN   NS
ru.                   172800  IN   NS
ru.                   172800  IN   NS
ru.                   172800  IN   NS
;; Received 297 bytes from in 125 ms   345600  IN   NS   345600  IN   NS
;; Received 107 bytes from in 66 ms   86400   IN   A            86400   IN   NS            86400   IN   NS
;; Received 91 bytes from in 65 ms

... and it worked when querying directly the name servers responsible for the wanted domain:

# dig -t a
; <<>> DiG 9.3.4-P1 <<>> -t a
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1530
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;             IN   A

;; ANSWER SECTION:      86400   IN   A

;; AUTHORITY SECTION:          86400   IN   NS          86400   IN   NS

;; Query time: 65 msec
;; WHEN: Tue Apr 15 21:05:12 2008
;; MSG SIZE  rcvd: 91

Note: The size of the answer is 91 bytes long, so nothing wrong from this side.

I think we will never know what was going wrong here, even if the heart of the problem seems related specifically only to the two same name servers.