Subject: [DNSOP] new version of IPv6 rDNS for ISPs

From: "Lee Howard" <[email-masked]>
Date: Wed, 21 Nov 2012 10:01:23 -0500

You may remember this draft from a couple of years ago.  People keep asking
me what a residential ISP should do for IPv6 PTR records, and I keep
repeating what's in the draft.
The intent is to document existing solutions, since prepopulating PTRs like
we did in IPv4 doesn't work.  Last time I brought it to DNSOP, there was
interest, but not necessarily as a working group document.  Since it's been
a while, and the operator community is still asking for guidance, I've
updated it, and would like a renewed review of it as an individual
submission (unless this WG or v6ops wants it).

Filename:	 draft-howard-isp-ip6rdns
Revision:	 05
Title:		 Reverse DNS in IPv6 for Internet Service Providers
Creation date:	 2012-11-20
WG ID:		 Individual Submission
Number of pages: 13
URL:
http://www.ietf.org/internet-drafts/draft-howard-isp-ip6rdns-05.txt
Status:          http://datatracker.ietf.org/doc/draft-howard-isp-ip6rdns
Htmlized:        http://tools.ietf.org/html/draft-howard-isp-ip6rdns-05
Diff:
http://www.ietf.org/rfcdiff?url2=draft-howard-isp-ip6rdns-05

Abstract:
   In IPv4, Internet Service Providers (ISPs) commonly provide IN-
   ADDR.ARPA. information for their customers by prepopulating the zone
   with one PTR record for every available address.  This practice does
   not scale in IPv6.  This document analyzes different approaches for
   ISPs to manage the ip6.arpa zone for IPv6 address space assigned to
   many customers.

Thanks,

Lee

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Nov 2012 16:44:29 +0000

On Nov 21, 2012, at 10:01 AM, Lee Howard <[email-masked]>
 wrote:
> Since it's been

