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