Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Tommy Pauly]

I don’t personally find this proposal to be an improvement for clarity.

The fact that a client is SVCB-optional means, somewhat by definition, that 
they allow not using the SVCB results. Saying that the client “MAY” doesn’t 
really help; it’s the very definition of what SVCB-optional is. If the client 
doesn’t use non-SVCB connection modes at that point, then it is SVCB-reliant.

Listing out the details of what a non-SVCB connection does (not using the 
information from the SVCB record) also seems redundant. It is more accurate to 
just say “don’t use anything from SVCB if SVCB didn’t work” rather than trying 
to list out what all of those details might be.

Tommy

> On Aug 31, 2022, at 4:13 PM, Brian Dickson  
> wrote:
> 
> So, here is my suggestion, for "a sentence (or possibly two) which only 
> clarify what is already written?":
> 
> In section 3:
>If the client is SVCB-optional, and connecting using this list of
>endpoints has failed, the client now attempts to use non-SVCB
>connection modes.
> becomes:
>If the client is SVCB-optional, and connecting using this list of
>endpoints has failed, the client MAY attempt to use non-SVCB
>connection modes, using the origin name (without prefixes),
>the authority endpoint's port number, and no SvcParams.
> 
> (The original didn't use RFC 2119 language, but the list of failure modes in 
> 3.1 leads to "MAY" being the most appropriate choice.)
> 
> Let me know if that is good enough.
> (The rest can go into a -bis... how soon are we allowed to start a -bis 
> document? The day of RFC publication? I'd like to start that as soon as 
> possible, while everything is still fresh.)
> 
> Brian
> 
> On Wed, Aug 31, 2022 at 6:25 AM Warren Kumari  > wrote:
>> 
>> 
>> 
>> 
>> On Wed, Aug 31, 2022 at 4:39 AM, Brian Dickson 
>> mailto:brian.peter.dick...@gmail.com>> wrote:
>>> Here are some proposed text changes, per Warren's invitation to send text:
>> 
>> 
>> 
>> Um, no.  Warren said: "can we craft a sentence (or possibly two) which only 
>> clarify what is already written?". This is a significantly larger set of 
>> changes than that. The Section 3 changes in particular are (IMO) much more 
>> than a clarification. 
>> 
>> These may or may not be good changes, but anything approaching that level of 
>> change would have to be in a -bis document…
>> 
>> W
>> 
>> 
>>> 
>>> In section 1.2, change:
>>> 2.  TargetName: The domain name of either the alias target (for
>>>AliasMode) or the alternative endpoint (for ServiceMode).
>>> to:
>>> 2.  TargetName: Either the domain name of the alias target (for
>>>AliasMode) or the host name of the alternative endpoint (for 
>>> ServiceMode).
>>> 
>>> In section 2.4.2, change:
>>>As legacy clients will not know to use this record, service operators
>>>will likely need to retain fallback  and A records alongside this
>>>SVCB record, although in a common case the target of the SVCB record
>>>might offer better performance, and therefore would be preferable for
>>>clients implementing this specification to use.
>>> to:
>>>As legacy clients will not know to use this record, service operators
>>>will likely need to retain fallback  and A records at the service 
>>> name,
>>>although in a common case the target of the SVCB record
>>>might offer better performance, and therefore would be preferable for
>>>clients implementing this specification to use.
>>> 
>>> In section 2.4.3, change:
>>>In ServiceMode, the TargetName and SvcParams within each resource
>>>record associate an alternative endpoint for the service with its
>>>connection parameters.
>>> to:
>>>In ServiceMode, the TargetName and SvcParams within each resource
>>>record associate an alternative endpoint for the service with its
>>>connection parameters. The TargetName MUST be a host name
>>>(as defined in [DNSTerm].)
>>> 
>>> In section 3, the following changes are proposed; they introduce a new term 
>>> LASTNAME to be used to disambiguate the $QNAME reference so as to remove 
>>> ATTRLEAF prefixes from the appended target:
>>> 
>>>1.  Let $QNAME be the service name plus appropriate prefixes for the
>>>scheme (see Section 2.3).
>>> becomes:
>>>1.  Let $QNAME be the service name plus appropriate prefixes for the
>>>scheme (see Section 2.3). Let $LASTNAME be the service name without 
>>> any prefixes.
>>> 
>>> 
>>>3.  If an AliasMode SVCB record is returned for $QNAME (after
>>>following CNAMEs as normal), set $QNAME to its TargetName
>>>(without additional prefixes) and loop back to step 2, subject to
>>>chain length limits and loop detection heuristics (see
>>>Section 3.1).
>>> becomes:
>>>3.  If an AliasMode SVCB record is returned for $QNAME (after
>>>following CNAMEs as normal), set $QNAME to its TargetName
>>>(without additional prefixes), set 

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