The document looks pretty good to me, except that the motivation section is likely to be controversial (as I'm sure you are aware).   The reasons you state are not reasons that I personally find motivational; I want a working reverse tree because it's a way to publish information about an address, both for debugging purposes and for operational purposes (e.g., DANE).

I could make some suggestions about this section, but I think it might be better to just take it out.   I would just ditch the text in the introduction starting with "Some of the most..." and the three bullet items that follow it.

Aside from this quibble, I think the document is useful and should be published.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 21 Nov 2012 18:07:23 +0000

On 2012-11-21 4:44 PM, Ted Lemon wrote:
> ... Aside from this quibble, I think the document is useful and should
> be published.

my quibble is different. ipv6 is bringing some tough love to the
consumer-facing edge. the fact that ISP's auto-populated the IPv4 PTR
tree made it impossible for mail server operators to distinguish between
consumer grade and business grade internet connections. since consumer
grade connectees should really not be connecting to SMTP servers on
other networks, there's been a great deal of work to find all of the
common auto-populated PTR naming patterns in use anywhere in the world,
in order to reject off-net e-mail from consumer grade connections. this
work is inefficient, ineffective, painful even when correct, and often
wrong.

there are some excellent reasons not to use PTR RR records for this
purpose, starting with good security practices and continuing through
good engineering practices. nevertheless this is a pre-existing property
of the existing server plant, and even if server operators were willing
to give it up, the tail would be very long. i'm going to treat this as
an unavoidable universal mistake that all of us will have to live with,
forever, period.

network operators should provide PTR RR's for specific addresses which
have real names. the inability due to IPv6's richness of address space
to provide auto-naming for PTR's does not to me, a problem statement make.

paul

-- 
"It seems like the rules for automagic completion of incomplete names typed into browsers are going to start to look like those for the game of fizbin." --rick jones

---

From: Jim Reid <[email-masked]>
Date: Wed, 21 Nov 2012 18:28:00 +0000

> to provide auto-naming for PTR's does not to me, a problem statement make.

+1

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 21 Nov 2012 13:44:11 -0500

On Wed, Nov 21, 2012 at 06:07:23PM +0000, Paul Vixie wrote:
> other networks

I do not accept this premise, and I don't see any argument in favour
of it.  What evidence does "willing to pay more for the same lousy
service" provide with respect to "is not sending outbound crap"?

> an unavoidable universal mistake that all of us will have to live with,

There, we agree.

> have real names.

Also here.

A
-- 
Andrew Sullivan
[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Wed, 21 Nov 2012 19:14:45 +0000

> service" provide with respect to "is not sending outbound crap"?

that's not a dns question, and we seem to agree on the problem statement
mechanics, so i'm not going to answer this here beyond saying "if you
aren't willing to pay extra for a PTR RR on your end, then i don't want
you talking to my SMTP servers". in other words this is a personal
policy matter for me, and though i know a couple ten-million others feel
the same way, i'm not going to try to enshrine it in IETF's work, in any
way.

---

From: "Griffiths, Chris" <[email-masked]>
Date: Thu, 22 Nov 2012 16:55:49 +0000

> Aside from this quibble, I think the document is useful and should be published.

Ted,

I agree with this assessment, and perhaps it does make sense to update or remove as needed in a follow-up version.  I support this document being published, in order to provide the options that operators can take as they deploy IPv6 and support it in their DNS platforms.

---

From: Frank Habicht <[email-masked]>
Date: Thu, 22 Nov 2012 12:30:25 +0300

Hi,

>> to provide auto-naming for PTR's does not to me, a problem statement make.

+1
not pre-populating rDNS here.
feel that absence of rDNS is a useful indicator for "don't accept spam from
here".

1.1
s/2.0.192.IN-ADDR-ARPA/2.0.192.IN-ADDR.ARPA/g
while I consider 1.1 correct. I doubt whether that's a "good" situation.

2.1
sounds a bit like it's bad to receive an NXDOMAIN. Is it bad?
is "successful lookup" one that gets a response,
or one that has  ANSWER: >0   ?

Under recommendations I personally would like the negative response to be
given more consideration. Maybe as a default behavior for residential
connections as long as end users have not chosen any of the other options
(as/if provided by the ISP)...?

Frank

---

From: Joe Abley <[email-masked]>
Date: Thu, 22 Nov 2012 14:07:53 -0500

Hi Lee,

Some comments below, based on a fairly cursory skim through (so, I may well have missed and/or understood things).

2.2 Wildcard match

There is no mention of the issue of uniqueness. What do you do when you have five thousand different customers who all attempt secure dynamic updates with the name "macbook"? Or, what to do when you have two Nest thermostats in the same house (on the same network) both of which think their name is "nest"?

If there was a possible solution where a customer device could auto-register a name using dynamic DNS, how would it know what nameservers to send the UPDATE messages to? Extract the MNAME from the closest-enclosing SOA? How do you find the closest-enclosing SOA, bearing in mind that the address concerned might previously have been used by someone else, and hence the blah.blah.ip6.arpa owner name might already exist?

2.3.1 Dynamic DNS from individual hosts

I think it should be mentioned that this is a niche scenario, and that the vast majority of customers today don't connect a single host directly to their DSL/cable/whatever modem. And alongside that, some study should be cited that has come to that conclusion based on actual measurements, rather than my speculation :-)

2.3.2 Dynamic DNS through Residential Gateways

I think this section makes an assumption that the place to send your UPDATEs to is the same DNS server that is handed out (e.g. via DHCP option) for use as a recursive server. If that's really a requirement, that ought to be spelled out (because I think in general it's unusual). Most ISPs hand out at least two such addresses. Can either one be used? If not, which one?

2.3.3 Dynamic DNS Delegations

This approach would leave a single nameserver responsible for a delegation, which is contrary to general best practice. Quite possibly that's a reasonable trade-off in this case (poor link quality affecting DNS resolution would also affect the ability of the customer to use the network) but the trade-off should be mentioned.

The conclusion that this is not an option for residential ISPs assumes sysadmin requirements on the part of the user, incidentally. If this convention was widely deployed in home gateways, users wouldn't need to care.

2.5 Dynamically Generate PTR When Queried ("On the Fly")

The DNSSEC commentary is a bit weird. Keys are associated with zones, not with RRSets. Keys would not need to be generated on the fly; I think you're talking about signatures.

4.3 Considerations for Other Uses of the DNS

I don't understand this section at all. What does it mean?

General

I don't feel that in its current form this draft provides much practical advice to an ISP who is trying to find an analogue to "pre-populate all my IN-ADDR zones containing customer addresses" as is commonly (whatever you think about it) done in IPv4. I don't think that's generally a fault of the draft; I think this is just an operational consideration that was not well-explored during the development of IPv6. There are potentially additional requirements for hosts, routers, DHCPv6 and RADIUS in here.

Perhaps a more useful approach (if there is consensus that more work is required in this area) would be to work on a requirements document for the solution space.

If the goal is rather to figure out practical advice which ISPs can use today to provide PTR records for their customers, then I think this draft needs to provide some more concrete advice.

Joe

On 2012-11-21, at 10:01, Lee Howard <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Nov 2012 20:24:25 +0000

> The conclusion that this is not an option for residential ISPs assumes sysadmin requirements on the part of the user, incidentally. If this convention was widely deployed in home gateways, users wo…

The mechanism for specifying how the delegation happens should allow the zone to be delegated to more than one name server—presumably the primary would be the CPE device, but someone who really cares about the reliability of the reverse zone, if there is such a person, would want to set up a secondary elsewhere and keep it up to date with zone transfers or the like.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 23 Nov 2012 10:10:11 +1100

In message <[email-masked]>, Joe Abley writes:
> There is no mention of the issue of uniqueness. What do you do when you have 
> five thousand different customers who all attempt secure dynamic updates with
>  the name "macbook"? Or, what to do when you have two Nest thermostats in the
>  same house (on the same network) both of which think their name is "nest"?
> 
> If there was a possible solution where a customer device could auto-register 
> a name using dynamic DNS, how would it know what nameservers to send the UPDA
> TE messages to? Extract the MNAME from the closest-enclosing SOA? How do you 
> find the closest-enclosing SOA, bearing in mind that the address concerned mi
> ght previously have been used by someone else, and hence the blah.blah.ip6.ar
> pa owner name might already exist?
> 
> I think it should be mentioned that this is a niche scenario, and that the va
> st majority of customers today don't connect a single host directly to their 
> DSL/cable/whatever modem. And alongside that, some study should be cited that
> has come to that conclusion based on actual measurements, rather than my spe
> culation :-)

