Subject: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-04.txt

From: [email-masked]
Date: Wed, 17 Mar 2021 10:10:38 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

        Title           : Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)
        Authors         : Ben Schwartz
                          Mike Bishop
                          Erik Nygren
	Filename        : draft-ietf-dnsop-svcb-https-04.txt
	Pages           : 48
	Date            : 2021-03-17

Abstract:
   This document specifies the "SVCB" and "HTTPS" DNS resource record
   (RR) types to facilitate the lookup of information needed to make
   connections to network services, such as for HTTPS origins.  SVCB
   records allow a service to be provided from multiple alternative
   endpoints, each with associated parameters (such as transport
   protocol configuration and keys for encrypting the TLS ClientHello).
   They also enable aliasing of apex domains, which is not possible with
   CNAME.  The HTTPS RR is a variation of SVCB for HTTPS and HTTP
   origins.  By providing more information to the client before it
   attempts to establish a connection, these records offer potential
   benefits to both performance and privacy.

   TO BE REMOVED: This document is being collaborated on in Github at:
   https://github.com/MikeBishop/dns-alt-svc [1].  The most recent
   working version of the document, open issues, etc. should all be
   available there.  The authors (gratefully) accept pull requests.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-04
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-https-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 17 Mar 2021 21:04:34 -0400

Release notes for this revision:
      *  Simplify the IANA instructions (pure First Come First Served)
      *  Recommend against publishing chains of >8 aliases
      *  Clarify requirements for using SVCB with a transport proxy
      *  Adjust guidance for Port Prefix Naming
      *  Minor editorial updates

I'm only aware of one outstanding issue: a proposal to change the name of
the "echconfig" key to "ech".  This key corresponds to a value that is an
"ECHConfigList", which is a collection of "ECHConfig" structs, and some
implementers have reported that the singular/plural name-value mismatch
created confusion.  This issue is discussed in detail here:
https://github.com/MikeBishop/dns-alt-svc/pull/299.

This name has no effect on queries, responses, or zone transfers, but it
does appear in zone files.  Zone files will not be portable between
implementations that use different names.  This is true whether we "burn"
the current codepoint and allocate a new one, or simply rename the current
codepoint.  However, using a new codepoint would allow updated
implementations to support both names, facilitating zone file portability
in one direction.  It would also be possible to support the old name with
special-case name aliasing logic.

In my view, the temporary portability benefit is too small to justify the
permanent registry pollution of a deprecated codepoint, especially because
ECH itself is not yet finalized, and there are no deployments except for
standards development purposes.  However, others have disagreed.  We'll
need to reach consensus before making any changes here.

--Ben

On Wed, Mar 17, 2021 at 1:11 PM <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 18 Mar 2021 10:42:20 -0700

> On Mar 17, 2021, at 6:04 PM, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> I'm only aware of one outstanding issue: a proposal to change the name of the "echconfig" key to "ech".  This key corresponds to a value that is an "ECHConfigList", which is a collection of "ECHConfig" structs, and some implementers have reported that the singular/plural name-value mismatch created confusion.  This issue is discussed in detail here: https://github.com/MikeBishop/dns-alt-svc/pull/299 <https://github.com/MikeBishop/dns-alt-svc/pull/299>.
> 
> This name has no effect on queries, responses, or zone transfers, but it does appear in zone files.  Zone files will not be portable between implementations that use different names.  This is true whether we "burn" the current codepoint and allocate a new one, or simply rename the current codepoint.  However, using a new codepoint would allow updated implementations to support both names, facilitating zone file portability in one direction.  It would also be possible to support the old name with special-case name aliasing logic.
> 
> In my view, the temporary portability benefit is too small to justify the permanent registry pollution of a deprecated codepoint, especially because ECH itself is not yet finalized, and there are no deployments except for standards development purposes.  However, others have disagreed.  We'll need to reach consensus before making any changes here.

Personally, I’d prefer to see the name change, and not burn a codepoint, as long as we’re not breaking any zone files.

I think the question is: does anyone have a zone that has actually deployed the echconfig parameter? I see many responses with SVCB/HTTPS records, but none with the echconfig in practice. If someone is aware of a production deployment that can’t move, please speak up!