So, here is my suggestion, for "a sentence (or possibly two) which only
clarify what is already written?":

In section 3:

   If the client is SVCB-optional, and connecting using this list of
   endpoints has failed, the client now attempts to use non-SVCB
   connection modes.

becomes:

   If the client is SVCB-optional, and connecting using this list of
   endpoints has failed, the client MAY attempt to use non-SVCB
   connection modes, using the origin name (without prefixes),

   the authority endpoint's port number, and no SvcParams.

(The original didn't use RFC 2119 language, but the list of failure modes
in 3.1 leads to "MAY" being the most appropriate choice.)

Let me know if that is good enough.
(The rest can go into a -bis... how soon are we allowed to start a -bis
document? The day of RFC publication? I'd like to start that as soon as
possible, while everything is still fresh.)

Brian

On Wed, Aug 31, 2022 at 6:25 AM Warren Kumari  wrote:

>
>
>
>
> On Wed, Aug 31, 2022 at 4:39 AM, Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>> Here are some proposed text changes, per Warren's invitation to send text:
>>
>
>
> Um, no.  Warren said: "can we craft a sentence (or possibly two) which
> only clarify what is already written?". This is a significantly larger set
> of changes than that. The Section 3 changes in particular are (IMO) much
> more than a clarification.
>
> These may or may not be good changes, but anything approaching that level
> of change would have to be in a -bis document…
>
> W
>
>
>
>> In section 1.2, change:
>>
>> 2.  TargetName: The domain name of either the alias target (for
>>AliasMode) or the alternative endpoint (for ServiceMode).
>>
>> to:
>>
>> 2.  TargetName: Either the domain name of the alias target (for
>>AliasMode) or the host name of the alternative endpoint (for
>> ServiceMode).
>>
>> In section 2.4.2, change:
>>
>>As legacy clients will not know to use this record, service operators
>>will likely need to retain fallback  and A records alongside this
>>SVCB record, although in a common case the target of the SVCB record
>>might offer better performance, and therefore would be preferable for
>>clients implementing this specification to use.
>>
>> to:
>>
>>As legacy clients will not know to use this record, service operators
>>will likely need to retain fallback  and A records at the service
>> name,
>>although in a common case the target of the SVCB record
>>might offer better performance, and therefore would be preferable for
>>clients implementing this specification to use.
>>
>>
>> In section 2.4.3, change:
>>
>>In ServiceMode, the TargetName and SvcParams within each resource
>>record associate an alternative endpoint for the service with its
>>connection parameters.
>>
>> to:
>>
>>In ServiceMode, the TargetName and SvcParams within each resource
>>record associate an alternative endpoint for the service with its
>>connection parameters. The TargetName MUST be a host name
>>(as defined in [DNSTerm].)
>>
>> In section 3, the following changes are proposed; they introduce a new
>> term LASTNAME to be used to disambiguate the $QNAME reference so as to
>> remove ATTRLEAF prefixes from the appended target:
>>
>>
>>1.  Let $QNAME be the service name plus appropriate prefixes for the
>>scheme (see Section 2.3).
>>
>> becomes:
>>
>>1.  Let $QNAME be the service name plus appropriate prefixes for the
>>scheme (see Section 2.3). Let $LASTNAME be the service name
>> without any prefixes.
>>
>>
>>
>>3.  If an AliasMode SVCB record is returned for $QNAME (after
>>following CNAMEs as normal), set $QNAME to its TargetName
>>(without additional prefixes) and loop back to step 2, subject to
>>chain length limits and loop detection heuristics (see
>>Section 3.1).
>>
>> becomes:
>>
>>3.  If an AliasMode SVCB record is returned for $QNAME (after
>>following CNAMEs as normal), set $QNAME to its TargetName
>>(without additional prefixes), set $LASTNAME to this new $QNAME
>> and loop back to step 2, subject to
>>chain length limits and loop detection heuristics (see
>>Section 3.1).
>>
>>
>>Once SVCB resolution has concluded, whether successful or not, SVCB-
>>optional clients SHALL append to the priority list an endpoint
>>consisting of the final value of $QNAME, the authority endpoint's
>>port number, and no SvcParams.  (This endpoint will be attempted
>>before falling back to non-SVCB connection modes.  This ensures that
>>SVCB-optional clients will make use of an AliasMode record whose
>>TargetName has A and/or  records but no SVCB records.)
>>
>> becomes:
>>
>>Once SVCB resolution has concluded, whether successful or not, SVCB-
>>optional clients SHALL append to the priority list an endpoint
>>consisting of the final value of $LASTNAME, the 

