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: cat...@isc.org > To: bind-users@lists.isc.org > Subject: Re: > > On 13/03/12 20:46, Mark Andrews wrote: > > > > In message <cb84b51a.4a53a%dan.mcdon...@austinenergy.com>, Daniel McDonald > > writ > > es: > >> > >> On 3/13/12 8:20 AM, "hugo hugoo" <hugo...@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@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
