tips on debugging DNS
Kimi
kimimeister at gmail.com
Sun Dec 16 00:47:12 UTC 2007
On 16/12/2007, Niall O'Reilly <Niall.oReilly at ucd.ie> wrote:
>
> 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 a learning exercise, I was asking for hints not a howto or a
someone to debug my config even if it appeared that way, merely trying
to give as much info as possible
> This is probably not about BIND, but about service design.
>
thing is my deisgn worked before I went away quite flawlessly but now
I am back and I am having issues, I know I made a change but for the
lyfe of me can't remember what it is.
> 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.
>
I'm not advertising a domain to big wide world, only
privately/internally. Im not interested in performance, but I am
paranoid in the sense I like to know what is happening.
> 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.
>
I will read your email properly, although I do think I had my wires
crossed, mis-understood what Kevin Darcy was trying to say before &
being way too paranoid for my own good at the time (02 Feb 2006).
>
> 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
>
>
>
>
>
Thanks Niall
--
Kimi
More information about the bind-users
mailing list