h the message size
> constraints in LLNs, it might thus be necessary to prune the DNS message
> for records actually useful to the querying DoC client.
>
> Lastly, mind, that, at least in our model for DoC, a DoC client does not
> further distribute the information it gathered via DoC
or
> actually new normative text that replaces or updates text from the
> dependency. Don’t do that.
>
> Examples can be put into their own section and clearly marked as such.
>
> Grüße, Carsten
>
> Sent from mobile, sorry for terse
>
> On 20. Sep 2022, at 17:12, Ben Schwartz
>
hich a stub resolver will chase a
CNAME chain. That is always the recursive resolver's job.
On Mon, Oct 24, 2022 at 2:25 PM Martine Sophie Lenders <
m.lend...@fu-berlin.de> wrote:
> Hi!
>
> Am 21.09.22 um 21:31 schrieb Ben Schwartz:
> > Preparing a separate document on com
I think it would be helpful if this document were more explicit about its
motivation. In my view, the underlying motivation for this draft is to enable
seamless management of DNS service within a CoAP-centered deployment, by
sharing key distribution, access controls, monitoring, etc. The draft
On 6/28/23, 10:24 AM, "Martine Sophie Lenders" wrote:
Hi Ben,
On 23.06.23 22:23, Ben Schwartz wrote:
> I think it would be helpful if this document were more explicit about
> its motivation. In my view, the underlying motivation for this draft is
> to enable seamless manage
I think firmware size is a perfectly reasonable and sufficient motivation for
this draft, but I don't think it can be described as "performance".
--Ben Schwartz
From: Christian Amsüss
Sent: Wednesday, July 5, 2023 12:17 PM
To: Ben Schwartz
Cc:
I agree with DKG's analysis.
Also, as an implementor, I think this requirement would be onerous. In the
software I am modifying, implementing DNS-over-TLS is dramatically easier
than adding a validating stub resolver. I wouldn't be implementing
DNS-over-TLS if DNSSEC were mandatory (in either mo
I'm glad this is coming to DPRIVE.
My main question for the authors is: how does this compare to routing a
DNS-over-TLS socket through a TCP forwarder? It seems to me that a TCP
forwarder (operated by a separate party from the DNS-over-TLS recursive)
would offer a similar level of privacy protect
On Sat, Jul 14, 2018 at 8:30 PM Stephane Bortzmeyer
wrote:
> On Tue, Jul 03, 2018 at 06:18:51PM -0400,
> Ben Schwartz wrote
> a message of 293 lines which said:
>
> > My main question for the authors is: how does this compare to
> > routing a DNS-over-TLS socket
Feamster
wrote:
>
>
> > On Jul 14, 2018, at 9:43 PM, Ben Schwartz 40google@dmarc.ietf.org> wrote:
> >
> > For the record, I'm proposing something much _weaker_ than Tor: a TCP
> packet forwarder relaying a DNS-over-TLS stream. It seems to me that this
> ma
Thanks for writing this up. Your recommendation makes sense to me, and I
think it will be useful in practice.
One thought: instead of rejecting unsafe 0-RTT data with FormErr, could we
tell servers to reject the early data at the TLS layer to force a
retransmission? That seems like it might be s
On Tue, Aug 20, 2019 at 9:39 AM Henderson, Karl
wrote:
> Hi Ben and Hugo,
>
>
>
> I wanted to follow up and see if my response to Paul satisfies your
> concerns regarding ADoT being a new unspecified protocol?
>
>
>
> To be clear, we argue that ADoT is NOT a new protocol. ADoT is simply DoT
> wit
On Wed, Oct 30, 2019 at 2:37 AM Watson Ladd wrote:
>
> The root zone is data: whether one distributes it via DoT, DoH, IPv6, or
> carrier pigeon is irrelevant to the policies that goven what's in it.
>
That is arguably true, but I think we are having this discussion primarily
because of RFC 4035
; Hello Ben,
>
> On Tue, 2020-05-26 at 21:27 -0400, Ben Schwartz wrote:
>
> I like the idea of signalling DoT support in the DS record, but I worry a
> bit about putting the SPKI fingerprint in the DS as well. Having to update
> the parent zone whenever the TLSA key needs to be r
I think opportunistic or unauthenticated encryption is worth pursuing.
However, your quote also says "use authentication when possible", and I
agree. I would like to avoid selecting an opportunistic encryption design
that doesn't match well with our authenticated encryption design, so I
think that
On Tue, Sep 8, 2020 at 7:26 AM Neil Cook wrote:
> Thanks for reviewing! Some responses inline,
>
> Neil
>
> On 28 Aug 2020, at 15:41, Ben Schwartz wrote:
>
> Some commentary on this draft:
>
> Section 3 proposes that there is an apparent inconsistency within RFC 8484
On Wed, Sep 9, 2020 at 11:31 AM Neil Cook wrote:
>
>
> On 9 Sep 2020, at 15:35, Ben Schwartz
> wrote:
>
>>
>>
>>1. Caching at the CPE reduces upstream resolver load by quite a lot
>>more than you might imagine not actually a big problem but it’
On Mon, Feb 15, 2021 at 5:25 PM Paul Hoffman wrote:
...
> I propose a way forward: make the two protocols obviously different so
> that they don't affect each other. For those who want opportunistic
> ADoT(Q), change the current design so that deploying it would not make
> creating and deploying
On Tue, Mar 23, 2021 at 12:23 PM Jim Reid wrote:
> It doesn’t seem right to allow a TLD operator to tell someone what DoH
> server(s) to use/not use to resolve $tld's names.
I think there's a miscommunication here. The proposals here are about
how a TLD operator can tell a **recursive resolver
Yes, the "dot" ALPN came well after RFC 7858 was published, so most of the
early implementations don't send it.
On Tue, May 4, 2021 at 9:33 PM Erik Kline wrote:
> When I went to go find where the "dot" ALPN came from I couldn't find it
> easily.
>
> The IANA registry said 7858, but when we did D
On Fri, Jul 30, 2021 at 12:11 PM Shane Kerr
wrote:
...
> This can't store out-of-bailiwick data, which means we can't secure an
> arbitrary NS RRset this way. Converting DNSName from "prefix" to just
> "name" would allow that.
>
Actually I think it can, but I confused the issue with a mistake be
On Tue, Aug 3, 2021 at 4:55 PM Paul Hoffman wrote:
> If the WG is going to go to DS in the parent to have a signed signaling
> response, it would make sense that the signal in the child have an
> identical format. If we go with that, I'd rather see CDS be used in the
> child instead of SVCB.
>
I
On Tue, Aug 3, 2021 at 5:20 PM Paul Hoffman wrote:
> On Aug 3, 2021, at 2:06 PM, Ben Schwartz wrote:
> >
> > On Tue, Aug 3, 2021 at 4:55 PM Paul Hoffman
> wrote:
> >> If the WG is going to go to DS in the parent to have a signed signaling
> response, it would mak
On Fri, Aug 27, 2021 at 9:25 AM Alexander Mayrhofer <
alex.mayrhofer.i...@gmail.com> wrote:
...
> I can't speak as an implementor, but looks good (and logical) to me!
>
Thanks!
...
> My gut feeling tells me we're introducing new failure modes somewhere
> here, so that's where my caution came fr
an adopted document with the sole purpose of
describing rules for safe use of 0-RTT [1]. I would like to see the text
on 0-RTT moved into that document, so the working group can provide
consistent guidance on the use of 0-RTT, regardless of transport.
--Ben Schwartz
[1] https://datatracker.ietf.or
On Mon, Sep 20, 2021 at 10:53 AM Vladimír Čunát
wrote:
> Hello.
>
> > If the parent zone also implements authenticated encryption, this
> > provides sufficient protection for the glue records, but many
> > important parent zones seem unlikely to implement authenticated
> > encryption in the near
On Thu, Sep 23, 2021 at 12:53 PM Petr Špaček wrote:
> On 20. 09. 21 18:12, Ben Schwartz wrote:
>
...
> > 2: communication to TLD servers. I believe we have very
> > privacy-interesting data in QNAMEs there already, arguably even the
> > most
> > s
On Fri, Oct 15, 2021 at 2:51 PM Christian Huitema
wrote:
> * Details on usage of 0-RTT with XFR QUERY, issue
> https://github.com/huitema/dnsoquic/issues/99 by Martin Thomson. The
> current text is wrong, because 0-RTT resumption includes carry over of
> the authentication negotiated in the previ
On Fri, Nov 19, 2021 at 6:48 PM Daniel Kahn Gillmor
wrote:
...
> To avoid incurring additional minor timeouts for such a recursive
> resolver, the pool operator should either:
>
Nit: These should not be timeouts. The non-participating backends are
expected to return TCP RST or ICMP Destination
The SNI guidance looks good to me.
I find it confusing to mention ECH in this draft. ECH can never be used
with this specification, because there is (by definition) no SVCB record to
provide the ECH keys. (If there is a SVCB record in play, then we are no
longer in "unilateral probing".)
I did
On Fri, Dec 10, 2021 at 5:03 PM Daniel Kahn Gillmor
wrote:
> Hi Ben--
>
> Thanks for the prompt review and feedback!
>
> On Thu 2021-12-09 16:14:36 -0500, Ben Schwartz wrote:
> > The SNI guidance looks good to me.
> >
> > I find it confusing to mention ECH in t
I support WG adoption of this draft.
On Wed, Feb 23, 2022 at 7:23 AM Brian Haberman
wrote:
> Just a reminder that there are a few days remaining on this adoption
> call. To date, we have gotten very little input and cannot judge
> consensus on so little feedback. Please review the document and p
also
breaks a usual rule of not having parent-side content depend on the child ZSK.
--Ben
From: Joe Abley
Sent: Tuesday, June 24, 2025 3:29 PM
To: Ben Schwartz
Cc: Johan Stenstam ; Working Group DNSOP
; dns-privacy@ietf.org ; Erik Bergström
; Leon Fernandez
Su
Per RFC 9461, the SVCB record should be:
_dns.ns1.p.axfr.net. 10800 IN SVCB 1 ns1.p.axfr.net. alpn="doq,dot,doh”
This uses the prescribed "_dns" prefix and omits the "do53" ALPN ID (which is
not defined and would not help here anyway).
Apart from that minor issue, I don't object to this signali
On Jul 8, 2025, at 6:16 PM, Bill Woodcock wrote:
On Jul 9, 2025, at 00:13, Ben Schwartz wrote:
On Jul 8, 2025, at 5:39 PM, Peter Thomassen
wrote:
It may be more difficult to directly compare reachability of port 853 from
other vantage points, both because other network reasons may be at
> On Jul 8, 2025, at 5:39 PM, Peter Thomassen
> wrote:
>
> On 6/24/25 21:37, Ben Schwartz wrote:
>> 1. An attacker could strip the SVCB record and its RRSIG, resulting in an
>> ordinary delegation response that would be accepted and used without
>> encryption
until after receiving the SVCB hint.
--Ben
From: Johan Stenstam
Sent: Wednesday, June 25, 2025 5:27 AM
To: Joe Abley; Ben Schwartz
Cc: Working Group DNSOP; dns-privacy@ietf.org; Erik Bergström; Leon Fernandez
Subject: Re: [DNSOP] Proposal for opportunistic
37 matches
Mail list logo