Tommy

> 
> --Ben
> 
> On Wed, Mar 17, 2021 at 1:11 PM <[email-masked] <mailto:[email-masked]>> wrote:
> 
>    https://github.com/MikeBishop/dns-alt-svc <https://github.com/MikeBishop/dns-alt-svc> [1].  The most recent
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ <https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/>
> 
> https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-04 <https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-04>
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-04 <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-04>
> 
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-https-04 <https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-https-04>
> 
> 
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 19 Mar 2021 10:05:03 +1100

> On 19 Mar 2021, at 04:42, Tommy Pauly <tpauly=[email-masked]> wrote:
> 
> 
> 
>> I'm only aware of one outstanding issue: a proposal to change the name of the "echconfig" key to "ech".  This key corresponds to a value that is an "ECHConfigList", which is a collection of "ECHConfig" structs, and some implementers have reported that the singular/plural name-value mismatch created confusion.  This issue is discussed in detail here: https://github.com/MikeBishop/dns-alt-svc/pull/299.
>> 

It’s not so much is it in use or not.  As I said this is a process issue.  When
the code point was assigned the way it was the wire and presentation formats are
supposed to be *frozen* as that allows DNS developer to deploy code without having
to worry about the specification changing underneath them.

For BIND we haven’t shipped code with SVBC / HTTPS code points yet even to the
point of parsing the records.  We have merge request that has been tracking the
draft.  I never felt the specification was stable enough to do that and unfortunately
I was correct.  ALPN has had its parsing changed, the same presentation format produces
different wire formats.  echconfig vs ech is minor compared to that.

I have not looked to see what other DNS vendors have done so far.

If we go ahead there needs to be a section that specified the differences in
parsing between the draft when the code point was issued and when the RFC is
published.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: "libor.peltan" <[email-masked]>
Date: Fri, 19 Mar 2021 09:05:14 +0100

FYI in Knot DNS, the implementation is at exactly the same state: an 
existing merge request. For us, it's technically no issue if the 
presentation/wire format changes during next few weeks.

I'm saying nothing about ideological consequences of such approach.

/Libor

---

From: Pieter Lexis <[email-masked]>
Date: Fri, 19 Mar 2021 10:51:47 +0100

Hi,

On 3/18/21 6:42 PM, Tommy Pauly wrote:
> Personally, I’d prefer to see the name change, and not burn a codepoint,
> as long as we’re not breaking any zone files.

Agree.

> I think the question is: does anyone have a zone that has actually
> deployed the echconfig parameter? I see many responses with SVCB/HTTPS
> records, but none with the echconfig in practice. If someone is aware of
> a production deployment that can’t move, please speak up!

We released PowerDNS Authoritative Server 4.4.0 with explicit draft-01
support. We can put the name-change in a future patch release, mention
this in the the upgrade docs and add some code to log that the old name
is in use for a few releases. We have not heard of any deployments that
use SVCB/HTTP.

Cheers,

Pieter

---

From: Willem Toorop <[email-masked]>
Date: Fri, 19 Mar 2021 11:14:50 +0100

No version of NSD, Unbound, ldns and getdns with SVCB and HTTPS support
has been released yet, so no problem for us to change the name of
SvcParamKey 5 to ech for us there, but ...

The Net::DNS perl library does have parsing and printing of SVCB and
HTTPS based on draft-ietf-dnsop-svcb-https-01 since version 1.26
(released on August 6, 2020). @Dick, what is your position on this?

I am aware of only 1 deployed HTTPS RR with echconfig:

crypto.cloudflare.com.	300	IN	HTTPS	1 . alpn=h2
ipv4hint=162.159.135.79,162.159.136.79
echconfig=AEf+CQBDABNjbG91ZGZsYXJlLWVzbmkuY29tACAjs5LfHm27uMBFmLDI++shXFnrIB3tDgU6gMZfkJoFYAAgAAQAAQABAAAAAA==
ipv6hint=2606:4700:7::a29f:874f,2606:4700:7::a29f:884f

