A class DNS query

[Martin Hui]

Hi,

My DNS always have the following alerts in syslog. Kindly anyone in here can tell me what happened.
-----------------------------------------------
Apr 21 15:11:11 DNS02 named[9529]: ns_req: no address for root server
Apr 21 15:11:11 DNS02 named[9529]: sysquery: no addrs found for root NS ()
Apr 21 15:11:25 DNS02 named[9529]: sysquery: no addrs found for root NS (dns0.sonera.grx)
Apr 21 15:11:25 DNS02 named[9529]: sysquery: no addrs found for root NS (dns1.sonera.grx)
Apr 21 15:11:25 DNS02 named[9529]: ns_req: no address for root server
Apr 21 15:11:25 DNS02 named[9529]: sysquery: no addrs found for root NS ()
Apr 21 15:11:58 DNS02 named[9529]: sysquery: no addrs found for root NS (dns0.sonera.grx)
Apr 21 15:11:58 DNS02 named[9529]: sysquery: no addrs found for root NS (dns1.sonera.grx)
----------------------------------------------

Thank you.

martin

[Mauro Gatti]

Hallo Martin, try to read this:
http://www.intac.com/~cdp/cptd-faq/section6.html#root
http://www.reedmedia.net/misc/dns/errors.html

I don't know if these will be usefull...

Bye

RGDS

Mauro

[Todd Whitcher]

Hi Martin,

That message indicates you are missing or have a corrupt entry for the Address record for the dns0 nameserver in your root hints file. You should have a NS record for the root server and a A record for it.

Something like this:

. 99999999 IN NS dns0.sonera.grx.
dns0.sonera.grx. 99999999 IN A ip_of_dns0


Hope that helps, check your root hints file which can be called anything but is typically called db.cache. Reference your named.conf file to see what your root hints line is pointing to.

ex
zone "." {
type hint;
file "db.cache";
};


Todd

[Martin Hui]

Hi Tod,

We have done more or less the samething as you said except that we use 3600000 instead of 99999999.

After changing the hint file, we stopped/started the named in yesterday afternoon

However, when we checked the syslog tody, we found that same alerts were caputed in this early morning.

Do you have any clue?

I also have another question.

Our root DNS set the TTL differently for both NS and A records.

From the captured data, our root DNS provider set the TTL = 1 day in A record and TTL = 2 days in NS record.

Will this cause my DNS have such alerts after the TTL expires?

Thanks in advance.

Best regards,
Martin

[Todd Whitcher]

Hi Martin,

I dont see a problem w/ having different time to live (ttl) for your A and NS records, typically they are the same. The errors are still indicating the same issue, you can't get a A record for dns0 or dns1.

Since the message says no address found for root name server dns1.sonera.grx what happens when you look up that server from the system logging those messages?

You can use nslookup or dig to test.

nslookup
> set q=A
> dns0.sonera.grx

You should get the address records returned, note which nameserver answers your query.

> dns1.sonera.grx

Next test to see if dns1 and dns0 return in your name server query, note which nameserver answers the query.

> set q=NS
> sonera.grx

I would expect to see dns1 and dns0 returned.

Hope that helps,

[Martin Hui]

Hi Todd,

I did what you described. When i did the followings:-

-------------

Next test to see if dns1 and dns0 return in your name server query, note which nameserver answers the query.

> set q=NS
> sonera.grx

-------------

I could not see dns1 and dns0 returned. Instead, my dns prompted me with:

""can't find sonera.grx: non-existent host/domain.""

What should i do next?? HELP!!

Thanks

[Todd Whitcher]

Hi Martin,

This sounds like a configuration issue to me. The nslookup is just proving that the record does not exist, I'd suspect some errors during startup of named.Can you show me your /etc/named.conf entry on your nameserver for your root hints file? Can you also show me the file you are using for your root hints file, ex. db.cache.

When you issue nslookup, are you on the dns server? Can you point nslookup to the dns server you are setting up and get it to respond?

>nslookup
> server name_of_dns_server
> dns0.sonera.grx.

Can you show me the named messages when your nameserver starts up from syslog.log? Just grep named out of your syslog.log file.


I will not be available to check your response for the rest of today, you may want to open a case with the HP response center and provide them w/ the data from your nameserver for assistance. I can check on your message on Friday.

Todd

[Martin Hui]

Hi Todd,

The same thing happened to me again today.