Re: [DNSOP] HSTS on receiving a signed HTTPS record (was: Questions / concerns with draft-ietf-dnsop-svcb-https ...)

[Brian Dickson]

On Wed, Aug 31, 2022 at 10:43 AM Eric Orth  wrote:

> I'm not sure what exactly is being changed or clarified with this
> suggestion.  Section 9.5 already applies at SHOULD-level, whether
> cryptographically protected or not and whether the received records were
> AliasMode or ServiceMode.
>

The text in 9.5 has some language that is actually NOT at the SHOULD level:

   Because HTTPS RRs are received over an often-
   insecure channel (DNS), clients MUST NOT place any more trust in this
   signal than if they had received a 307 (Temporary Redirect) response
   over cleartext HTTP.


That's what the suggestion is making an effort to strengthen, under
specific conditions (e.g. cryptographically protected HTTPS records
received).

The current 9.5 text quoted above, is placing MUST NOT guidance,
independent of whether the records were cryptographically protected.

I'm thinking it would be better to fix the quoted language above, in a -bis
document, if the suggested text isn't acceptable as an update to the
about-to-be-published draft.

The logic used to reach that MUST NOT is suspect, IMHO.
The main non-requirements on DNSSEC (i.e. that HTTPS does not require it)
are then turned into an "assume all DNS responses are not cryptographically
protected" inferentially.

It would be better guidance to instruct clients to use appropriate levels
of trust, on signed vs unsigned DNS, and/or DNS received over encrypted
transports.

I also think the guidance would be more precise if the encrypted transport
were not lumped together with the signed content.
Also something for a potential -bis or best practice document.

Brian


> On Wed, Aug 31, 2022 at 5:43 AM Martin Thomson  wrote:
>
>> On Wed, Aug 31, 2022, at 18:39, Brian Dickson wrote:
>> > One additional suggested addition to the end of section 3.1 is:
>> >>If DNS responses are cryptographically protected, and at least
>> >>one HTTPS AliasMode record has been received successfully,
>> >>clients MAY apply Section 9.5 (HSTS equivalent) restrictions
>> >>even when reverting to non-SVCB connection modes. Clients
>> >>also MAY treat resolution or connection failures subsequent
>> >>to the initial cryptographically protected AliasMode record
>> >>as fatal.
>> > [Brian's note: this last would provide some guidance to implementers of
>> > clients: a signed HTTPS AliasMode record is a strong signal that the
>> > DNS operator is discouraging fallback, albeit at a "MAY" level.]
>> >
>> > NB: The 2.4.3 change could be removed as it is mostly independent, as
>> > could the last addition to 3.1.
>> > The 1.2 change is very minor, is not too important but presents a
>> > succinct clarification on the hostname vs domain name thing.
>> > The 2.4.2 change and section 3 changes together are fixes for the
>> > prefix/no-prefix issue (which was basically a scrivener's error, and
>> > does not change the semantics at all.) They should stay or go as one
>> > unit.
>>
>> I somewhat like this change, but I would generalize to receiving any
>> signed HTTPS record during resolution, rather than limiting it to AliasMode.
>>
>> That said, it is somewhat gratuitous.  I'd want it standardized if that
>> was what was expected, but I'd prefer to defer that to an
>> extension/follow-up.
>>
>> (In case you hadn't guessed, I tend to agree with those arguing for no
>> change to the spec.)
>>
>> ___
>> 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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Doodle poll for DNSOP WG interim week 26-30 September 2022

