Forward zone not working

[Mark Andrews]

In message <CAE8gLhnw1mO735RnPYtjh5Tw-t2j16x5yJfG7GjDNUCAXDim+Q at mail.gmail.com>, MegaBrutal writes:
> 2016-05-16 19:45 GMT+02:00 Alan Clegg <alan at clegg.com>:
> > On 5/16/16, 1:30 PM, "MegaBrutal" <bind-users-bounces at lists.isc.org on
> > behalf of megabrutal at gmail.com> wrote:
> >
> >>I want to have valid reverse & forward hostnames set up
> >>for this /64 subnet.
> >
> > This is silly.  Don't do this.
> 
> Why?
> 
> Most ISPs set up reverse & forward domain names for pool addresses.
> OK, I'm not an ISP, but it really seems to be a widely accepted and
> endorsed policy, to the point that addresses not having a reverse DNS
> often treated as suspicious.
> 
> 
> 2016-05-16 22:50 GMT+02:00 Mark Andrews <marka at isc.org>:
> >
> > If you want to delegate space to another server DELEGATE it.  Add
> > NS records for the other server.  Forward "zones" are NOT designed
> > to do this.  Doing actual delegations is *not* hard and works with
> > every server in the world.
> 
> What is the acceptable use case for forward zones, then?
> 
> See, ideally the zone should be served by my BIND server, it should be
> authoritative for the zone. Why I can't use it as the authoritative
> server for the zone is that BIND does not have a feature that the
> other DNS server has (on-the-fly generation of IPv6 reverse & forward
> records, without the need to store 2 * 2 ^ 64 records in zone files).

Ideally every machine should be registering its own PTR record in
the DNS and addresses without machines shouldn't have PTR records.
The only reason ISP did this is that they were too lazy to manage
PTR records for their customers.

We have had the tools for machines to be able to update their own
PTR records for nearly 2 decades now and only the reluctance of
ISP's to allow their clients to update the PTR records for their
own addresses has lead to this.

	zone 2.0.192.in-addr.arpa {
		type master;
		file "2.0.192.in-addr.arpa";
		update-policy {
			grant * tcp-self * PTR;
		};
	};

And on the client side a tool that does the equivalent of this
when a address is obtained.

	nsupdate -V << EOF
	local 192.0.2.1
	update delete 1.2.0.192.in-addr.arpa IN PTR
	update add 1.2.0.192.in-addr.arpa 3600 IN PTR host.example.net
	send
	EOF

Even better would be

	zone 2.0.192.in-addr.arpa {
		type master;
		file "2.0.192.in-addr.arpa";
		update-policy {
			grant * tcp-self * KEY;
			grant * selfsub *;
		};
	};

and then use SIG(0) to update the PTR record after installing a KEY
record.  This allows the client to cleanup records after it has
been renumbered.

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