tips on debugging DNS

[Kimi]

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