[Benno Overeinder]

Dear DNSOP WG,

We are planning our second DNSOP WG interim meeting for 2022 in the week 
of 26-30 September.


The draft draft-ietf-dnsop-rfc8499bis is on the agenda for the interim 
meeting:

- https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/

Please fill in the Doodle poll to settle on a day and time:

- https://doodle.com/meeting/participate/id/e9QDWqBe

The options for the time slots are a compromise for CEST/EDT/PDT/JST.

We will close the Doodle poll at the end of Tuesday 6 September.


Best regards,

Suzanne, Tim and Benno

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

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Paul Hoffman]

Off-list:

> Can we "rescue" just the clarifications/corrections?

Yes, with an Internet Draft that would become an RFC later. Brian pretty much 
refuses to do this kind of thing, so you should consider doing it yourself.

--Paul

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Reminder OARC 39 - Call for Contribution

[Manu Bretelle]

*Reminder: Deadline for OARC 39 abstract submission - September 06, 23:59
UTC *

Please note that, we are looking for contributions and remote participation
is actively supported

---
OARC 39 will be a two-day hybrid meeting held on* 22 & 23 October in
Belgrade, Serbia *at 10:00 AM (Local time - CEST (UTC+02:00)) The onsite
part of the meeting will be *co-located with RIPE** 85.*

The Programme Committee is seeking contributions from the community.

All DNS-related subjects and suggestions for discussion topics are welcome.
For inspiration, we provide a non-exhaustive list of ideas:

- Operations: Any operational gotchas, lessons learned from an outage,
details/reasons for a recent outage (how to improve TTR, tooling).
- Deployment:  DNS config management and release process.
- Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly
detection.
- Scaling: DNS performance management and metrics. Increasing DNS Server
Efficiency
- Security/Privacy: DNSSEC signing and validation, key storage, rollovers,
qname minimization, DoH/DoT

*Note: OARC 39 will be a joint conference with CENTR and abstract
submissions from CENTR members are welcome.*

As it is a *hybrid *workshop, we'd like to encourage brevity; presentations
should not be longer than 20 minutes (with additional time for questions).

**Workshop Milestones:**

*2022-09-06Deadline for submission (23:59 UTC)*
2022-09-08Preliminary list of contributions published
2022-09-20Full agenda published
2022-10-03Deadline for slideset submission and Rehearsal
2022-10-22OARC 39 Workshop - Day1
2022-10-23OARC 39 Workshop - Day2

The Registration page and details for presentation submission are published
at:


To allow the Programme Committee to make objective assessments of
submissions, so as to ensure the quality of the workshop, submissions
SHOULD include slides. Draft slides are acceptable on submission.

Additional information for speakers at OARC 39:

* your talk will be broadcast live and recorded for future reference
* your presentation slides will be available for delegates and others to
download and refer to, before, during and after the meeting
* *Remote speakers have mandatory rehearsal on 2022-10-04 at 14:00 UTC. *It
would be very useful to have your slides (even if draft) ready for this.

*Note: DNS-OARC provides registration fee waivers for the workshop to
support those who are part of underrepresented groups to speak at and/or
attend DNS-OARC. More details will be provided when registration opens.*

If you have questions or concerns you can contact the Programme Committee:
https://www.dns-oarc.net/oarc/programme
via 

*Manu Bretelle, for the DNS-OARC Programme Committee*

OARC depends on sponsorship to fund its workshops and associated social
events.  Please contact  if your organization is
interested in becoming a sponsor.