Also, it would have been nice to have some test-vectors of RR's in
presentation format and wire format (in hexdump) in an appendix in the
document, to assist in the creation of interoperable implementations.
Maybe this can still be added?

-- Willem

Op 19-03-2021 om 09:05 schreef libor.peltan:
>>> On 19 Mar 2021, at 04:42, Tommy Pauly
>>> <tpauly=[email-masked]> wrote:
>>>
>>>
>>>
>>>> On Mar 17, 2021, at 6:04 PM, Ben Schwartz
>>>> <bemasc=[email-masked]> wrote:
>>>>
>>>> I'm only aware of one outstanding issue: a proposal to change the
>>>> name of the "echconfig" key to "ech".  This key corresponds to a
>>>> value that is an "ECHConfigList", which is a collection of
>>>> "ECHConfig" structs, and some implementers have reported that the
>>>> singular/plural name-value mismatch created confusion.  This issue
>>>> is discussed in detail here:
>>>> This name has no effect on queries, responses, or zone transfers,
>>>> but it does appear in zone files.  Zone files will not be portable
>>>> between implementations that use different names.  This is true
>>>> whether we "burn" the current codepoint and allocate a new one, or
>>>> simply rename the current codepoint.  However, using a new codepoint
>>>> would allow updated implementations to support both names,
>>>> facilitating zone file portability in one direction.  It would also
>>>> be possible to support the old name with special-case name aliasing
>>>> logic.
>>>>
>>>> In my view, the temporary portability benefit is too small to
>>>> justify the permanent registry pollution of a deprecated codepoint,
>>>> especially because ECH itself is not yet finalized, and there are no
>>>> deployments except for standards development purposes.  However,
>>>> others have disagreed.  We'll need to reach consensus before making
>>>> any changes here.
>>> Personally, I’d prefer to see the name change, and not burn a
>>> codepoint, as long as we’re not breaking any zone files.
>>>
>>> deployed the echconfig parameter? I see many responses with
>>> SVCB/HTTPS records, but none with the echconfig in practice. If
>>> someone is aware of a production deployment that can’t move, please
>>> speak up!
>>>
>>> Tommy
>>>>          Title           : Service binding and parameter
>>>> specification via the DNS (DNS SVCB and HTTPS RRs)
>>>>          Authors         : Ben Schwartz
>>>>                            Mike Bishop
>>>>                            Erik Nygren

---

From: Miek Gieben <[email-masked]>
Date: Fri, 19 Mar 2021 11:18:30 +0100

[ Quoting <[email-masked]> in "Re: [DNSOP] I-D Action: draft-ietf-..." ]
>ipv6hint=2606:4700:7::a29f:874f,2606:4700:7::a29f:884f

miekg/dns has support for the draft version of SVCB since Oct 11 2020:

https://github.com/miekg/dns/pull/1067

this is used by cloudflare and who knows how many other projects. The PR speaks of testing
against a Python implementation, so that _also_ has support for the older draft.

/Miek

--
Miek Gieben

---

From: Pieter Lexis <[email-masked]>
Date: Fri, 19 Mar 2021 11:19:38 +0100

Hi Willem, Ben,

> Maybe this can still be added?

+1000

The PowerDNS unit tests already has a bunch of tests that do the
presentation -> wire -> presentation roundtrip. I could convert those to
using example.com, use some more hex and send a PR to the authors should
they want this.

Cheers,

Pieter

-- 
Pieter Lexis
PowerDNS.COM BV -- https://www.powerdns.com

---

From: Willem Toorop <[email-masked]>
Date: Fri, 19 Mar 2021 11:47:41 +0100

> using example.com, use some more hex and send a PR to the authors should

:+1:

That'd be nice!

Do you also have tests for peculiar/corner and failure cases?

Cheers,
-- Willem

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 19 Mar 2021 10:42:43 -0400

> using example.com, use some more hex and send a PR to the authors should

Great idea.  Thanks in advance!

Does anyone have an example of test vector presentation that they like?
Perhaps it should be structured as a pair of zone files representing the
same zone, one in SVCB format and one in RFC 3597.

---

From: Pieter Lexis <[email-masked]>
Date: Fri, 19 Mar 2021 18:03:29 +0100

