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:<ai71f0$3q8s$1 at isrv4.isc.org>...
> > What Doug was trying to tell you was that you should use real names when asking for help.
> >
> > Didn't you read the part of the FAQ that Doug pointed you to?
> >
> >
> > - Kevin
>
> Thank you for point it out.
>
> from the FAQ, I realized the Realname helps to diagnose and solve
> problems,
> I am quite understandable. But since this failure is so hard to
> repeat, I
> really don't expect you guys to try it , as a matter of fact.
>
> If you can read my first mail more carefully, you will realize that
> realname
> is not a problem in this case. I just want some experts and guys
> familiar with
> bind's source codes help me to figure out what that error message
> exactly mean.
>
> Maybe I can describe how this got happened before you can give me some
> advice.
>
> these days we've gotten a resolving problem for a domain name. Every
> time the
> problem occured , we noticed there was only that domain's NS record in
> my cache,  while no A record of that domain's name server, in other
> words, these
> A record expired before the NS record did.
>
> Also I haven't figured out how this could happen so far. Since we
> first get
> these RR in the cache, the NS record and the A record is collected
> from the
> same server at the same time, their TTL should be the same, so they
> should get
> expired at the same time, am I right ?

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

> so one expire before another
> one should
> never happen, that's what's in my mind so far, maybe someone could
> help me out.
>
> Any way, this happened. then next time when a name which belongs to
> that domain
> got resolved, we noticed though named.run that the named forwarded
> this request
> to the root server. The root server replied with a package including
> two NS
> record and one A record .

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.

Real names would have helped here.

> Then, at this time, the error "update failed
> foo.com
> 2" appeared. We couldn't resolve all those names belongs to that
> domain until
> the NS record got expired either.

"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.

> So, we are eager to know what that error message mean. If that mean
> the whole
> package come back from the root server was updated to the cache fail,
> that
> problem is understandable. But if that just mean only two NS records
> were
> updated fail , while the A record was successfully updated, this
> problem should
> not even happen.

Maybe the glue record that was returned was stale, and the missing glue record was
unresolvable.

Or, maybe not.

Real names would have helped here.


- Kevin