BIND 4 -> 8 gotcha

[Jim Reid]

>>>>> "David" == David Hedley <david at inty.co.uk> writes:

    >>  The query-source address option sets the address and maybe the
    >> port number that the name server uses for *sending* queries. It
    >> doesn't have any effect on the addresses that the name server
    >> listens on for incoming queries. That can be controlled through
    >> the listen-on option.

    David> Nonetheless, it still works (I did say it was a hack!). It
    David> _does_ affect the addresses that the name server listens on
    David> for incoming queries. 

Well yes and no. What your query-source option does is make the name
server create a UDP socket bound to the wildcard address and port
number 53. It's not "listening" on that socket: as a datagram
transport service UDP doesn't have this concept. So when your system
receives a query addressed to one of the random dialup interfaces, its
TCP/IP stack delivers the packet to the name server because this
wildcard socket happens to exist.

    David> When a request (or response) comes in for 'named' to an IP
    David> address that isn't in its list of interfaces, it still
    David> processes it anyhow,

These queries should probably cause the name server to log warnings
about "refused query on non-query socket". That's what usually happens
when a query is sent to the socket the name server uses for its own
queries. To be honest, I'm surprised that these queries are getting
answered. I know named goes to great lengths to send a reply back out
the interface that the query was received on, but I didn't think it
would go as far as that. It's always nice to learn something new...

    David> hence the query-source hack works
    David> (unless a TCP connection is required :)

And the reason a TCP connection won't work is because there's no TCP
listener socket wildcarded to port 53. [An inbound TCP SYN packet
isn't going to get delivered unless there's a listener socket waiting
to receive it.] This means that this hack/feature won't work for zone
transfers or queries that generate a truncated response from the name
server. Maybe you can live with that or kludge around it as well.

    David> But there should at least be some option for restoring the
    David> BIND-4 mode of operation!

Perhaps. But sometimes backwards compatibility isn't desirable. :-)

If the interval-interface option won't do - say because the pattern of
dialup usage is irregular - you could take the problem out of the name
server. It would be straightforward to write a little daemon that
scanned for interface changes and gave the name server a kick via ndc
to add or remove sockets as appropriate. Yes, this is ugly, but so is
forcing the name server to use network interfaces that pop up and
disappear at random IMHO.

    David> The server itself is not dialling up - other computers are
    David> dialling into it (and are being given the server-end IP
    David> address of the PPP link as a DNS server). The firewall
    David> restricts incoming traffic along the PPP link and only
    David> allows certain packets to the server end of the PPP link
    David> until further authentication is requested and granted,
    David> which requires DNS to function properly.

    David> Sure, we could reconfigure our firewall, but we'd rather
    David> not have to if at all possible!

Well that's your choice. I have a nasty feeling that the feature/hack
that you're relying on might come back and haunt you when it's least
expected. For instance some important lookups from the dial-in hosts
don't work because they need TCP connections. Or maybe the feature
goes away in a future BIND or OS release. I'd prefer to have a clean
named.conf file and have the dial-in users send their queries to the
fixed IP addresses of the name server. However since I don't know your
infrastructure, I've no idea if tweaking your firewall and the dialup
user configurations is a viable option or not.