What does "update failed foo.com 2" mean ?

[Kevin Darcy]

likun at asiainfo.com wrote:

> Kevin Darcy <kcd at daimlerchrysler.com> wrote in message news:<ai9rlh$5b5o$1 at isrv4.isc.org>...
> > No, the TTLs could be completely different. According to the RFC's, the TTLs of every RR in an
> > RRset (defined by name/class/type) must be the same, but the NS and A records in the response
> > are different RRsets, so they are permitted to have different TTLs. Sometimes this is
> > deliberate -- maybe the address of a nameserver is about to change, so the TTL might be lowered
> > to ease the transition, but it makes no sense to also lower the TTL on the NS record if it is
> > staying the same
>
> first of all, thanks for input. yes, I understand that TTL of NS and A
> record can be different. but I just focus on this case, actually, in
> this case, the initial TTL for NS and A record is definitely the same.
> I can tell it also from then dumped db file. so since from authorized server
> came out the same TTL for both NS and A record, how can it get different
> as time passed?

They might have started out the same, but if either of them were queried independently of the other
before both timed out, then one of the cache entries could have been "refreshed", then they would
have differing TTLs and would expire at different times.

> > Two NS and only 1 A record? That's a little unusual. Did one of the NS records point to a name
> > in a ccTLD? If both of them were in gTLD's, then I would have expected the gTLD server
> > (I assume you mean gTLD server rather than root server) to return both glue records.
>
> another A record isn't configed in gTLD servers, it is under com.cn domain.
> so obviously gTLD servers don't fetch glues from other servers.

That explains that, then.

> > "update failed foo.com 2" just means that one or more of the RRs from the root-server response
> > failed to update the cache, presumably because the information already present in the cache had
> > a higher "credibility" (see RFC 2181 for the data-ranking order). You said that the NS records
> > were still in cache, right? If they came directly from an authoritative nameserver, then they
> > would have a higher credibility than the referral NS records from the delegation. This is
> > entirely usual and normal.
>
> can we definitely tell that there are 2 records failed updating to
> the cacah by the "2" of the error information?

No, the number refers to the record type. NS=2. So all it's telling you is that it failed to update
an NS RRset.


- Kevin