Problems with named default configuration in 6-STABLE
Heiko Wundram (Beenic)
wundram at beenic.net
Tue Jul 17 23:00:28 UTC 2007
On Tuesday 17 July 2007 23:06:22 Jeremy Chadwick wrote:
> Can you expand on this, re: why it's "bad advice"? I also cannot make
> heads or tails of the BIND ARM saying it's "not recommended". Please
> shed some light on this for those of us less experienced in the know,
> if you could (I mean that sincerely).
See my mail: <200707171410.41601.wundram at beenic.net>, also in this thread.
A stub zone is basically a zone that's only configured with an absolutely
necessary amount of records (for the _zone_ itself). The idea behind stub
zones is the following:
$ORIGIN modelnine.org
stubzone IN NS ns1.stubzone
How is stubzone ever going to be resolvable unless you specify glue for
ns1.stubzone.modelnine.org? Normally, the standard "way" of doing this would
be to set up a glue (A) record for ns1.stubzone in modelnine.org, but with
stub zones you can also create different zone files:
$ORIGIN modelnine.org
<zilch>
$ORIGIN stubzone.modelnine.org
IN NS ns1
ns1 IN A a.b.c.d
which you can then integrate into your bind configuration as a normal zone for
modelnine.org and as a stub zone for stubzone.modelnine.org, and which only
contains the glue necessary to have the subdomain/-zone working by itself,
but does not contain other records.
When the nameserver sees a stub zone, it will not take the content of the zone
file as "authoritative" on existance or non-existance of domain names in that
zone, but only uses the records in the zone as glue or nameserver definitions
which are necessary to run the lookup to the "true" zone behind the stub,
which are then normally resolved. So, basically, this is a (different) way of
defining glue, which I personally don't find very appealing, as it splits the
glue over many, many files.
This mechanism is simply not applicable to the situation this thread was
talking about (using the root zone as hint or slave), that's what Doug was
trying to say, and I was trying to say in the mail I hinted at above.
--
Heiko Wundram
Product & Application Development
-------------------------------------
Office Germany - EXPO PARK HANNOVER
Beenic Networks GmbH
Mailänder Straße 2
30539 Hannover
Fon +49 511 / 590 935 - 15
Fax +49 511 / 590 935 - 29
Mail wundram at beenic.net
Beenic Networks GmbH
-------------------------------------
Sitz der Gesellschaft: Hannover
Geschäftsführer: Jorge Delgado
Registernummer: HRB 61869
Registergericht: Amtsgericht Hannover
More information about the freebsd-stable
mailing list