bind 8.3.3 and forwarding
Kevin Darcy
kcd at daimlerchrysler.com
Tue Mar 30 01:09:36 UTC 2004
Mark Benschop wrote:
>Hi !
>
>I have to phase out 3 of my 5 secondairy 8.3.3 bind servers in a closed
>(not internet connected) network.
>Since I have no complete control over the configuration of the clients
>it is still possible that some machines will try to resolve stuff on the
> "phased out" machines, I thought it would be a good idea to make make
>the old boxes forwarders to my primary/new secondairies and log the
>queries that are done to them in order to determine who is still using them.
>
>The problem is that something goes wrong with the forwarding (i think).....
>Whenever I try to resolv something using the forwarding server, I'm
>getting a "SERVFAIL" so nothing is found.
>When I look on in the querylogging on the the server that the forwarder
>forwards to (i.e. my new secondairy) I see the following :
>
>First a query direct to the new secondairy
>17:57:45.590XX+/145.78.156.10/lr006b01.lr006.kpn-post.nl/A/IN
>
>now a 'forwarded query'
>17:58:30.972 XX+/145.78.156.10/./NS/IN
>the ip-address in these lines is my workstation.
>
>The questions are :
>-Isn't the 'forwarder' supposed to contact the new seconairy instead of
>my workstation ?
>
Depends on how your workstation is configured. You haven't told us
anything about that. From the evidence above, it looks like you might be
running some sort of caching and/or forwarding resolver on your
workstation. This greatly complicates the troubleshooting process. Why
don't you try issuing some queries *directly* to the forwarder to see if
it is working properly? It's the forwarder's configuration and not your
workstation's configuration that you're really trying to troubleshoot
here right?
>-Why does my workstation seem to ask for an empty record ?
>
It's not an "empty" record, it's a root-zone NS query. It's common for
caching resolvers to generate such queries. Are you sure your internal
root zone is OK? What happens if you try a root-zone NS query directly
to one of the authoritative servers from the command line? Hopefully
your "hints" file doesn't contain exclusively only the "old" servers;
those servers are now mere forwarders so they don't answer
authoritatively for the root zone. If none of the hints-configured root
servers responds authoritatively for the root zone, then all caching
resolvers (including your workstation?) are going to fail their
"priming" queries and not be able to resolve much of anything. This
would manifest itself with SERVFAIL responses, so it matches the
symptoms you're seeing.
>-Is there a better solution for what I want to achieve ? Phasing out by
>forwarding / logging queries ?
>
My remote servers are usually slaves for large numbers of zones, so in
low-bandwidth situations, I don't want both the old and new servers
sucking down those updates, and thus I have in the past made the old box
a forwarder to the new one during the migration of that particular
location to new nameserver hardware. When bandwidth is not an issue, my
preference is to leave the old servers authoritative until all of the
clients with obsolete resolver configurations are identified and
updated. The reason for this is that I've run into some oddball apps
that actually care whether the responses have the AA bit set or not...
- Kevin
More information about the bind-users
mailing list