Subject: [DNSOP] ip6.arpa reverse delegation

From: Michael Richardson <[email-masked]>
Date: Sun, 23 Nov 2014 16:14:12 -0500

I have read:
  Automated Delegation of IP6.ARPA reverse zones with Prefix Delegation
  draft-andrews-dnsop-pd-reverse-02

as a method to delegate reverse zones to CPE devices as the prefix
is delegated.  I find the method entirely sensible, and I think highly
secure.  I don't know if this belongs in dnsop or in homenet (or dhcpv6,
since a new DHCPv6 option is requested, and this enhances DHCPv6-PD): I'll
let the INT and Ops ADs sort that out.

I suggest that one of these WGs should adopt it, and even suggest that this
document should Updates: 6204/7084.  If I had the required code point, I
would implement it today in an IPv6 ACS I work on (ServPOET), and contribute
code to Barrier Breaker OpenWRT (to dnsmasq) to do the client end.

I want to say that this is very similar to the way that the "wavesec"
mechanism that the FreeS/WAN project experimented with a decade ago (a few
Minneapolis and Atlanta IETF networks back around IETF50).  We used DHCP
to carry a key, this was installed by TSIG update by the DHCP(v4) server, and
was used to populate the reverse DNS.  The result was an IPsec
laptop/32<->gateway(0.0.0.0/0) tunnel, using IPsec for security across the
wireless rather than the WEP that was common at the time.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 24 Nov 2014 11:47:08 +0200

> let the INT and Ops ADs sort that out.

Is this actually desired by the operators? At least here (.fi), ISPs seem to consider the reverse pointing to x.customer.y.isp.fi a feature, not a bug, of the current IPv4 deployment and specified same for future IPv6 deployments as well. (At the moment my ISP does not officially support IPv6, but do provide it via 6rd, and I get NXDOMAIN for reverses, but v4 is populated for more or less all ISPs.)

> code to Barrier Breaker OpenWRT (to dnsmasq) to do the client end.

odhcp6c is the DHCPv6 client there, so some (slightly awkward) integration between dnsmasq/odhcp6c would be implied..

(dnsmasq is relatively statically configured no-IPC daemon, so I suppose odhcp6c could provide it with some sort of config file fragment which provides the information from step 2 in the draft to dnsmasq..)

Cheers,

-Markus

---

From: Michael Richardson <[email-masked]>
Date: Mon, 24 Nov 2014 09:29:10 -0500

Markus Stenberg <[email-masked]> wrote:
    >> I have read: Automated Delegation of IP6.ARPA reverse zones with
    >> Prefix Delegation draft-andrews-dnsop-pd-reverse-02
    >> 
    >> as a method to delegate reverse zones to CPE devices as the prefix is
    >> delegated.  I find the method entirely sensible, and I think highly
    >> secure.  I don't know if this belongs in dnsop or in homenet (or
    >> dhcpv6, since a new DHCPv6 option is requested, and this enhances
    >> DHCPv6-PD): I'll let the INT and Ops ADs sort that out.

    > Is this actually desired by the operators? At least here (.fi), ISPs

I don't care what they want: I want it as a customer.
At this point, one can not originate email from IPv6 addresses without
working reverse names.

I don't care if some operators do not want to deploy, and I don't care if
some customers can't be bothered to setup or or own their reverse map.

Nobody is forcing anyone to do this; (or to run IPv6).
But, if someone wants to delegate the reverse (and I know many operators who
do), this seems like the right way to do it.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Ted Lemon <[email-masked]>
Date: Mon, 24 Nov 2014 10:34:07 -0500

> Is this actually desired by the operators? At least here (.fi), ISPs seem to consider the reverse pointing to x.customer.y.isp.fi a feature, not a bug, of the current IPv4 deployment and specified…

I have heard different things from different operators.   Some are skeptical, some definitely want this. So I think we have to just provide a way to do it, and let the operators (and their customers) decide whether they care to do it.

Populating the reverse tree with garbage records is a really bad thing to do IMHO, although you will hear voices on dnsop disagreeing with this perspective.   It's also pretty expensive, particularly if you do dnssec: there is no way to generate a static zone for that many IP addresses, so you have to fake up records in response to specific queries and then do on-the-fly signing.   Which to me sounds like a DoS attack in the making.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 24 Nov 2014 16:56:20 +0200