Individual hosts should be doing dynamic DNS.  Where that update
is sent to may change but all machines should be doing it and should
support TSIG as a minimum.  They should also expect to see DNAME
and CNAME records.  i.e. the update may be to a name other than
that produced by the address to IP6.ARPA (and IN-ADDR.ARPA) mapping.

Individual hosts should be able to work out where to send the updates
by querying the DNS to find the nameservers of the containing zone
after processing and DNAME/CNAME mappings.  We shipped code sans
DNAME/CNAME remapping a decade ago that did this.

Darwin and Windows already support sending dynamic updates though
I don't believe they handle the presence of DNAME or CNAME.

> I think this section makes an assumption that the place to send your UPDATEs 
> to is the same DNS server that is handed out (e.g. via DHCP option) for use a
> s a recursive server. If that's really a requirement, that ought to be spelle
> d out (because I think in general it's unusual). Most ISPs hand out at least 
> two such addresses. Can either one be used? If not, which one?
> 
> This approach would leave a single nameserver responsible for a delegation, w
> hich is contrary to general best practice. Quite possibly that's a reasonable
>  trade-off in this case (poor link quality affecting DNS resolution would als
> o affect the ability of the customer to use the network) but the trade-off sh
> ould be mentioned.

Firstly there are multiple ways to do a "delegation".
* Use a DNAME to a namespace that is already delegated.
  a.b.c.d.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA DNAME IP6.EXAMPLE.NET
* The traditional method using NS records.

> The conclusion that this is not an option for residential ISPs assumes sysadm
> in requirements on the part of the user, incidentally. If this convention was
> widely deployed in home gateways, users wouldn't need to care.

And with IPv6 I would expect most homes *will* get dynamic forward zones.
IPv6 *is* a game changer and people are still rooted in IPv4 think.

> The DNSSEC commentary is a bit weird. Keys are associated with zones, not wit
> h RRSets. Keys would not need to be generated on the fly; I think you're talk
> ing about signatures.
> 
> I don't feel that in its current form this draft provides much practical advi
> ce to an ISP who is trying to find an analogue to "pre-populate all my IN-ADD
> R zones containing customer addresses" as is commonly (whatever you think abo
> ut it) done in IPv4. I don't think that's generally a fault of the draft; I t
> hink this is just an operational consideration that was not well-explored dur
> ing the development of IPv6. There are potentially additional requirements fo
> r hosts, routers, DHCPv6 and RADIUS in here.
> 
> Perhaps a more useful approach (if there is consensus that more work is requi
> red in this area) would be to work on a requirements document for the solutio
> n space.
> 
> If the goal is rather to figure out practical advice which ISPs can use today
>  to provide PTR records for their customers, then I think this draft needs to
>  provide some more concrete advice.
> 
> 
> Joe
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Joe Abley <[email-masked]>
Date: Thu, 22 Nov 2012 19:11:14 -0500

On 2012-11-22, at 18:10, Mark Andrews <[email-masked]> wrote:

> support TSIG as a minimum.

The missing pieces here include:

 - what sane ISP/campus/home network/hotspot operator gives credentials to customers or even random users to complete dynamic updates to one of their master servers?
 - how can a TSIG key be shared between a network operator and a client that potentially don't know each other?
 - what name should a user be allowed to specify in their PTR RDATA?
 - what stops user A from sending authentically TSIG-signed UPDATEs to a nameserver and changing (or removing) user B's PTR?
 - what consumer systems do this by default? (I think it's none, but I thought I'd ask)

