Subject: [DNSOP] summary (was: RE: new version of IPv6 rDNS for ISPs)

From: "Lee Howard" <[email-masked]>
Date: Wed, 28 Nov 2012 15:51:47 -0500

Thanks for the lively discussion!

Here's what I heard, in addition to several useful, non-controversial text
suggestions:

1.  Uses for reverse DNS
  a. Several people think it's unnecessary to require PTRs.  A few even
think a lack of PTRs might be a good thing (in the case of mail servers
rejecting connections).
  b. A few people think they are useful, because their servers can put the
PTR response in logs and they have some idea where a connection came from.
Others point out that WHOIS is a better source, with debate about the
usefulness and utility of WHOIS.  In my opinion, the need should be filled
as close as possible to those who need it: don't rely on ISPs to develop
infrastructure for your convenience, without any benefit to them.
  c.  I did not see anyone say that PTRs are required.  Some people have
asked me to take a position, in this or another document, that PTRs are not
required (for residential Internet users).  Someone else may submit that
document.

2. Delegation: Several people support delegating to the home gateway.
  a.  There is no mechanism to tell a home gateway that it is now
authoritative for "12345.customer.example.net."  Or is there?  Without that,
it also wouldn't know what FQDN to put in PTR RRs.
  b.  Violates RFC6092 REQ-8.
  c.  Delegating to a single auth nameserver may or may not be acceptable.
  d. (from v6ops) ISP should slave from customer CPE

3.  Dynamic DNS
  a. Several people like dDNS, but it isn't clear that there's an existing
mechanism for telling hosts to whom to send their dDNS updates.
  b. dDNS does help the case of privacy or other temporary addresses

Of ~13 people commenting, I heard three people explicitly say, "Please
publish this document" and one say, "This doesn't provide enough practical
advice about how to do in IPv6 what we did in IPv4; maybe write a
requirements doc instead."  

One approach to finding consensus then:
1.  Update the document to reflect the points in #1 above.  
2.  Support someone else writing a draft called "PTRs unnecessary" or
whatever.  I have someone in mind.
3.  Document the problems with #2(a) and #3(a) above.  Since there is
currently no mechanism, no requirements document, and no charter to change
these limitations, this provides the best information available at this
time.  
4.  Write a requirements document to fill gaps in #2 and #3.  This may
coincidentally fall into work spinning off from 6renum.  I would very much
like co-authors for this, since I will not be able to give it my full
attention.

As I make responsive changes, I will also try to change the tone a bit, from
a survey of possible mechanisms, to guidance for operators ("Here's what
operators should do; here are other possible mechanisms, and why they aren't
worth bothering about.")

Thanks again for the very useful feedback and discussion.  I hope this
message will reflect rough consensus, or at least clearer detail of where
I've missed the point.

Lee

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 Nov 2012 21:23:28 +0000

>  d. (from v6ops) ISP should slave from customer CPE

The really good point that you almost made here is that the CPE device doesn't necessarily have an FQDN zone to update, and if it is delegated the PTR zone and doesn't have anything to stuff into it, it might stuff something harmful into it.   So it would be good to advise against that.

Then the question of what forward zone to publish is interesting; I'd assumed that the ISP would never be involved in this.   I suppose some ISPs might want to offer this as a service, so it would be worth documenting how they ought to do it.

There is a draft that documents how the reverse zone could be set up (as part of the DHCP PD process).   If we think there's a real use case for the ISP offering the customer a zone, we should define a way for the ISP to do this (I'd suggest a DHCP option, since we're presumably doing DHCP PD to delegate a prefix).

> whatever.  I have someone in mind.

This is a waste of time—it will never get consensus.   We've wasted time in this working group trying to do this in the past.

> like co-authors for this, since I will not be able to give it my full

I have some interest in this topic and would be willing to write some docs, although you might not agree with the docs I would write.

---

From: "Lee Howard" <[email-masked]>
Date: Wed, 28 Nov 2012 17:10:28 -0500

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]]
> Sent: Wednesday, November 28, 2012 4:23 PM
> To: Lee Howard
> Cc: <[email-masked]>
> Subject: Re: [DNSOP] summary (was: RE: new version of IPv6 rDNS for ISPs)
> 
> > authoritative for "12345.customer.example.net."  Or is there?  Without
> > that, it also wouldn't know what FQDN to put in PTR RRs.
> The really good point that you almost made here is that the CPE device
doesn't necessarily
> have an FQDN zone to update, and if it is delegated the PTR zone and
doesn't have anything
> to stuff into it, it might stuff something harmful into it.   So it would
be good to advise
> against that.
>
> Then the question of what forward zone to publish is interesting; I'd
assumed that the ISP
> would never be involved in this.   I suppose some ISPs might want to offer
this as a service,
> so it would be worth documenting how they ought to do it.

