Subject: Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-isp-ip6rdns

From: 神明達哉 <[email-masked]>
Date: Tue, 3 May 2016 10:56:14 -0700

At Mon, 25 Apr 2016 16:50:42 -0400,
Tim Wicinski <[email-masked]> wrote:

> This starts a Working Group Last Call  for draft-ietf-dnsop-isp-ip6rdns
>
> Current versions of the draft is available here:
>
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-isp-ip6rdns/
>
> Please review the draft and offer relevant comments. Also, if someone
> feels the document is *not* ready for publication, please speak out with
> your reasons.

I've read the latest version (01) of the draft.  I don't think this
document is ready for publication.

I think a good summary of why not is this comment by Stephane
Bortzmeyer: "It seems this document did not take into account the
lessons from the failure of draft-ietf-dnsop-reverse-mapping-considerations".

The draft as currently written looks quite awkward, especially if
considering the role of reverse mapping that many of this wg
participants seemingly have in their mind.  In my understanding
everyone agrees a revers mapping can be useful for purposes like
debugging or pure logging, but many of us doubt the use of reverse
mapping for purposes like access controls.  And, because of the second
point, the attempt of making a reverse-forward match is pretty
dubious, especially if it involves technical difficulties such as
scalability issues, since this matching is quite tightly coupled to
the practices like PTR-(and matching with forward)-based access
control; for the purpose of logging helpful information only
human-readable PTR should suffice.

Yet the focus of this document is about how to ensure the
forward-reverse match.  It may be true that this draft does not
encourage that practice.  But if the wg is generally suspicious about
the practice in the first place, it would look quite awkward that the
same wg is going to publish something that describes how to do that
practice.  One common "excuse" to resolve such conflict is to say that
we are just describing what operators want or might do without either
encouraging or discouraging the practice.  But, again, if the wg
generally thinks such a practice doesn't make sense, this logic
doesn't make much sense either to me.  If we really think such a
practice has no sense, we should more explicitly say so and even
discourage it; or, if we actually think we should change our own mind
so it's consistent with what operators want to do, we should rather
encourage it more explicitly.

In my view, this is one of the main reasons why
draft-ietf-dnsop-reverse-mapping-considerations failed: it tried to
provide some balanced position between what operators out there
think/want with reverse mapping and what (most of?) wg participants
consider those practices with reverse mapping, but its vague tone was
confusing or misleading, and yet we couldn't agree on providing a
stronger statement on either side.  draft-ietf-dnsop-isp-ip6rdns seems
to inherit this particular problem from reverse-mapping-considerations.

I'm not sure how we can move forward from here *if* my above concerns
are valid.  I can think of a few possibilities, but I'm afraid the
author (and probably other people) don't like these:
- drop the focus on ensuring reverse-forward match and just state some
  ideas of how we can provide IPv6 reverse mappings if someone wants
  them
- keep the current content, but clearly state that the IETF (and
  dnsop) wg thinks these are bad ideas but document it since operators
  don't listen what wg thinks anyway
- publish it as an individual draft rather than a wg document so that
  it will be clearer that it's independent from wg's view on practices
  with revers mappings.  dnsop can still provide superficial technical
  comments.

Some other general comments on the draft body follow.  They are
generally irrelevant to the bigger issue I stated above:

