Lame delegation to server with cached NS data.

[Two Dog]

Hello,

While this is more of a DNS question than a BIND question I do
appreciate your help with this, as I'm having some trouble
understanding it.

The domain in question is wecdsb.on.ca when I query it returns an
answer only occasionally. This domain is not under our control or do I
have any authority over it.

I did a traversal of the domain at http://www.squish.net/dnscheck and
saw that one of the name servers for that domain ns4.dm.egate.net is
"Loop Detected! Probable cause is lame delegation to server with
cached NS data"

As far as I understand it that means the egate.net name server is
sending out the request for a question it already has the answer too
thereby creating a loop. Would that be correct? If so what could one
do to resolve that issue?

I've also tried looking up this domain against other name servers and
they too occasionally return a timed out result or no host.

How can I educate this customer that the 'problem' in question does
not exist on our network but his network layout?

Thanks so much.

Peter

[Kevin Darcy]

Two Dog wrote:

Calling this a "loop" is I think a little misleading. The wecdsb.on.ca
domain has been delegated to ns4.dm.egate.net (as well as to
ns.wecdsb.on.ca), but ns4.dm.egate.net is not authoritative for the
zone. This is a typical "lame" delegation, then. Most nameservers
implementations will recognize this lameness and simply ignore what
ns4.dm.egate.net has to say about the zone. What this boils down to,
however, is there is exactly *one* working nameserver for the domain
(ns.wecdsb.on.ca). If that nameserver gets a little busy, or its
connectivity blinks out temporarily, then the whole domain can become
unresolvable for anyone who doesn't already have the relevant
information cached. If the domain owner cares about the availability of
that zone, they should arrange for at least one other nameserver to be
authoritative for the zone, and then update the delegation records and
the NS records in the zone to reflect that redundancy.

- Kevin

[Two Dog]

Thanks for putting that into perspective. I was a little confused
about the "loop" but you cleared it up.

[Jonathan de Boyne Pollard]

TD> While this is more of a DNS question than a BIND question [...]

... and thus belongs in a different newsgroup ...

TD> As far as I understand it that means the egate.net name server is
TD> sending out the request for a question it already has the answer too
TD> thereby creating a loop. Would that be correct?

No. It's a lot simpler than that. The "ca." content DNS servers
delegate "wecdsb.on.ca." to the two content DNS servers at 209.202.75.74
and 216.235.1.42. In its turn, the "wecdsb.on.ca." content DNS server
at 216.235.1.42 delegates "wecdsb.on.ca." to 209.202.75.74 and back to
itself. That's the loop.

TD> "Probable cause is lame delegation to server with cached NS data"

And that's precisely what is happening in this case. The
"wecdsb.on.ca." content DNS server at 216.235.1.42 is vainly trying to
wear all of the hats at once, and provide proxy DNS service as well as
content DNS service (when it should really be configured to provide only
the latter). It only knows about the "wecdsb.on.ca." delegation in the
first place because at some point, less than a day ago, someone used it
for proxy DNS service and caused it to look the delegation up.
Eventually, the delegation information will expire from its cache, and
instead of publishing a self-referral (in answer to "*.wecdsb.on.ca."
questions) it will start publishing a *backwards* referral, for either
"ca." or ".", until the next time that someone comes along and uses it
for proxy DNS service to look up something in "wecdsb.on.ca.".

TD> How can I educate this customer that the 'problem' in question does
TD> not exist on our network but his network layout?

Depending from who your customer actually is, the problem may not be
anything to do with your customer, either.

The people who need to fix things are the owner of the content DNS
server at 216.235.1.42 and the owner of "wecdsb.on.ca.". The latter
needs to talk to the former, and persuade/pay him/her to configure
his/her content DNS server to hold the "wecdsb.on.ca." DNS data in its
database and to publish them.