Without explicit caution, the CPE might populate .local for FQDN.  Yes, I
assumed that
everyone knew that residential users rarely have their own domain name, and
would have
to get it from their ISP.  I don't think ISPs especially want to provide
this--there's no gain
and lots of potential pain.

> 
> There is a draft that documents how the reverse zone could be set up (as
part of the DHCP
> PD process).   If we think there's a real use case for the ISP offering
the customer a zone, we
> should define a way for the ISP to do this (I'd suggest a DHCP option,
since we're
> presumably doing DHCP PD to delegate a prefix).

We might want to check with some ISPs and see if they would be interested in
consuming
such a spec.  I doubt many would--it's something to troubleshoot that offers
little value to
the residential user. 

> > currently no mechanism, no requirements document, and no charter to
> > change these limitations, this provides the best information available
> > at this time.
> > coincidentally fall into work spinning off from 6renum.  I would very
> > much like co-authors for this, since I will not be able to give it my
> > full attention.
> 
> I have some interest in this topic and would be willing to write some
docs, although you
> might not agree with the docs I would write.

Then it would be healthy for us to collaborate!  Maybe we can drive
compromise
positions before making the WG(s) thrash.

Lee

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 Nov 2012 22:35:24 +0000

> and lots of potential pain.

I think that there's minimal potential pain if it's done right, and it's something they could charge extra for, but that's pretty much the only scenario in which I expect ISPs to do this.   OTOH, it seems like a pretty obvious market for a third party.

> such a spec.  I doubt many would--it's something to troubleshoot that offers

Actually I'd have to disagree with this.   It offers significant value to the residential user in that their site can now have a globally-unique name, which is a problem we've discussed at some length in homenet, and which remains an unsolved problem.

> positions before making the WG(s) thrash.

Sure!   :)

---

From: Tony Finch <[email-masked]>
Date: Thu, 29 Nov 2012 11:06:18 +0000

> > Yes, I assumed that everyone knew that residential users rarely have
> > their own domain name, and would have to get it from their ISP.  I
> > don't think ISPs especially want to provide this--there's no gain and
> > lots of potential pain.
>
> I think that there's minimal potential pain if it's done right, and it's
> something they could charge extra for, but that's pretty much the only
> scenario in which I expect ISPs to do this.  OTOH, it seems like a
> pretty obvious market for a third party.

It ought to be part of the basic package. (Like Demon Internet in the
mid-1990s.)

> > We might want to check with some ISPs and see if they would be
> > interested in consuming such a spec.  I doubt many would--it's
> > something to troubleshoot that offers little value to the residential
> > user.
>
> Actually I'd have to disagree with this.  It offers significant value to
> the residential user in that their site can now have a globally-unique
> name, which is a problem we've discussed at some length in homenet, and
> which remains an unsolved problem.

If every site has a domain name then it becomes easy to support wide-area
service discovery, so people can still make use of what they have at
home when they are away.

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: "Lee Howard" <[email-masked]>
Date: Thu, 29 Nov 2012 09:17:01 -0500

