dig-problems, query-problems
pilsl at goldfisch.at
pilsl at goldfisch.at
Thu Jan 24 01:56:55 UTC 2002
I've two basic questions regarding dns-queries. I just dont understand
what going on in all the resolve-process and maybe someone can give me
a deeper understanding:
first:
if I add a new entry (lets say a A entry called test) to a zone on
the master-named (and update the serial) and then dig for this entry
from a different machine (that runs a non-forwarding nameserver) it
cant be found for quite a while (few hours) and the dig reveals an old
serial in its authority-section. When I issue a dig +trace the entry
is found ...
# dig @localhost test.goldfisch.at
; <<>> DiG 9.1.1 <<>> @localhost test.goldfisch.at
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51748
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;test.goldfisch.at. IN A
;; AUTHORITY SECTION:
goldfisch.at. 10800 IN SOA ns1.goldfisch.at. peter.goldfisch.at. 2002011413 10800 3600 3600000 86400
;; Query time: 67 msec
;; SERVER: 127.0.0.1#53(localhost)
;; WHEN: Thu Jan 24 02:01:51 2002
;; MSG SIZE rcvd: 81
Then I run a trace-dig to hunt the problem down and trace resolves the
address and prints the correct result:
# dig @localhost test.goldfisch.at +trace
; <<>> DiG 9.1.1 <<>> @localhost test.goldfisch.at +trace
;; global options: printcmd
. 518292 IN NS D.ROOT-SERVERS.NET.
. 518292 IN NS E.ROOT-SERVERS.NET.
. 518292 IN NS F.ROOT-SERVERS.NET.
. 518292 IN NS G.ROOT-SERVERS.NET.
. 518292 IN NS H.ROOT-SERVERS.NET.
. 518292 IN NS I.ROOT-SERVERS.NET.
. 518292 IN NS J.ROOT-SERVERS.NET.
. 518292 IN NS K.ROOT-SERVERS.NET.
. 518292 IN NS L.ROOT-SERVERS.NET.
. 518292 IN NS M.ROOT-SERVERS.NET.
. 518292 IN NS A.ROOT-SERVERS.NET.
. 518292 IN NS B.ROOT-SERVERS.NET.
. 518292 IN NS C.ROOT-SERVERS.NET.
;; Received 436 bytes from 127.0.0.1#53(localhost) in 8 ms
at. 172800 IN NS NS2.UNIVIE.AC.at.
at. 172800 IN NS NS.EU.NET.
at. 172800 IN NS NS1.UNIVIE.AC.at.
at. 172800 IN NS NS.UU.NET.
at. 172800 IN NS NS7.UNIVIE.AC.at.
at. 172800 IN NS NS3.AUSTRIA.EU.NET.
;; Received 264 bytes from 128.8.10.90#53(D.ROOT-SERVERS.NET) in 142 ms
goldfisch.at. 345600 IN NS ns1.goldfisch.at.
goldfisch.at. 345600 IN NS ns2.goldfisch.at.
goldfisch.at. 345600 IN NS ns4.goldfisch.at.
;; Received 137 bytes from 193.171.255.66#53(NS2.UNIVIE.AC.at) in 42 ms
test.goldfisch.at. 86400 IN A 213.229.42.99
goldfisch.at. 86400 IN NS ns1.goldfisch.at.
goldfisch.at. 86400 IN NS ns2.goldfisch.at.
goldfisch.at. 86400 IN NS ns4.goldfisch.at.
;; Received 153 bytes from 213.229.42.99#53(ns1.goldfisch.at) in 52 ms
why does trace find the answer and normal dig does not ?? Is it
possible that normal dig query slaveserver (like ns2 or ns4) first and
this slaves doesnt have the newest zonefile yet ? I thought a request
will always be directed to primary nameserver first and only if this
fail - to the second and so on !?
I also killed and restarted named (on the machine where I run dig) but
the results stays mysterious to me ...
second:
As I read in the dns-howto, I enabled query only for local in my
named.conf and added 'allow-query { any; };' to all "public" domains.
Unfortunately I got loads of "query denied" entries in my syslog then.
As soon as I allowed query global and added 'allow-query { local; };'
to the "private" domains, things worked.
third:
I tried to run "named -d 1000" to debug as soon as possible (and
hopefully see all incoming queries) but no more messages than when
running nnamed without the debug-option went to my syslog.
thnx a lot for any help,
peter
More information about the bind-users
mailing list