Re: Should a nameserver know about itself?

[Bruce Campbell <[e-mail]>]

On Thu, 10 May 2001, Robert Elz wrote:

>     From:        Bruce Campbell <[e-mail]>
> 
>   | 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???

Part of it is how we *currently* deal with delegation requests.  We verify
each attribute (domain, nameserver) before verifying the whole request,
ie:

	domain: 220.219.218.in-addr.arpa   
		domain->validate() returns true if domain name is 'correct'
	nserver: ns1.example.com
	nserver: ns2.example.com
		nserver->validate() returns true if nameserver is
		considered to be 'responding'.

	( each attribute validate() method doesn't have the 'full'
	  delegation request on hand, so currently
          nserver->validate() can't directly test the domain on the given
          nameserver. )

So, our current implementation of nserver->validate() is flawed, because,
as has been pointed out, a nameserver doesn't *need* to know about itself,

( Personal opinion is that is *should* know about itself, as most of the
  cases we've seen where a nameserver doesn't know about itself have been
  broken in other ways )

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

One of the future projects is an ongoing reverification of delegations
within our space.  The caching of nameserver good/bad results is
considered a good thing, and this caching was intended to be done in the
above nserver->validate method.

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

After we redo the code, this is what we'll be doing.  The
nserver->validate() check will get reduced to seeing if the data supplied
actually resolves as a hostname (or its a valid IPv{4,6} address).

> itself, ...).   The only real point in distinguishing is to give a better
> reason to supply for refusing to do the delegation.

Currently we reject on:

	non-authoritative
	SOA mismatches across supplied nameservers
	NS listing mismatches across supplied nameservers (both what they
		supply and whats in the actual zone file)

Unfortunately, we don't have any tests to reliably produce:

'*ERROR* Nameserver boggle.example.com appears to be running version bar
         of software foo.  This is broken as it does not correctly
         implement feeping-creaturism #34693.  Try again with better
         software.'

;)

-- 
  Bruce Campbell <[e-mail]>                [phone]
                      Systems Administrator                          APNIC