Possible to copy an entire domain?

Don Stokes don at daedalus.co.nz
Mon Dec 9 22:50:37 UTC 2002


Doug Barton <DougB at DougBarton.net> wrote:
>On Sun, 8 Dec 2002, Don Stokes wrote:
>> Doug Barton <DougB at dougbarton.net> wrote:
>> >Brian Johnson wrote:
>> >> Can static zones share the same master file?
>> >http://dougbarton.net/bind-users/FAQ.html#SameFile
>>
>> Your example does not give IP addresses for ns1.example.com &
>> ns2.example.com, i.e. example.com shouldn't be one of the zones sharing
>> the file.
>
>That is implicit, although I suppose I should add an explanation to that
>effect.

It's not at all implicit.  You have three zones, example.com,
example.net and example.org.  Of these, example.com *must* have A
records for ns1.example.com, ns2.example.com and mailhost.example.com,
and you don't say this.

Moreover, example.net and example.org *don't* need the A records, and in
fact *must* *not* have any example.com records in them.  If these are
listed as unqualified names, i.e. just ns1, ns2 & mailhost, this would
be redundant but not actually wrong.

A more realistic example would be to not have example.com sharing the
same file as example.net and example.org.  example.com would be the
"operational" domain, containing names for all the infrastructure, while
example.net and example.org as "aliases", sharing common zone files with
pointers into example.com for all infrastructure.

>I think you're confusing domains and TLD's here. However, your suggestion
>fails to scale beyond say... two domains, because it requires host record
>registrations for every name server in every domain I administer. That's
>incredibly difficult to manage when you're dealing with hundreds,
>thousands, or in my case, hundreds of thousands of domains.

Yes, it requires host records, and yes, this does scale.  If you live in
COM or NET, it tends to be less of a problem, but out here in ccTLD
land, where the ccTLD lives on different servers to COM & NET, you run
across this problem a lot.  Consider these registered domains:

co.nz:
	example.co.nz.		NS	ns1.example.net.
				NS	ns2.example.net.

net:
	example.net.		NS	ns1.example.net.nz.
				NS	ns2.example.net.nz.

net.nz:
	example.net.nz.		NS	ns1.example.net.nz.
				NS	ns2.example.net.nz.
	ns1.example.net.nz.	A	10.1.2.3
	ns2.example.net.nz.	A	10.2.3.4

In this situation, BIND 8 could not resolve a name test.example.co.nz.  
ns[12].example.net did not and could not have glue in the co.nz zone
file.  Likewise, ns[12].example.net.nz can not have glue in the net zone
file.  The third hop finally did have glue, because the name servers are
in the same zone as the domain being queried.  BIND 8 would get its
knickers in a knot long before getting anywhere near the A records for
ns[12].example.net.nz.

This is a real situation I saw recently -- only the names have been
changed to protect the guilty.

If this had been registered as:

	example.co.nz.		NS	ns1.example.co.nz.
				NS	ns2.example.co.nz.
	ns1.example.co.nz.	A	10.1.2.3
	ns2.example.co.nz.	A	10.2.3.4

there would have been glue from the beginning.  Registering in this
fashion forces the registry to have glue -- even the ones that don't
use separate host records and only accept glue for the NSes that relate
to the domain itself.  (NZ is like that.)  

Really, in COM or NET land, if your registrar makes adding host records
hard, find a new registrar.  As TLDs split further, and more names go
into TLDs other than COM and NET, this is only going to get worse.  Even
our old, uh, friend Verisign has made adding host records to the
registry seamless.

-- don


More information about the bind-users mailing list