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

From: Jeroen Massar <[email-masked]>
Date: Wed, 06 May 2009 22:26:35 +0200

Hi,

I guess quite a few ISPs who are providing public IP addresses to their
customers must be seeing these and then loads of them on their NS's:

May  5 14:15:14 noc named[26139]: client xxxx:xxxx:xxxx::x#3421046:
update '3.2.1.8.b.d.1.0.0.2.ip6.arpa/IN' denied

or the IPv4 equivalent. Now I know that most of these will come from
Windows as they have this setting activated per default and one could if
running inside an Active Directory turn those off easily, but in the
case where one doesn't have control over the hosts in question it would
be nice if there was a flag for indicating that the zone is able or not
to update, and possibly where to send updates. Is there such a mechanism
already?

If there is no such option, maybe something like:
$ORIGIN 3.2.1.8.b.d.1.0.0.2.ip6.arpa.
@	DDNS .

or:
@	DDNS ddns-updates.example.net.

The first indicating there is no updating host, the latter indicating
where to send updates, as otherwise the NS in the SOA will always get
the queries and maybe that is not the correct location.

note: finding the ORIGIN of the zone where that record is available is
of course a tricky thing, IPv6 it is most likely at the /64 level but it
could be higher up, would a per-nibble-scan then be the idea, for IPv4
one would be fine with 4 queries there to check what can be done.

(of course if we had the above mechanism one would still get it
deployed, but at least it would resolve it for newly installed/upgraded
hosts)

Greets,
 Jeroen

---

From: Mark Andrews <[email-masked]>
Date: Thu, 07 May 2009 09:45:01 +1000

In message <[email-masked]>, Jeroen Massar writes:
> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> --------------enigF842B7CDDCA78E6FBBFFED67
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> Hi,
> 

	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.

	IN-ADDR.ARPA and IP6.ARPA are delegated to the ISP so that
	the hostnames of the machines at the addresses can be
	registered in the DNS.  It's not there, despite what some
	ISP's think, for their naming schemes.

	If I'm leasing a shop then I get to choose the name of the
	shop, not the person I'm leasing the shop from.

	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.

	Mark
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 May 2009 19:21:24 -0500

> 	are not processed.  A update over TCP should be strong

CGA would work nicely for IPv6.   TCP depends on there being good  
isolation between hosts on the local network, which I don't think is a  
valid assumption.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 07 May 2009 11:01:20 +1000

In message <[email-masked]>, Ted Lemon writes:
> CGA would work nicely for IPv6.

Agreed but that also requires protocol work to add signature method.

> TCP depends on there being good  

It should be reasonable for many situations.  Looking at my cable
connection I can't see any of my neighbor's traffic so to spoof
this requires a blind TCP spoof.  Add some ingress filtering and
this is almost impossible to break.

Mark

---

From: Joe Abley <[email-masked]>
Date: Thu, 7 May 2009 07:40:49 +0200

> to update, and possibly where to send updates. Is there such a  

There's a mechanism available which is in use by some people, but  
which when presented to dnsop led to much frowning and the document  
withered on the vine.

   http://tools.ietf.org/id/draft-jabley-dnsop-missing-mname-00.txt

The principle objection from memory was that this approach might cause  
yet more junk traffic to be received by the root servers. There was  
some sympathy for the fact that there is no good mechanism available  
to signal "DDNS not available" but in general there was no consensus  
that this was a real problem that needed solving.

Joe

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 07 May 2009 08:45:54 +0200

Mark Andrews wrote:
[..]
> 	own the host and they shouldn't be forcing name constraints

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.

> 	are not processed.  A update over TCP should be strong

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.