On Thu, 30 Oct 2008, bsfinkel@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