Re: [DNSOP] DNS Grease?

rnity. 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...@gmail.co

Re: [DNSOP] DNS Grease?

at 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...@gmail.co

Re: [DNSOP] DNS Grease?

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

[DNSOP] Resolver cooperation (re: key tags but not only key tags)

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

Re: [DNSOP] [Ext] AD Review of draft-ietf-dnsop-rfc8109bis

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

Re: [DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2024-01-30

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

Re: [DNSOP] Followup Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping

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 Dickson P.S. I'm no long

Re: [DNSOP] WGLC draft-ietf-dnsop-rfc8109bis (2nd round)

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

Re: [DNSOP] Paul Wouters' Discuss on draft-ietf-dnsop-dns-error-reporting-07: (with DISCUSS)

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

Re: [DNSOP] QNAME minimization is bad

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

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping

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 below

Re: [DNSOP] QNAME minimization is bad

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

Re: [DNSOP] QNAME minimization is bad

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

Re: [DNSOP] NOTIFY: How to locate the target

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

Re: [DNSOP] draft-thomassen-dnsop-generalized-dns-notify and draft-ietf-dnsop-dnssec-bootstrapping

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

Re: [DNSOP] Call for Adoption: draft-bellis-dnsop-qdcount-is-one

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

Re: [DNSOP] Call for Adoption: draft-thomassen-dnsop-generalized-dns-notify

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 >

Re: [DNSOP] Compact DoE sentinel choice

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

Re: [DNSOP] Compact DoE sentinel choice

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

Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?

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

Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?

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

Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?

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

Re: [DNSOP] Compact DoE sentinel choice

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

Re: [DNSOP] Compact DoE sentinel choice

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

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 being

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

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

Re: [DNSOP] Best Practices for Managing Existing Delegations When Deleting a Domain or Host

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 >

Re: [DNSOP] Best Practices for Managing Existing Delegations When Deleting a Domain or Host

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 >

Re: [DNSOP] Multiple drafts discussing the use of DNS NOTIFY

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

[DNSOP] draft-klh-dnsop-rfc8109bis suggested text

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

Re: [DNSOP] Call for Adoption: draft-klh-dnsop-rfc8109bis

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

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

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

Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion

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

Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

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

Re: [DNSOP] Call for Adoption: Compact Denial of Existence in DNSSEC

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

Re: [DNSOP] Meaning of lame delegation

(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

Re: [DNSOP] Working Group Last Call for "Domain Verification Techniques using DNS"

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

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

[DNSOP] URI (scheme or other) future work (was Re: [Ext] Possible alt-tld last call?)

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

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

Re: [DNSOP] [Ext] Possible alt-tld last call?

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

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements

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

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements

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

Re: [DNSOP] Possible alt-tld last call?

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

Re: [DNSOP] Possible alt-tld last call?

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

Re: [DNSOP] Possible alt-tld last call?

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

Re: [DNSOP] Possible alt-tld last call?

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bcp-05.txt

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

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

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

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

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

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

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

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 se

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

nce 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: &

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

hould 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 Dickson < >> brian.pe

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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, as f

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

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

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

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

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-16: please review

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

Re: [DNSOP] draft-ietf-dnsop-alt-tld-17

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

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

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

Re: [DNSOP] draft-schanzen-gns and namespace mechanisms

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

Re: [DNSOP] [Ext] On ALT-TLD, GNS, and namespaces...

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.

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dns-alt-tld

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

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dns-alt-tld

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

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

Re: [DNSOP] signing parent-side NS (was: Re: Updating RFC 7344 for cross-NS consistency)

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

Re: [DNSOP] [Ext] DNSOP Document Adoption Poll (June 2022)

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

Re: [DNSOP] CDS Bootstrapping for vanity DNS servers

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

Re: [DNSOP] Wildcard junk vs NXDOMAIN junk

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

Re: [DNSOP] DNSSEC as a Best Current Practice

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

Re: [DNSOP] Call for Adoption: draft-wisser-dnssec-automation

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

Re: [DNSOP] [Ext] More private algorithms for DNSSEC

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

Re: [DNSOP] Call for Adoption: draft-thomassen-dnsop-dnssec-bootstrapping

lling 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

Re: [DNSOP] Call for Adoption: DNSSEC as BCP: draft-hoffman-dnssec

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

Re: [DNSOP] On removing a pargraph in RFC4035

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

Re: [DNSOP] Fwd: DNSSEC algorithm used on ietf.org

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

Re: [DNSOP] DNSSEC as a Best Current Practice

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

Re: [DNSOP] DNSSEC as a Best Current Practice

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

Re: [DNSOP] Another attempt at consensus on the bailiwick discussion

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.

[DNSOP] Fwd: New Version Notification for draft-dickson-dnsop-ds-hack-02.txt

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

[DNSOP] Fwd: New Version Notification for draft-dickson-dnsop-glueless-02.txt

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

[DNSOP] Fwd: New Version Notification for draft-dickson-dprive-dnst-00.txt

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

[DNSOP] Fwd: New Version Notification for draft-dickson-dprive-adot-auth-06.txt

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

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-dns-error-reporting-00.txt

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

Re: [DNSOP] Question on interpretation of DO and CD

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

Re: [DNSOP] Question on interpretation of DO and CD

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

Re: [DNSOP] Bailiwick discussion for draft-ietf-dnsop-rfc8499bis

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

Re: [DNSOP] FYI: WG adoption of DNS binding in ADD

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

[DNSOP] FYI: WG adoption of DNS binding in ADD

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

[DNSOP] Fwd: New Version Notification for draft-dickson-dnsop-glueless-01.txt

cult to tell without getting feedback, so please let me know what you think. Brian Dickson -- Forwarded message - From: Date: Fri, Sep 17, 2021 at 1:20 PM Subject: New Version Notification for draft-dickson-dnsop-glueless-01.txt To: Brian Dickson A new version of I-D, draft-dicks

  1   2   3   4   >