out of zone NS records

[Mark.Andrews at nominum.com]

> 
> I have been tasked with bringing a group of nameservers into a standard
> alignment respective to their functions.  These servers were all running
> BIND 8.1.1, 8.1.2 or 4.9.3, and had enjoyed little attention over the years.
> Though I have many years of UNIX administration experience, I am a BIND/DNS
> novice; be aware that I am RTFM (including the O'Reilly book), poring over
> RFCs and still recovering from the flames I suffered LAST time I asked a
> question in this group.  You guys are all really brilliant, but you do not
> suffer newbies gracefully.  Be that as it may, I HUMBLY and RESPECTFULLY
> request your guidance on a small issue:
> 
> Solaris 2.6 on a SPARCstation 10, running what appears to be 4.9.3 
> 	(the binary said 8.1, but it was a different size than the 8.1
> binary running elsewhere)

	The size of the binary is dependent apon complier options,
	processor type etc.  Solaris binaries with debugging symbols
	are known to be big w.r.t. other platforms.

> 
> After the first attempt at running 8.2.3, the errors made it clear that the
> config and db files were flawed.
> I have found and corrected most of the errors except for these NS records in
> each zone file:
> 
> osc.uscg.mil.   IN      NS      netman.osc.uscg.mil.
> osc.uscg.mil.   IN      NS      sarpro1.osc.uscg.mil.
> osc.uscg.mil.   IN      NS      sarpro2.osc.uscg.mil.
> ;
> netman.osc.uscg.mil.    IN      A       152.119.204.204 
> sarpro1.osc.uscg.mil.   IN      A       152.119.204.221 
> sarpro2.osc.uscg.mil.   IN      A       152.119.204.222
> 

	BIND only supports glue records that are below the top of
	the parent zone.  Early versions supported them everywhere
	and there are some configurations that require you to have
	these record.

	e.g.
	    all the nameservers for example.com in example.net
	    and all the nameservers for example.net in example.com.

	BIND however does not support those configurations as
	they have been found to be impossible to maintain is it
	is impossible to trace the source of bad glue.  BIND
	enforces the restriction by dropping out of zone records.

	The current restrictions allow you to find the source of
	bad glue as it has to be coming from a parent nameserver.

	The fix for these error messages is to remove the offending
	records.

	Mark

> which generate the following errors:
> 
> Mar  2 17:37:22 ddnmail named[14094]: fnoc.navy.mil:92: data "osc.uscg.mil"
> outside zone "fnoc.navy.mil" (ignored)
> Mar  2 17:37:22 ddnmail named[14094]: fnoc.navy.mil:93: data "osc.uscg.mil"
> outside zone "fnoc.navy.mil" (ignored)
> Mar  2 17:37:22 ddnmail named[14094]: fnoc.navy.mil:94: data "osc.uscg.mil"
> outside zone "fnoc.navy.mil" (ignored)
> Mar  2 17:37:22 ddnmail named[14094]: fnoc.navy.mil:96: data
> "netman.osc.uscg.mil" outside zone "fnoc.navy.mil" (ignored)
> Mar  2 17:37:22 ddnmail named[14094]: fnoc.navy.mil:97: data
> "sarpro1.osc.uscg.mil" outside zone "fnoc.navy.mil" (ignored)
> Mar  2 17:37:22 ddnmail named[14094]: fnoc.navy.mil:98: data
> "sarpro2.osc.uscg.mil" outside zone "fnoc.navy.mil" (ignored)
> Mar  2 17:37:22 ddnmail named[14094]: fnmoc.navy.mil:93: data "osc.uscg.mil"
> outside zone "fnmoc.navy.mil" (ignored)
> Mar  2 17:37:22 ddnmail named[14094]: fnmoc.navy.mil:94: data "osc.uscg.mil"
> outside zone "fnmoc.navy.mil" (ignored)
> Mar  2 17:37:22 ddnmail named[14094]: fnmoc.navy.mil:95: data "osc.uscg.mil"
> outside zone "fnmoc.navy.mil" (ignored)
> Mar  2 17:37:22 ddnmail named[14094]: fnmoc.navy.mil:97: data
> "netman.osc.uscg.mil" outside zone "fnmoc.navy.mil" (ignored)
> Mar  2 17:37:22 ddnmail named[14094]: fnmoc.navy.mil:98: data
> "sarpro1.osc.uscg.mil" outside zone "fnmoc.navy.mil" (ignored)
> Mar  2 17:37:22 ddnmail named[14094]: fnmoc.navy.mil:99: data
> "sarpro2.osc.uscg.mil" outside zone "fnmoc.navy.mil" (ignored)
> 
> It is clear that these records are out of our zone
> (fnmoc.navy.mil/fnoc.navy.mil), but is there any other way that I can
> include them as entries in a zone file without major changes to my current
> zone configuration?  I think not, but I would like a confirmation.  Again,
> thank you.
> 
> (Elizabeth) Annette Lee
> FNMOC, Monterey CA
> (831) 656-4426
> 
> 
> 
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com