BIND limits and performance questions

[Kevin Darcy]

Morris Balamut wrote:

> Hi
>
> It is my understanding that BIND limits the number of name servers in a zone
> to 16. What does that really mean?

> Was that also the case for BIND 4.x? How does it enforce that limit? and
>   what happens if the limit is exceeded,
>   are some name servers ignored?  What kind of impact might a user experience?
>
I assume you're talking about NSMAX. I don't think it's really accurate to say
that BIND enforces this limit on "name servers in a zone". It's more like BIND
won't *use* any nameservers for a zone beyond the first 16. If someone has 16
*non-functional* nameservers for a zone, chances are that the entire zone is
down. So it really doesn't make much of a difference in practice anyway.

I think NSMAX also applies to the number of addresses you can configure into a
masters { } clause, and maybe also into a forwarders { } clause also...

> I have a customer currently running a version of BIND 4.x and most zones
> have 19 master name servers defined (and
> there are a fair amount of zones).  They are planning to migrate to 8.2.x in
> the near future and I am concerned that
> there will be a problem? What kind of consequences can they expect?

I'm not sure what you mean by "19 master nameservers defined". Do you mean 19
NS records, or 19 addresses in the masters { } clause (actually, since this is
BIND 4, I should probably say "19 addresses in the "secondary" line)?

> What are the pros and cons of having multiple master name servers?

Hard to answer without knowing what you mean by "master name server".
Technically, if "master" means "the original source of all data for the zone",
then there can only be one "master" if you're using regular
AXFR/IXFR replication. This may be completely separate from what is in the NS
records for the zone; there's no requirement that the "master" (in the above
sense) even *have* an NS record in the zone.

> This same customer has significant number of zones that are managed by a
> different organization within the company.
> This group has its own set of name servers and typically they have one or
> two masters per zone, however virtually all these
> zones have the 19 name servers discussed earlier defined as secondary name
> servers.

Okay, now you're making a distinction between "masters" and "secondary name
servers". So I'm completely confused by your explanation. Perhaps it would be
better if you just stuck to "master" and "slave", where "slave" means "a
replica of the master".

> This is complicated by existing company policies that allow virtually any
> domain to any address or range of addresses
> on their network. They have, at last count, 55 top level domains and at
> least 1000+ subdomains. In addition the network
> is world-wide.
>
> It would seem to me that they must be violating some 'rules'.

No, not necessarily. Across all of our subsidiaries, we probably have at least
as many "top level" (I assume you mean second-level, like something under a
generic TLD or a country-code TLD) domains, although I doubt we have anywhere
near 1000 subdomains. DNS scales well. Why do you think the sheer number of
domains and/or subdomains would break a "rule"?

Note, however, that 19 NS records is very likely to overflow the 512-byte limit
of a DNS UDP packet and thus require TCP retries. This is ugly for two reasons:
1) TCP is more expensive than UDP for ordinary DNS queries, and 2) TCP port 53
might be blocked by firewalls or router filters.

> They have
> intermittent problems that they have not been able
> to track down. It would seem to me that the zone transfers alone could make
> the name servers 'crazy'.

Well, certainly if *all* of their nameservers slaved *all* of their zones, they
would probably bury themselves in zone-transfer traffic. But if it's parceled
out in a reasonable fashion, there's no reason it couldn't work...


- Kevin