"Extra" NS on zone file can be used?

[Kevin Darcy]

I can't locate a copy of the FAQ to which you refer, but the part you quoted sounds just
plain wrong. The NS records of the zone, which are returned in the Authority Section of
responses, have higher "credibility" than the delegation NS records, and must therefore
*REPLACE* the delegation NS'es, according to Section 5.4.1 of RFC 2181. This is why it's
so important for the NS'es in the zone to be correct and functional, and to be identical
to, or a subset of the delegation NS'es (see the recent discussion involving Mark Andrews
and myself, on this topic). So the simple answer is yes, if you put an NS in the zone,
other nameservers will attempt to use it.

I'm not sure what the best way would be of implementing your hidden-master scenario.
Hacking nsupdate should be considered a last resort. Why not put one of the slave's names
in the MNAME and arrange to have it resolve to the master's address only in your
*internal* DNS? The world would think that that slave is the master, but you'd know
better...


- Kevin

Jesus Couto wrote:

> Hi,
>
>         I have read in a few places (for example, Question 2.17 of the
> comp.protocols.tcp-ip.domains FAQ) that the NS records for a zone
> defined inside the zone file arent really used... again from the FAQ:
>
> "They're essentially unused, though they are returned in the authority
> section of reply packets from your name servers"
>
>         So, lets say I add a NS record inside, say, "test" zone file listing
> "dada.ext" as
> a nameserver for it. A query for a name inside test (say, a.test) will
> return the NS as listed in the zone file. It will cause the server to
> fetch the A record for "dada.ext", and the next query into "test" will
> have that address into the Additional Info section of the answer. (All
> this checked using nslookup at d2 level and query logging on the "ext"
> server, but I may be wrong).
>
>         So, then, the server that did the second query into test will have the
> full list of NS as listed in the zone file and the address for all of
> them in the cache, right? And that  means that on further queries from
> that server, the "extra" server will be used for some of them, right?
> Thats what I'm thinking, but as it contradicts whats the FAQ states, I
> want some confirmation.
>
>         All this comes from playing with nsupdate and hidden masters... because
> a) the server only does the updates if its listed as the MNAME on the
> SOA of the zone and b) nsupdate only sends the updates to the MNAME
> server if its also a NS for the zone, I thought that, to have a hidden
> master, we could list the "real" server, on a private IP net and a
> private domain, on the NS of the zone file. Ex.:
>
> $ORIGIN mypublicdomain.com
>
>         82400   IN      SOA     master.priv. root.mypublicdomain.com. (
>                 2 1000 1000 1000 7200 )
>         82400   IN      NS      ns1.mypublicdomain.com.
>         82400   IN      NS      ns2.mypublicdomain.com.
>         82400   IN      NS      master.priv.
>
> but if at the end this means that the public servers ns1 and ns2 are
> going to start propagating that master.priv is an NS for
> mypublicdomain.com and giving away its private IP, then making servers
> on the internet to try to query that when doing lookups into
> mypublic.domain.com, its going to be ugly. (In any case, to solve this,
> I'm either going to use the perl Net::DNS module or rewrite nsupdate or
> the resolver lib to send queries to a given server instead of using the
> NS listed at the zone).
>
>         So, its this analysis right, and "extra" NS on the zone files will be
> used by external nameservers? Its then necessary to list as NS on a
> public zone only public, reachable nameservers?
>
>         Thanks in advance to whoever steps in and clarify this issue for me;
>
>                                                                         Jesus Couto F.