Markus Stenberg writes:
> seem to consider the reverse pointing to x.customer.y.isp.fi a
> feature, not a bug, of the current IPv4 deployment and specified
> same for future IPv6 deployments as well. (At the moment my ISP does
> not officially support IPv6, but do provide it via 6rd, and I get
> NXDOMAIN for reverses, but v4 is populated for more or less all
> ISPs.) 

The Ficora (Finnish Communications Regulatory Authority)
recommendation for taking IPv6 in use for consumers in Finland
actually recommends that all ISPs do offer IPv6 reverse, either by
delegating it or automatically adding reverses for all IPv6 addresses.

https://www.viestintavirasto.fi/ohjausjavalvonta/ohjeettulkinnatsuosituksetjaselvitykset/ohjeidentulkintojensuositustenjaselvitystenasiakirjat/suositusipv6nkayttoonotostakuluttajalaajakaistaliittymissa2002014s.html

It lists 3 different example methods how this can be done, and notes
that it is important that this is done automatically, i.e without
consumer needing to ask for anything (of course if you want the
reverses to be delegated to you, then you need to contact your ISP and
ask for it).

They examples they include are:

[7] IPv6 Dynamic Reverse Mapping,
http://users.on.net/~rmibus/pymds/IPv6-auto-rDNS.pdf

[8] Python Modular DNS Server (pymds),
http://code.google.com/p/pymds/

[9] Kazunori Fujiwara (JPRS), One implementation of IPv6
reverse DNS server,
http://member.wide.ad.jp/~fujiwara/v6rev.html

Btw, it also recommends that consumer always gets the same prefix and
that the lifetime of the prefix is long i.e. recommended value for
preferred lifetime is 7 days and recommended value for valid lifetime
is 30 days. This of course do have connection to the reverses,
especially if they are delegated to the consumer (which most likely
would also actually require completely stable prefix).

So if your ISP in finland does not offer IPv6 reverses yet, they do
not follow the recommendation, thus you could send them email and ask
them to start following "Ficora Recommendation 200/2014 S" :-)
-- 
[email-masked]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 24 Nov 2014 16:56:57 +0100

>> a method to delegate reverse [DNS] zones to CPE devices

> Is this actually desired by the operators?

I'm a little ashamed to admit that I don't understand the purpose of
reverse DNS.

To my naive eyes, if you already know the IP of a host, then you should be
able to ask the host directly for its hostname at the application layer --
unless you've already got the information (think SMTP HELO).  If your
application protocol doesn't support doing that, then there's RFC 4620.
(Yeah, I know, experimental.)

Note that there's no new security issues with doing that -- you still
confirm that the given hostname maps to the host's IP address, as you
already do with the hostname obtained from reverse DNS.

I'm probably confused -- could somebody please explain?

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Mon, 24 Nov 2014 12:04:59 -0500

> I'm a little ashamed to admit that I don't understand the purpose of

Reverse DNS is useful for logging, so that you can associate a name with a host.   You don't necessarily want to (and may not be able to) send a request to the host, but the reverse tree is pretty easy to populate if everybody does the right thing.   With DNSSEC, the reverse tree also becomes a place where you can hang keys that associate with the IP address.   And, again given that the host itself might not be entirely reachable, being able to look up its name in the reverse tree can tell you something about it.

Of course, in many cases this sort of stuff is not needed and might even be harmful in terms of privacy. But when it is needed, the mechanism is nice to have.

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 24 Nov 2014 09:08:04 -0800

> On Nov 24, 2014, at 9:04 AM, Ted Lemon <[email-masked]> wrote:
> 

A nice mechanism I've seen for IPv6 that is remarkably useful along these lines (first seen by me in looking at Comcast's DNS infrastructure):

In the lower 64 bits of the IPv6 address, encode as human-readable the IPv4 address.  So, for example, if a machine's V4 address is 10.1.2.4, the IPv6 address is 2101:{...}:10:1:2:4

--
Nicholas Weaver                  it is a tale, told by an idiot,
[email-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc