On 21. 04. 21 19:00, Ben Schwartz wrote:
On Wed, Apr 21, 2021 at 12:44 PM Wellington, Brian
<bwelling=40akamai....@dmarc.ietf.org
<mailto:40akamai....@dmarc.ietf.org>> wrote:
I’m not a fan of the new text in section 4.3:
Recursive resolvers MUST be able to convey SVCB records
with unrecognized SvcParamKeys or malformed SvcParamValues.
It is perfectly reasonable for a recursive resolver to reject any
malformed DNS record. There’s a significant difference between
“malformed” and “unknown”. A recursive resolver should definitely
allow records with unknown SvcParamKeys, but if the format of a
record is known, a resolver should be allowed (encouraged, in fact)
to check that it conforms to that format.
The concern here was about differing interpretations of future
standards. For example, if some SvcParamValue is defined as a URL (for
some future key), implementations are likely to disagree about whether
certain bytestrings are valid URLs. (There are several definitions and
a zillion edge cases.) The resolver has no use for these values, so the
most compatible behavior is to treat them as opaque bytestrings.
We very deliberately chose the phrase "MUST be able to convey" to
recognize that resolvers might be configured not to convey a record with
a malformed value, but it should be possible.
Do you think we should change this sentence?
I can see the same ambiguity as Brian.
What about this text as replacement?
---
Recursive resolvers MUST be able to convey SVCB records with
unrecognized SvcParamKeys if they conform to RDATA wire format (section
2.2).
---
What I mean: Resolvers must be able to handle _unknown_ SvcParams as
opaque byte strings.
Various resolvers will do some sort of filtering on individual params,
but such filtering is "local policy" and nothing we write into the RFC
can change local policy anyway. For that reason I would not go to great
lengths to explain what to do with unrecognized URLs etc.
--
Petr Špaček
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
