On 13. 09. 22 10:33, libor.peltan wrote:
Hi all, especially Paul,
while implementing RFC 8427 in Knot DNS, we found that this RFC does not
say anything about EDNS option. This results in general rules for RR
being applied, resulting in very ugly:
"additionalRRs": [
{
"NAME": ".",
"TYPE": 41,
"TYPEname": "OPT",
"CLASS": 1232,
"TTL": 32768,
"rdataOPT": "\\# 24
00030014646E732D7669782D646E7330312E6E69632E637A",
"RDLENGTH": 24,
"RDATAHEX": "00030014646e732d7669782d646e7330312e6e69632e637a"
}
It seems interesting to me, that this RFC is single-authored,
Informational and non-WG.
Do you think we should improve this, making the JSON representation of
OPT anyhow more useful?
If so, how do you think we should proceed? Writing a new RFC draft
updating this?
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.
Besides JSON format it would also help with other text representations,
e.g. in test systems which need to describe queries and answers in some
human-readable format.
[11]
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-11
--
Petr Špaček
Internet Systems Consortium
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
