On Tue, Sep 13, 2022 at 10:33:44AM +0200, libor.peltan wrote:
> while implementing RFC 8427 in Knot DNS, we found that this RFC does not
> say anything about EDNS option.
One might the case that the EDNS(0) OPT-RR is a "pseudo-RR", and so does
not follow general RR presentation format. Indeed, for example, "dig"
does not display its content as an "additional" record. So it is not
surprising that treating it as a general RR yields poor results.
> Do you think we should improve this, making the JSON representation of
> OPT anyhow more useful?
The "OPT-RR" is message metadata, and so should not be confused with
other sorts of additional records. (TSIG would also fall into that
bucket).
> If so, how do you think we should proceed? Writing a new RFC draft
> updating this?
Standardising presentation forms of EDNS(0) data and options would IMHO
be useful, but are I think a somewhat separate concern from other RR
types. OPT RRs should for example never be seen in zone files, or in
(additional) data returned to applications by a stub resolver.
On Tue, Sep 13, 2022 at 12:33:37PM +0200, Petr Špaček wrote:
> I think this is a sign of a more generic problem: EDNS options sometimes
> do not have standardized and well described "presentation" format.
>
> If we were to fix that I think we should have one catch-all RFC to
> define missing presentation forma(s) for all known EDNS options [11]
> (it's not that many) and then require new RFCs to specify it.
I am in favour.
I should also note that in terms of presentation forms, the SVCB record
is particularly challenging, since it also sports extensible options of
arbitrary types, and requires both a generic presentation form (for not
known options) and a type-specific form for known options.
What makes SVCB even more "interesting", is that some of the options are
compound types (lists, structures, ...) and their JSON presentation
forms really should go beyond the string presentation form encodings, to
a proper structural decomposition of each option.
We don't currently even have a way to define such grammars in DNS RFCs,
all we know how to do is specify wire forms and zone file syntax.
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