> after processing and DNAME/CNAME mappings.

I think you skipped a step -- you need to find the zone cut before you can find the nameservers responsible for the zone. I guess I do that by asking for blah.ip6.arpa/IN/SOA and checking the authority section, but what if the authority section is empty because of software choices in some nameserver? I guess then I need to

[krill:~]% ifconfig en0 | grep inet6 | grep -vi fe80::
	inet6 2001:4900:1042:100:7ed1:c3ff:fee8:102f prefixlen 64 autoconf 
[krill:~]% 
[krill:~]% dig 7.7.2.6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short
[krill:~]% dig 7.2.6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short 
[krill:~]% dig 2.6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short 
[krill:~]% dig 6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short 
[krill:~]% dig 4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short 
[krill:~]% dig f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short 
[krill:~]% dig d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short 
[krill:~]% dig 8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short  
[krill:~]% dig e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short  
[krill:~]% dig 7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short  
[krill:~]% dig 2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short  
[krill:~]% dig a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short 
[krill:~]% dig e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short 
[krill:~]% dig 4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short 
[krill:~]% dig 8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short 
[krill:~]% dig 5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short 
[krill:~]% dig 0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short 
[krill:~]% dig 0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short 
[krill:~]% dig 1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short 
[krill:~]% dig 0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short 
[krill:~]% dig 2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short 
. jabley.hopcount.ca. 2011032174 10800 3600 604800 86400
[krill:~]% 

Ah, there it is. There's no MNAME specified (I rudely called it ".") but let's pretend I didn't do that.

Now I need to know:

  what is my name?
  how do I know the name is unique within this network?
  what TSIG key should I use?

Let's suspend disbelief and suppose that I am capable of knowing a reasonable name that represents a reasonable, valid FQDN, that I know it's unique, and that I have somehow discovered a TSIG secret for the local network that is still a secret, and isn't shared knowledge amongst 300,000 other customers.

Once I've answered those questions, I send a TSIG-signed UPDATE to the MNAME-specified server and update:

7.7.2.6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN PTR krill.hopcount.ca.

Presumably we're encouraging PTR records to make sense, in which case I also want to update:

krill.hopcount.ca. AAAA 2001:4900:1042:100:584e:a27e:8df4:6277

Since hopcount.ca is my own domain, and I run the server referenced in the MNAME (assuming again I change it from "." to something sensible), there is some chance I could make this work. What if the domain is hosted elsewhere? What if it's the ISP's domain I've decided to use? What if I have no reasonable parent domain configured, and the local hostname is "Joe's Computer"?

I need to repeat this for every v6 address I have (I have five right now, apparently, not counting the link-local) and also handle deletion of AAAAs and PTRs that might already be there, accommodating the full range of abrupt disconnects that phones and networks enjoy six hundred times per day.

Even without harping on about the many unanswerable questions in the travelogue above, this whole procedure seems filled with fail.

> I don't believe they handle the presence of DNAME or CNAME.

I believe these days none of (Windows, Mac OS X, iOS, Android) do this by default. Windows and Mac OS X can be made to do this kind of thing with specific configuration ("wide-area bonjour", "Active Directory"), which is usually only ever done in an enterprise context.

I think current tools for this suck, and current protocols are going to need extensions to be defined before the situation gets any better. Happy to be proven wrong, though.

If there's a good way to do this (enforce a naming scheme that guarantees uniqueness, use SIG(0), whatever) then I think this draft needs to spell it out in a way that people can actually implement, both as vendors of consumer operating systems and as v6-capable ISPs. Simply saying "this has been easy for a decade" doesn't really get us anywhere. 

Joe

---

From: Mark Andrews <[email-masked]>
Date: Fri, 23 Nov 2012 12:16:32 +1100

In message <[email-masked]>, Joe Abley writes:
>  - what sane ISP/campus/home network/hotspot operator gives credentials =
> to customers or even random users to complete dynamic updates to one of =
> their master servers?

ISP's have a contractual relationship often with shared secrets
(username / password) for updating all sorts of information via a
web interface.  TSIG is just a username / password pair operated
over DNS instead of HTTP / HTTPS.  You can still do all the sanity
checking you want on the names if you want.  Named has the hooks
to do this today.  What it doesn't have yet is a external TSIG
database but that is realitively easy to add.

>  - how can a TSIG key be shared between a network operator and a client =
> that potentially don't know each other?