Here is the snapshot on my /etc/named.conf
-----------
zone "." {
type hint;
file "root.hint";
};
-----------
File "root.hint" looks like as below:-
-----------
. 99999999 IN NS DNS0.SONERA.GRX.
. 99999999 IN NS DNS1.SONERA.GRX.
. 99999999 IN NS DNS2.SONERA.GRX.
DNS0.SONERA.GRX. 99999999 IN A 194.215.72.38
DNS1.SONERA.GRX. 99999999 IN A 194.215.72.69
DNS2.SONERA.GRX. 99999999 IN A 194.215.72.141
--------------
When i test the followings again:-
--------------
> set q=A
> dns0.sonera.grx
--------------
we got the following output from local DNS.
------------------------------------------
> set q=A
> dns0.sonera.grx
Server: dns01.oam.com
Address: 192.168.1.3

*** dns01.oam.com can't find dns0.sonera.grx: Non-existent host/domain
-------------------------------------------
syslog.log alert
---------------------------------------
Apr 23 17:10:28 DNS01 named[26523]: sysquery: no addrs found for root NS (dns0.sonera.grx)
Apr 23 17:11:33 DNS01 named[26523]: sysquery: no addrs found for root NS (dns2.sonera.grx)
Apr 23 17:11:33 DNS01 named[26523]: sysquery: no addrs found for root NS (dns0.sonera.grx)
Apr 23 17:11:33 DNS01 named[26523]: sysquery: no addrs found for root NS (dns2.sonera.grx)
Apr 23 17:11:33 DNS01 named[26523]: sysquery: no addrs found for root NS ()
--------------------------------------------

As i mentioned before, the TTL for A and NS record is different. This thing was happened when the A record information was expired in our local DNS.

Please find the following logs.

Before A record TTL expires, we have the following:-
---------------------------------
Got answer (129 bytes):
HEADER:
opcode = QUERY, id = 45435, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 3, authority records = 0, additional = 3

QUESTIONS:
(root), type = NS, class = IN
ANSWERS:
-> (root)
type = NS, class = IN, dlen = 17
nameserver = dns1.sonera.grx
ttl = 92426 (1d1h40m26s)
-> (root)
type = NS, class = IN, dlen = 7
nameserver = dns2.sonera.grx
ttl = 92426 (1d1h40m26s)
-> (root)
type = NS, class = IN, dlen = 7
nameserver = dns0.sonera.grx
ttl = 92426 (1d1h40m26s)
ADDITIONAL RECORDS:
-> dns1.sonera.grx
type = A, class = IN, dlen = 4
internet address = 194.215.72.69
ttl = 6026 (1h40m26s)
-> dns2.sonera.grx
type = A, class = IN, dlen = 4
internet address = 194.215.72.141
ttl = 6026 (1h40m26s)
-> dns0.sonera.grx
type = A, class = IN, dlen = 4
internet address = 194.215.72.38
ttl = 6026 (1h40m26s)

------------
Non-authoritative answer:
(root)
type = NS, class = IN, dlen = 17
nameserver = dns1.sonera.grx
ttl = 92426 (1d1h40m26s)
(root)
type = NS, class = IN, dlen = 7
nameserver = dns2.sonera.grx
ttl = 92426 (1d1h40m26s)
(root)
type = NS, class = IN, dlen = 7
nameserver = dns0.sonera.grx
ttl = 92426 (1d1h40m26s)

Authoritative answers can be found from:
dns1.sonera.grx
type = A, class = IN, dlen = 4
internet address = 194.215.72.69
ttl = 6026 (1h40m26s)
dns2.sonera.grx
type = A, class = IN, dlen = 4
internet address = 194.215.72.141
ttl = 6026 (1h40m26s)
dns0.sonera.grx
type = A, class = IN, dlen = 4
internet address = 194.215.72.38
ttl = 6026 (1h40m26s)
-------------------------------------------

After the A record TTL expires, sonera IP address information was gone as seen below:-

-------------------------------------------

> .
Server: dns01.oam.com
Address: 192.168.1.3

;; res_nmkquery(QUERY, , IN, NS)
------------
SendRequest(), len 17
HEADER:
opcode = QUERY, id = 43538, rcode = NOERROR
header flags: query, want recursion
questions = 1, answers = 0, authority records = 0, additional = 0

QUESTIONS:
(root), type = NS, class = IN

------------
------------
Got answer (81 bytes):
HEADER:
opcode = QUERY, id = 43538, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 3, authority records = 0, additional = 0

