solved! - Re: 1 hour subdomain failures

[Barry Margolin]

In article <199908241914.PAA17139 at shell.one.net>,
John Studarus  <studarus at one.net> wrote:
>
>	Unfortunately the ISP never told us what 
>version of software they were running but we were
>able to determine the problem and place a fix.
>	Turns out the caching name server got 
>confused on an NS record that pointed to a name
>server in the subdomain.
>	i.e.
>	(in the mydomain.com)
>	subdomain.mydomain.com.	1H IN NS	ns.mydomain.com.
>
>	(in the mydomain.com subdomain)
>	subdomain.mydomain.com.	1H IN NS	ns.subdomain.mydomain.com.
>
>	ns.mydomain.com and ns.subdomain.mydomain.com are
>the same machines.
>
>	So - when the first record expired (after an hour) it 
>would try and use the second record to determine the name server 
>to use.  This would fail (infinite loop? - NS record for 
>subdomain.mydomain.com points to ns.subdomain.mydomain.com).

This is a case where you are required to place a glue A record in the
parent zone.  Glue records are intended specifically to solve this
chicken-and-egg problem.

>It would fail for 1 hour while the TTL expires and then
>work again when it caches the subdomain.mydomain.com IN NS
>ns.mydomain.com record.

Why wouldn't it go to a secondary server?  Or are they all in the
subdomain, so they were all affected by the problem?

>	The fix was to replace the entries with:
>
>	(in the mydomain.com)
>	subdomain.mydomain.com.	1H IN NS	ns.mydomain.com.
>
>	(in the mydomain.com subdomain)
>	subdomain.mydomain.com.	1H IN NS	ns.mydomain.com.
>
>	Is this a bug in an older version of BIND (or
>some other name server software)?  It probably doesn't
>make sense to place ns records in the subdomain but
>it's interesting that it works with the latest

Why doesn't it make sense to place NS records in the subdomain?  Consider
all the delegations from the COM and NET domains -- many of them point to
nameservers in the subdomain being delegated.  For instance, the servers
for GTEI.NET will soon be changing to DNSAUTH1.SYS.GTEI.NET,
DNSAUTH2.SYS.GTEI.NET, and DNSAUTH3.SYS.GTEI.NET (we're phasing out the
name servers that are left over from NEARNET, BARRNET, and SURANET).

>BIND release.  We were not able to duplicate this 
>problem anywhere else.  

As far as I can tell, the only "bug" was that you didn't install glue
records in the parent zone.  How do you expect any version of BIND to
figure out the address of ns.subdomain.domain.com when they have to contact
that server to get its address?

-- 
Barry Margolin, barmar at bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.