[DNSOP] draft-ietf-dnsop-refuse-any: points from 神明達哉

[Joe Abley <[e-mail]>]

JINMEI-san, all,

With reference to:

  https://mailarchive.ietf.org/arch/msg/dnsop/zy86pvg139PaKFXo-BO6SPUfh3k

> 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.

The draft at present doesn't require an implementer to abuse HINFO; it provides options to avoid doing so whilst still meeting the described objectives of the proposal. Since abusing HINFO is not mandatory, I presume you are objecting to the proposal sanctioning such shenanigans at all.

If I have that right (please correct me if I'm wrong) I don't think I am the right person to make the call, being just a lowly document scribe. If this remains a concern for you, I suggest that we defer that question to our chairs and ask them to gauge consensus. My own personal views of pragmatism vs. elegance shouldn't enter into it; this is a working group document.

> 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.

This text suggests that my interpretation above is wrong, and what you are objecting to is just the way that the HINFO approach is described. I think the specification is more clear if we spell out the whole synth-HINFO approach in its entirety and don't try to subsume it into the "return a subset of { RRSets that there } u { RRSets that we just synthesised }".

Again, I am not entirely confident that I understand your concern, so both my reactions above might be nonsense. Please try again if it seems that I don't understand your point.

> 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 am not sure I understand the benefit of not including it, given that it is observable behaviour for a large number of domains today (even if that is so due to the volume of domains hosted at a single operator). I think we do better service to operators and implementors by describing what is implemented. As you point out, Cloudflare's implementation may be less general-purpose than BIND9 or NSD, and that might be a reason for the implementation choices to be different. Cloudflare is unlikely to be the last non-general implementation, however, so perhaps the mechanism most appropriate there will be relevant to others.

> 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

I agree. Perhaps "One or more of the RRSets at a QNAME". "... or a subset" seems wrong, actually; since some vestigial fragment of a set theory lecture in the depths of my pre-history is telling me that the empty set is always a valid subset.

> - 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).

Agreed. That should be made consistent.


Joe