Re: [DNSOP] Second Working Group Last Call: draft-ietf-dnsop-refuse-any

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

On Thu, Mar 16, 2017 at 12:11 AM, tjw ietf <[e-mail]> wrote:

> During the first WGLC of draft-ietf-dnsop-refuse-any, several issues were
> raised by the working group that needed to be addressed. The Authors
> addressed the issues, but the changes are enough that there should be a
> second Working Group Last Call on the changes.
[...]
> Please take a few moments to refer the changes and let the working group
> know if the document is ready to move forward.   We're mostly looking for
> remaining issues that have not been addressed.

I've reviewed the 04 version.  I still do not think it's ready to move
forward as it still abuses HINFO.  I understand some other people
don't care about this point, and some others may even love the idea
(those who are using it right now).  But I've also seen yet some other
people have the same concern, so it shouldn't be only me.  I don't
think we have a clear consensus on this point yet.

To be hopefully a bit more productive, I have a specific counter
proposal: remove the mandatory text about the use of HINFO, e.g.,

- remove this bullet from section 4
   2.  A DNS responder can return a synthesised HINFO resource record.
       See Section 6 for discussion of the use of HINFO.
- remove ', in which case...' from Section 4.2
   If there is no CNAME present at the owner name matching the QNAME,
   the resource record returned in the response MAY instead be
   synthesised, in which case a single HINFO resource record SHOULD be
   returned.

In fact, in terms of externally observable behavior, synthesizing
HINFO is just one form of "selecting one RRset of the QNAME"; the
HINFO is added and immediately removed at the time of answering the
ANY query, so in that sense we don't have to bother to mention it with
normative keywords.

Regarding the choice of HINFO in case of synthesizing, it may make
sense to specify a particular type as part of normative spec if many
other implementations are going to implement it.  But, as Section 8
explains two major general purpose open source implementations, NSD
and BIND 9, seem to only support the "subset" approach.  I suspect
it's actually not feasible for those generic implementations to
hardcode HINFO as long as their users could also use that type as
"real zone data".  Some special purpose implementation with full
control on what it configures, like in the case of Cloudflare, may
freely explore the approach of synthesizing HINFO at their discretion.
But I don't think it necessarily has to be a part of normative part of
this spec, at least at this moment.

I've also noticed a couple of other points I raised in my previous
review (https://www.ietf.org/mail-archive/web/dnsop/current/msg18746.html)
were not yet addressed.  These are (section numbers are for 03):

- Section 3

   1.  A DNS responder can choose to select one or subset of RRSets at
       the QNAME.

  'one or subset of RRSets' sounds a bit awkward to me

- Section 4

   A DNS responder which receives an ANY query MAY decline to provide a
   conventional response, or MAY instead send a response with a single
   RRSet in the answer section.

  "a single RRSet" doesn't seem to be fully consistent of "one or
  subset of RRSets" stated in the preceding section (see the previous
  bullet).

--
JINMEI, Tatuya