Use a DH TKEY exchange with packets sourced from the address you want to
be updated.  You then have a TSIG that is bound to a address.  You only
allow that TSIG to update the associated reverse name.

>  - what name should a user be allowed to specify in their PTR RDATA?

Any legal multi label hostname.  You can do checks on the name for
obsenties if you want.

>  - what stops user A from sending authentically TSIG-signed UPDATEs to a =
> nameserver and changing (or removing) user B's PTR?

See above.

>  - what consumer systems do this by default? (I think it's none, but I =
> thought I'd ask)

We are designing for the FUTURE.  The consumer systems WILL do this
if the operators add support.  This is all existing protocols being
bolted together.

> I think you skipped a step -- you need to find the zone cut before you =
> can find the nameservers responsible for the zone. I guess I do that by =
> asking for blah.ip6.arpa/IN/SOA and checking the authority section, but =
> what if the authority section is empty because of software choices in =
> some nameserver? I guess then I need to

We shipped code to do this back before the turn of the millenium
with BIND 8 as it was needed for nsupdate.

> 	inet6 2001:4900:1042:100:7ed1:c3ff:fee8:102f prefixlen 64 =
> autoconf=20
> [krill:~]%=20
> [krill:~]% dig =
> 7.7.2.6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. =
> IN SOA +short
> [krill:~]% dig =
> 7.2.6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. =
> IN SOA +short=20
> [krill:~]% dig =
> 2.6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN =
> SOA +short=20
> [krill:~]% dig =
> 6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN =
> SOA +short=20
> [krill:~]% dig =
> 4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA =
> +short=20
> [krill:~]% dig =
> f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA =
> +short=20
> [krill:~]% dig =
> d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA =
> +short=20
> [krill:~]% dig =
> 8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA =
> +short =20
> [krill:~]% dig e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. =
> IN SOA +short =20
> [krill:~]% dig 7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. =
> IN SOA +short =20
> [krill:~]% dig 2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN =
> SOA +short =20
> [krill:~]% dig a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN =
> SOA +short=20
> [krill:~]% dig e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA =
> +short=20
> [krill:~]% dig 4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA =
> +short=20
> [krill:~]% dig 8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA =
> +short=20
> [krill:~]% dig 5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20=
> 
> [krill:~]% dig 0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20=
> 
> [krill:~]% dig 0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20
> [krill:~]% dig 1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20
> [krill:~]% dig 0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20
> [krill:~]% dig 2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20
> [krill:~]%=20

% nsupdate -dd
> update add e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. 0 in ptr dummy.example.net.
> send
Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id:   5017
;; flags: qr rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA

;; AUTHORITY SECTION:
2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. 0 IN	SOA	. jabley.hopcount.ca. 2011032174 10800 3600 604800 86400

Found zone name: 2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa
The master is: .
couldn't get address for '.': not found
% 
 
> Ah, there it is. There's no MNAME specified (I rudely called it ".") but =
> let's pretend I didn't do that.
> 
> Now I need to know:
> 
>   what is my name?

Names don't depend apon where you are in the network.  You give a
machine a name when you configure it for the first time.

>   how do I know the name is unique within this network?

The name is fully qualified.  There is no "unique within this network" to
worry about.  It's globally unique.

>   what TSIG key should I use?

The one you negotiate with the nameserver.

> Let's suspend disbelief and suppose that I am capable of knowing a =
> reasonable name that represents a reasonable, valid FQDN, that I know =
> it's unique, and that I have somehow discovered a TSIG secret for the =
> local network that is still a secret, and isn't shared knowledge amongst =
> 300,000 other customers.
> 
> Once I've answered those questions, I send a TSIG-signed UPDATE to the =
> MNAME-specified server and update:
> 
> =
> 7.7.2.6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. =
> IN PTR krill.hopcount.ca.
> 
> Presumably we're encouraging PTR records to make sense, in which case I =
> also want to update:
> 
> Since hopcount.ca is my own domain, and I run the server referenced in =
> the MNAME (assuming again I change it from "." to something sensible), =
> there is some chance I could make this work. What if the domain is =
> hosted elsewhere? What if it's the ISP's domain I've decided to use? =
> What if I have no reasonable parent domain configured, and the local =
> hostname is "Joe's Computer"?

Well you host your zone on a server that does dynamic updates.
 
> I need to repeat this for every v6 address I have (I have five right =
> now, apparently, not counting the link-local) and also handle deletion =
> of AAAAs and PTRs that might already be there, accommodating the full =
> range of abrupt disconnects that phones and networks enjoy six hundred =
> times per day.

Well you would send one update for the forward with all your addresses.

> Even without harping on about the many unanswerable questions in the =
> travelogue above, this whole procedure seems filled with fail.
> 
> I believe these days none of (Windows, Mac OS X, iOS, Android) do this =
> by default. Windows and Mac OS X can be made to do this kind of thing =
> with specific configuration ("wide-area bonjour", "Active Directory"), =
> which is usually only ever done in an enterprise context.
> 
> I think current tools for this suck, and current protocols are going to =
> need extensions to be defined before the situation gets any better. =
> Happy to be proven wrong, though.

Tools become better as every starts to support it.
 
> If there's a good way to do this (enforce a naming scheme that =
> guarantees uniqueness, use SIG(0), whatever) then I think this draft =
> needs to spell it out in a way that people can actually implement, both =
> as vendors of consumer operating systems and as v6-capable ISPs. Simply =
> saying "this has been easy for a decade" doesn't really get us anywhere.=20=