QUESTIONS:
(root), type = NS, class = IN
ANSWERS:
-> (root)
type = NS, class = IN, dlen = 17
nameserver = dns2.sonera.grx
ttl = 85498 (23h44m58s)
-> (root)
type = NS, class = IN, dlen = 7
nameserver = dns0.sonera.grx
ttl = 85498 (23h44m58s)
-> (root)
type = NS, class = IN, dlen = 7
nameserver = dns1.sonera.grx
ttl = 85498 (23h44m58s)

------------
Non-authoritative answer:
(root)
type = NS, class = IN, dlen = 17
nameserver = dns2.sonera.grx
ttl = 85498 (23h44m58s)
(root)
type = NS, class = IN, dlen = 7
nameserver = dns0.sonera.grx
ttl = 85498 (23h44m58s)
(root)
type = NS, class = IN, dlen = 7
nameserver = dns1.sonera.grx
ttl = 85498 (23h44m58s)
>
------------------------------

Another interesting question why our DNS cannot over-ride our root DNS TTL even we have used 999999999.

Thank you in advance for your help over the past few days.

martin

[Todd Whitcher]

Hi Martin,

That is interesting. I broke out the O'Reilly DNS book 4th edition pg 69 and took a look at the ttl description since I was under the impression it was not needed anymore. This is what it states:

"What are the 3600000s for? Thats an explicit time to live for the records in the file. In older versions of this file, this number was 99999999. Since the contents of thsi file were originally cached, the name server needed to know how long to keep those records active. 99999999 seconds was just a very long time-the root name server data was to be kept in cache for as long as the server ran.

Since the name server now stores this data in a special place and does'nt discard it if it times out, the TTL is unnecessary. But it is not harmfull to have the 3600000s, and it makes for interesting BIND folklore when you pass responsibility to the next name server administor.

So there appears to be an issue w/ your nameserver timing out your root hints records when it should not be. What version of bind are you running on your system?

[Todd Whitcher]

Martin,

Another thought is that your getting the ttl from the dns0 dns1 dns2 directly. Try to point dig at the dns0 dns1 and dns2 nameservers and query for the root nameservers or for their A and NS records. Its possible a SOA record may be overwriting the TTL? I'm not sure.

- dig @dns0.sonera.grx . NS
- dig @dns1.sonera.grx . NS
- dig @dns2.sonera.grx . NS

Test w/ A records and NS records also, see if your getting conflicint TTL's.

- dig @dns0.sonera.grx dns0.sonera.grx A
- dig @dns1.sonera.grx dns1.sonera.grx A

etc.

Test each one and see if you are getting some conflicting TTL for your A records etc.

Possibly one of the root nameservers is providing the short TTL and hosing things up?

Hope that helps,

Todd

[Martin Hui]

Hi Todd,

Can you show me how to use "point dig" with an illustrating example? i never use this before.

- dig @dns0.sonera.grx . NS ??

Thanks

martin

[Todd Whitcher]

You can use the @server_name to point dns to dns0 dns1 etc.

For example:

I'm going to query the hp nameserver www.atl.hp.com for the nameserver records for google.com. I use the following command.

# dig @www.atl.hp.com google.com NS

dig @www.atl.hp.com google.com. NS

; <<>> DiG named 9.2.0 <<>> @www.atl.hp.com google.com. NS
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3211
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4

;; QUESTION SECTION:
;google.com. IN NS

;; ANSWER SECTION:
google.com. 288180 IN NS ns4.google.com.
google.com. 288180 IN NS ns1.google.com.
google.com. 288180 IN NS ns2.google.com.
google.com. 288180 IN NS ns3.google.com.

;; ADDITIONAL SECTION:
ns1.google.com. 113540 IN A 216.239.32.10
ns2.google.com. 335396 IN A 216.239.34.10
ns3.google.com. 113547 IN A 216.239.36.10
ns4.google.com. 96563 IN A 216.239.38.10

;; Query time: 16 msec
;; SERVER: 15.51.240.8#53(www.atl.hp.com)
;; WHEN: Fri Apr 23 11:35:25 2004
;; MSG SIZE rcvd: 164


Lets say I want to know what my nameserver has as the root nameservers ( whats in its root hints file). I can just put a "." in the query.


Show me the root "." nameservers

#dig @www.atl.hp.com . NS

; <<>> DiG named 9.2.0 <<>> @www.atl.hp.com . ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16146
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;. IN NS

