DNS "chicken-and-egg" Problem
bsfinkel at anl.gov
bsfinkel at anl.gov
Fri Oct 31 19:22:33 UTC 2008
I wrote:
>>To summarize this problem -
>>
>> 1) One of my mailers is trying to find the "A" record for
>>
>> igpp.ucla.edu
>>
>> so that it can verify that mail from that domain is
>> legitimate mail.
>>
>> 2) The ucla.edu name servers delegate the zone to a name server
>>
>> igpp.ucla.edu
>>
>> I talked with a DNS admin at UCLA, and he told me that they have
>> in the ucla.edu zone a delegation and glue:
>>
>> igpp.ucla.edu. 6H IN NS igpp.ucla.edu
>> igpp.ucla.edu. 6H IN A 128.97.94.1
>>
>> 3) When I query the four ucla.edu name servers, dig returns:
>>
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
>> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>> ;; QUERY SECTION:
>> ;; igpp.ucla.edu, type = A, class = IN
>>
>> ;; AUTHORITY SECTION:
>> igpp.ucla.edu. 6H IN NS igpp.ucla.edu.
>>
>> ;; ADDITIONAL SECTION:
>> igpp.ucla.edu. 6H IN A 128.97.94.1
>>
>> 4) Why is this information not in the cache on my server?
>> Jinmei Tatuya said it might be due to a cache-clearing bug
>> in 9.5.0 (I am running 9.5.0-P2). I ran a test with
>> "max-cache-size 256M", and I did not see the record cached.
>> And I doubt that the cache was full.
>>
>> 5) Someone (I do not remember who, and I cannot find the reply in
>> the list archives) pointed out to me that the answers I am
>> getting from UCLA are not authoritative - the "aa" flag is
>> missing.
>>
>>What could cause glue information (that I think is correct) in the
>>ucla.edu zones to be returned to my server as not authoritative?
>>I now assume that the reason that my BIND does not cache the glue is
>>that the glue is not marked authoritative. Thanks.
And I got various replies, which I will attempt to answer:
----------
"Hays, Ken" <hays at otc.fsu.edu> replied:
> Barry, If the dig ends with @128.97.94.1, the reply is authoritative.
I know that if I query the address of the authoritative name server for
the igpp.ucla.edu zone, then I will get an authoritative answer.
But how does BIND know that the authoritative address of the igpp
nameserver is 128.97.94.1?
----------
Tatuya, JINMEI replied:
>The question is still not very clear to me. My response mainly
>focused on the "real" problem that the caching server (occasionally?)
>returns SERVFAIL for that specific query. Are you saying the server
>is still returning SERVFAIL even after raising max-cache-size and even
>if the server does not reach that limit?
>
>To answer the question directly...we need more information. What
>specifically did you try and which "this information" exactly are you
>talking about? Does that happen with mostly empty cache? Is it
>reproduceable or occasional? It would be helpful if you can show
>detailed steps toward the question, like
>- starting a server
>- dig the server with a query
>- do rndc dumpdb
>and show the dump output, explaining which information you're
>expecting in the cache but isn't there. Note that there's nothing
>wrong about some information not in a cache per se (entries can be
>purged for various reasons, by default). So you should first explain
>that it should be in the cache according to the detailed procedure.
>It should also be noted that missing cache itself is not necessarily
>problematic as long as the required information is finally returned
>(though suboptimal in that it may take longer time and consume more
>resources). So it's also helpful to explain whether it causes a real
>problem like SERVFAIL.
There are a number of problems that arise out of trying to find the
authoritive answer to the question
What is the "A" record for igpp.ucla.edu?
1) Sometimes I get SERVFAIL when I query my local name servers.
And I am not sure why.
2) When I query the four UCLA name servers I get an answer, but that
answer does not have the "aa" bit set. I am not sure
a) why the "aa" bit is not set, as the answer is coming from an
authoritative name server.
b) why BIND is not cacheing that information. Maybe because the
information is not marked authoritative? Maybe because the
DNS cache is being cleaned to aggressively (as JINMEI thinks)?
I just ran a test on my two internal BIND 9.5.0-P2 servers
max-cache-size:
256M - oberon - SERVFAIL
32M - titania - non-authoritative answer
oberon% dig igpp.ucla.edu
; <<>> DiG 8.3 <<>> igpp.ucla.edu
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;; igpp.ucla.edu, type = A, class = IN
;; Total query time: 64 msec
;; FROM: oberon.it.anl.gov to SERVER: default -- 146.139.254.3
;; WHEN: Fri Oct 31 13:44:35 2008
;; MSG SIZE sent: 31 rcvd: 31
oberon%
titania% dig igpp.ucla.edu
; <<>> DiG 8.3 <<>> igpp.ucla.edu
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; QUERY SECTION:
;; igpp.ucla.edu, type = A, class = IN
;; ANSWER SECTION:
igpp.ucla.edu. 1D IN A 128.97.94.1
;; AUTHORITY SECTION:
igpp.ucla.edu. 1D IN NS igpp.ucla.edu.
;; Total query time: 134 msec
;; FROM: titania.it.anl.gov to SERVER: default -- 146.139.254.5
;; WHEN: Fri Oct 31 13:41:43 2008
;; MSG SIZE sent: 31 rcvd: 61
titania%
I dumped the cache on each machine, and I see:
oberon - 256M - nothing in the cache for igpp.ucla.edu nor 128.97.94.1.
34,218 records in the named_dump.db file
titania - 32M - nothing in the cache for igpp.ucla.edu, but
; Unassociated entries
; 128.97.94.1 [srtt 17917] [flags 00000000] [ttl 1737]
19,420 records in the named_dump.db file
What is an "unassociated entry"?
Note that the 256M max-cache-size machine returned SERVFAIL, while the
default 32M max-cache-size machine gave me a non-authoritative answer.
But I did not see igpp.ucla.edu in either cache.
So it is not clear what is causing the SERVFAIL.
As for the answers to questions 2a) and 2b), these two queries do
not help, I believe. But see below.
----------
David Forrest <drf at maplepark.com> replied:
>When I dig at dns.ucla.edu. I find that igpp.ucla.edu. is the
>authoritative ns for igpp.ucla.edu and it tells me with a glue RR where
>igpp.ucla.edu is found. But it does not seem authoritative.
>
>When I dig at igpp.ucla.edu. I get this and it shows as authoritative.
>
>;; ANSWER SECTION:
>igpp.ucla.edu. 86400 IN SOA igpp.ucla.edu.
>dns.igpp.ucla.edu. 2008103001 43200 3600 604800 86400
>igpp.ucla.edu. 86400 IN A 128.97.94.1
>igpp.ucla.edu. 86400 IN WKS 128.97.94.1 6 21 23 25 79
>igpp.ucla.edu. 86400 IN NS igpp.ucla.edu.
>igpp.ucla.edu. 86400 IN MX 10
>barracuda.igpp.ucla.edu.
>
>;; ADDITIONAL SECTION:
>barracuda.igpp.ucla.edu. 86400 IN A 128.97.68.2
>
>;; Query time: 185 msec
>;; SERVER: 128.97.94.1#53(128.97.94.1)
>;; WHEN: Thu Oct 30 16:32:18 2008
>;; MSG SIZE rcvd: 170
>
>Looking about, I found this note.
>It appears that RFC 1035 says that the above results are correct. RFC
>1035 also cautions about caching non-authoritative information but does
>not forbid it. But it is a 1987 RFC... 21 years old.
>
>Defined in RFC 1035. NS RRs appear in two places. Within the zone file, in
>which case they are authoritative records for the zone's name servers. At
>the point of delegation for either a subdomain of the zone or in the
>zone's parent. Thus the zone example.com's parent zone (.com) will contain
>non-authoritative NS RRs for the zone example.com at its point of
>delegation and subdomain.example.com will have non-authoritative NS RSs in
>the zone example.com at its point of delegation. NS RRs at the point of
>delegation are never authoritative only NS RRs for the zone are regarded
>as authoritative. While this may look a fairly trivial point, is has
>important implications for DNSSEC.
David seems to imply that the glue record is always non-authoritative
I ran a quick test, asking
dig uky.edu @A3.NSTLD.COM.
and getting the glue records:
flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
The answer does not have "aa". so, referral records are not marked
as authoritative. When would BIND cache glue information, if that
information is not marked authoritative?
I am still confused.
----------------------------------------------------------------------
Barry S. Finkel
Computing and Information Systems Division
Argonne National Laboratory Phone: +1 (630) 252-7277
9700 South Cass Avenue Facsimile:+1 (630) 252-4601
Building 222, Room D209 Internet: BSFinkel at anl.gov
Argonne, IL 60439-4828 IBMMAIL: I1004994
More information about the bind-users
mailing list