Re: [dnsext] Domain "Flag" to indicate (non-)availability of automatic DNS updates for reverse DNS

Mark Andrews wrote:
[..]
> 	Or realise that end hosts SHOULD have the ability to update
> 	their PTR records to reflect their own names.  Remember
> 	ISP's are leasing the addresses to the hosts.  ISP's don't
> 	own the host and they shouldn't be forcing name constraints
> 	on the hosts.

Well, that is actually the fun part. SixXS actually allows one to
delegate the subnet reverse* DNS to a DNS server of ones own choosing.
Not everybody does that though and thus the updates end up at us.

Coming to think of it, maybe an other route is to per-default set a "NS
." or something like that making the delegation lame? Though that is I
think also not a proper way to solve it.

> 	The real question is how to do this so that spoofed updates
> 	are not processed.  A update over TCP should be strong
> 	enough for this.

As in this case it involves tunnels we can do full RPF checks on the
packets and are sure that when it arrives to us that those packets
really originate from there. In a shared (eg cable) environment or where
one does not have such a strict hierarchy it becomes harder.

The point in this question was simply that we don't want to handle the
DDNS updates, which do end up at our boxes. In these cases people are
not aware that they can configure a reverse DNS server, even though they
have the possibility to do so, and as it is enabled per default on
Windows it still happens.

Greets,
 Jeroen

* = we have /64's over the tunnel, where ::1 is the PoP (us) and ::2 is
the users endpoint, these one cannot change for reverse DNS, but they
are are already pre-populated, the /48 one can route to ::2 though is
fully theirs an they can configure multiple DNS servers there and even
to DNSSEC on them.