CIDR in-addr.arpa problem

Kevin Darcy kcd at chrysler.com
Tue Mar 16 20:31:18 UTC 2010


What do the CNAMEs look like in 33.168.192.in-addr.arpa, or, if that's 
not a delegated zone, the closest-enclosing zone of that?

                                                                         
                                             - Kevin

On 3/16/2010 3:19 PM, Lister wrote:
> Hello all,
>
> I have a problem with a CIDR IN-ADDR.ARPA delegation of a /28 netblock.
> Domain names and IP numbers have been edited for privacy purposes.
>
> I've had my local ISP make me a CIDR in-addr.arpa delegation for the 
> block
> 192.168.33.112/28 to my name servers:
>        ns1.mydomain.dom
>        ns2.mydomain.dom
>
> on my BIND-9.6.0-P1 I did the following:
>
> in named.conf:
> --------------
> zone "112/28.33.168.192.in-addr.arpa" {
>   type master;
>   file "master/112-28.33.168.192.rev";
>   allow-query { any; };
>   allow-transfer { affilates; };        //irrelevant to the topic in 
> question
>   notify yes;
> };
>
> in master/112-28.33.168.192.rev:
> --------------------------------
> $ORIGIN 112/28.33.168.192.in-addr.arpa.
> $TTL 3600       ; 1 hour
> @ IN SOA  ns1.mydomain.dom. hostmaster.mydomain.dom. (
>            2010031600 ; serial
>            15m        ; refresh
>            10m        ; retry
>            1d         ; expire
>            60         ; -ve cache ttl
>            )
> $TTL 1d
> @  NS             ns1.mydomain.dom.
> @  NS             ns2.mydomain.dom.
> $TTL 30
> 113  PTR         host1.mydomain.dom.
> 114  PTR         host2.mydomain.dom.
> ;.
> ;.
> 126  PTR        hostN.mydomain.dom.
>
> To the best on my knowledge, the above config is correct. However BIND 
> responds to PTR queries authoritatively with NXDOMAIN, and, AFTER 
> FORWARDING. It gives the same query respone for anything in the /24 
> (class C) network, not only my /28.
> Naturally, it should NOT forward; and if it does, it should NOT 
> respond authoritatively.
>
> Using a '-' instead of '/' in the config files made no difference.
> I tried this on BIND-9.6.0-P1 on FreeBSD-7.1 and BIND-9.4.3-P3 on 
> CentOS 5.3 with the same results.
>
> BIND 9.6 was built in a standard way as FreeBSD port. This is how it 
> was as obtained from syslog:
> built with '--localstatedir=/var' '--disable-linux-caps' 
> '--with-randomdev=/dev/random' '--with-openssl=/usr' 
> '--with-libxml2=/usr/local' '--without-idn' '--enable-threads' 
> '--sysconfdir=/etc/namedb' '--prefix=/usr' '--mandir=/usr/share/man' 
> '--infodir=/usr/share/info/' '--build=x86_64-portbld-freebsd7.1' 
> 'build_alias=x86_64-portbld-freebsd7.1' 'CC=cc' 'CFLAGS=-O2 
> -fno-strict-aliasing -pipe' 'LDFLAGS= -rpath=/usr/lib:/usr/local/lib' 
> 'CXX=c++' 'CXXFLAGS=-O2 -fno-strict-aliasing -pipe'
>
>
> Please tell me if I did something wrong or it's a BIND problem and if 
> so, if there's a workaround.
>
> Kind regards,
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
>





More information about the bind-users mailing list