;; ANSWER SECTION:
. 351317 IN NS E.ROOT-SERVERS.NET.
. 351317 IN NS F.ROOT-SERVERS.NET.
. 351317 IN NS G.ROOT-SERVERS.NET.
. 351317 IN NS H.ROOT-SERVERS.NET.
. 351317 IN NS I.ROOT-SERVERS.NET.
. 351317 IN NS J.ROOT-SERVERS.NET.
. 351317 IN NS K.ROOT-SERVERS.NET.
. 351317 IN NS L.ROOT-SERVERS.NET.
. 351317 IN NS M.ROOT-SERVERS.NET.
. 351317 IN NS A.ROOT-SERVERS.NET.
. 351317 IN NS B.ROOT-SERVERS.NET.
. 351317 IN NS C.ROOT-SERVERS.NET.
. 351317 IN NS D.ROOT-SERVERS.NET.

;; Query time: 11 msec
;; SERVER: 15.51.240.8#53(www.atl.hp.com)
;; WHEN: Fri Apr 23 11:37:24 2004
;; MSG SIZE rcvd: 228


Does this help?

Todd

[Martin Hui]

Hi Todd,

I finished with use "dig point". Can you see any conflict from the result?

# dig @dns0.sonera.grx. NS

; <<>> DiG 8.3 <<>> @dns0.sonera.grx. NS
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3
;; QUERY SECTION:
;; ., type = NS, class = IN

;; ANSWER SECTION:
. 2D IN NS dns1.sonera.grx.
. 2D IN NS dns2.sonera.grx.
. 2D IN NS dns0.sonera.grx.

;; ADDITIONAL SECTION:
dns0.sonera.grx. 1D IN A 194.215.72.38
dns1.sonera.grx. 1D IN A 194.215.72.69
dns2.sonera.grx. 1D IN A 194.215.72.141

;; Total query time: 265 msec
;; FROM: DNS01 to SERVER: dns0.sonera.grx. 194.215.72.38
;; WHEN: Fri Apr 23 23:35:52 2004
;; MSG SIZE sent: 17 rcvd: 129

# dig @dns1.sonera.grx. NS

; <<>> DiG 8.3 <<>> @dns1.sonera.grx. NS
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3
;; QUERY SECTION:
;; ., type = NS, class = IN

;; ANSWER SECTION:
. 2D IN NS dns2.sonera.grx.
. 2D IN NS dns0.sonera.grx.
. 2D IN NS dns1.sonera.grx.

;; ADDITIONAL SECTION:
dns0.sonera.grx. 1D IN A 194.215.72.38
dns1.sonera.grx. 1D IN A 194.215.72.69
dns2.sonera.grx. 1D IN A 194.215.72.141

;; Total query time: 238 msec
;; FROM: DNS01 to SERVER: dns1.sonera.grx. 194.215.72.69
;; WHEN: Fri Apr 23 23:36:12 2004
;; MSG SIZE sent: 17 rcvd: 129

# dig @dns2.sonera.grx. NS

; <<>> DiG 8.3 <<>> @dns2.sonera.grx. NS
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3
;; QUERY SECTION:
;; ., type = NS, class = IN

;; ANSWER SECTION:
. 2D IN NS dns1.sonera.grx.
. 2D IN NS dns2.sonera.grx.
. 2D IN NS dns0.sonera.grx.

;; ADDITIONAL SECTION:
dns1.sonera.grx. 1D IN A 194.215.72.69
dns2.sonera.grx. 1D IN A 194.215.72.141
dns0.sonera.grx. 1D IN A 194.215.72.38

;; Total query time: 221 msec
;; FROM: DNS01 to SERVER: dns2.sonera.grx. 194.215.72.141
;; WHEN: Fri Apr 23 23:36:56 2004
;; MSG SIZE sent: 17 rcvd: 129

# dig @dns0.sonera.grx dns0.sonera.grx A

; <<>> DiG 8.3 <<>> @dns0.sonera.grx dns0.sonera.grx A
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2
;; QUERY SECTION:
;; dns0.sonera.grx, type = A, class = IN

;; ANSWER SECTION:
dns0.sonera.grx. 1D IN A 194.215.72.38

;; AUTHORITY SECTION:
sonera.grx. 1D IN NS dns2.sonera.grx.
sonera.grx. 1D IN NS dns0.sonera.grx.
sonera.grx. 1D IN NS dns1.sonera.grx.

;; ADDITIONAL SECTION:
dns1.sonera.grx. 1D IN A 194.215.72.69
dns2.sonera.grx. 1D IN A 194.215.72.141

;; Total query time: 265 msec
;; FROM: DNS01 to SERVER: dns0.sonera.grx 194.215.72.38
;; WHEN: Fri Apr 23 23:39:39 2004
;; MSG SIZE sent: 33 rcvd: 133

# dig @dns1.sonera.grx dns1.sonera.grx A

