Re: [BIND-BUGS #18] Non-delegated master domains

[dan () DPCSYS COM (Dan Busarow)]

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 dan () capistrano beach net:/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.                            dan () dpcsys com
 Dana Point, California  83 09 EF 59 E0 11 89 B4   8D 09 DB FD E1 DD 0C 82