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

[神明達哉 <[e-mail]>]

At Mon, 25 Apr 2016 16:50:42 -0400,
Tim Wicinski <[e-mail]> 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