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

[internet-drafts]

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/


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tommy Pauly]

> On Mar 17, 2021, at 6:04 PM, Ben Schwartz 
>  wrote:
> 
> 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.

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  > wrote:
> 
> 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/ 
> 
> 
> 

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

[Mark Andrews]

> On 19 Mar 2021, at 04:42, Tommy Pauly  
> wrote:
> 
> 
> 
>> On Mar 17, 2021, at 6:04 PM, Ben Schwartz 
>>  wrote:
>> 
>> 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.
> 
> 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

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

>> --Ben
>> 
>> On Wed, Mar 17, 2021 at 1:11 PM  wrote:
>> 
>> 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-s

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

[libor.peltan]

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

Dne 19. 03. 21 v 0:05 Mark Andrews napsal(a):



On 19 Mar 2021, at 04:42, Tommy Pauly  wrote:




On Mar 17, 2021, at 6:04 PM, Ben Schwartz  
wrote:

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.

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

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


--Ben

On Wed, Mar 17, 2021 at 1:11 PM  wrote:

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.


Th

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

[Pieter Lexis]

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Willem Toorop]

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++shXFnrIB3tDgU6gMZfkJoFYAAgAAQAAQABAA==
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:
> 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
> 
> Dne 19. 03. 21 v 0:05 Mark Andrews napsal(a):
>>
>>> On 19 Mar 2021, at 04:42, Tommy Pauly
>>>  wrote:
>>>
>>>
>>>
 On Mar 17, 2021, at 6:04 PM, Ben Schwartz
  wrote:

 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.
>>> 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
>> 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
>>
 --Ben

 On Wed, Mar 17, 2021 at 1:11 PM  wrote:

 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 paramete

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

[Miek Gieben]

[ Quoting  in "Re: [DNSOP] I-D Action: draft-ietf-..." ]

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++shXFnrIB3tDgU6gMZfkJoFYAAgAAQAAQABAA==
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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Pieter Lexis]

Hi Willem, Ben,

On 3/19/21 11:14 AM, Willem Toorop wrote:
> 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?

+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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Willem Toorop]

Op 19-03-2021 om 11:19 schreef Pieter Lexis:
> Hi Willem, Ben,
> 
> On 3/19/21 11:14 AM, Willem Toorop wrote:
>> 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?
> 
> +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.

:+1:

That'd be nice!

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

Cheers,
-- Willem

> 
> Cheers,
> 
> Pieter
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Pieter Lexis]

Hi Willem,

On 3/19/21 11:47 AM, Willem Toorop wrote:
> 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

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Peter van Dijk]

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  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 

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 ",
"\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/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dick Franks]

On Fri, 19 Mar 2021 at 10:15, Willem Toorop  wrote:
>8
>
>
> 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?

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

Printing uses lightly toasted RFC3597 format:

x1.example. IN  SVCB0 foo.example.com.

x2.example. IN  SVCB1 .

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 20010db80001
20010db800530001 )

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

--rwf

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Willem Toorop]

Op 19-03-2021 om 18:03 schreef Pieter Lexis:
> Hi Willem,
> 
> On 3/19/21 11:47 AM, Willem Toorop wrote:
>> 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 :).

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].
> 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
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

> On 22 Mar 2021, at 20:41, Willem Toorop  wrote:
> 
> Op 19-03-2021 om 18:03 schreef Pieter Lexis:
>> Hi Willem,
>> 
>> On 3/19/21 11:47 AM, Willem Toorop wrote:
>>> 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 :).
> 
> 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.

And BIND.

> 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.

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

> 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.

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

> 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.

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.

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

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

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

Reject the transfer if the records are invalid.

> Or dynamic updates?

Return FORMERR to the updater.

> 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].
>> 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
>> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Willem Toorop]

Op 22-03-2021 om 15:50 schreef Ben Schwartz:
> On Mon, Mar 22, 2021 at 5:41 AM Willem Toorop  > wrote:
> 
> 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.
> 
> 
> 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.

Sure, so this:

x8.example. 3600IN  SVCB16 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. 3600IN  SVCB( \# 115 0010
03666f6f076578616d706c65036f7267 00 ; foo.example.org.
 0008 00010004007b0355
0001 0009 0268320568332d3139
0004 0004 c201
0006 0020 20010db801020304
  20010db8
; key123=...
007b 000f 736f6d65206f746865722074657874
; key853=...
0355 0004 74657374
)

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

> 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.
> 
> 
> 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. 3600IN  SVCB0 . mandatory=key0
x10.example.3600IN  SVCB( \# 9  00
 0002 
)

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

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

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.3600IN  SVCB( \# 26  00
0004 0004 c201
0001 0003 026832
 0004 00010004
)

or am I stretching it now...

Cheers,
-- Willem

> 
> 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.
> 
> 
> 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.
> 
> ___
> 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

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

[Pieter Lexis]

Hi folks,

On 3/22/21 5:29 PM, Willem Toorop wrote:
> [...]
> Would be good to have that in a test vector ;).

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)

> Most here tilt to *failing to load*, so these should fail to load:
> [...]
> 
> I think it would be good to have this added to the test-vectors appendix.

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

Cheers,

Pieter

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop