(no subject)

[Kevin Darcy]

news at bt.net wrote:

> Newsgroups: comp.protocols.dns.bind
> Subject: stubs for in-addr.arpa, 8.2.2p5 problems
> From: dentm at bt.net.nospam (Michael Dent)
> Message-ID: <8E98DC1F0mdentbtnetnospam at news-reader.bt.net>
> User-Agent: Xnews/2.05.24
> Lines: 28
> Date: Fri, 10 Dec 1999 21:38:31 GMT
> NNTP-Posting-Host: 194.74.75.194
> X-Trace: newreader.ukcore.bt.net 944861911 194.74.75.194 (Fri, 10 Dec 1999 21:38:31 GMT)
> NNTP-Posting-Date: Fri, 10 Dec 1999 21:38:31 GMT
>
> When configuring stubs for reverse delegation of /24, what do you put as NS
> records in the parent /16 zone file?  do you put the names of the original
> NS the zone was delegated to, or the name of the NS your delegating it off
> to via stub?
> or do you not put NS records in the /16 zone file?

Strictly speaking, creating a stub definition for a child zone does *not* constitute a
delegation of that zone.

To delegate, you need to put the NS records in the parent master zone, specifying all of
the nameservers which are authoritative for the child zone, and which you are designating
as accepting queries for the zone. Normally, this would be the same list of NS'es which
appear in the child zone itself. Note that you would *not* include the master of the parent
zone as an NS of the child zone if it only has a stub definition for the child: nameservers
aren't authoritative for zones they merely stub, and you should only be listing
authoritative nameservers in delegation NS records (otherwise, they are "lame"
delegations).

> I take it there are no disadvantages to using stub?  The server keeps a
> copy of the NS information obtained in a zone file and that would be read
> in on a restart of named. I've had to delegate off 70 /24 networks and I
> used stubs. I was just wondering if it was better to use just NS entries in
> the zone file.

The disadvantage to using stubs is the zone-transfer overhead, mainly. The stub definition
costs you this overhead, and if you're master for the parent zone, and have proper
delegations, what does it buy you in return? The only thing I can think of is if *all* of
the NS'es for the zone become lame, your stubs will allow you to limp along for a while
longer than delegations alone will (at least until the zone expires). But if you're
watching for lame delegations in your logs, and updating your delegation records
accordingly, then it shouldn't ever come to this, and you're just expending the stub
zone-transfer overhead for no benefit.

In my opinion, a stub zone should really be thought of more as a lightweight (in most
circumstances) but non-authoritative alternative to being a slave for a delegated zone; not
as an actual substitute for delegation.

> Also does anybody else have problems with 8.2.2P5? I've got a caching only
> nameserver which was getting slow in response or not even giving a
> response. I did queries like 'host www.cisco.com ns1.xxx.xx' from the box
> itself.

It's possible that it was running into memory exhaustion. Did you check how large the
process was at the time of the slowdown? Was the machine swapping heavily?

> I killed named and restarted and it started giving response really quickly
> and had no problems. I don't know how i can find out what is wrong.  I did
> a truss on the pid when it was slow or not responding and it was doing
> sendto() and recvfrom() and poll() quite a bit so it was doing something.
> Testing systems which poll the server still say it is having problems. I've
> had complaints about another server as well.
> Over 100 days its had about 700 million UDP packets out and the same number
> in, so its a busy server. Its a sparc running solaris 2.6.

14 million packets average per day is certainly not chicken feed. What kind of Sparc are
you running this on? Is this a normal volume for the machine? It's possible that some sort
of configuration problem is causing excess queries. It's also possible that if you're
getting hit with a lot of recursive queries for those stub zones, and the TTL values are
fairly small, that you're expending a lot of resources constantly querying the
authoritative servers for the information. If so, it might make sense from a tuning
perspective to actually become an unregistered slave for those zones. But if memory
exhaustion is your problem, this will actually make things worse, since now all of that
zone information is resident in memory.


- Kevin