---

From: "John Levine" <[email-masked]>
Date: 23 Nov 2012 01:46:42 -0000

>And with IPv6 I would expect most homes *will* get dynamic forward zones.

More likely no forward zones, since they serve no useful purpose.

>IPv6 *is* a game changer and people are still rooted in IPv4 think.

Agreed.  Why do you think that a host that is not a server and will
never be contacted by (non-malicious) other hosts needs a name?

R's,
John

PS: If you were planning to say that with the magic of IPv6, everyone will
be able to run servers on their home cable connection, don't bother.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 23 Nov 2012 12:56:51 +1100

> never be contacted by (non-malicious) other hosts needs a name?

Because servers out there won't allowing it access without a name.
I know this is stupid but they exist.
 
> be able to run servers on their home cable connection, don't bother.

I expect to have fibre to the home within 5 years as part of the
NBN rollout here in Aus.  With that there is no good reason discourage
running servers at home as there are with asymetric access technologies
like cable and aDSL.

Mark

---

From: "John Levine" <[email-masked]>
Date: 23 Nov 2012 02:13:41 -0000

>I know this is stupid but they exist.

Given a choice between rolling out complex and fragile rDNS systems,
and telling people with such servers that the IPv6 world is different,
I know what I'd do.

>running servers at home as there are with asymetric access technologies

Nothing personal, but if you think that upload speed has anything to
do with the rules against servers on consumer broadband, you don't
understand the internet access business very well.  (Hint: ADSL
uptream bandwidth is unshared to the DSLAM.)

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Fri, 23 Nov 2012 13:22:32 +1100

> uptream bandwidth is unshared to the DSLAM.)

There are lots of reasons.  Most of which don't make any sense at
all if you examine them critically.  If you are paying for bits to
be moved it should matter where they are being moved from.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 23 Nov 2012 03:18:09 +0000

> be able to run servers on their home cable connection, don't bother.

Why not?

---

From: George Michaelson <[email-masked]>
Date: Fri, 23 Nov 2012 13:37:08 +1000

>> be able to run servers on their home cable connection, don't bother.

Because the lack of public IPv4 was only an *excuse* for blocking this functionality: ISPs in the main don't want you to equalise traffic coming from their CAN network out to the world, they didn't build with that model in mind.

One can even invert the sentence a bit: they made assumptions about the traffic asymmetries in the world and built to take advantage of them.

OTOH, if you want to say "with the magic of IPv6, servers in the home are now at least possibly simpler" I am there. I know, because I've used some, to great effect.

(I hated setting up NAT inbound rules to one, and only one internal IP. with IPv6, I have to open an ACL inbound, but having said I want port 22 SSH to work, I can now get to all my home nodes. Internode IPv6 native on ADSL2+)

Of course, you still hit ISP level ACLs. there are a bunch of simplistic portblocks they do, on the basis that it felt right at the time, and if it was good enough then, it must still be good now. Port 25 for instance, inbound, to their CAN numbered space can be "hard"

-G

---

From: Ted Lemon <[email-masked]>
Date: Fri, 23 Nov 2012 03:51:19 +0000

> Because the lack of public IPv4 was only an *excuse* for blocking this functionality: ISPs in the main don't want you to equalise traffic coming from their CAN network out to the world, they didn't…

I hear you, but this isn't really a meaningful rejoinder, because this equalization you are talking about isn't a prerequisite for selling devices that will want to publish services from the home.

You can't have a network that only lets traffic go in one direction.   IPv4+NAT makes it hard for traffic to go in both directions, and yet still we have bittorrent, Skype, limited VoIP, and lots of back-to-my-pc solutions.   We have dyndns.org, which wouldn't have needed to exist if people weren't setting up home servers.

