DNS "chicken-and-egg" Problem

[David Forrest]

On Thu, 30 Oct 2008, bsfinkel at anl.gov 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.
> ----------------------------------------------------------------------
> Barry S. Finkel

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 Forrest                  e-mail:   drf @ maplepark.com
Maple Park Development Corporation  http://www.maplepark.com
St. Louis, Missouri