Well 2 is a DNS requirement from the word dot. I’m surprised any DNS developer would not know that. It allows records to pass through servers that don’t know the rdata fields structure.
-- Mark Andrews > On 17 Jun 2020, at 22:57, libor.peltan <[email protected]> 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. > > (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 > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
