tips on debugging DNS
Niall O'Reilly
Niall.oReilly at ucd.ie
Sun Dec 16 00:01:32 UTC 2007
On 15 Dec 2007, at 20:18, Kimi Ostro wrote:
> My problem is that internal name resolution works fine. Anything
> beyond is not working at all.
>
> my two internal name servers' forward any none local queries to a
> caching resolver only name server.
I've seen your later postings as well. You seem to be asking us
all, "how can I make BIND do X?" without first having asked yourself
(and, if you need to afterwards, us also), "Is X a reasonable
thing to be trying to do?"
This is probably not about BIND, but about service design.
There are two sides to DNS: resolving queries for clients on your
own net, and advertising your domain to the Internet world
(including your own net). It's important to understand this, and
useful to keep these two sides apart when designing and implementing
your name service. After you have it all working, you can look at
optimizing things.
1: Resolving queries
Client systems on your network need access to at least one, and
preferably two "full-function resolver" name servers. The job of
these is to receive queries, retrieve the corresponding information
from (local or remote) "authoritative" name servers, and to return
the retrieved information to the querying source. These servers
need to be able to do recursion; that's what "full-function" means.
Each client must be configured with a list of resolver servers to
use.
Note that having more than two full-function resolver servers
available to any particular client system most likely doesn't win
you much. Some clients are reputed not to look beyond the first
two on the list. Besides, failing over twice or more degrades
the "user experience" more than enough to bring you complaints
which you would probably prefer to avoid. If you have a complex
network, it makes sense to configure clients on different LANs
to refer to corresponding distinct pairs of full-function
resolvers.
Since the resolving name service is most likely one you want to
offer just to clients on your own network, rather than to anyone
on the entire Internet, you'll probably wish to restrict which
clients may present queries to these servers. For BIND, you can
do this using the "allow-query { ... };" configuration statement.
2: Advertising your domain
A full-function resolver can only do its job for clients from
which queries originate if it can locate and interrogate the
authoritative name servers for each domain for which it has to
deal with queries.
You need two or more authoritative name servers for your domain
(NB: not for your net!). These should be placed to avoid a single
common point of failure. In particular, you need to place them on
different networks; this will ensure that when your network goes
down, your entire domain doesn't just disappear for a while.
You need to arrange that whoever administers your parent domain
has added delegation records for your domain do that users of
client systems connected to other networks can discover your
authoritative servers.
Your off-site authoritative name servers have no need (or, as many
would say, have no business) to do recursion. On the other hand,
since they may receive queries from any full-function resolver
serving a client system whose user wishes to do business with your
company, they need to allow queries from all over. You'll need
"allow-query { any; };" and "recursion no;".
It's simplest to set up your on-site authoritative name servers
separate from your full-function resolvers, in the same way as
the off-site ones.
3: Summary of basic model
For your network:
Two local full-function recursive resolvers (FFRs)
More if you have a complex network with many LANs
Each client system configured with a list of two local FFRs
For your domain:
One or more on-site authoritative name servers (master, slaves)
Additional off-site slave servers (ISP, business partner, ...)
Delegation records from parent domain
4: Suggested optimizations
It's usual for full-function resolvers to act as master authoritative
servers for special zones such as "localhost" and "127.in-addr.arpa".
This has significant advantages: immediate response can be given to
a client instead of performing recursion, and queries for these
strictly local domains are kept on-site. These zones never change,
so there is no advantage in using a master/slave architecture.
It's not uncommon for full-function resolvers to act as unadvertised
slave authoritative servers (sometimes called "stealth servers") for
local domains. Immediate response (without recursion) and elimination
of stale DNS records (provided that NOTIFY is supported and used) are
advantages of this approach.
The idea of having full-function resolvers act as unadvertised master
servers for reverse domains corresponding to private (RFC1918) and
other special address ranges is becoming well accepted. BIND 9.4 does
this automagically for several such domains, avoiding others in order
not to disrupt any existing local use.
Best regards,
Niall O'Reilly
University College Dublin IT Services
PGP key ID: AE995ED9 (see www.pgp.net)
Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9
More information about the bind-users
mailing list