Hi Willem,

> That'd be nice!

PR is here [1].

> Do you also have tests for peculiar/corner and failure cases?

I'm a little bit unsure what you men with this :). The code is here[2].
I've also opened a PR updating our parser for the draft-03 changes for
multiple values, that one also has some tests for the value parser[3].

Cheers,

Pieter

1 - https://github.com/MikeBishop/dns-alt-svc/pull/307
2 -
https://github.com/PowerDNS/pdns/blob/3a63bb5fca1c45a6e9dee808a56ca6cbea2be0d8/pdns/test-dnsrecords_cc.cc#L209-L230
3 -
https://github.com/PowerDNS/pdns/pull/10074/files#diff-1c55ae7b2d1073637c05a035de9ef6688ecffb209e50b3bef8b3d9ea1c5a329dR308-R393

---

From: Peter van Dijk <[email-masked]>
Date: Fri, 19 Mar 2021 18:53:09 +0100

On Fri, 2021-03-19 at 10:42 -0400, Ben Schwartz wrote:
> Does anyone have an example of test vector presentation that they like? Perhaps it should be structured as a pair of zone files representing the same zone, one in SVCB format and one in RFC 3597.

tl;dr: +1 to that

I recently implemented CSYNC in PowerDNS, and was greatly aided therein
by RFC 7477 section 2.1.3, which I will quote here:

===

The following CSYNC RR shows an example entry for "example.com" that
indicates the NS, A, and AAAA bits are set and should be processed by
the parental agent for example.com.  The parental agent should pull
data only from a zone using a minimum SOA serial number of 66 (0x42
in hexadecimal).

example.com. 3600 IN CSYNC 66 3 A NS AAAA

The RDATA component of the example CSYNC RR would be encoded on the
wire as follows:

  0x00 0x00 0x00 0x42             (SOA Serial)
  0x00 0x03                       (Flags = immediate | soaminimum)
  0x00 0x04 0x60 0x00 0x00 0x08   (Type Bit Map)

===

In my case, I could take these hex octets, sprinkle in a few
backslashes, and make the test case fit *our* codebase:

test-dnsrecords_cc.cc:     (CASE_S(QType::CSYNC, "66 3 A NS AAAA",
"\x00\x00\x00\x42\x00\x03\x00\x04\x60\x00\x00\x08"))

Ever since I've been wondering what the best format would be, though,
so that vendors could exchange collections of test vectors. I already
imagined OARC maintaining that collection even!

I think your SVCB/3597 pairing might be that format. I know NLnetlabs
and ISC have tools that can even generate the latter from the former
(for supported types, of course), which makes testing and verifying
implementations very easy if the RFC also shows that pair, and even
allows users (and draft authors!) to do the same checks.

The only thing I wonder about is whether we can combine the 3597 format
with the 3 part breakdown 7477 did on the hexdump, which also is very
educational. Of course, nothing prevents us from doing both the
breakdown and a couple of 3597 pairings.

So, +1 from me!

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 19 Mar 2021 14:49:33 -0400

> same zone, one in SVCB format and one in RFC 3597.

OK.  Please review Pieter's proposed text (
https://github.com/MikeBishop/dns-alt-svc/pull/307/files), which is more
like pseudocode and does not resemble that.

...

> educational.

Dick Franks demonstrated a relatively legible version of the 3597 format at
the bottom of this email:
https://mailarchive.ietf.org/arch/msg/dnsop/o31r8q5wN0FHXh8yE2fJUNG5dU8/

> Of course, nothing prevents us from doing both the

I would be OK with having both, especially if the dual-zones can be kept
reasonably compact.

---

From: Dick Franks <[email-masked]>
Date: Sat, 20 Mar 2021 13:49:43 +0000

On Fri, 19 Mar 2021 at 10:15, Willem Toorop <[email-masked]> wrote:
>8

Change of name only affects parsing. Easy to accept both until RFC put to bed.

