In message
<cae8glhnw1mo735rnpytjh5tw-t2j16x5yjfg7gjdnucaxdi...@mail.gmail.com>,
MegaBrutal writes:
> 2016-05-16 19:45 GMT+02:00 Alan Clegg <a...@clegg.com>:
> > On 5/16/16, 1:30 PM, "MegaBrutal" <bind-users-boun...@lists.isc.org on
> > behalf of megabru...@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 <ma...@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: ma...@isc.org
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