(Please note that OARC is run on a non-profit basis, and is not in a
position to reimburse expenses or time for speakers at its meetings.)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Viktor Dukhovni]

On Wed, Aug 31, 2022 at 01:39:32AM -0700, Brian Dickson wrote:

> Here are some proposed text changes, per Warren's invitation to send text:
> 
> In section 1.2, change:
> 
> 2.  TargetName: The domain name of either the alias target (for
>AliasMode) or the alternative endpoint (for ServiceMode).
> 
> to:
> 
> 2.  TargetName: Either the domain name of the alias target (for
> AliasMode) or the host name of the alternative endpoint (for ServiceMode).

This looks correct.  The alternative target name needs to be a valid
hostname.

> In section 2.4.2, change:
> 
>As legacy clients will not know to use this record, service operators
>will likely need to retain fallback  and A records alongside this
>SVCB record, [... unchanged ...]
> 
> to:
> 
>As legacy clients will not know to use this record, service operators
>will likely need to retain fallback  and A records at the service name,
>[... unchanged ...]

This is correct, because in the presence of one or more AliasMode
records the ServiceMode record is no longer "alongside" the A/
records.

> In section 2.4.3, change:
> 
>In ServiceMode, the TargetName and SvcParams within each resource
>record associate an alternative endpoint for the service with its
>connection parameters.
> 
> to:
> 
>In ServiceMode, the TargetName and SvcParams within each resource
>record associate an alternative endpoint for the service with its
>connection parameters. The TargetName MUST be a host name
>(as defined in [DNSTerm].)

This is basic conformance with RFC 1123 section 2, avoids
interoperability issues with proxies, and various software that
validates hostnames in applications and DNS resolvers.  Otherwise, this
document may need to update RFC 1123, relaxing the syntax rules for
hostnames.

> In section 3, the following changes are proposed; they introduce a new term
> LASTNAME to be used to disambiguate the $QNAME reference so as to remove
> ATTRLEAF prefixes from the appended target:
> 
> 
>1.  Let $QNAME be the service name plus appropriate prefixes for the
>scheme (see Section 2.3).
> 
> becomes:
> 
>1.  Let $QNAME be the service name plus appropriate prefixes for the
>scheme (see Section 2.3). Let $LASTNAME be the service name without
>any prefixes.
> 
> 
>3.  If an AliasMode SVCB record is returned for $QNAME (after
>following CNAMEs as normal), set $QNAME to its TargetName
>(without additional prefixes) and loop back to step 2, subject
>to chain length limits and loop detection heuristics (see
>Section 3.1).
> 
> becomes:
> 
>3.  If an AliasMode SVCB record is returned for $QNAME (after
>following CNAMEs as normal), set $QNAME to its TargetName
>(without additional prefixes), set $LASTNAME to this new $QNAME
>and loop back to step 2, subject to chain length limits and
>loop detection heuristics (see Section 3.1).
> 
> 
>Once SVCB resolution has concluded, whether successful or not, SVCB-
>optional clients SHALL append to the priority list an endpoint
>consisting of the final value of $QNAME, the authority endpoint's
>port number, and no SvcParams.  (This endpoint will be attempted
>before falling back to non-SVCB connection modes.  This ensures that
>SVCB-optional clients will make use of an AliasMode record whose
>TargetName has A and/or  records but no SVCB records.)
> 
> becomes:
> 
>Once SVCB resolution has concluded, whether successful or not, SVCB-
>optional clients SHALL append to the priority list an endpoint
>consisting of the final value of $LASTNAME, the authority endpoint's
>port number, and no SvcParams.  (This endpoint will be attempted
>before falling back to non-SVCB connection modes.  This ensures that
>SVCB-optional clients will make use of an AliasMode record whose
>TargetName has A and/or  records but no SVCB records.)
> 

This scary-looking long edit is an attempted bug correction.  But Ben
tells me that the actual intent is to only add $QNAME to the search list
if there's a non-zero number of AliasMode records encountered.
Otherwise, there is no need to append any $QNAME to the list, since it
is the same as the legacy fallback (non-SVCB connection modes below).

