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

[Ted Lemon <[e-mail]>]

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, 神明達哉 <[e-mail]> wrote:

> 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
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>