As another top-level comment on this draft:
For at least some operators, deploying safely will also require having a
way for clients to signal which SVCB record was used. For example, load
reporting, debugging/diagnostics, and other operational use-cases would
need to know whether the background
Agreed that this is an area we should improve the wording on.
I think the intent is:
* within a resource record in the RRset, concatenate the
s to obtain the TXT-DATA and treat that as a "domain
validation string"
* individual resource records are independent domain validation strings.
The change
t;
>
> Thoughts?
>
> tim
>
>
> On Mon, Jul 7, 2025 at 3:28 PM wrote:
>
>> Internet-Draft draft-ietf-dnsop-domain-verification-techniques-09.txt is
>> now
>> available. It is a work item of the Domain Name System Operations (DNSOP)
>> WG
>> of the IETF.
There are two cases here:
1) Accidental retention of zone contents (this seems unlikely, but worth
mentioning)
2) Malicious reintroduction of zone contents (this is the concern we need
to make sure is well-addressed, and is one of the reasons it is critical
that validations are tied to users/accou
mitigation for failures to comply with requirement #3.
> * To obfuscate certain vendor-specific identifiers.
> * To guard against entries accidentally placed in the wrong zone.
> * etc.
>
> --Ben
>
> --
> *From:* John R Levine
> *Sent:* Sunday, Ju
> This is an OK start, but it would be better if the draft covered the
actual security issues (on-path attackers) and dealt with time more
carefully.
Good point. I've proposed some text on this as part of my PR:
https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/comm
Following this discussion, I've taken a pass at proposing some updates to
clarify the "purpose"
of domain validation (as suggested by Ben in PR #160 although I started
with a new take on it)
as well as to clarify the difference between one-off validation and
persistent validation.
See:
https://git
I've been thinking about this a bunch, and I think DCV is not necessarily
one-time and the current focus on that is counter-productive. Instead we
should be describing what properties are present due to the persistence of
a DCV entry, especially since it is public once entered into the DNS. This
I agree with Paul W here. I don't think there's disagreement between the
authors, and I believe that
it is important to cover\ the *current* practices where assumptions about
persistence are being made.
If we go back to the examples that were in an appendix of earlier versions
of this draft some o
There's an extensive discussion in
https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/pull/160
on the purpose and nature of DCV which seems more appropriate to bring to
the list rather than keep in github.
A few fundamental parts of this seem to be:
1) Is DCV just po
>From the server operator side, I feel strongly that the multi-CDN example
should show a selected CDN setup not a merged CDN setup.
The "Automation is required to keep these records consistent with the
original records in the CDN providers' zones." mentioned
in the current example is outside of the
I also opened https://github.com/tlswg/draft-ietf-tls-svcb-ech/issues/17 to
add examples there.
Erik
On Sun, Oct 6, 2024 at 10:36 AM Erik Nygren wrote:
> There's nothing prohibiting this in RFC 9460 and there may be reasonable
> operational use-cases for this,
> but operat
There's nothing prohibiting this in RFC 9460 and there may be reasonable
operational use-cases for this,
but operationally if you do it that way then all servers in the TargetName
need to support the ech value.
If they don't, then this would be a misconfiguration.
If you have different pools of se
On Fri, Oct 4, 2024 at 3:48 PM Salz, Rich wrote:
> This is explicitly prohibited rfc9460 as it would provide linkability.
>
>
>
> So what? We’re not the protocol police and if someone wants to track,
> RFC9460 compliance isn’t going to stop them. Especially for something as
> controversial as EC
On Fri, Oct 4, 2024 at 3:20 PM Stephen Farrell
wrote:
>
> On 10/4/24 19:30, Paul Wouters wrote:
> > Which makes me wonder if it makes sense to advise long TTLs on these
> > records so that they move along on your phone/laptop even if you enter
> > these kind of networks.
>
> There's a tension bet
ver name or information about it by
observing traffic to DNS authorities [rfc9076].
On Fri, Oct 4, 2024 at 3:06 PM Erik Nygren wrote:
> The suggested text seems inoffensive to me as well, but we may also want
> to expand it to cover the recursive-to-authoritative path for resolvers
> as
The suggested text seems inoffensive to me as well, but we may also want to
expand it to cover the recursive-to-authoritative path for resolvers
associated with the client. (ie, just using DoH to your home router isn't
going to help when it uses Do53 to the authorities.).
On the topic of DNSSEC,
On Wed, Jul 24, 2024 at 10:18 AM Shumon Huque wrote:
>
> On your last point, yes, I think we can say that if a verifier sees
> multiple
> validation records, they can abort.
>
>
I'd think it would be better to allow looking at the full RRset and
succeeding if any of the records match?
This seems
I think mTLS (client certs) makes sense as a recommendation in
draft-tjjk-cared, but is critical to call out the privacy issues with TLS
client certs in TLS versions prior to TLS 1.3. (ie, in TLS 1.2 and before
the client certificates are sent in-the-clear in the handshake unless
renegotiation is
Thank you for writing this up! I think this is long-overdue
and I'd be supportive of the dnsop working group adopting this.
(It seems to make more sense for me to do this in dnsop while keeping v6ops
informed.)
We likely will want to cover the concerns that Geoff raises around
fragmentation,
but
It does seem like it would be good to document the "Authoritative Forwarding
Proxy" use-case as it is more common. There are a number of commercial
services doing this now, both for performance, DDoS defense, and other
use-cases.
An important thing we really should define is safeguards for loop
pr
Hello,
Thank you for pulling together this draft! Having worked on related
systems a number of times it will be valuable to have something here
standardized.
A number of comments and suggestions:
1) APEX domains, and hostnames vs domains
You define APEX but don't then reference this. This is
ocess.
Best, Erik
On Thu, Sep 29, 2022 at 9:16 AM Erik Nygren wrote:
> One item discussed above that the authors would like to clarify is to be
> consistent
> about whether the alternative endpoint name (TargetName) is a hostname
> or a domain name. In all but one place in the d
tances[0].
>
> W
>
> [0]: I'm not convinced that this situation rose to the "exceptional
> circumstances" bar, but seeing as I'd already paused it (not knowing what
> all the issues were) and because the changes are clarifications, I'm
> willing to acceptin
There seem to be two topics:
1) Victor's clarification makes sense, although the wording is a little
awkward and perhaps we can improve that sentence.
The section was already implying that meaning (ie, that the fallback
addition of the QNAME was for the AliasMode case)
but clarifying this
Catching up on this thread, I agree with Ben Schwartz, Tommy Pauly, and
Eric Orth
that the current behavior makes sense and that no fundamental technical
change is needed.
No matter what we do, odd faults and misconfigurations will happen and
Postel's law applies.
Client implementers will try and b
I think Expert Review makes sense (with the expert reviewing the SHOULD
around the specification).
On Tue, Mar 22, 2022 at 8:34 PM Martin Thomson wrote:
> I agree with Tommy.
>
> Selecting an expert who is able to recognize when wider review might help
> is a far lower bar than the one Ray sugge
On Wed, May 19, 2021 at 7:01 PM Brian Dickson
wrote:
>
>
> On Wed, May 19, 2021 at 3:00 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> On Wed, May 19, 2021 at 2:50 PM Paul Hoffman
>> wrote:
>>
>>> Are these still just idle ideas you are tossing out (as you indicated
>>> ea
On Wed, May 19, 2021 at 5:12 PM Tommy Pauly wrote:
>
>
> On May 19, 2021, at 1:34 PM, Brian Dickson
> wrote:
>
>
>
> On Wed, May 19, 2021 at 7:49 AM Tommy Pauly wrote:
>
>> I wanted to chime in on this discussion as a client-side implementor who
>> has already widely deployed support for SVCB/H
On Mon, May 17, 2021 at 5:36 PM Ben Schwartz wrote:
>
>
> On Sat, May 15, 2021 at 12:48 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> On Thu, May 13, 2021 at 10:25 AM Ben Schwartz wrote:
>>
>>>
>>>
>>> On Thu, May 13, 2021 at 12:51 AM Brian Dickson <
>>> brian.peter.dick.
On Wed, May 12, 2021 at 4:44 PM Brian Dickson
wrote:
>
> Having multiple AliasMode records within an RRset (with either the same or
> different Priority) would provide an avenue for dealing with resolution
> failure - which is one of the main reasons for any CDN customer to use
> multiple CDNs, i
We have a very incomplete list of work-in-progress SVCB/HTTPS RR
implementations here
for people who wish to do interop testing:
https://github.com/MikeBishop/dns-alt-svc/blob/master/svcb-implementations.md
Feel free to submit PRs to add to that list. At some point we may convert
it to something
er to avoid future ones needing to be artificially constrained. Is
there a reason we'd
want to decrease this (eg, to 31)?
On Wed, Jul 15, 2020 at 1:07 PM Ólafur Guðmundsson
wrote:
> How about 2 or 10 ?
> why do the names to need to be long ?
>
> Olafur
>
>
> On Thu, Jul
Would this be better as a SHOULD NOT? Or just better to remove this,
or replace with non-normative txt?
Opened: https://github.com/MikeBishop/dns-alt-svc/issues/221
On Mon, Jul 13, 2020 at 8:03 PM Mark Andrews wrote:
> Section 2.4.1. AliasMode paragraph 2. Why have "MUST NOT" here?
>
>
>T
Or 64?
- Erik
[Sent from my IPv6 connected T-Mobile 4G LTE mobile device]
On Thu, Jul 9, 2020, 9:40 PM Ben Schwartz wrote:
> How about 255 characters?
>
> On Thu, Jul 9, 2020 at 9:25 PM Mark Andrews wrote:
>
>> Can we please have a length limit on key names? At the moment they could
>
As discussed in a previous thread, we've renamed the HTTPSSVC RR to be the
"HTTPS" RR.
The SVCB RR is keeping its name.
A new version of the draft has been published with this change as well as
with other changes:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/
(We separated the
balancing information in a IP
>> constrained
>> > space. Just like the address is distinct from the URL, the port
>> separates
>> > the 'what' from the 'how' and that's good.
>>
>> your reply above precisely demonstrates the risk o
On Mon, Mar 9, 2020 at 10:32 PM Paul Vixie wrote:
> On Monday, 9 March 2020 20:56:39 UTC Ben Schwartz wrote:
> > It occurs to me that I hit "publish" on this draft without updating the
> > release notes, so I'll mention some of the many changes since -01 here
> > instead:
> >
> > ...
> >
> > As
On Wed, Feb 26, 2020 at 2:34 PM Lanlan Pan wrote:
> My option:
> 1) ANAME just configured in zonefile, and anlayzed by authoritative server.
> 2) Authoritative server response to recursive (or resolver) on its policy
> as before, such as geo-ip, GSLB, ...
> 3) No upgrade on recursive and resolve
On Fri, Feb 21, 2020 at 9:53 AM Vladimír Čunát
wrote:
> In this case however, I personally believe it's much better design *not*
> to put the link-following work on authoritative servers (or their
> provisioning) but further down the chain (resolvers and/or clients).
> Well, I suppose I don't rea
Good idea. Created a PR:
https://github.com/MikeBishop/dns-alt-svc/pull/110
But yes, we're actively working through issues on SVCB with the hope of
publishing
a new version shortly, and would certainly like to discuss in Vancouver.
Erik
On Wed, Feb 19, 2020 at 4:13 PM Warren Kumari wrote:
It is time to finalize names for HTTPSSVC and SVCB. Following a thread on
the DNSOP list that Tommy started, I created a poll incorporating some of
the ideas. After we get some feedback here, the WG chairs and authors will
pick a set to propose and see if we can get consensus. Here is a poll to
f
Some of my current leanings:
SVCB and HTTPB (SVCB and HTTPSB)
Of even shorter: "SB" and "HSB"
(I also prefer SVCHTTPS over HTTPSSVC as the latter is way too easy to
leave out one of the S's.)
I'd considered just calling "SVCB" as "B" but that makes it harder to
search for.
This is also why "H
- Forwarded message -
From:
Date: Mon, Sep 23, 2019 at 7:01 PM
Subject: New Version Notification for
draft-nygren-dnsop-svcb-httpssvc-00.txt
To: Mike Bishop , Erik Nygren ,
Benjamin Schwartz
A new version of I-D, draft-nygren-dnsop-svcb-httpssvc-00.txt
has been successfully submit
The device could also have an IPv6 interface via a tunnel or VPN client.
- Erik
[Sent from my IPv6 connected T-Mobile 4G LTE mobile device]
On Thu, Aug 29, 2019, 5:44 AM Naveen Kottapalli
wrote:
> My query was about the behavior we observed on a gateway where a pure v4
> subscriber (no
The need to bootstrap ESNI (encrypted SNI) keys via DNS is the forcing
function here for clients. They need to do something new here to address
that, and if that requires an additional lookup then there is opportunity
if other problems can be solved at the same time as long as we don't slow
down E
meservers, but also ones that effectively have
to be resolvers in-order to do inline sibling record resolution (and
caching)
and sending ECS.
Erik
On Mon, Jul 15, 2019 at 4:56 AM Matthijs Mekking
wrote:
> Hi Erik,
>
> Thanks for sharing this perspective.
>
> On 7/12/19 7:
One of the intended goals of ANAME is to improve interoperability of
onboarding onto CDNs for URLs at a zone apex, such as “http(s)://example.com
”.
The TL;DR is that ANAME is unlikely to allow interoperability here unless
authorities are willing to effectively and scalablely do recursion-with-ECS
ise, I think many of us would very much love to see this
> implemented, as much of ANAME is fundamentally incapable of meeting the
> intended goals, which this does very nicely.
>
> Brian
>
> On Mon, Jul 8, 2019 at 2:20 PM Erik Nygren wrote:
>
>> Ray, thanks for i
2019 18:46:25 +
> Resent-From:ietf-http...@w3.org
> Date: Wed, 3 Jul 2019 14:45:47 -0400
> From: Erik Nygren
> To: ietf-http...@w3.org Group , Mike Bishop
> , Erik Nygren , Benjamin
> Schwartz , Erik Nygren - Work
>
>
>
>
> Ben, Mike, and I have s
Some comments:
* We should define what TLS SNI value gets sent. Perhaps the first value
of "domain-to-match" when present, but preferably the hostname of the URL
when it's not an IP?
* Should clients consider the templates list to be ordered or unordered?
We may wish to define the behavior for h
How does draft-schwartz-httpbis-dns-alt-svc-02 with some changes to make it
more DNS-aligned (e.g. the name as a separate field in the record) not help
here? It comes from the HTTP world and is aligned with the existing AltSvc
feature and thus is useful in other ways (such as perhaps solving the D
On Thu, Nov 1, 2018 at 6:34 PM Brian Dickson
wrote:
> ...
>
> Third, there is an issue with the impact to anycast operation of zones
> with ANAMEs, with respect to differentiated answers, based on topological
> locations of anycast instances.
>
> There is currently an expectation on resolving a g
On Tue, Jun 19, 2018 at 11:24 AM, Ray Bellis wrote:
> On 19/06/2018 15:43, tjw ietf wrote:
>
> > I find it personally appalling we can spend so many cycles injecting
> > dns into http but we can’t be bothered to fix what end users want.
>
> It's the HTTP folks that are putting most of those cycle
On Fri, Jun 15, 2018 at 8:12 PM, Shumon Huque wrote:
> On Fri, Jun 15, 2018 at 6:40 PM Mark Andrews wrote:
>
>> What we should be asking is why a service that needs multiple machines
>> isn’t using SRV. It has randomisation between servers explicitly defined
>> along with proportional load balan
On Fri, Jun 15, 2018 at 3:52 PM, Mukund Sivaraman wrote:
> On Fri, Jun 15, 2018 at 02:38:00PM -0400, Bob Harold wrote:
> > Round-robin is a documented feature that many applications use. Removing
> > it from DNS resolvers, and then having to add it to a much larger number
> of
> > applications,
A number of folks have been bitten by a bug in bind 9.12 where it silently
changes the default sorting of rrsets to always be sorted (even if the
authoritative response wasn't sorted). This causes problems for services
assuming at least some degree of round-robin behavior by clients as now
many cl
On Mon, Aug 7, 2017 at 4:41 AM, Mike West wrote:
>
> I poked at the draft a bit over the weekend, reworking it into a
> stand-alone document in https://tools.ietf.org/
> html/draft-west-let-localhost-be-localhost-04. I think it ends up being
> clearer overall, and hopefully y'all agree.
>
This
I wrote a similar draft a few years ago which I've been considering
resurrecting if there is interest:
https://tools.ietf.org/html/draft-nygren-service-bindings-00
One of the big challenges that at least in the web context, browsers want
to make as few DNS lookups as possible prior to making
59 matches
Mail list logo
