Authoritative only based on interface

[Smith, William E. (Bill), Jr.]

I have some additional information that may or may not shed lite.  I've
tracked this problem a little further and found that two of the offending
hosts/IP's are frequent offenders.  When I looked into exactly what they
were(platform, etc), I found one was a static NT 4 server running some
flavor of SNMP while the other was a W2K server running some flavor of SNMP.
Both of these are statically defined clients and not DHCP.  Is it possible
that something in the SNMP software is triggering these update attempts to
the secondary?  Also, these offending IP's do not make attempts to update on
all of our secondaries though sometimes this is the case. 

Bill

-----Original Message-----
From: Jim Reid [mailto:jim at rfc1035.com] 
Sent: Tuesday, July 17, 2001 12:30 PM
To: pelln at icke-reklam.ipsec.nu
Cc: comp-protocols-dns-bind at moderators.isc.org
Subject: Re: Authoritative only based on interface


>>>>> "pelln" == pelln  <pelln at icke-reklam.ipsec.nu.invalid> writes:

    >> Bob <BHockney at ix.netcom.com> wrote:
    >> Is there a way I can configure BIND (9.1) to answer a query
    >> only if it is authoritative if the query comes from one
    >> interface, but allow forwarding to answer the query if it come
    >> from another interface?  What I want to do is have it respond
    >> it external queries only if authoritative but respond to all
    >> internal queries.  Any insight appreciated.

    pelln> Views can do this, it does not work by interface though,
    pelln> but by the source address in the query.

It's not necessary to use views to control lookups based on IP address. Just
define ACLs for the inside and outside networks and apply them to
allow-query clauses as appropriate. For instance, someone could have a
global allow-query clause which is limited to the local network and have
per-zone allow-query clauses which are unrestricted. That way local users
can make arbitrary lookups and the outside world can only get answers for
queries about names in the zones served by the name server.

    pelln> You could use interface-specific bind behaviour, you would
    pelln> have to start several bind, and on each bind's config have
    pelln> 'listen-on' statements to use a specific interface.

This probably won't solve the problem. It will do more or less what the
original poster asked, namely handle queries based on the interface that
they were sent to. This is not necessarily the same thing as the interface
that took delivery of the incoming packet which is what seems to have been
originally asked. Most (all?) Unix TCP/IP implementations use the weak end
system model. They accept packets for any of the local addresses for the
host no matter which interface receives them. [See Stevens: Unix Network
Programming Vol1 or TCP/IP Illustrated Vol2.] There's usually no way of
telling which interface actually received the query. Packets come off the
wire and the host's network interface device drivers put them into one queue
for going up the kernel's TCP/IP stack.