On Mon, 10 May 1999, Ian Carr-de Avelon wrote:
> Dear Aleph,
> I'll leave it to your discresion as to whether this should go
> public. For me this is simply a problem relating to adding MX records
> with 192.168.xx.xx addresses to internal name servers. Some people may
> assume that if they rely on DNS data for their own domains, they are
> only relying on the intergrety of their own servers. With BIND 8 this
> appears not to be true. If somone can change the delegation of a domain,
> or make a new domain like EMIT. or 168.192.IN-ADDR.ARPA., bind 8 will
> accept the data pointed to via route servers etc. in place of local
> master files.
Unless I'm missing your point, bind 8.2 does not exhibit this behaviour.
Your own master zones are accepted. Tested with bind 8.2 and "fake"
master zones for test.com and 1.192.168.in-addr.arpa.
capistrano.beach.net # what /usr/sbin/named | grep named
/usr/sbin/named:
named 8.2 Tue Mar 23 11:23:34 PST 1999 danat_private:/usr/home/dan/bind8.2/src/bin/named
capistrano.beach.net # nslookup www.test.com
Server: ns.beach.net
Address: 206.16.184.129
Name: www.test.com
Address: 192.168.1.1
capistrano.beach.net # nslookup 192.168.1.1
Server: ns.beach.net
Address: 206.16.184.129
Name: www.test.com
Address: 192.168.1.1
www.test.com is, in reality, 207.206.9.99
Apologies to Test.com, Inc., I've given you your zone back :)
Now, if you have a zone like (note only two octets, 192.168)
zone "168.192.in-addr.arpa" {
type master;
file "db.192.168";
};
It's not going to be used to directly look up 192.168.1.1
192.168.1.1 is in the zone 1.168.192.in-addr.arpa so your lookups
will fail, but it's not due to a bug in bind.
Dan
--
Dan Busarow 949 443 4172
Dana Point Communications, Inc. danat_private
Dana Point, California 83 09 EF 59 E0 11 89 B4 8D 09 DB FD E1 DD 0C 82
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:45:46 PDT