A simpler fix should be possible.

>If the client is SVCB-optional, and connecting using this list of
>endpoints has failed, the client now attempts to use non-SVCB
>connection modes.
> 
> becomes:
> 
>If the client is SVCB-optional, and connecting using this list of
>endpoints has failed, the client MAY attempt to use non-SVCB
>connection modes, using the origin name (without prefixes),
> 
>the authority endpoint's port number, and no SvcParams.

And then this change likely becomes redundant.

> One additional suggested addition to the end of section 3.1 is:
> 
>If DNS responses are cryptographically protected, and 

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Warren Kumari]

On Wed, Aug 31, 2022 at 4:39 AM, Brian Dickson <
brian.peter.dick...@gmail.com> wrote:

> Here are some proposed text changes, per Warren's invitation to send text:
>


Um, no.  Warren said: "can we craft a sentence (or possibly two) which only
clarify what is already written?". This is a significantly larger set of
changes than that. The Section 3 changes in particular are (IMO) much more
than a clarification.

These may or may not be good changes, but anything approaching that level
of change would have to be in a -bis document…

W



> In section 1.2, change:
>
> 2.  TargetName: The domain name of either the alias target (for
>AliasMode) or the alternative endpoint (for ServiceMode).
>
> to:
>
> 2.  TargetName: Either the domain name of the alias target (for
>AliasMode) or the host name of the alternative endpoint (for
> ServiceMode).
>
> In section 2.4.2, change:
>
>As legacy clients will not know to use this record, service operators
>will likely need to retain fallback  and A records alongside this
>SVCB record, although in a common case the target of the SVCB record
>might offer better performance, and therefore would be preferable for
>clients implementing this specification to use.
>
> to:
>
>As legacy clients will not know to use this record, service operators
>will likely need to retain fallback  and A records at the service
> name,
>although in a common case the target of the SVCB record
>might offer better performance, and therefore would be preferable for
>clients implementing this specification to use.
>
>
> In section 2.4.3, change:
>
>In ServiceMode, the TargetName and SvcParams within each resource
>record associate an alternative endpoint for the service with its
>connection parameters.
>
> to:
>
>In ServiceMode, the TargetName and SvcParams within each resource
>record associate an alternative endpoint for the service with its
>connection parameters. The TargetName MUST be a host name
>(as defined in [DNSTerm].)
>
> In section 3, the following changes are proposed; they introduce a new
> term LASTNAME to be used to disambiguate the $QNAME reference so as to
> remove ATTRLEAF prefixes from the appended target:
>
>
>1.  Let $QNAME be the service name plus appropriate prefixes for the
>scheme (see Section 2.3).
>
> becomes:
>
>1.  Let $QNAME be the service name plus appropriate prefixes for the
>scheme (see Section 2.3). Let $LASTNAME be the service name without
> any prefixes.
>
>
>
>3.  If an AliasMode SVCB record is returned for $QNAME (after
>following CNAMEs as normal), set $QNAME to its TargetName
>(without additional prefixes) and loop back to step 2, subject to
>chain length limits and loop detection heuristics (see
>Section 3.1).
>
> becomes:
>
>3.  If an AliasMode SVCB record is returned for $QNAME (after
>following CNAMEs as normal), set $QNAME to its TargetName
>(without additional prefixes), set $LASTNAME to this new $QNAME and
> loop back to step 2, subject to
>chain length limits and loop detection heuristics (see
>Section 3.1).
>
>
>Once SVCB resolution has concluded, whether successful or not, SVCB-
>optional clients SHALL append to the priority list an endpoint
>consisting of the final value of $QNAME, the authority endpoint's
>port number, and no SvcParams.  (This endpoint will be attempted
>before falling back to non-SVCB connection modes.  This ensures that
>SVCB-optional clients will make use of an AliasMode record whose
>TargetName has A and/or  records but no SVCB records.)
>
> becomes:
>
>Once SVCB resolution has concluded, whether successful or not, SVCB-
>optional clients SHALL append to the priority list an endpoint
>consisting of the final value of $LASTNAME, the authority endpoint's
>port number, and no SvcParams.  (This endpoint will be attempted
>before falling back to non-SVCB connection modes.  This ensures that
>SVCB-optional clients will make use of an AliasMode record whose
>TargetName has A and/or  records but no SVCB records.)
>
>If the client is SVCB-optional, and connecting using this list of
>endpoints has failed, the client now attempts to use non-SVCB
>connection modes.
>
> becomes:
>
>If the client is SVCB-optional, and connecting using this list of
>endpoints has failed, the client MAY attempt to use non-SVCB
>connection modes, using the origin name (without prefixes),
>
>the authority endpoint's port number, and no SvcParams.
>
>
> One additional suggested addition to the end of section 3.1 is:
>
>If DNS responses are cryptographically protected, and at least
>one HTTPS AliasMode record has been received successfully,
>clients MAY apply Section 9.5 (HSTS equivalent) restrictions
>even when reverting to non-SVCB connection modes. Clients
>
>also MAY 