- Section 2.1:

   [...] For best user experience, then, it is important to
   return a response, rather than have a lame delegation.

  Although a general statement this is true, and while the definition
  of "lame delegation" may not be robust, I don't think we generally
  use the term "lame delegation" for issues described around here
  (e.g., simply meaning some name doesn't exist).

- Section 2.3

   [...] There is no
   standard way to indicate to a host what server it should send dDNS
   updates to.

  This may be true in a strict sense, but I thought it's widely
  adopted practice to use SOA's MNAME to identify the server to which
  a particular DNS update should be sent.

- Section 2.3.1

   Once it learns its address, and has a resolving name server, the host
   must perform an SOA lookup on the ip6.arpa record to be added, to
   find the owner, eventually to find the server authoritative for the
   zone (which might accept dynamic updates).  [...]
   [...] Once found, the host sends dynamic AAAA
   and PTR updates using the concatenation defined above
   ("hostname.customer.example.com").

  I see what it tries to say, but this doesn't seem to be very
  accurate.  Usually those AAAA and PTR would belong to different
  zones.  In particular the owner name of the AAAA wouldn't belong to
  an ip6.arpa domain.

- Section 2.3.2

   The alternate option is for the gateway to relay dynamic DNS updates
   from hosts to the servers and domain provided by the ISP.

  I don't understand this "forwarding" behavior.  Can this be
  described in more detail?

- Section 2.3.3

   If a device requests a
   DHCPv6 Prefix Delegation, that may be considered a reasonably
   reliable indicator that it is a gateway, [...]

  If and when the recommendation of using DHCPv6 PD by end hosts
  in draft-ietf-v6ops-host-addr-availability is more widely used
  this may become not true.

- Section 2.3.3

   [...]  In fact, this kind of
   delegation will not work for devices complying with [RFC6092], which
   includes the requirement, "By DEFAULT, inbound DNS queries received
   on exterior interfaces MUST NOT be processed by any integrated DNS
   resolving server."

  Is this true?  I thought this restriction is about queries with the
  RD bit on, and in case of an auth-recursive hybrid server, only
  about queries that don't belong to zones that the server has
  authority.

- Section 2.5

   [...] unsigned
   records can indicate that these records are less trusted, which might
   be acceptable.

  I don't understand this...if this is a signed zone and some RRset
  in that zone is provided as an answer without an RRSIG, that answer
  is not just "less trusted", but should be considered to be invalid.

- Section 3

   [...] lame
   delegation should be avoided.

  I suspect this use of 'lame delegation' is not appropriate (see
  above).

Minor points/editorial matters:

- Section 1.1: I guess '\.' should be '.'

   \.

- Section 1.2: s/f00/f00::/

   2001:db8:f00/48 zone alone, even with automation it is impractical to

- Section 2.3: s/ERROR/error/? ('ERROR' is not a mnemonic of a
  standard DNS RCODE):

   not assured, though the host should expect an ERROR or NOERROR
   message from the server [RFC2136]; TCP provides transmission control,

--
JINMEI, Tatuya

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 4 May 2016 16:39:34 +0200

On Tue, May 03, 2016 at 10:56:14AM -0700,
 神明達哉 <[email-masked]> wrote 

> author (and probably other people) don't like these:

May be:

- drop normative text ("you are a bad boy if you don't have a PTR")
and add text like "some people would like to have a PTR record and
some of these people would like to have matching address record(s)
and PTR record(s). In that case, this document presents some
strategies that could be useful to implement PTR with IPv6 addresses."

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 May 2016 11:43:16 -0400

Jinmei-san, with all due respect, I think that you are missing the mark
here.  The point of this document is not to make normative requirements.
That's why it's informational.   It's simply to enumerate the set of
options that ISPs have.   The reason that the author, who works for an
operator, decided to write the document was that no such document existed,
and such a document would be useful for informational purposes.   It is not
the purpose of the document to either recommend or deprecate the practice
described in RFC 1912; indeed, the consensus of the working group seems to
be that the practices in RFC 1912 regarding PTR records are no longer best
practices.

Nevertheless, operators have to deal with support calls when there is no
PTR mapping, and end users have to deal with the inaccessibility of
services operated by people who still believe in and rely upon the RFC 1912
recommendations.   I personally think it's a terrible idea to use PTR
records for host validation, yet I still want PTR records set up according
to RFC 1912 because I care more about being able to access services that do
PTR lookups than I do about purity.

Additionally, if you look at section 11 of RFC 6763, there is actually a
strong motivation for at least having the PTR tree delegated, because it
allows the home network to publish rendezvous records for DNS service
discovery on the home network.   Without this capability, unicast DNSSD may
be quite difficult to successfully deploy in the home, which would be a
shame.   This is actually something that ought to be mentioned in the
document.

The point is that the mere fact that you do not think this is useful isn't
a reason not to publish it.   The working group already got consensus that
this work was useful when we adopted it; the question now is, are there
_mistakes_ in the document that need to be corrected prior to publication,
or that would mean that despite the working group consensus to adopt the
document, it is no longer a good idea to publish it.   I do not think the
concerns you have raised are the sort of concerns that would motivate such
a reconsideration.

On Tue, May 3, 2016 at 1:56 PM, 神明達哉 <[email-masked]> wrote:

> lessons from the failure of
> draft-ietf-dnsop-reverse-mapping-considerations".
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 6 May 2016 11:08:16 +0200

On Wed, May 04, 2016 at 11:43:16AM -0400,
 Ted Lemon <[email-masked]> wrote 
 a message of 518 lines which said:

> The point of this document is not to make normative requirements.

But it does: 'Best practice is that "Every Internet-reachable host
should have a name"'.

> It's simply to enumerate the set of options that ISPs have.

But it does not limit itself to that.

> The point is that the mere fact that you do not think this is useful
> isn't a reason not to publish it.  The working group already got
> consensus that this work was useful when we adopted it; the question
> now is, are there _mistakes_ in the document that need to be
> corrected prior to publication,

I don't think we have the same view of what is a Working Group Last
Call. IMHO, there is nothing restricting a working group to just fix
mistakes. The Last Call is also, as its name says, the opportunity to
check the general issues.

---

From: [email-masked]
Date: Fri, 06 May 2016 11:32:17 +0200 (CEST)

> But it does: 'Best practice is that "Every Internet-reachable host

I agree. Especially with IPv6 in mind, "Every Internet-reachable host
should have a name" is *not* best practice.

Steinar Haug, AS2116

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 May 2016 07:26:47 -0400

I believe that this was unintentional.   I think Lee agreed to fix it.

---

From: "Howard, Lee" <[email-masked]>
Date: Fri, 6 May 2016 13:41:27 +0000

Yes; will fix (I think I said in another message). Off today, will catch up again next week.

Lee

From: DNSOP <[email-masked]<mailto:[email-masked]>> on behalf of Ted Lemon <[email-masked]<mailto:[email-masked]>>
Date: Friday, May 6, 2016 7:26 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: tjw ietf <[email-masked]<mailto:[email-masked]>>, dnsop WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-isp-ip6rdns

Steinar Haug, AS2116

________________________________

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: 神明達哉 <[email-masked]>
Date: Fri, 6 May 2016 09:34:21 -0700

At Wed, 4 May 2016 11:43:16 -0400,
Ted Lemon <[email-masked]> wrote:

> here.

First off, I didn't intend to be opposed to providing reverse mappings
per se.  If my comments read that way, that was because of my poor
writing ability (I'm also aware that my points are subtle, so it's not
actually that surprising).  My main concern was about the attempt of
using it (especially with checking a reverse-forward match) for
purposes like access control/host validation, about this draft
discussing how to provide reverse mappings (and, again, largely
focusing on ensuring the reverse-forward match) along with describing
those purposes, and yet about us (at least you, me, and some others in
this WG according to this thread) considering those purposes to be a
"terrible idea".

I fully understand this document does not provide normative
requirements.  But in the way it's currently organized, I'm afraid
it will simply promote a vicious circle: more people will think they
need to provide reverse mapping (and in particular ensure the
reverse-forward match) in the face of the existence of the "terrible
idea"; then people employing such ideas will have even less reason to
stop the terrible practice, the terrible practice will proliferate
even more widely; then even more people will see the need for
providing reverse mapping (and reverse-forward match) for this
reason...

To me, just not including normative text isn't enough to stop it.
Cynics might say the terrible practice won't go away whatever we
say in an RFC.  That might be true, but I'd still like to give it a
try instead of simply giving it up completely.

[...]

> PTR lookups than I do about purity.

I see the point, and it made me realize that this is another incident
of a common pattern: people who employ terrible practices are
different from people suffering from those practices, and we have a
dilemma of whether to help the latter or to even promote the bad
practices as a result.  So, do we share a view something like this?

  While a reverse mapping is generally useful for informational
  purposes, some people use it even more aggressively, such as for
  access control or host validation based on the existence of a
  reverse mapping, and often also on matching between the reverse and
  forward mapping.  It is believed that those practices are not very
  effective at best, especially for their side effect of punishing
  otherwise-legitimate users and their service providers.  Although an
  ideal solution to this is to encourage stopping those harmful
  practices possibly with replacing them with more effective ones,
  the sad operational reality is that it's less likely that the
  operators employing those practices will listen anytime soon.  Until
  then, the victim end users and their service providers will pay the
  cost of the practices, and the only realistic intermediate remedy is
  to provide required reverse mappings and often ensure the
  revers-forward match.  This document shows possible options on how
  to do this for those latter types of operators.

If so, I believe we're not on so different pages, and it's probably
just a matter of how to present it.  If we even have a fundamental
disagreement here, perhaps we have to disagree, and see how the wg
concludes in the end.

> concerns you have raised are the sort of concerns that would motivate such

I thought a WG last call is a good chance of raising any substantial
concerns even if it was against some original consensus at around the
adoption time (when it's often the case where people can't anticipate
all possible issues).  So, in general, I don't think I have no right
to raise an issue like this (even if and) simply because the wg had a
different consensus before.

Whether a specific comment/opinion is substantial enough is a
different question.  I respect your view is that it's not, but after
all this kind of matter is generally subjective.  I still believe it's
important, but as I'm aware that's also just another subjective
opinion, I'll see what others think.

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 May 2016 14:59:12 -0400

> providing reverse mapping (and reverse-forward match) for this
I think this is a legitimate concern, although I feel that the document,
particularly with the change Lee agreed to, does a good job of avoiding
that.   However, as you say, communication is hard, so perhaps I am being
overly optimistic.

> practices as a result.  So, do we share a view something like this?

Exactly.

>   to do this for those latter types of operators.

The problem with this text when it was proposed before (it was proposed
before!) is that not everybody agrees on it either.   So last time we had
this discussion (which we have had more than once already, not counting
this time), we decided to just be neutral, rather than either saying "this
is a bad idea" or "this is a great idea."   I think the document is still
useful, because honestly I do not think it is going to make much difference
as far as host name checking goes.   I think if we want host name checking
to die, we should talk to authors of open source software that support this
feature into taking it out.   I think, for example, that openssh does this.
  Maybe we should talk to them.

> isn't

 You can certainly argue that any objection can be raised at any time.
However, as a practical matter, if we don't set the "do not publish" bar
fairly high, it becomes impossible to ever publish anything, because for
any discussion that did not achieve unanimous consensus, it can always be
reopened.

I am not the one calling consensus here (indeed, at present there is no
context within the IETF in which I could or would call consensus).   But if
I were, I would encourage the authors to try to make the language as
neutral as possible (as I have done, as an individual participant), but
would not try to say "if the authors won't say this is a bad idea, then we
shouldn't publish the document."

I supported adoption of the document, even though there was no consensus to
say that hostname/ptr validation is a bad idea, because I think that making
operators aware of what their options are is more important than trying to
fix the hostname/ptr validation problem.   I very much agree with you that
we should formally deprecate hostname/ptr validation, but to make that part
of this draft effectively means that we don't publish this draft, I think.
  So this is actually a really good example of the principle that I
expressed earlier about last call consensus.

---

From: 神明達哉 <[email-masked]>
Date: Mon, 9 May 2016 11:15:09 -0700

At Fri, 6 May 2016 14:59:12 -0400,

>   Maybe we should talk to them.

To be clear, I didn't (yet) intend to suggest using the above text in
the draft.  It was just to see whether we are basically on the same
page if we described it without trying to be *too neutral* or whether
we are in disagreement on some more fundamental point.  Interpreting
the above response as it's the former, and hopefully some more share
the same view, I'd personally like to propose including some text like
this - it could be weakened if some part of it is considered
controversial, but I'd at least like to do the harm as a result of
being afraid of controversial and being too neutral (and therefore
ambiguous).

Of course, this is just one personal feedback.  As you said it may be
that we can't simply agree on any kind of this text.  It's ultimately
up to the wg to decide.

--
JINMEI, Tatuya

---

From: "Howard, Lee" <[email-masked]>
Date: Mon, 9 May 2016 18:31:54 +0000

>that we can't simply agree on any kind of this text.  It's ultimately

I think we tried this in 2006-2008 with reverse-mapping-considerations, and in 2009 with early versions of this draft, and occasionally in the following years. I think the existing document balances the considerations and represents, if not everyone's opinion, the best consensus that currently exists.

Lee

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 May 2016 14:58:23 -0400

Yes, that's my recollection as well.   We've been working on some version
or another of this draft for kind of a long time, and that's why the
current document is as neutral as it is.   I think that neutrality really
does represent wg consensus, not in the sense that everybody is neutral,
but that there is nothing other than being neutral that will not raise
strong objections.

On Mon, May 9, 2016 at 2:31 PM, Howard, Lee <[email-masked]> wrote:

> I think we tried this in 2006-2008 with reverse-mapping-considerations,
> and in 2009 with early versions of this draft, and occasionally in the
> following years. I think the existing document balances the considerations
> and represents, if not everyone's opinion, the best consensus that
> currently exists.
>
> Lee
>
> >
> >--
> >JINMEI, Tatuya
> >
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.
>

---

From: joel jaeggli <[email-masked]>
Date: Mon, 9 May 2016 21:51:23 -0700

On 5/4/16 8:43 AM, Ted Lemon wrote:
> operator, decided to write the document was that no such document
> existed, and such a document would be useful for informational purposes.
>   It is not the purpose of the document to either recommend or deprecate
> the practice described in RFC 1912; indeed, the consensus of the working
> group seems to be that the practices in RFC 1912 regarding PTR records
> are no longer best practices.
> 
> services operated by people who still believe in and rely upon the RFC
> 1912 recommendations.   I personally think it's a terrible idea to use
> PTR records for host validation, yet I still want PTR records set up
> according to RFC 1912 because I care more about being able to access
> services that do PTR lookups than I do about purity.
> 
> discovery on the home network.   Without this capability, unicast DNSSD
> may be quite difficult to successfully deploy in the home, which would
> be a shame.   This is actually something that ought to be mentioned in
> the document.
> 
> consensus that this work was useful when we adopted it; the question now
> is, are there _mistakes_ in the document that need to be corrected prior
> to publication, or that would mean that despite the working group
> consensus to adopt the document, it is no longer a good idea to publish
> it.   I do not think the concerns you have raised are the sort of
> concerns that would motivate such a reconsideration.

process observation

It's also of course possible that the community outside the working
group partcipants will see the issue differently then does the working
group (that not what wglc is for). It is certainly possible to disagree
with the document without asserting that the contents are a mistake.

thanks
joel

> 
> On Tue, May 3, 2016 at 1:56 PM, 神明達哉 <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Tim Wicinski <[email-masked] <mailto:[email-masked]>> wrote:
> 
>        ("hostname.customer.example.com
>     <http://hostname.customer.example.com>").
> 
>     [email-masked] <mailto:[email-masked]>

---

From: "Peter van Dijk" <[email-masked]>
Date: Tue, 10 May 2016 15:46:50 +0200

Hello,

just cleaning up a backlog, I know I missed the last call date :)

Yes, we know of various (PowerDNS) deployments doing live and dynamic 
signing. There are 300k domain setups doing live signing. CloudFlare 
signs everything live. It is a solved problem.

Regarding the draft, in section 2.5 it says

    Administrators should consider whether the lack of user-specified
    hostnames is a drawback.

This is not true - it would be trivial to allow the enduser to specify a 
few specific hostnames and deterministically auto generate the rest. 
Example code (in production for some networks, I understand) here: 
https://github.com/cmouse/pdns-v6-autorev

The last paragraph of 2.5 also makes no sense to me. Database 
synchronisation from a single master is a solved problem.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

On 29 Apr 2016, at 1:43, Alain Durand wrote:

> Section 2.5. "Dynamically Generate PTR When Queried ('On the Fly')" 
> was originally written years ago. Some recent announcement from DNS 
> vendors generating and signing DNS records on the fly seem to be an 
> existence proof that this would actually work and the scalability 
> concerns, certainly valid a few years ago, may not be that critical 
> now.
>
> Alain, speaking on my own behalf.
>
>
>
>> On Apr 25, 2016, at 4:51 PM, Tim Wicinski <[email-masked]> wrote:
>>
>> feels the document is *not* ready for publication, please speak out 
>> with your reasons.
>>
>> There was a large amount of feedback on the draft prior to it being 
>> adopted, and we feel the author addressed all the outstanding issues.
>> Please let us know if this is not the case.
>>
>> This starts a two week Working Group Last Call process, and ends on
>> 9 May 2016.
>>
>> thanks
>> tim
>>

---

From: "John Levine" <[email-masked]>
Date: 10 May 2016 16:07:57 -0000

>few specific hostnames and deterministically auto generate the rest. 

Putting names into the zone is the easy part.  Deciding who's allowed to
add names and what names they're allowed to add is not.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Wed, 11 May 2016 11:49:20 +1000

> add names and what names they're allowed to add is not.

For reverse zones, UPDATE over TCP from the matching IP works and
there are nameservers that support this and can be configured to
only accept PTR records as well.

It wouldn't be hard to add a EDNS option that says "remove if not
refreshed after XXXX seconds" to the update request and the master
server could maintain a time based list to clean up.

One can do UPDATE over TCP self for PTR + KEY (or just KEY) and
self using SIG(0) of PTR + KEY once the KEY is installed.  This
allows the client to clean up after itself independent of the address
the UPDATE request comes from.  Server implementations already
support this.

One can do update TCP self /48 (already implemented in some servers)
(or any other configured prefix length) to install NS records or
DNAME records to do "delegations" of either style.  Allow KEY to
allow client cleanups.  The DHCP server can remove the delegation
when the PD expires so you have cleanup.  The update self size needs
to be tuned to the PD size.  If you want to add more moving parts
the DHCP server can add the KEY which is supplied w/ the DHCP PD
request.

This is not hard to do.  We just need to pick what is reasonable
to do and recommend it.  The customer side will appear once we
recommend a approach.

Border routers do the delgation while individual nodes to the self
updates.

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: Tue, 10 May 2016 21:57:48 -0400

Yes, indeed that was discussed in the DNSSD working group as a way to do
DNS service advertisement using DNS rather than mDNS.

---

From: "Howard, Lee" <[email-masked]>
Date: Thu, 12 May 2016 13:51:53 +0000

>only accept PTR records as well.

I've never figured out how a printer knows what server will accept UPDATEs
from it.

So, you wouldn't allow another host (say, a PC or a gateway) to populate?
You get no hostname if you don't speak TCP UPDATE. I can live with that,
just asking.

>server could maintain a time based list to clean up.

I look forward to your draft.

>the UPDATE request comes from.  Server implementations already

Client implementations?

>the DHCP server can add the KEY which is supplied w/ the DHCP PD

Oh, you're assuming the delegation is to something in the home, then?
I still think that's a bad idea, because it's a DDoS vector.
And removing delegation doesn't work if the ISP is delegating to itself.
You could delete the zone and re-create it, but it'll still point
(probably) to the same server.

>Border routers do the delgation while individual nodes to the self

I've been taking the approach all along of "What is currently possible."
If you think this is a problem space that needs to be solved, I look
forward to your draft proposing this solution.

Lee

---

From: Mark Andrews <[email-masked]>
Date: Fri, 13 May 2016 16:23:34 +1000

> I've never figured out how a printer knows what server will accept UPDATEs

You can find the containing zone easily enough.  Code to do that
was added to libresolv back in the 1990's.  You send the update to
the nameservers for the zone starting with the NS that matches the
SOA MNAME.  For tcp-self you don't want to forward (return NOTIMP)
or examine the UPDATE request as see if it passes the tcp-self test
before fowarding and all the master to accept updated from the other
nameservers based on tcp address but for SIG(0) you can forward
updates.  Apple also got _dns-update._udp registered so you can use
SRV to override the SOA MNAME (they failed to document it as required
which is why people missed it).

http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=53&page=4

> >the UPDATE request comes from.  Server implementations already

dnssec-keygen + nsupdate with the correct set of options.  nsupdate
will find the correct server to send the update to (support for
SRV is on the to do list).

% dnssec-keygen -T KEY -a RSASHA256 -b 2048 -n HOST 4.3.2.1.in-addr.arpa
Generating key pair......................................+++ .............................................+++ 
K4.3.2.1.in-addr.arpa.+008+13510
% cat K4.3.2.1.in-addr.arpa.+008+13510.key 
4.3.2.1.in-addr.arpa. IN KEY 512 3 8 AwEAAdqtaoLxk98xaWwNfyNkb9z/hL4TzKKqE36Gwl1flzrPUf1PNMgI +hfBdTbxQgfWeUMzerMyrGHc+/rdWbIw70I3hnXI+yOrOcay1sNscQLe fNpWBFyEhGlChY/4bu7siRxlfhff1uf2jg9/eOzYjLxCVcBJRwLJvHOa htV8aT6GkOe6LfUvJmFyWm9MN+dwrqMyaWEX7fxdaS8MwVhNh9q56ir+ 2Sdl2nuD1fAPTUVab1TKjJ/dyy5GPLBcL5ObWyBl19BF3d2KjpMkXA5E Ph7dNBvk7ZKZ6XU0JOn0iY0W2+0VTsN8N2B/2SpDR2kNkqSv387dbw3i oAgviyXGJz0=
%  

#
# Add the key using TCP from the designated address.
#
(
echo local 1.2.3.4
echo update delete 4.3.2.1.in-addr.arpa IN KEY
cat K4.3.2.1.in-addr.arpa.+008+13510.key |
sed -e 's/^/update add /' -e 's/IN/3600 IN/'
echo send
) |
nsupdate -v 

#
# Add the PTR record after removing any existing PTR records
# using SIG(0) to authenticate.
#
nsupdate -k K4.3.2.1.in-addr.arpa.+008+13510 << EOF
update delete 4.3.2.1.in-addr.arpa 3600 IN PTR
update add 4.3.2.1.in-addr.arpa 3600 IN PTR host.example.net.
send
EOF
 
> I still think that's a bad idea, because it's a DDoS vector.

Absolutely total FUD.  UPDATE is no worse than QUERY. 

> (probably) to the same server.

You only need to delegate if you are synthesising PTR records.
 
> forward to your draft proposing this solution.

I'm talking about what is currently possible using existing tools.
People just refuse to accept that it is.

Named already has the code for self-48 (called 6to4-self) doing the
other prefixes lengths would be a hour or so work.

tcp-self already exists for host KEY / PTR records.  self / selfsub
already exists for SIG(0).

See update-policy.

Mark

> This E-mail and any of its attachments may contain Time Warner Cable propri=
> etary information, which is privileged, confidential, or subject to copyrig=
> ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
> se of the individual or entity to which it is addressed. If you are not the=
>  intended recipient of this E-mail, you are hereby notified that any dissem=
> ination, distribution, copying, or action taken in relation to the contents=
>  of and attachments to this E-mail is strictly prohibited and may be unlawf=
> ul. If you have received this E-mail in error, please notify the sender imm=
> ediately and permanently delete the original and any copy of this E-mail an=
> d any printout.