So really, while it may be true that ISPs will resist certain kinds of home servers being set up, and I don't people to be running web servers targeted to the general public on home network connections, it's entirely reasonable to think that low-use home servers will be a reality in the near future.   We know that ISPs are talking about serious, high-reliability M2M applications.   So external reachability is going to be a reality.

It's easy to dismiss this (which I don't think you were doing—I'm really referring back to what John Levine said) by putting down home servers as a "hobbyist" sort of thing, which ISPs won't feel market pressure to support, but I think that this attitude is actually what's unrealistic.   There is a *huge* untapped market in peer-to-peer applications. 

We can think now about how to make sure that this market has the tools it needs to grow, or we can ignore it until it becomes big, at which point it will be too late.

---

From: Tony Finch <[email-masked]>
Date: Fri, 23 Nov 2012 11:17:23 +0000

Joe Abley <[email-masked]> wrote:
>
> If there was a possible solution where a customer device could
> auto-register a name using dynamic DNS, how would it know what
> nameservers to send the UPDATE messages to? Extract the MNAME from the
> closest-enclosing SOA? How do you find the closest-enclosing SOA,
> bearing in mind that the address concerned might previously have been
> used by someone else, and hence the blah.blah.ip6.arpa owner name might
> already exist?

Just query for the SOA at the full RDNS name, and the name server will
return the zone apex name and SOA record in the authority section of its
reply (or possibly in the answer section though that's unlikely).

http://tools.ietf.org/html/draft-andrews-dnsext-soa-discovery

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Tony Finch <[email-masked]>
Date: Fri, 23 Nov 2012 11:28:26 +0000

Joe Abley <[email-masked]> wrote:
>
> I think you skipped a step -- you need to find the zone cut before you
> can find the nameservers responsible for the zone. I guess I do that by
> asking for blah.ip6.arpa/IN/SOA and checking the authority section, but
> what if the authority section is empty because of software choices in
> some nameserver?

Are name servers allowed to leave out the SOA record? It would break
negative cacheing.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Fri, 23 Nov 2012 11:36:04 +0000

John Levine <[email-masked]> wrote:
>
> Why do you think that a host that is not a server and will

Is there such a thing as a host that is not a server? Multicast DNS and
DNS-SD exist so that you can discover devices and services on your lan.

Tony.

---

From: Joe Abley <[email-masked]>
Date: Fri, 23 Nov 2012 06:39:02 -0500

> Are name servers allowed to leave out the SOA record? It would break

I was being pessimistic. If that authority-section SOA was frequently missing (e.g. for devices behind home gateways) would anything break from the perspective of stub resolvers? I can't think of anything; hence I assume it's broken.

Joe

---

From: Jim Reid <[email-masked]>
Date: Fri, 23 Nov 2012 11:42:16 +0000

> http://tools.ietf.org/html/draft-andrews-dnsext-soa-discovery

We have been here before.

The ENUM name space has comparable properties to ip6.arpa: lots of labels, "irregular" delegation points and sparse population. Some ENUM applications and use cases had a need to find the closest encloser too. So a long time ago, I helped write up something similar for the ENUM WG -- http://tools.ietf.org/html/draft-ietf-enum-void-02 -- and was told I was a naughty boy. It was apparently a Very Bad Thing to treat data from the Authority Section as an answer from the DNS: resolving servers could do this, but nothing else apparently. I suspect Mark's draft may have been killed because of that too.

FWIW there were other religious issues which meant that ENUM draft ended up going nowhere.

---

From: Jim Reid <[email-masked]>
Date: Fri, 23 Nov 2012 11:52:10 +0000

On 23 Nov 2012, at 11:28, Tony Finch <[email-masked]> wrote:

> Are name servers allowed to leave out the SOA record?

Yes. Though it depends on what the question was, which server you ask and what data it has. RFC2308 lists some examples of valid NXDOMAIN/NODATA responses containing no SOA record.

> It would break negative cacheing.

So what?

It's not compulsory to implement or support that. Which would of course be a Bad Idea.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 24 Nov 2012 01:34:22 +1100

In message <[email-masked]>, Jim Reid writes:
> The ENUM name space has comparable properties to ip6.arpa: lots of labels, "i
> rregular" delegation points and sparse population. Some ENUM applications and
>  use cases had a need to find the closest encloser too. So a long time ago, I
>  helped write up something similar for the ENUM WG -- http://tools.ietf.org/h
> tml/draft-ietf-enum-void-02 -- and was told I was a naughty boy. It was appar
> ently a Very Bad Thing to treat data from the Authority Section as an answer 
> from the DNS: resolving servers could do this, but nothing else apparently. I
>  suspect Mark's draft may have been killed because of that too.

No, it just needed some more work so that whether the zeroing of
the -ve TTL on the SOA query was not done unconditionally.  Named
now has a per zone flag to control this.

There is nothing wrong with using the SOA record from the -ve
response.  Named has been doing it for about 15 years in nslookup.
If it is not there it falls back to stripping a label at a time
until it gets the SOA record.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 23 Nov 2012 12:22:24 -0500

Just use DNSSEC, the RRSIG records tell you the apex of the zone :-)

	Olafur

