Zone Authority Subnets

Mark Andrews Mark_Andrews at isc.org
Thu Oct 20 05:47:50 UTC 2005


	Change your gmail defaults.  The current settings add stupid urls
	that make the email unreadable especially when you are discussing
	domain name.

> I have searched a while for this, but here is what I have come to conclude.
> in-addr.arpa does not understand classless boundaries.

	It doesn't.  It was designed before CIDR existed.

> If the name servers for 1.2.160.0/20 <http://1.2.160.0/20> are set to my
> own, then I have authority over this zone.
> 
> I made a entry in bind9 config:
> 
> zone "2.1.in-addr.arpa" {
>         type master;
>         file "/etc/bind/db.2.1.0.0";
> };

	You should have all 16 zones that cover this range.

	zone "160.2.1.in-addr.arpa" {
		...
	};
	...
	zone "175.2.1.in-addr.arpa" {
		...
	};
 
> This way, the server will answer all of those requests.
> 
> $TTL 900
> @        IN      SOA    ns1.mydomain.com <http://ns1.mydomain.com>.   
>    admin.mydomain.com <http://admin.mydomain.com>. (
> 2005102000 ; Serial Number
> 900 ; Refresh after 3 hours
> 900 ; Retry after 1 hour
> 604800 ; Expire after 1 week
> 900 ) ; Minimum TTL of 1 day
> 
>         IN      NS ns1.mydomain.com <http://ns1.mydomain.com>.
>         IN      NS ns2.mydomain.com <http://ns2.mydomain.com>.
> 
> 1.160.2.1.in-addr.arpa.     IN      PTR     mail.mydomain.com
> <http://mail.mydomain.com>.
> 
> 
> Yes, this works great and all, until further inspection.
> 
> `host 1.2.160.1` shows mail.mydomain.com <http://mail.mydomain.com>
> 
> However:
> 
> dig 160.2.1.in-addr.arpa
> 
> Fails! Why? I think its because there is no authority for that 'class b'
> (/24) zone.

	Fails how?  You are most probably misinterpreting the result.

	B.T.W. Class B zones where /16's not /24's.
 
> Besides making separate zone files for each of my 1.2.[160-175] 'class b'
> zones, what can I do instead?

	That's what you do.  If you really want to only change one zone
	you can create those 16 zones.  Fill them with CNAMES that point to
	another zone then add the PTR records to the other zones.  Why
	anyone would do that rather than just have the PTR records in the
	original zones is beyound me.
 
> host -t ns 160.2.1.in-addr.arpa
> 
> Fails as well.

	Of course it fails.  There are no NS records there.
 
> How can I resolve this?
> Thank you

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org



More information about the bind-users mailing list