One of the potential challenges for RFCs is references to works-in-progress or
other less-than-stable items (URIs).
Here is my thought: would updating those be something that could be handled by
errata rather than doing a -bis?
Brian
Sent from my iPhone
___
ternity. Not all of them are
obvious or commonly known, but they are definitely present (AIUI).
A couple of examples off the top of my head:
- EDNS (for DNSSEC)
- DNAME support (for DNSSEC)
Brian
> David
>
> On Wed, Apr 24, 2024 at 2:59 PM Brian Dickson <
> brian.peter.dick...@
or that the grease coverage facilitated flagging of
code points subsequent to the EDNS grease thing.
It's kind of like a flag day, but more of a soft opening, i.e. a dependency
situation.
Brian
>
> David
>
> On Wed, Apr 24, 2024 at 2:09 PM Brian Dickson <
> brian.peter.dick..
On Wed, Feb 28, 2024 at 7:11 AM Shumon Huque wrote:
> Thanks for your comments David. I hope it will progress too, and good to
> hear that that grease worked well for TLS and QUIC.
>
> On random vs reserved values, we do intend to propose some reserved ranges
> (there is a placeholder section in
Thinking about the KeyTrap problem, and the discussions here about
potential approaches to mitigation of "bad stuff", one thought that came to
mind was that everyone would necessarily have the same data to crunch (or
avoid), and there might be ways to leverage the work required.
This is just an in
On Thu, Feb 1, 2024 at 12:03 PM Mark Andrews wrote:
> There is nothing to prevent us saying that responses to priming queries
> SHOULD/MUST set TC if all of the addresses of the root servers won’t fit in
> the response or that the root server address should be looked up as if they
> are glue in t
On Mon, Jan 29, 2024 at 3:45 PM Wes Hardaker wrote:
> IESG Secretary writes:
>
> > The Domain Name System Operations (dnsop) WG will hold a virtual
> > interim meeting on 2024-01-30 from 18:00 to 19:00 Europe/Amsterdam
> > (17:00 to 18:00 UTC).
>
> I'm sadly very day-job conflicted with this slo
ecure chain of trust from root to nameservers' names)
- CDO nameservers publish Signaling records in their own signed zone(s)
I'm not sure whether any aspects of the comment above would improve the
draft. Either way (with or without), I'm fine with proceeding to published.
Brian
On Thu, Dec 28, 2023 at 1:35 PM Tim Wicinski wrote:
> All,
>
> We wrapped up the second working group last call for
> draft-ietf-dnsop-rfc8109bis with no comments pro or con.
> The chairs can only assume the working group is not interested in moving
> this work forward.
>
Speaking only for myse
Sent from my iPhoneOn Dec 13, 2023, at 1:32 PM, Warren Kumari wrote:On Tue, Dec 12, 2023 at 9:18 PM, Paul Wouters wrote:Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-dns-error-reporting-07: Discuss
When responding, please keep the subject line int
Sent from my iPhone
> On Nov 10, 2023, at 12:02 PM, John R Levine wrote:
>
>
>>
>>> I'd like to write a draft that updates RFC 9156 by describing
>>> situations like this that caches could recognize and avoid useless
>>> churn, added to section 2.3 which already suggests special casing
>>>
I support advancing this document.
Brian Dickson (speaking only for myself)
On Fri, Nov 10, 2023 at 4:46 AM Peter Thomassen wrote:
> Dear DNSOP,
>
> (This is mainly for those who did not attend today's DNSOP session in
> Prague.)
>
> The chairs announced today that the
On Fri, Nov 10, 2023 at 11:30 AM Denny Watson wrote:
> On 11/10/2023, Stephane Bortzmeyer wrote:
> > On Fri, Nov 10, 2023 at 02:45:08PM +,
> > Denny Watson wrote
> > a message of 50 lines which said:
> >
> >> One thing that is of interest to me; There appears to be no way for
> >> the ow
On Fri, Nov 10, 2023 at 6:45 AM Denny Watson wrote:
> On 11/10/2023, Paul Wouters wrote:
> > On Fri, 10 Nov 2023, John R Levine wrote:
> >
> >> Subject: [DNSOP] QNAME minimization is bad
> >>
> >> Well, not always bad but sometimes.
> >
> > A bit misleading subject :P
> >
> >> I'd like to write a
I think what we have here is (as Daffy Duck famously put it) "pronoun
trouble".
The target for a NOTIFY would necessarily be found in the SOA record of the
registrant's zone, not the parent's zone. I think that's where the
confusion has arisen.
The SOA record would need to be initially configured
On Fri, Oct 13, 2023 at 10:48 AM John Levine wrote:
> I was looking at these two drafts. The first one says that scanning
> for CDS updates is bad, so use NOTIFY(CDS) rather than scanning. The
> second one says to scan for DS bootstrap. I am experiencing cognitive
> dissonance.
>
I believe a mo
On Thu, Sep 28, 2023 at 10:00 AM Tim Wicinski wrote:
>
> We want to thank Joe and Ray for getting this republished with the notes
> from the previous meeting.
>
> Thanks Ted and Eric for their comments today, we will remember them.
> I will say that this chair likes the appendix, to remind me wha
I support adoption.
I am willing to review and contribute.
There is a good chance of using the feature, particularly for the
CDS/CDNSKEY use case.
Brian
On Thu, Sep 14, 2023 at 7:10 PM Suzanne Woolf wrote:
> Dear colleagues,
>
>
>
> This note starts a Call for Adoption for
> draft-thomassen-dns
On Thu, Jul 27, 2023 at 2:49 PM Brian Dickson
wrote:
>
>
> On Tue, Jul 25, 2023 at 10:59 PM Viktor Dukhovni
> wrote:
>
>> On Tue, Jul 25, 2023 at 08:19:21PM -0700, Brian Dickson wrote:
>>
>> > At the name that does not exist, generate and sign (on the fl
On Tue, Jul 25, 2023 at 10:59 PM Viktor Dukhovni
wrote:
> On Tue, Jul 25, 2023 at 08:19:21PM -0700, Brian Dickson wrote:
>
> > At the name that does not exist, generate and sign (on the fly) a CNAME
> > record with RDATA of something like "nxname.empty.as11
Top-reply (since there are already a bunch of threaded replies that might
benefit from this):
Queries are small, and have room in the first packet for EDNS (and often
the resulting size will still be < 576).
Idea:
EDNS "signal" + bits -> tells server the client knows about the new meaning
of the 15
On Wed, Jul 26, 2023 at 5:09 PM Robert Edmonds wrote:
> George Michaelson wrote:
> > if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in
> > the header.
> >
> > What would be interesting uses of the flow-label? Oh wait.. that's
> > right, nobody really knows at scale how to use
On Wed, Jul 26, 2023 at 4:12 PM George Michaelson wrote:
> if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in
> the header.
>
> What would be interesting uses of the flow-label? Oh wait.. that's
> right, nobody really knows at scale how to use flow-label either.
>
> I tend to "
On Tue, Jul 25, 2023 at 3:39 PM Shumon Huque wrote:
> On Tue, Jul 25, 2023 at 11:28 AM Viktor Dukhovni
> wrote:
>
>> On Tue, Jul 25, 2023 at 10:43:25AM -0700, Shumon Huque wrote:
>>
>> > Ok, yes, I understand now, thanks. An NXNAME ignorant validator
>> > will treat a response to a query for the
On Mon, Jul 24, 2023 at 1:55 PM Viktor Dukhovni
wrote:
> In today's session we had some discussion of the choice of sentinel
> RTYPEs for ENTs vs. NXDOMAIN.
>
> There isn't much in the meeting to cover the fine details of various
> alternatives, so I hope a followup message will make my comments
On Mon, Jul 17, 2023 at 12:20 PM John R Levine wrote:
> Just to be clear, I think it's quite reasonable to encourage people to put
> tokens at _name but I still see it as a matter of taste, not a technical
> issue.
>
> On Mon, 17 Jul 2023, Brian Dickson wrote:
> > TCP b
On Mon, Jul 17, 2023 at 11:05 AM John R Levine wrote:
> >>> TCP, you already have worse problems, like DNSSEC doesn't work.
> >
> > Triggering TCP is still not good, even if it all works. It is still
> > better avoiding by not stuffing the APEX. So I think we still want
> > to leave something in
On Tue, Jul 11, 2023 at 12:07 PM Hollenbeck, Scott wrote:
> Folks, we could really use feedback from people with DNS expertise to help
> document a set of best practices for managing existing DNS delegations at
> the
> TLD level when EPP domain and host objects are deleted. As described in
> this
On Tue, Jul 11, 2023 at 12:07 PM Hollenbeck, Scott wrote:
> Folks, we could really use feedback from people with DNS expertise to help
> document a set of best practices for managing existing DNS delegations at
> the
> TLD level when EPP domain and host objects are deleted. As described in
> this
On Sun, Jun 11, 2023 at 8:09 PM Paul Wouters wrote:
>
> On Jun 10, 2023, at 15:42, Tim Wicinski wrote:
> >
> >
> > All
> >
> > The chairs have been looking at two different drafts discussing the use
> of using DNS NOTIFY to update DNSSEC information.
>
> Interesting, as the reason for using CD
I forgot to mention willingness to contribute text.
Here is one suggestion:
Add to section 3 (or under 3.1) text to the effect of:
The recursive resolver SHOULD ensure that the reassembly size advertised is
below the threshold in its immediate network vicinity.
Specifically, if a response with th
On Wed, 31 May 2023, Tim Wicinski wrote:
>
> Subject: Re: [DNSOP] Call for Adoption: draft-klh-dnsop-rfc8109bis
>
> This call for adoption ends: 7 June 2023
>
I too am in favour of adoption.
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.o
On Fri, May 5, 2023 at 11:46 AM Joe Abley wrote:
> Hi Peter,
>
> On Fri, May 5, 2023 at 04:39, Peter Thomassen > wrote:
>
> > Having the delegating party check for service for the requested zone
> > at time of delegation request and refuse to update / register if
> > this check fails
>
> It woul
George is (of course) right.
I think the following set of definitions might be useful to consider.
Lame server: older language used to describe a "lame zone server".
Lame zone server: a server listed in the NS set for a zone, which is not
providing authoritative answers for said zone.
Partially l
Top-reply (to avoid adding to confusion by attempting to add in-line
commentary of uncertain value):
I also agree that this is very valuable and definitely helpful for
diagnostics.
I think there are a number of edge cases, for which disambiguation might be
helpful.
Apologies if this seems to add c
On Mon, May 1, 2023 at 12:55 PM libor.peltan wrote:
> Hi Paul,
>
> if you really ask for opinions, here is mine.
>
> Considering the recent voluminous discussion about the meaning of Lame
> delegation, it seems to me that there are at least several people being
> more-or-less sure what the term m
On Wed, Apr 26, 2023 at 8:43 AM Shumon Huque wrote:
> I support adoption too.
>
>
Me too. Support. Happy to review or contribute. (Not a lie.)
Brian
> As I've mentioned earlier, this mechanism is widely deployed and needs a
> published specification. Adopting the work will also allow us to for
(Incorporating but not quoting various other responses in this thread,
implicitly, based on the dates they were sent.)
On Mon, Apr 3, 2023 at 1:02 PM Wessels, Duane wrote:
> Dear DNSOP,
>
> I am participating in an SSAC work party where we are writing about DNS
> delegations where a delegated na
On Fri, Feb 17, 2023 at 4:06 PM tjw ietf wrote:
> John
>
> Paul is right. As an operator one thing I always obsess on in is the data
> in my zones. Why is it there , should it be, etc. Another example you may
> understand is “who created this incorrect DMARC record?”
>
> I’ve given them much muc
On Mon, Oct 24, 2022 at 12:45 PM Paul Wouters wrote:
> On Mon, 24 Oct 2022, Brian Dickson wrote:
>
> > Just to expand on this idea (which I quite like), the original AS112 was
> enhanced to handle new/arbitrary names, so
> > that AS112 operators don't need to do anythi
On Sun, Oct 23, 2022 at 12:33 PM Paul Vixie wrote:
>
>
> David Conrad wrote on 2022-10-23 12:00:
> > Rob,
>
> not rod, but i have three comments.
>
> > On this mailing list, I think there is a pretty good understanding of
> > the intent of .alt and I don’t think there is much in the way of
> > di
On Mon, Oct 24, 2022 at 7:18 AM Ben Schwartz wrote:
>
>
> On Sun, Oct 23, 2022 at 4:31 AM Eliot Lear wrote:
>
>> Hi Ben and Wes,
>> On 21.10.22 20:45, Ben Schwartz wrote:
>>
>>
>> Rather than placing "alt" in the TLD position, I think it might be better
>> as a scheme modifier: https+alt://...
On Fri, Oct 21, 2022 at 1:36 PM Paul Vixie wrote:
>
>
> Brian Dickson wrote on 2022-10-21 12:42:
> >
> >
> > On Fri, Oct 21, 2022 at 9:52 AM Paul Vixie
> > > <mailto:40redbarn@dmarc.ietf.org>> wrote:
> >
> > ...
> >
> &
On Fri, Oct 21, 2022 at 9:52 AM Paul Vixie wrote:
> see inline.
>
> Wes Hardaker wrote on 2022-10-21 09:09:
> > Joe Abley writes:
> >
> >>> Normally, a registry is created when it will help the operation of
> >>> the protocol. The problem here is that there's an _anti_-protocol,
> >>> and there
On Thu, Oct 20, 2022 at 1:16 AM Eliot Lear wrote:
> Hi,
>
> First, I would like us to continue to consult on the registry matter at
> least through the London IETF, and would ask the chairs for some time in
> London for this purpose. I would also be available for side meetings
> with any interes
On Wed, Oct 19, 2022 at 12:22 PM Tim Wicinski wrote:
>
>
> This starts a Working Group Last Call for
> draft-ietf-dnsop-dnssec-validator-requirements
>
> Current versions of the draft is available here:
>
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-validator-requirements/
>
> The C
Quick meta-question:
If there is new information that would suggest additions to the document as
helpful (improves document), which would be the normal or best approach:
- Ask for additions to the document during the WGLC itself
- Offer comments on the addition alongside a request to delay
On Sun, Oct 16, 2022 at 8:03 AM Suzanne Woolf wrote:
> Dear Colleagues,
>
>
> The chairs have gotten a couple of requests, off-list and on, for a WGLC
> on draft-ietf-dnsop-alt-tld.
>
> We’ve reviewed the current draft closely and have some concerns that we
> feel need to be resolved before any e
Speaking only for myself (and definitely not for my employer, GoDaddy)...
On Sun, Oct 16, 2022 at 11:45 PM Eliot Lear wrote:
>
> On 17.10.22 04:20, Paul Wouters wrote:
>
> > Basically, .alt is what IETF recommends you should not do, and we
> > should not keep
> > a registry of entries within it.
On Mon, Oct 17, 2022 at 7:12 AM Joe Abley wrote:
>
> My goal is certainly not to put any brakes on if the effect of that is to
> make things move more slowly. I apologise if that's what I have done in
> suggesting to Brian that semantic-free labels do not fit the problem space.
>
>
And I, in retu
On Sun, Oct 16, 2022 at 9:08 AM Eliot Lear wrote:
> Hiya!
>
> Thanks to Suzanne and the chairs for moving things forward. On this point:
> On 16.10.22 17:22, Warren Kumari wrote:
>
>
>
>> 2. Having the IETF maintain a registry of pseudo-SLDs concerns me on the
>> basis that having the IETF “reco
On Mon, Oct 10, 2022 at 9:19 AM Viktor Dukhovni
wrote:
> On Mon, Oct 10, 2022 at 07:57:45AM -0700, internet-dra...@ietf.org wrote:
>
> > This draft is a work item of the Domain Name System Operations WG of the
> IETF.
> >
> > Filename: draft-ietf-dnsop-dnssec-bcp-05.txt
> > [...]
> > A di
On Thu, Sep 22, 2022 at 2:05 AM Kazunori Fujiwara
wrote:
> > From: Petr Špaček
> >> Then, do you agree the following requirements ? (as DNS software
> >> developpers)
> >> 1. SHOULD set DF bit on outgoing UDP packets on IPv4,
> >> and SHOULD not use FRAGMENT header on IPv6.
> >
> > Theoretic
On Wed, Sep 7, 2022 at 9:09 PM Martin Thomson wrote:
>
>
> On Thu, Sep 8, 2022, at 13:29, Brian Dickson wrote:
> > If no AliasMode record was processed, then $QNAME would be the origin
> > name PLUS the prefix(es) of type attrleaf ( underscore thingies). Those
> >
On Wed, Sep 7, 2022 at 7:41 PM Paul Hoffman wrote:
> On Sep 7, 2022, at 5:48 PM, Viktor Dukhovni
> wrote:
> > Once SVCB resolution has concluded, whether successful or not,
> > +if at least one AliasMode record was processed,
> > SVCB-optional clients SHALL append to the priority list an
> > end
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'
ink 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 Dic
the semantics at all.) They should stay or go as one unit.
Brian
On Tue, Aug 30, 2022 at 12:08 AM Brian Dickson <
brian.peter.dick...@gmail.com> wrote:
>
>
> On Sat, Aug 27, 2022 at 3:00 PM Ben Schwartz wrote:
>
>>
>>
>> On Fri, Aug 26, 2022 at 10:49 PM Brian
On Sat, Aug 27, 2022 at 3:00 PM Ben Schwartz wrote:
>
>
> On Fri, Aug 26, 2022 at 10:49 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>> Fail fast may not be appealing, but in some (probably the majority of)
>> cases, it may be the most c
On Fri, Aug 26, 2022 at 11:54 AM Tommy Pauly wrote:
>
>
> On Aug 26, 2022, at 4:29 AM, Ben Schwartz 40google@dmarc.ietf.org> wrote:
>
>
>
>
> On Thu, Aug 25, 2022 at 7:19 PM Viktor Dukhovni
> wrote:
>
>> On Thu, Aug 25, 2022 at 04:35:39PM -0400, Ben Schwartz wrote:
>>
>> > Relatedly, the
On Thu, Aug 25, 2022 at 1:35 PM Ben Schwartz wrote:
> For now, I think it's better to keep the current guidance, in order to
> minimize the risk of disruptions as these new RR types begin to be deployed.
>
I have a small favor to ask.
Could you try to "sell" the guidance from the hypothetical p
On Thu, Aug 25, 2022 at 1:35 PM Ben Schwartz wrote:
>
> Brian proposes a use case of serving only a warning message on the origin
> endpoint, in order to minimize the load on IP addresses that are likely
> hardcoded into a customer's zone.
>
So, the major update to add to this is:
- We (GoDa
On Fri, Aug 26, 2022 at 4:29 AM Ben Schwartz wrote:
>
>
> On Thu, Aug 25, 2022 at 7:19 PM Viktor Dukhovni
> wrote:
>
>> On Thu, Aug 25, 2022 at 04:35:39PM -0400, Ben Schwartz wrote:
>>
> Indeed it is a possible position to say that the Internet is not yet
>> ready for semantically distinct servi
On Thu, Aug 25, 2022 at 1:35 PM Ben Schwartz wrote:
> (Also, Brian's analysis indicates that the origin hostname's address
> record TTL would bias the endpoint selection, but this is not correct.)
>
This statement intrigues me, and I think is highly relevant to the
discussion.
Could you explai
On Thu, Aug 25, 2022 at 1:35 PM Ben Schwartz wrote:
> Thanks to Brian, Viktor, and others for the very close review, as always.
> While I disagree with many of the claims made here, it's clear that some of
> the text has proven confusing. I'm not familiar with the process rules
> given the draft
On Thu, Aug 25, 2022 at 7:58 AM Paul Hoffman wrote:
> On Aug 24, 2022, at 7:14 PM, Brian Dickson
> wrote:
>
> >> Are you saying that it was explicit after WG Last Call but changed? Or
> during IETF Last Call and was changed?
> >>
> > No, I'm saying that,
On Wed, Aug 24, 2022 at 6:19 PM Paul Hoffman wrote:
> On Aug 24, 2022, at 5:14 PM, Brian Dickson
> wrote:
> > "at this stage" is only the case due to the draft not being explicit in
> the flow.
>
> Are you saying that it was explicit after WG Last Call but chan
On Wed, Aug 24, 2022 at 4:11 PM Eric Orth wrote:
>
>
> On Wed, Aug 24, 2022 at 4:58 PM Viktor Dukhovni
> wrote:
>
>> * When the initial SVCB (also HTTPS, ...) query returns an AliasMode
>> result, lookup failures in all subsequent SVCB/HTTPS queries are
>> "fatal"
>> even for SVC
On Tue, Aug 23, 2022 at 9:15 AM Paul Hoffman wrote:
> On Aug 23, 2022, at 8:50 AM, Warren Kumari wrote:
> > I think that is helpful to communicate expectations,
>
> Is the suggestion that the non-DNS protocol follow the DNS wire format
> and/or presentation format now an expectation? This seems
On Tue, Aug 23, 2022 at 11:52 AM Paul Hoffman
wrote:
> Thanks again for all the discussion; it is helping the document. You can
> see from the diff at <
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-alt-tld-17> that we
> have tightened the language, particularly around what is display form
On Sat, Aug 20, 2022 at 10:07 AM Warren Kumari wrote:
> Brian Dickson recently reached out to one of the DNSOP chairs to raise
> some technical concerns related to the AliasMode functionality in
> draft-ietf-dnsop-svcb-https.
>
> Although this document has already passed WGLC, IET
One tidbit that might have been overlooked, is that draft-schanzen-gns (and
the various documents it references, including stuff in github) has a
technical problem.
The TL;DR: is that nsswitch (and similar systems) depend on individual
resolution mechanisms (whatever those may be) returning NXDOMA
Sent from my iPhone
> On Aug 17, 2022, at 3:12 PM, Timothy Mcsweeney wrote:
>
>
>>> On 08/17/2022 2:14 PM EDT Paul Hoffman wrote:
>>>
>>> The Intro says" the rightmost label, to signify that the name is NOT rooted
>>> in the DNS, and that it should NOT be resolved using the DNS protocol.
On Wed, Aug 3, 2022 at 11:40 PM Martin Schanzenbach
wrote:
> Excerpts from Brian Dickson's message of 2022-08-03 18:09:32 -0700:
> > Top-reply (not apologizing for doing so, either):
> >
> > If I read the actual draft correctly, it is _not_ intended to be a DNS
> > drop-in replacement.
> > Instea
Top-reply (not apologizing for doing so, either):
If I read the actual draft correctly, it is _not_ intended to be a DNS
drop-in replacement.
Instead, it is meant to be an _alternative_ to DNS.
So, why even use DNS-compatible label strings? That is an obviously
conflict-causing choice, which is e
On Sun, Jul 31, 2022 at 11:54 AM Paul Vixie wrote:
>
>
> Andrew McConachie wrote on 2022-07-28 03:24:
> >> Path MTU discovery remains widely undeployed due to
> >>security issues, and IP fragmentation has exposed weaknesses in
> >>application protocols.
> >
> > PMTUD doesn’t work through
On Tue, Jul 26, 2022 at 6:22 AM Petr Špaček wrote:
> On 28. 06. 22 16:20, Bob Harold wrote:
> > But the parent NS set is not covered by DNSSEC, and thus could be
> spoofed??
> > (Wish we could fix that!)
>
> I share your wish.
>
> Does anyone else want to contribute?
>
I have an interest in fi
Honestly, since doing any sort of poll is "new", maybe the first poll
should have been, is doing this via a poll acceptable as a process/policy
thing for the WG?
Doing such a poll should include not only how folks feel about using polls
for this, but also could ask people to indicate the likelihoo
On Tue, Jun 21, 2022 at 7:51 PM wrote:
>
> Hi.
>
> During a meeting today of ROW (https://regiops.net), the I-D on CDS
> bootstrapping by using a DNSSEC-signed name at name server zone (
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/)
> was discussed.
> In that discussi
On Thu, Apr 7, 2022 at 9:51 AM John R. Levine wrote:
> A friend of mine asserts that wildcard DNS records are a problem because
> hostile clients can use them to fill up DNS caches with junk answers to
> random queries that match a wildcard. But it seems to me that you can do
> it just as well w
On Thu, Apr 7, 2022 at 5:45 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:
> As I wrote:
>
> >> Such an individual would have to get access, create the records, give
> >> them to others, who then have to on-path attack you. At the TLD level
> >> and higher, this involves HSMs and phys
On Fri, Mar 25, 2022 at 8:36 AM Benno Overeinder wrote:
> As with the previous Call for Adoption today, at this week's DNSOP
> meeting at IETF 113, we announced that we are initiating a Call for
> Adoption for the draft-wisser-dnssec-automation. With the survey we
> conducted for the last IETF 1
On Tue, Mar 29, 2022 at 1:31 PM Mark Andrews wrote:
>
>
> > On 30 Mar 2022, at 00:28, Peter Thomassen wrote:
> >
> >
> >
> > On 3/28/22 20:34, Mark Andrews wrote:
> >> About the only part not already specified is matching DS to DNSKEY
> using PRIVATEDNS but as you can see it is obvious to anyone
ng to contribute text, review, and may even have an
implementation available by the time it is ready for publication.
Brian Dickson
>
> This call for adoption ends: 8 April 2022
>
> Thanks,
>
> Suzanne, Tim and Benno
>
> ___
&g
g to contribute text, review, etc.
>
>
I support adoption of this by the WG.
I am willing to review, and to contribute text.
Brian Dickson
> This call for adoption ends: 7 April 2022
>
> Thanks,
> tim wicinski
> For DNSOP co-chairs
>
>
On Thu, Mar 24, 2022 at 9:53 AM Ulrich Wisser wrote:
> Hi Mark,
>
> Sorry for the late answer, IETF and some other stuff keeps me busy.
>
>
> Let’s start with this
>
> *We did not and do not propose to remove anything from RFC 4035. Currently
> we are asking for RFC 6840 to be amended *
>
> *RFC
On Wed, Mar 23, 2022 at 9:22 AM Petr Menšík wrote:
> Because NSEC3 algorithm still does not have any alternative to SHA-1, hard
> crypto failure would be blocker for any our DNS products. I haven't heard
> about it even being considered this way.
>
I think this is a relatively common misconcepti
On Tue, Mar 22, 2022 at 7:12 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:
> Paul Wouters wrote:
>
> >> Wrong. DNSSEC as PKI is not cryptographically secure subject to
> >> MitM attacks on CA chains, which is not more difficult than
> >> MitM attacks on ISP chains.
> >
> > I think at
On Mon, Mar 21, 2022 at 5:28 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:
> Paul Wouters wrote:
>
> >> If a resolver correctly knows an IP address of a nameserver of a
> >> parent zone
> >
> > This statement seems a recursion of the original problem statement?]
>
> What?
>
> The sta
On Wed, Dec 15, 2021 at 2:01 PM Paul Vixie wrote:
>
>
> Wessels, Duane wrote on 2021-12-15 13:17:
> > ...
> >
> > On one hand I think it would be a lot simpler to just say that only
> address records can be glue. But I’m not sure that is defendable given the
> directions things are going. Here’
Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian
-- Forwarded message -
From:
Date: Sun, Sep 19, 2021 at 2:42 PM
Subject: New Version Notification for draft-dickson-dnsop-ds-hack-02.txt
To: Brian Dickson
A new version of I-D
Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian
-- Forwarded message -
From:
Date: Wed, Sep 22, 2021 at 12:50 AM
Subject: New Version Notification for draft-dickson-dnsop-glueless-02.txt
To: Brian Dickson
A new version of I
Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian
-- Forwarded message -
From:
Date: Sun, Oct 24, 2021 at 9:13 PM
Subject: New Version Notification for draft-dickson-dprive-dnst-00.txt
To: Brian Dickson
A new version of I-D
Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian
-- Forwarded message -
From:
Date: Tue, Nov 9, 2021 at 6:11 PM
Subject: New Version Notification for draft-dickson-dprive-adot-auth-06.txt
To: Brian Dickson
A new version of I
FYI, I too like it and believe it should progress.
(We will likely implement it once it is published, too.)
Brian
On Tue, Oct 19, 2021 at 6:20 PM Bill Woodcock wrote:
>
>
> > On Oct 20, 2021, at 3:07 AM, Paul Hoffman
> wrote:
> >
> > Just noting that no one has said anything about this draft s
Sent from my iPhone
> On Oct 7, 2021, at 12:55 AM, Joe Abley wrote:
>
> On Oct 7, 2021, at 09:49, Brian Dickson
> wrote:
>
>> Quick question in a top-reply, sorry:
>> Mark:
>> Is there any combination of flag bits or EDNS options that a stub can use to
&g
Quick question in a top-reply, sorry:
Mark:
Is there any combination of flag bits or EDNS options that a stub can use
to reliably determine if a resolver is validating?
Obviously there are clever tricks possible, such as sending queries to a
small set of domains that identify whether resolvers val
On Wed, Oct 6, 2021 at 12:05 PM Paul Wouters wrote:
> On Wed, 6 Oct 2021, Paul Hoffman wrote:
>
> > Greetings again. I think that all of the issues from the WG on
> draft-ietf-dnsop-rfc8499bis have been dealt with, except one significant
> one. Almost a year ago, Tony Finch started a thread about
servers. I'm not at all convinced it would be useful or a
good alignment of use cases.)
I think it SHOULD be limited in scope to recursives, in which case it would
belong in ADD. (But that is a hard IF and ONLY IF, IMNSHO).
Brian
On Mon, Sep 27, 2021 at 2:18 PM Brian Dickson
wrote:
> In cas
In case anyone does not follow the ADD WG, or does not closely follow
DPRIVE, there is a WG adoption call for an SVCB binding for DNS.
There are two days left in that adoption call.
I encourage folks to take a look and give feedback concerning where they
think any such draft belongs (e.g. DNSOP i
1 - 100 of 387 matches
Mail list logo