5

I'm working on a project to set up a Bind9 DNS server on a network with a 255.255.252.0 subnet.

Currently, the way it is set up makes it impossible to run nslookup From 192.168.1.101/22 through ns1 @ 192.168.1.61/22 on a 192.168.0.0/22 network with a gateway of 192.168.1.1/22. Don't ask why I started addressing at 192.168.1.1 and not 192.168.0.1. I just did. Easier to type two 1s in a row but want extra address space. I put my dhcp wifi clients in the .2.1-255 range and run vms in the .3.1-255 range. The point is that it seems Bind seems to think all addresses @ 192.168.1.0-255 are from a separate /24 zone.

This bears to question, does a 0.168.192. reverse zone look like a /24 subnet by default in Bind? What about a 168.192. reverse zone? Are they all /16 zones to Bind?

Which returns me to my original question.

Despite all the errors in my Bind config, which would be good to know what I should do to fix them specifically, how do I achieve what I want to do?

How do you program Bind to host a /22, /21, or any nonstandard bitted zone?

Here is my reverse zone file in the raw.

$ttl 38400
0/22.0.168.192.in-addr.arpa.    IN  SOA ns.fqdn.com. user.emai.com. (
            1489024990
            10800
            3600
            604800
            38400 )
61.1.168.192.in-addr.arpa.  IN  NS  ns.fqdn.com.
61.1.168.192.in-addr.arpa.  IN  PTR ns.fqdn.com.
1.1.168.192.in-addr.arpa.   IN  PTR fw.fqdn.com.
62.1.168.192.in-addr.arpa.  IN  PTR ws.fqdn.com.
63.1.168.192.in-addr.arpa.  IN  PTR multi.fqdn.com.
25.1.168.192.in-addr.arpa.  IN  PTR fs.fqdn.com.
110.1.168.192.in-addr.arpa. IN  PTR thncl.fqdn.com.

The following errors were found in the BIND configuration file /etc/bind/named.conf or referenced zone files ..

 zone fqdn.com/IN: NS 'fqdn.com' has no address records (A or AAAA)
    zone fqdn.com/IN: not loaded due to errors.
    _default/fqdn.com/IN: bad zone
    /var/lib/bind/192.168.0.rev:2: SOA record not at top of zone (0/22.0.168.192.in-addr.arpa)
    /var/lib/bind/192.168.0.rev:9: ignoring out-of-zone data (61.1.168.192.in-addr.arpa)
    /var/lib/bind/192.168.0.rev:10: ignoring out-of-zone data (1.1.168.192.in-addr.arpa)
    /var/lib/bind/192.168.0.rev:11: ignoring out-of-zone data (62.168.192.in-addr.arpa)
    /var/lib/bind/192.168.0.rev:12: ignoring out-of-zone data (63.1.168.192.in-addr.arpa)
    /var/lib/bind/192.168.0.rev:13: ignoring out-of-zone data (25.1.168.192.in-addr.arpa)
    /var/lib/bind/192.168.0.rev:14: ignoring out-of-zone data (110.1.168.192.in-addr.arpa)
    zone 0.168.192.in-addr.arpa/IN: loading from master file /var/lib/bind/192.168.0.rev failed: not at top of zone
    zone 0.168.192.in-addr.arpa/IN: not loaded due to errors.
    _default/0.168.192.in-addr.arpa/IN: not at top of zone 

This being said, the only thing I can think of is to expand the zone to a 168.192. zone and put an ACL that limits lookups to the /22 subnet, leaving the zone file expanded and open.

Any help is appreciated, Server Buddies!

1 Answer 1

14

With the scheme defined for mapping IPv4 addresses to reverse DNS names (RFC 1035 §3.5), it not possible to do delegations that are not at the /8, /16 or /24 boundaries.

For networks larger than /24, you'd simply delegate multiple zones of the closest smaller size.

So your /22 network would be put into four consecutive /24 zones:

  • 0.168.192.in-addr.arpa
  • 1.168.192.in-addr.arpa
  • 2.168.192.in-addr.arpa
  • 3.168.192.in-addr.arpa

For smaller than /24 networks, a bit of a clever hack defined in RFC 2317 is used, where in the parent zone CNAME records are added for the names belonging to each individual IP address of the smaller network, pointing all of these into a new namespace and then delegating that namespace instead.

1
  • Nice explanation! Thanks!
    – Bee Kay
    Jun 17, 2020 at 21:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .