Hi Tommy,
My point in more detail: DNS itself Is a key-(multi)value database.
Embedding another key-value list into RR data seems misconceptual.
Moreover, this embeeded stuff od somewhat Complex, with different
requirements on the keys, their order, and values.
However, i havent found any better solution w/o different drawbacks :(
BR,
Libor
On 2020-06-17 15:50, Tommy Pauly wrote:
On Jun 17, 2020, at 5:10 AM, .peltan <libor.pel...@nic.cz> wrote:
Hi all,
i'm a developer of Knot DNS authoritative server. I have some comments
on the SVCB draft and some suggestions for improvements. Just consider
my thoughts and then do whatever is best.
(1) The format of SVCB (and HTTPS) RR is too complicated, especially
for parsing presentation format to wireformat and back, including
consistency checks. Perhaps instead of
www 3600 IN HTTPS 1 . alpn=h2 port=8443
It could be
www 3600 IN HTTPS 1 . alpn h2
1 . port 8443
Which gives slightly bigger RRSet wireformat, but not by much.
I find this format suggestion to be far more confusing to read, since
these really are key-value pairs, and the SvcDomainName and the
SvcDomainPriority fields are shared across the different key-value
pairs.
What specifically is too hard to parse in the draft’s format? Is that
something that more clarifying examples can help with instead?
Tommy
(2) Paragraph 2.2 explicitly requires that SvcDomainName must not be
compressed. Is there a reason? Especially when the response packets
are large (and I expect that for SVCB they will), any compression
helps.
(3) Paragraph 2.5 contradicts itself: "SvcDomainName MUST be the name
of a domain that has SVCB, AAAA, or A records" versus "SvcDomainName
MAY be the owner of a CNAME record". What is the meaning here?
(4) Let's assume that CNAME is allowed under SvcDomainName. Paragraph
4.1 is too vague and I don't see what an authoritative (not
recursive!) server shall answer in situation SVCB->CNAME->A (all
in-bailiwick). Shall the CNAME and A be added to additional section?
For comparison, in situation MX->CNAME->A we don't bother since this
situation is forbidden (see RFC 2181).
(5) Wouldn't one octet for priority field be enough?
(6) There are not enough examples in the document. There are many
variants of SVCB records, the formal ABNF description is difficult to
read, and it would also illustrate what kind of services those records
are designed to handle.
Best regards and thanks for your effort,
Libor Peltan
CZ.NIC
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
