consolidating Reverse Zones

Grant Taylor gtaylor at tnetconsulting.net
Fri Oct 22 00:27:55 UTC 2021


On 10/21/21 1:33 AM, Edwardo Garcia wrote:
> Hai all,

Hi,

> One of these is we have a number of reverse zones, a /19 in fact, they 
> are mostly GENERATE'd  for regions with fixed gw and a few other local 
> custom PTRs

So 32 x /24s.  Annoying, but not terrible to work with.

> In our examples I have tried
> zone "8-15.110.100.in-addr.arpa" {
>          type master;
>          file "cgnat.rev";
>          notify no;
> };
> I also tried 8/21.110.100...

I've had bad luck with "/" in domain (dot) names (of in-addr.arpa and 
elsewhere).

> and it always complain loading from master file cgnat.rev failed: 
> unknown class/type
> 
> The zone file has usual header, and PTR entry are only
> 151.10  PTR     blue.stop.
> (even tried   10.151)

I don't see the expected "IN(ternet)" class indication.  That matches 
the unknown class / type message you are getting.

I would expect something like the following:

151.10   3600   IN   PTR   blue.stop.

Perhaps there is a BIND zone file optimization that I'm not taking into 
account.

> I guess bind can not consolidate like this and we have to put up with a 
> million /24 zone files ?

Maybe it's just me, but I feel like 32 is a far cry from a million /24 
zone files.

> I was thinking because we can do classless dele with smaller than /24, 
> it would work on bigger  :)

Remember, DNS does things on the domain (dot) boundary.  DNS ~> BIND 
does not have any knowledge that "8-15" or "8/21" in the 
"8-15.110.100.in-addr.arpa" or "8/21.110.100.in-addr.arpa" domains 
represent subnet prefixes.  To BIND, they are just strings of text that 
mean something to the hostmaster.  This is why RFC 2317 CNAMEs some of 
the records to records in a separate domain name that can be delegated.

You should be able to use $GENERATE to be able to create the records.

    $GENERATE 0-15 $ CNAME $-21.110.100.in-addr.arpa.

That being said, I would never use RFC 2317 CNAME alias for the 3rd 
octet.  I would use standard NS delegation.  E.g.:

    $GENERATE 0-15 $ NS mydnsserver.example.net.

Then I would configure the domains / zones on my DNS server.

...

Aside:  I've been known to use what I refer to as cross delegation.  It 
works for me.  But credible people have discouraged it.

Server 1 has records like this:

    $GENERATE 0-127   $.2.0.192.in-addr.arpa. PTR $.2.0.192.in-addr.arpa.
    $GENERATE 128-255 $.2.0.192.in-addr.arpa. NS server2.example.net.

Server 2 has records like this:

    $GENERATE 0-127   $.2.0.192.in-addr.arpa. NS server1.example.net.
    $GENERATE 128-255 $.2.0.192.in-addr.arpa. PTR $.2.0.192.in-addr.arpa.

This simply re-uses the same method of delegating owner names / 
sub-domains from one server to another server.  I tend to refer to this 
as cross delegation.  Some will refer to this as an ugly hack.  But it 
has worked for me every time that I've needed to use it.

...

Finally, the more that I look at your 100.110.8/21 example, the more 
that I realize that you're probably wanting to have two incrementing 
numbers, the 8-15 for the 3rd octet and 0-255 for the 4th octet.  I 
don't think that $GENERATE can do that.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20211021/8428f00f/attachment.bin>


More information about the bind-users mailing list