Re: Should a nameserver know about itself?

Robert Elz <kre@munnari.OZ.AU> Thu, 10 May 2001 17:01 UTC

Received: from nic.cafax.se ([192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03435 for <dnsop-archive@odin.ietf.org>; Thu, 10 May 2001 13:01:56 -0400 (EDT)
Received: by nic.cafax.se (8.12.0.Beta5/8.12.0.Beta5) id f4AGd7fw009277 for dnsop-outgoing; Thu, 10 May 2001 18:39:07 +0200 (MEST)
Received: from ratree.psu.ac.th (ratree.psu.ac.th [192.100.77.3]) by nic.cafax.se (8.12.0.Beta7/8.12.0.Beta5) with ESMTP id f4AGd2Lt009272 for <dnsop@cafax.se>; Thu, 10 May 2001 18:39:05 +0200 (MEST)
Received: from brandenburg.cs.mu.OZ.AU (reserv150.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id XAA05578; Thu, 10 May 2001 23:38:59 +0700 (ICT)
Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f4AGctc02364; Thu, 10 May 2001 23:38:56 +0700 (ICT)
From: Robert Elz <kre@munnari.OZ.AU>
To: Bruce Campbell <bruce.campbell@apnic.net>
cc: dnsop@cafax.se
Subject: Re: Should a nameserver know about itself?
In-Reply-To: <Pine.BSF.4.21.0105100927150.43413-100000@julubu.staff.apnic.net>
References: <Pine.BSF.4.21.0105100927150.43413-100000@julubu.staff.apnic.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 10 May 2001 23:38:55 +0700
Message-ID: <2362.989512735@brandenburg.cs.mu.OZ.AU>
Sender: owner-dnsop@cafax.se
Precedence: bulk

    Date:        Thu, 10 May 2001 09:50:26 +1000 (EST)
    From:        Bruce Campbell <bruce.campbell@apnic.net>
    Message-ID:  <Pine.BSF.4.21.0105100927150.43413-100000@julubu.staff.apnic.net>

  | Right.  Now that we've gotten that out of the way, can anyone suggest a
  | *reliable* test for verifying that a nameserver is responding ( which is
  | seperate from verifying that a nameserver is authoritatively serving a
  | given zone )

There have been some suggestions for that, but ... why???

If you know (either empirically, or by having been referred from another
server) that a nameserver is supposed to serve a particular zone, then
you send it a query about that zone.  If it sends you back some kind of
DNS response, then it has a DNS implementation.  If it sends you back
good data about the zone, then it is configured to handle the zone (so
you get two answers for the price of one...)

If you don't know any zone that a server is supposed to be serving, why
would you ever care if it has a DNS server on it or not?   (Unless it is
supposed to be your local back end resolver I suppose, but I doubt that is
the case you're concerned with).

That is, if you're never going to send it a query, why would you care what
it would say if you did?   What does it matter?

So, just check if it serves the zone that you're being asked to delegate.

If it does that, then you know (also, for free) that it must also have
a responding nameserver.   If it doesn't, you should be able to work
out from what happened whether the problem is no nameserver at all (you
get ICMP port unreachable, no response at all, TCP reset, ...) or perhaps
a firewall filtering you from the nameserver, which is effectively the same
thing, or a nameserver that just doesn't know the zone (a referral, a
NXDOMAIN, a non-auth answer, a list of NS records that doesn't include
itself, ...).   The only real point in distinguishing is to give a better
reason to supply for refusing to do the delegation.

kre