On Thu, 30 Oct 2008, [EMAIL PROTECTED] 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