Printing uses lightly toasted RFC3597 format:

    x1.example. IN      SVCB    0 foo.example.com.

    x2.example. IN      SVCB    1 .

    x3.example. IN      SVCB    ( \# 25 0010    ; 16
       03666f6f076578616d706c6503636f6d 00     ; foo.example.com.
        0003 0002 0035 )

    x4.example. IN      SVCB    ( \# 28 0001    ; 1
        03666f6f076578616d706c6503636f6d 00     ; foo.example.com.
        ; key667=...
        029b 0005 68656c6c6f )

    x5.example. IN      SVCB    ( \# 32 0001    ; 1
        03666f6f076578616d706c6503636f6d 00     ; foo.example.com.
        ; key667=...
        029b 0009 68656c6c6fd2716f6f )

    x6.example. IN      SVCB    ( \# 55 0001    ; 1
        03666f6f076578616d706c6503636f6d 00     ; foo.example.com.
        0006 0020 20010db8000000000000000000000001
20010db8000000000000000000530001 )

    x7.example. IN      SVCB    ( \# 46 0010    ; 16
        03666f6f076578616d706c65036f7267 00     ; foo.example.org.
        0000 0002 0001
        0001 0009 0268320568332d3139
        0004 0004 c0000201 )

--rwf

---

From: Willem Toorop <[email-masked]>
Date: Mon, 22 Mar 2021 10:41:18 +0100

Op 19-03-2021 om 18:03 schreef Pieter Lexis:
> I'm a little bit unsure what you men with this :).

Well, I am wondering how much the parser should just normalize or
produce a syntax error instead. I noticed from the 7th example in your
PR, that you automatically put the SvcParams in the correct order, so
you apply normalization there in the sense that your parser sorts the
SvcParams. So do Net::DNS and (unreleased) ldns b.t.w.

But what about the keys in the "mandatory" SvcParam? Should they be
sorted automatically? Or should the parser produce an error if they are
not sorted? Currently both both Net::DNS and ldns sort them for you.

What if keys appear double in the "mandatory" SvcParam? Should the
parser produce an error or remove the doubles? Currently ldns removes
them, but Net::DNS produces and error.

What if keys that may not appear in "mandatory" (like key0 or mandatory
itself) appear in the "mandatory" SvcParam? Should they be removed
automatically or should they produce and error.

What if keys that are listed in "mandatory" do not appear in the RR.

What if there is a DNSSEC signature alongside the SVCB or HTTPS RR?
Should normalization be applied to the rdata then?

What if the SVCB and/or HTTPS is not parsed by an authoritative, but
received via AXFR or IXFR? Or dynamic updates?

Also, I love the annotated RFC3597 format that Net::DNS produces and I
think we should use that in the test-vectors!

> The code is here[2].

---

From: Mark Andrews <[email-masked]>
Date: Tue, 23 Mar 2021 00:55:57 +1100

> On 22 Mar 2021, at 20:41, Willem Toorop <[email-masked]> wrote:
> 

And BIND.

> not sorted? Currently both both Net::DNS and ldns sort them for you.

They MUST remain in the entered order unless the specification is
changed to say to sort them.  BIND preserves the order.

> them, but Net::DNS produces and error.

It’s an invalid record that should cause the zone load to fail
It’s an invalid record when received over the wire.

> automatically or should they produce and error.

It’s a syntax error or an invalid record when received over the wire.
Note: key0 is mandatory.

> What if keys that are listed in "mandatory" do not appear in the RR.

It’s an invalid record that should be rejected by the parser or
an invalid record when received over the wire.

> Should normalization be applied to the rdata then?

Yes.  The signer deals with the wire format, not the text format.

> received via AXFR or IXFR?

Reject the transfer if the records are invalid.

> Or dynamic updates?

Return FORMERR to the updater.

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 22 Mar 2021 10:50:16 -0400

> not sorted? Currently both both Net::DNS and ldns sort them for you.

The draft says:

   The presentation "value" SHALL be a comma-separated list
   (Appendix A.1) of one or more valid SvcParamKeys, either by their
   registered name or in the unknown-key format (Section 2.1).  Keys MAY
   appear in any order, but MUST NOT appear more than once.

and

   In wire format, the keys are represented by their numeric values in
   network byte order, concatenated in ascending order.