> From: Tony Finch [mailto:[email-masked]] On Behalf Of Tony Finch
> Sent: Thursday, November 29, 2012 6:06 AM
> To: Ted Lemon
> Cc: Lee Howard; <[email-masked]>
> > > don't think ISPs especially want to provide this--there's no gain
> > I think that there's minimal potential pain if it's done right, and
> > it's something they could charge extra for, but that's pretty much the
> > only scenario in which I expect ISPs to do this.  OTOH, it seems like
> > a pretty obvious market for a third party.
> 

<operator hat>
Show me a business case.
For the residential ISP, all I see is troubleshooting and time spent
explaining
DNS to customers.  In exchange, expensive upstream wavelengths get used.
</op hat>

> > > something to troubleshoot that offers little value to the
> > > residential user.
> >
> > Actually I'd have to disagree with this.  It offers significant value
> > to the residential user in that their site can now have a
> > globally-unique name, which is a problem we've discussed at some
> > length in homenet, and which remains an unsolved problem.
> 
service discovery,
> so people can still make use of what they have at home when they are away.

The question I think we should ask is, "If we develop a mechanism, will
anyone deploy it?"
The answer is not, "The mechanism enables other things." 
I don't want to waste my time, and the working group's time, on
dustbin-destined technologies.

Lee

---

From: Warren Kumari <[email-masked]>
Date: Thu, 29 Nov 2012 09:41:38 -0500

> I think that there's minimal potential pain if it's done right, and it's something they could charge extra for, but that's pretty much the only scenario in which I expect ISPs to do this.   OTOH, i…

You mean like DynDNS for example?

> Actually I'd have to disagree with this.   It offers significant value to the residential user in that their site can now have a globally-unique name, which is a problem we've discussed at some len…

Points at Dyn and afraid.org and 3322.org^w^w and no-ip…

<runs away, giggling…>
W

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

-- 
A. No
Q. Is it sensible to top-post?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Nov 2012 15:45:45 +0000

> You mean like DynDNS for example?

Exactly.   And DynDNS is a great example of why we need a standard.

---

From: "Lee Howard" <[email-masked]>
Date: Thu, 29 Nov 2012 16:42:48 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ted Lemon
> Sent: Thursday, November 29, 2012 10:46 AM
> To: Warren Kumari

Can you list the functional requirements?

Lee

---

From: Mark Andrews <[email-masked]>
Date: Fri, 30 Nov 2012 11:26:50 +1100

> Can you list the functional requirements?

We have a standard for dynamic DNS updating. And standards for
securing it.  There are even products from different companies that
interoperate.

http://dyn.com/support/bonjour-and-dns-discovery/

Now while that page has a SRV record _dns-update._udp in the zone
to find the server to send the update to the Mac will send the
request to the nameservers for the zone if it is not there.

Bog standard named has supported this since before the TSIG RFC was
finalised in 2000.

And if the client doesn't do it the DHCP server can.  It would not
suprise me to find someone running our DHCPv6 server updating a
zone hosted by dyn.com using UPDATE+TSIG.

Thats three vendors all interoperating with UPDATE+TSIG.

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Nov 2012 02:16:05 +0000

> Thats three vendors all interoperating with UPDATE+TSIG.

DynDNS.org does DNS updates?   I was under the impression that it was all done with web fu.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 30 Nov 2012 16:37:52 +1100

In message <[email-masked]>, T
ed Lemon writes:
> DynDNS.org does DNS updates?   I was under the impression that it was all d=
> one with web fu.

Yes.  They do TSIG signed DNS updates.  They do direct them to a
update server using a in zone SRV record rather than the nameservers
that are serving answers to the world but otherwise it is bog
standard UPDATE + TSIG.

Mark

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 30 Nov 2012 01:01:54 -0500

> that are serving answers to the world but otherwise it is bog

Well, yes, but the plain fact is that if you want all Dyn's features,
you have to use the webby API.  Also, not every customer has access to
UPDATE + TSIG.  

Full disclosure: Dyn gives me money, and I give them some of my feeble
brain.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Nov 2012 14:09:10 +0000

> that are serving answers to the world but otherwise it is bog

So it's OpenWRT that's missing the feature of using this update mechanism.