[DNSOP] HSTS on receiving a signed HTTPS record (was: Questions / concerns with draft-ietf-dnsop-svcb-https ...)

[Martin Thomson]

On Wed, Aug 31, 2022, at 18:39, Brian Dickson wrote:
> One additional suggested addition to the end of section 3.1 is:
>>If DNS responses are cryptographically protected, and at least
>>one HTTPS AliasMode record has been received successfully,
>>clients MAY apply Section 9.5 (HSTS equivalent) restrictions
>>even when reverting to non-SVCB connection modes. Clients
>>also MAY treat resolution or connection failures subsequent
>>to the initial cryptographically protected AliasMode record
>>as fatal.
> [Brian's note: this last would provide some guidance to implementers of 
> clients: a signed HTTPS AliasMode record is a strong signal that the 
> DNS operator is discouraging fallback, albeit at a "MAY" level.]
>
> NB: The 2.4.3 change could be removed as it is mostly independent, as 
> could the last addition to 3.1. 
> The 1.2 change is very minor, is not too important but presents a 
> succinct clarification on the hostname vs domain name thing.
> The 2.4.2 change and section 3 changes together are fixes for the 
> prefix/no-prefix issue (which was basically a scrivener's error, and 
> does not change the semantics at all.) They should stay or go as one 
> unit.

I somewhat like this change, but I would generalize to receiving any signed 
HTTPS record during resolution, rather than limiting it to AliasMode.

That said, it is somewhat gratuitous.  I'd want it standardized if that was 
what was expected, but I'd prefer to defer that to an extension/follow-up.

(In case you hadn't guessed, I tend to agree with those arguing for no change 
to the spec.)

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

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

Here are some proposed text changes, per Warren's invitation to send text:

In section 1.2, change:

2.  TargetName: The domain name of either the alias target (for
   AliasMode) or the alternative endpoint (for ServiceMode).

to:

2.  TargetName: Either the domain name of the alias target (for
   AliasMode) or the host name of the alternative endpoint (for
ServiceMode).

In section 2.4.2, change:

   As legacy clients will not know to use this record, service operators
   will likely need to retain fallback  and A records alongside this
   SVCB record, although in a common case the target of the SVCB record
   might offer better performance, and therefore would be preferable for
   clients implementing this specification to use.

to:

   As legacy clients will not know to use this record, service operators
   will likely need to retain fallback  and A records at the service
name,
   although in a common case the target of the SVCB record
   might offer better performance, and therefore would be preferable for
   clients implementing this specification to use.


In section 2.4.3, change:

   In ServiceMode, the TargetName and SvcParams within each resource
   record associate an alternative endpoint for the service with its
   connection parameters.

to:

   In ServiceMode, the TargetName and SvcParams within each resource
   record associate an alternative endpoint for the service with its
   connection parameters. The TargetName MUST be a host name
   (as defined in [DNSTerm].)

In section 3, the following changes are proposed; they introduce a new term
LASTNAME to be used to disambiguate the $QNAME reference so as to remove
ATTRLEAF prefixes from the appended target:


   1.  Let $QNAME be the service name plus appropriate prefixes for the
   scheme (see Section 2.3).

