BIND serving ppp connections

[Kevin Darcy]

Andrew P. wrote:

>Mark Andrews wrote:
>  
>
>>>Hello!
>>>
>>>I was trying to set up bind to serve ppp clients. The problem
>>>is that when it starts up, there are no ppp connections and
>>>it doesn't start listening on the ppp server address.
>>>
>>>Is there a way to tweak bind to listen on a wildcard address
>>>or on a non-existent address?
>>>      
>>>
>> 
>>	The real question is why are you bothering to attempt to
>>	listen on the ppp address.  Just have named listen on a
>>	stable interface and advertise its address to the ppp
>>	clients.
>>
>>	If you really want named to start listening on the interface
>>	you can lower the interface scanning interval and/or have the
>>	ppp daemon notify named that it has a new interface.  rndc
>>	reload / rndc reconfig.
>>
>>	It wouldn't be that hard to add "rndc rescan" to just rescan
>>	the interface table.
>>
>>	Note: you need to be running as root unless you are using a Linux
>>	box w/ capability support.
>>
>>	Mark
>>    
>>
>
>Thanks, but that's what the problem is all about. My network
>has complicated routing. Once I use an address of a stable
>interface clients will try to access it from different IPs, those
>prohibited by allow-query. And I can't do rndc reload as I'm
>not running bind as root (FreeBSD 5.3).
>
I believe you misunderstood Mark. Anyone with the relevant rndc key can 
execute an "rndc reload" or "rndc reconfig". What superuser authority is 
needed for is in order to bind a privileged port (53) on a 
newly-discovered interface. Sudo and other command-line-level utilities 
don't help here, since the binding is occurring completely within the 
named process itself.

I still don't quite understand why you can't just run named on one or 
more stable interfaces. Set your allow-query (and/or allow-recursion) to 
whatever address range is given to the PPP clients. You should be able 
to control that using your DHCP subsystem. Even if you have multiple 
pools and weird routing, you should be able to have named listen on 
multiple stable interfaces (virtual and/or physical) so that nameservice 
could be available "locally" on each pool/subnet and not have to go 
through a router. In the absolute worst case, you NAT the client's 
addresses to some range and "allow-query" that range (the stateless 
nature of DNS traffic makes it eminently NAT'able). What am I missing here?

                                                                         
                                                                  - Kevin