Subject: [DNSOP] Comments on draft-ietf-dnsop-svcb-https

From: "libor.peltan" <[email-masked]>
Date: Wed, 17 Jun 2020 14:10:14 +0200

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

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 17 Jun 2020 06:50:23 -0700

> On Jun 17, 2020, at 5:10 AM, libor.peltan <[email-masked]> 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
> 

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).
> 
> (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.
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Mark Andrews <[email-masked]>
Date: Wed, 17 Jun 2020 23:58:43 +1000

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-masked]> wrote:
> 
> Hi all,
>

---

From: [email-masked]
Date: Fri, 19 Jun 2020 21:58:32 +0200

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 <[email-masked]> wrote:
>> 
>> Hi all,
>> 
>> (1) The format of SVCB (and HTTPS) RR is too complicated, especially 
>> for parsing presentation format to wireformat and back, including 
> 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
> 
>> 
>> 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.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).
>>