---

From: Daryl Tanner <[email-masked]>
Date: Sat, 24 Nov 2012 01:32:10 +0000

> submission (unless this WG or v6ops wants it).

I'm in support of this document being published.

One observation is that the delegation to CPE routers (home gateways) is
contradictory to RFC6092:

 REC-8   By DEFAULT, inbound DNS queries received on exterior
           interfaces MUST NOT be processed by any integrated DNS
           resolving server.

Not suggesting delegation to CPE shouldn't happen, but would it would
negate this requirement.

Regards
Daryl

---

From: Paul Vixie <[email-masked]>
Date: Sat, 24 Nov 2012 02:16:58 +0000

On 2012-11-23 2:34 PM, Mark Andrews wrote:
> ...

indeed not. i think mark means nsupdate here. the history of this is, i
wrote for late model bind8 a function called res_findzonecut(), which
was part of integrating a contributed implementation of RFC 2136, which
i'd been the editor and main author of. the comments at the top of
lib/res/res_findzonecut.c are shown below. there's nothing untoward, or
spec-violating, or even spec-bending going on here.

/*
 * int
 * res_findzonecut(res, dname, class, zname, zsize, addrs, naddrs)
 *      find enclosing zone for a <dname,class>, and some server addresses
 * parameters:
 *      res - resolver context to work within (is modified)
 *      dname - domain name whose enclosing zone is desired
 *      class - class of dname (and its enclosing zone)
 *      zname - found zone name
 *      zsize - allocated size of zname
 *      addrs - found server addresses
 *      naddrs - max number of addrs
 * return values:
 *      < 0 - an error occurred (check errno)
 *      = 0 - zname is now valid, but addrs[] wasn't changed
 *      > 0 - zname is now valid, and return value is number of addrs[]
found
 * notes:
 *      this function calls res_nsend() which means it depends on correctly
 *      functioning recursive nameservers (usually defined in
/etc/resolv.conf
 *      or its local equivilent).
 *
 *      we start by asking for an SOA<dname,class>.  if we get one as an
 *      answer, that just means <dname,class> is a zone top, which is fine.
 *      more than likely we'll be told to go pound sand, in the form of a
 *      negative answer.
 *
 *      note that we are not prepared to deal with referrals since that
would
 *      only come from authority servers and our correctly functioning local
 *      recursive server would have followed the referral and got us
something
 *      more definite.
 *
 *      if the authority section contains an SOA, this SOA should also
be the
 *      closest enclosing zone, since any intermediary zone cuts
would've been
 *      returned as referrals and dealt with by our correctly
functioning local
 *      recursive name server.  but an SOA in the authority section
should NOT
 *      match our dname (since that would have been returned in the answer
 *      section).  an authority section SOA has to be "above" our dname.
 *
 *      however, since authority section SOA's were once optional, it's
 *      possible that we'll have to go hunting for the enclosing SOA by
 *      ripping labels off the front of our dname -- this is known as "doing
 *      it the hard way."
 *
 *      ultimately we want some server addresses, which are ideally the ones
 *      pertaining to the SOA.MNAME, but only if there is a matching NS RR.
 *      so the second phase (after we find an SOA) is to go looking for the
 *      NS RRset for that SOA's zone.
 *
 *      no answer section processed by this code is allowed to contain CNAME
 *      or DNAME RR's.  for the SOA query this means we strip a label and
 *      keep going.  for the NS and A queries this means we just give up.
 */

paul

---

From: [email-masked]
Date: Sat, 24 Nov 2012 09:17:34 +0100 (CET)

> Not suggesting delegation to CPE shouldn't happen, but would it would

DNS amplification attacks caused, at least partly, by DNS proxies in
CPEs is a significant problem. Note that this is often due to the CPEs
being open to *recursive* queries. A delegation would only need replies
to zones the CPE was authoritative for - however, I'm afraid such a
distinction would be lost on many CPE manufacturers.

There are also ISPs that block outgoing DNS queries to (residential)
CPEs, precisely because of DNS amplification attacks by these CPEs.

Steinar Haug, Nethelp consulting, [email-masked]