Hopefully that's clear enough.

> them, but Net::DNS produces and error.

I think authoritative servers "SHOULD" enforce the zone file requirements
to the extent possible, but responsibility ultimately lies with the zone
owner.

> What if keys that are listed in "mandatory" do not appear in the RR.

The draft says:

   For self-
   consistency (Section 2.4.3), listed keys MUST also appear in the
   SvcParams.

and (in Section 2.4.3)

   Zone-file implementations
   SHOULD enforce self-consistency.  Clients MUST reject any RR whose
   recognized SvcParams are not self-consistent, and MAY reject the
   entire RRSet.

---

From: Willem Toorop <[email-masked]>
Date: Mon, 22 Mar 2021 17:29:58 +0100

Op 22-03-2021 om 15:50 schreef Ben Schwartz:
> On Mon, Mar 22, 2021 at 5:41 AM Willem Toorop <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

Sure, so this:

x8.example.     3600    IN      SVCB    16 foo.example.org. (
        key853="test" key123="some other text"
        ipv4hint=192.0.2.1 mandatory=ipv4hint,alpn,key853,key123
        alpn=h2,h3-19 ipv6hint=2001:db8::1.2.3.4,2001:db8::
	)

is equivalent with

x8.example.	3600	IN	SVCB	( \# 115 0010
	03666f6f076578616d706c65036f7267 00	; foo.example.org.
	0000 0008 00010004007b0355
	0001 0009 0268320568332d3139
	0004 0004 c0000201
	0006 0020 20010db8000000000000000001020304
	          20010db8000000000000000000000000
	; key123=...
	007b 000f 736f6d65206f746865722074657874
	; key853=...
	0355 0004 74657374
	)

Would be good to have that in a test vector ;).

> I think authoritative servers "SHOULD" enforce the zone file
> requirements to the extent possible, but responsibility ultimately lies
> with the zone owner.

Excellent! How SHOULD it enforce? By failing to load or by fixing.
Most here tilt to *failing to load*, so these should fail to load:

; Forbidden key in mandatory
x9.example.	3600	IN	SVCB	0 . mandatory=key0
x10.example.	3600	IN	SVCB	( \# 9 0000 00
	0000 0002 0000
	)

; Double key in mandatory
x11.example.	3600	IN	SVCB	0 . (
	ipv4hint=192.0.2.1 alpn=h2 mandatory=ipv4hint,alpn,key4
	)
x12.example.	3600	IN	SVCB	( \# 28 0000 00
	0000 0006 000100040004
	0001 0003 026832
	0004 0004 c0000201
	)

; Key without SvcParam in mandatory
x13.example.	3600	IN	SVCB	0 . (
	ipv4hint=192.0.2.1 alpn=h2 mandatory=ipv6hint,alpn,key4
	)
x14.example.	3600	IN	SVCB	( \# 28 0000 00
	0000 0006 000100040006
	0001 0003 026832
	0004 0004 c0000201
	)

I think it would be good to have this added to the test-vectors appendix.

Should this fail to load too?

; Wireformat has SvcParams unordered
x15.example.	3600	IN	SVCB	( \# 26 0000 00
	0004 0004 c0000201
	0001 0003 026832
	0000 0004 00010004
	)

or am I stretching it now...

Cheers,
-- Willem

---

From: Pieter Lexis <[email-masked]>
Date: Mon, 22 Mar 2021 18:02:53 +0100

Hi folks,

On 3/22/21 5:29 PM, Willem Toorop wrote:
> [...]

Hence the inclusion of the unsorted keys vector :).

> Excellent! How SHOULD it enforce? By failing to load or by fixing.

This is all implementation specific of course :). For PowerDNS we don't
pre-parse the zones when serving (being a database driven server) so we
have a tool (`pdnsutil check-zone`) that will warn/error if things are
wrong with records, where we're covering most of these cases. We'll have
some sanity checking in-line (when serving), but there's no way we will
validate all constraints at runtime (we will probably when you use the
API to manipulate records, but that is not yet implemented)

> [...]

I'll try to update the vectors this week, changing the format and adding
some missed cases as well.

Cheers,

Pieter