[hugo hugoo]

Hello,
 
I have correctly understood the need to have the NS of a subdomain in the parent domain to avoid any malfunction with a future migratio to DNSSEC.
 
But can anybody give me a clear method to detect such missconfiguration?
Is this possible with dig or is it ony possible with the access to the bind text files?
 
Regards,
 
Hugo,
 

 

> Date: Wed, 14 Mar 2012 09:36:26 +0000
> From: cathya at isc.org
> To: bind-users at lists.isc.org
> Subject: Re:
> 
> On 13/03/12 20:46, Mark Andrews wrote:
> > 
> > In message <CB84B51A.4A53A%dan.mcdonald at austinenergy.com>, Daniel McDonald writ
> > es:
> >>
> >> On 3/13/12 8:20 AM, "hugo hugoo" <hugobxl at hotmail.com> wrote:
> >>
> >>> ==> do I have to create in zone "toto.be" the following NS record:
> >>> 
> >>> titi.toto.be. TTL IN NS ns1.xxx.be
> >>> 
> >>> 
> >>> I have found cases where this situation is present and other when it is not
> >>> present...and both cases seems to work.
> >>> What is the difference?
> >>
> >> The glue records aren't necessary when both the zone and subzone are on the
> >> same server, although it is good to have them for completeness. When the
> >> zones are on different servers you need the glue records.
> > 
> > No, they *are* necessary. Just because their lack does not cause
> > a resolution failure in all cases it doesn't mean they are not
> > necessary.
> > 
> > If the parent zone is signed but the child zone is unsigned then
> > the lack of NS records *will* cause validation failures unless
> > OPTOUT is in use even when both zones are only served by a common
> > set of servers.
> > 
> > DNSSEC catches out lots of bad practices that mostly pass unnoticed
> > with plain DNS.
> > 
> > Mark
> 
> I would recommend doing it properly including adding glue records (glue
> is the A records associated with the NS records for the delegated child
> zone - but only if those NS records point to names actually in the
> delegated zone).
> 
> If you don't do it properly, and then in say 12 months time, someone
> else starts slaving the parent zone to another server that doesn't also
> slave the child zone, things are going to break...
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20120319/f3eda192/attachment.html>