On 01/11/2021 18.29, Michael StJohns wrote:
Section 2 - "their definition should specify..." - this is obviously a
must and is guidance to the IANA for interpreting registrations. E.g.
lack of this data has to result in a rejected registration request.
Section 2.1 - "Key names should contain..." - drop the should as it
introduces ambiguity. The BNF is clear this is a MUST and is normative.
Section 2.1 - "...formats for such keys SHOULD use a comma-separated
list". This is a semi-reasonable SHOULD, but begs the question of
what you do if you don't use a comma separated list and adds to the
later parser complexity if someone chooses something else in a later
definition. Guidance such as "Requests for registration of lists or
set SvcParamKeys that propose a different format must justify any
deviation and are subject to rejection." may be appropriate here.
2.4.1 - "all RRs SHOULD have the same mode" - this is satisfactory as
the next sentence describes what to do if this is not the case.
I agree with what you write about these occurrences. Generally I hope
that it's not too late to make similar changes.
2.4.1 - " ... SHOULD be given preference..." and "SHOULD apply a
random shuffle" are not satisfactory as they lead to ambiguity between
the publisher and the client. There appears to be no good reason not
to make both of theses MUST.
2.4.2 - "SHOULD only have a single" and "SHOULD pick one at
random". The first is satisfactory as it's covered by guidance on the
following sentence. The second is not as it leads to ambiguity and
there appears to be no good reason not to make it a MUST. Among other
things, you really don't want someone to come along later and decide
that because 75% of the clients pick the first one, they can game the
system by manipulating the RRSet.
In these two points it should (heh) remain clear that there are
situations where the clients won't exactly do this - e.g. if some
protocol is not supported by the client or if it can assume that some of
the RRs probably would not lead to success (based on recent connections
attempts). In some later parts there is text for these fallbacks, so it
probably will remain clear, though I think would be better to reflect it
in the above formulations *if* they get strengthened to MUST.
2.4.2 "TargetName SHOULD NOT..." - this is unsatisfactory as it
doesn't explain what a client should do if it receives such a beast.
This needs client guidance and the client MUST ignore such a record.
Also are there other pathological cases where you might end up with
loops indirectly? If so, guidance for the client on how to detect
such cases needs to be given.
2.4.2. "...records SHOULD NOT..." is satisfactory as it describes how
a client resolves receiving such records.
I think I agree with these two points, too.
I don't have a strong opinion on the following comments about section
3. I don't feel qualified for such details around HTTPS and similar
clients.
On the other hand, I carefully re-read all resolver-related bits (mainly
sections 4.x, 5.2, 13, 14), and there the requirements language seems
good to me.
Perhaps I'd like to note just this paragraph from 13. security
considerations:
Clients MUST ensure that their DNS cache is partitioned for each local
network, or flushed on network changes, to prevent a local adversary
in one network from implanting a forged DNS record that allows them to
track users or hinder their connections after they leave that network.
Does this imply that if a DNS *resolver* is running on a device capable
of "switching networks" (e.g. laptop), it MUST ensure this DNS cache
handling? I'm not aware of such standards-track RFC requirements so
far, and it's reaching a bit further than just these new RR types. Note
that the actual client (like web browser) most likely won't be able to
control this (optional) layer of local DNS cache, though there are
always options like attempting some DNS bypass (e.g. via DoH, most
popularly).
--Vladimir | knot-resolver.cz
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