becomes:

   1.  Let $QNAME be the service name plus appropriate prefixes for the
   scheme (see Section 2.3). Let $LASTNAME be the service name without
any prefixes.



   3.  If an AliasMode SVCB record is returned for $QNAME (after
   following CNAMEs as normal), set $QNAME to its TargetName
   (without additional prefixes) and loop back to step 2, subject to
   chain length limits and loop detection heuristics (see
   Section 3.1).

becomes:

   3.  If an AliasMode SVCB record is returned for $QNAME (after
   following CNAMEs as normal), set $QNAME to its TargetName
   (without additional prefixes), set $LASTNAME to this new $QNAME and
loop back to step 2, subject to
   chain length limits and loop detection heuristics (see
   Section 3.1).


   Once SVCB resolution has concluded, whether successful or not, SVCB-
   optional clients SHALL append to the priority list an endpoint
   consisting of the final value of $QNAME, the authority endpoint's
   port number, and no SvcParams.  (This endpoint will be attempted
   before falling back to non-SVCB connection modes.  This ensures that
   SVCB-optional clients will make use of an AliasMode record whose
   TargetName has A and/or  records but no SVCB records.)

becomes:

   Once SVCB resolution has concluded, whether successful or not, SVCB-
   optional clients SHALL append to the priority list an endpoint
   consisting of the final value of $LASTNAME, the authority endpoint's
   port number, and no SvcParams.  (This endpoint will be attempted
   before falling back to non-SVCB connection modes.  This ensures that
   SVCB-optional clients will make use of an AliasMode record whose
   TargetName has A and/or  records but no SVCB records.)

   If the client is SVCB-optional, and connecting using this list of
   endpoints has failed, the client now attempts to use non-SVCB
   connection modes.

becomes:

   If the client is SVCB-optional, and connecting using this list of
   endpoints has failed, the client MAY attempt to use non-SVCB
   connection modes, using the origin name (without prefixes),

   the authority endpoint's port number, and no SvcParams.


One additional suggested addition to the end of section 3.1 is:

   If DNS responses are cryptographically protected, and at least
   one HTTPS AliasMode record has been received successfully,
   clients MAY apply Section 9.5 (HSTS equivalent) restrictions
   even when reverting to non-SVCB connection modes. Clients

   also MAY treat resolution or connection failures subsequent

   to the initial cryptographically protected AliasMode record

   as fatal.

[Brian's note: this last would provide some guidance to implementers of
clients: a signed HTTPS AliasMode record is a strong signal that the DNS
operator is discouraging fallback, albeit at a "MAY" level.]

NB: The 2.4.3 change could be removed as it is mostly independent, as could
the last addition to 3.1.
The 1.2 change is very minor, is not too important but presents a succinct
clarification on the hostname vs domain name thing.
The 2.4.2 change and section 3 changes together are fixes for the
prefix/no-prefix issue 

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-06.txt

[Murray S. Kucherawy]

Howdy,

On Thu, Aug 25, 2022 at 8:08 AM  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   : DNS Glue Requirements in Referral Responses
> Authors : M. Andrews
>   Shumon Huque
>   Paul Wouters
>   Duane Wessels
>   Filename: draft-ietf-dnsop-glue-is-not-optional-06.txt
>   Pages   : 12
>   Date: 2022-08-25
>
> Abstract:
>The DNS uses glue records to allow iterative clients to find the
>addresses of name servers that are contained within a delegated zone.
>Authoritative Servers are expected to return all available glue
>records for in-domain name servers in a referral response.  If
>message size constraints prevent the inclusion of all glue records
>for in-domain name servers, the server MUST set the TC flag to inform
>the client that the response is incomplete, and that the client
>SHOULD use another transport to retrieve the full response.  This
>document updates RFC 1034 to clarify correct server behavior.
>
> [...]
>

Section 1.1 needs to use the updated BCP 14 boilerplate.  See RFC 8174.

Section 3.2 uses "NOT REQUIRED", but this isn't BCP 14 language.  I'm not
sure what the fix is here.  Should that be a SHOULD or MAY?

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