; <<>> DiG 8.3 <<>> @dns1.sonera.grx dns1.sonera.grx A
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2
;; QUERY SECTION:
;; dns1.sonera.grx, type = A, class = IN

;; ANSWER SECTION:
dns1.sonera.grx. 1D IN A 194.215.72.69

;; AUTHORITY SECTION:
sonera.grx. 1D IN NS dns2.sonera.grx.
sonera.grx. 1D IN NS dns0.sonera.grx.
sonera.grx. 1D IN NS dns1.sonera.grx.

;; ADDITIONAL SECTION:
dns0.sonera.grx. 1D IN A 194.215.72.38
dns2.sonera.grx. 1D IN A 194.215.72.141

;; Total query time: 5237 msec
;; FROM: DNS01 to SERVER: dns1.sonera.grx 194.215.72.69
;; WHEN: Fri Apr 23 23:40:23 2004
;; MSG SIZE sent: 33 rcvd: 133

# dig @dns2.sonera.grx dns2.sonera.grx A

; <<>> DiG 8.3 <<>> @dns2.sonera.grx dns2.sonera.grx A
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUERY SECTION:
;; dns2.sonera.grx, type = A, class = IN

;; ANSWER SECTION:
dns2.sonera.grx. 1D IN A 194.215.72.141

;; AUTHORITY SECTION:
sonera.grx. 1D IN NS dns0.sonera.grx.
sonera.grx. 1D IN NS dns1.sonera.grx.
sonera.grx. 1D IN NS dns2.sonera.grx.

;; ADDITIONAL SECTION:
dns0.sonera.grx. 1D IN A 194.215.72.38
dns1.sonera.grx. 1D IN A 194.215.72.69
dns2.sonera.grx. 1D IN A 194.215.72.141

;; Total query time: 222 msec
;; FROM: DNS01 to SERVER: dns2.sonera.grx 194.215.72.141
;; WHEN: Fri Apr 23 23:40:57 2004
;; MSG SIZE sent: 33 rcvd: 159

Please advice.

Many thanks.

martin

[Martin Hui]

Hi,

Does anyone know how to obtain Database Dump so that i can see what my DNS has for the authoritative data and cache entries.

Thanks.

martin

[Todd Whitcher]

Hi Martin,

Sorry I did not have time to take a look at your post on Friday. I think you are on the right track by taking a database dump. Depending on the version of DNS you can use the rndc command to dump the database. Use the dumpdb option, from the man page for rndc.
dumpdb Dump the current contents of the
cache into the file specified by
the dump-file directive of the
options statement in the
configuration file, named.conf. If
the dump-file directive is not
specified, the cache data is dumped
to the named_dump.db file in the
directory specified by the
directory directive of the options
statement in the named.conf
configuration file.

What I would also suggest is doing a network trace to find out where you are getting the answer to your queries with the shorter time to live value.

You can use the nettl command to run the trace and you can read it with the netfmt command or if you have ethereal you can read it with that program. The ethereal program is more user friendly than netfmt.

To take the trace use this command.

nettl -tn pduin pduout -e ns_ls_ip -tm 99999 -f trace

Then use dig etc. to lookup your A records for your root nameservers.

Stop the trace

nettl -tf -e all

You will have a a output file(S) called trace.TRCXXX file which is in binary, you can format it with netfmt or with ethereal.

IF you are going to use netfmt to read the data you can create the following filter file.

# cat filter_file
filter udp_sport 53
filter udp_dport 53

Then format the trace with netfmt like so:

netfmt -Nnlf trace.TRCXXX -c filter > trace.out

You can use vi etc. to read the trace.out file. If you have ethereal you can set up a similar filter. You can get ethereal at www.ethereal.com

udp.srcport == 53 or udp.dstport == 53

I suspect that you are getting some bad information from one of your nameservers, checking the cache is a good idea also. The only note I have on that is to be sure you have HP's latest version of BIND 9.2 release 5.0 since there was a problem with dumping whats called the adb cache ( additional database cache ) You can download the latest rev. under software.hp.com.

http://software.hp.com/portal/swdepot/displayProductInfo.do?productNumber=BIND9.2

I will not be readily available this week to respond to this forums post but I will try to keep up with it.

Good Luck

Todd

[Martin Hui]

Hi Todd,

After my root DNS provider set the TTL for both IS and A records to the same, my DNS has not prompted me with alerts.

Interesting??

Thank you.

martin

[Todd Whitcher]

Martin,

Glad to hear its working. I have not run into that issue before, but in my experience I have not seen the records set to different values. I'm glad it resolved your problem...for now.

Todd