[DNSOP] Re: Working Group Last Call for draft-ietf-dnsop-generalized-notify

Okay, that sounds like confirmation to me. All good then! On 10-01-2025 11:29, Kazunori Fujiwara wrote: From: Matthijs Mekking I would use city.ise.mie.example instead, unless you have confirmation that JPRS is fine with using .jp as an example here. JP domain names have second-level, third

[DNSOP] Re: Working Group Last Call for draft-ietf-dnsop-generalized-notify

Hi Peter, On 09-01-2025 21:31, Peter Thomassen wrote: Hi Matthijs, Thank you for your helpful review! Please find some responses below: On 1/9/25 14:09, Matthijs Mekking wrote: Section 3 - "There MUST NOT be more than one DSYNC record for each combination of rrtype and scheme.

[DNSOP] Re: Working Group Last Call for draft-ietf-dnsop-generalized-notify

Late to the party, but I also support this draft. I read the latest version and I like it. Some comments below. Apologies if there are duplicate comments. Best regards, Matthijs Section 2.1 --- I notice that notifies for DNSKEY have been removed since the initial implementation. I g

Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)

On 6/20/23 17:14, John Levine wrote: It appears that Matthijs Mekking said: Hi, I like this draft because of it tackles the issues of wasteful CDS polling and it uses NOTIFY, a mechanism that is well known, already exists in implementations, and actually feels like a good fit (as opposed

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

Hi, On 6/10/23 21: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.  The two drafts are: https://datatracker.ietf.org/doc/html/draft-thomassen-dnsop-generalized-dns-notify-01

Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)

Hi, I like this draft because of it tackles the issues of wasteful CDS polling and it uses NOTIFY, a mechanism that is well known, already exists in implementations, and actually feels like a good fit (as opposed to overloading). A note on where to send CDS and CSYNC notifications. I sort

Re: [DNSOP] Call for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory

Hi, From the draft: For example, a single provider may (accidentally or maliciously) cause another provider's trust anchors and/or nameservers to be removed from the delegation. This is exactly what happened in my test environment when putting BIND 9 to the multi-signer test where one

Re: [DNSOP] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt

On 25-11-2021 13:00, Petr Špaček wrote: On 25. 11. 21 9:33, Matthijs Mekking wrote: 3.2.  Recommendation for validating resolvers I understand why the new text is here, but I think this now actually gives too little advice for operators and vendors. I know, this is a vague comment, I

Re: [DNSOP] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt

Hi Wes, I think the changes are moving the document in the right direction. Some comments: 3.1. Best-practice for zone publishers I wonder if we can make the requirement even stronger by saying "If NSEC3 must be used, then an iterations count of 0 MUST be used to alleviate computational bu

Re: [DNSOP] nsec3-parameters opinions gathered

I concur with Benno. For Bind 9, there is no technical challenge to set the iteration cap at a lower value. We prefer the value to be as low as possible, because it adds no real value at a real resource cost. But we will likely not implement blindly a maximum that will cause lots of operational

Re: [DNSOP] How does NSEC record(s) prove the Name Error?

Hi, The short answer is "find the closest encloser and determine the source of synthesis. I can recommend reading RFC 4592 "The Role of Wildcards in the Domain Name System" to understand better how wildcards work. I can recommend reading RFC 7129 "Authenticated Denial of Existence in the DNS" to

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

Hi, On 26-10-2021 01:56, Roy Arends wrote: On 20 Oct 2021, at 14:14, libor.peltan wrote: Hi all, although for me, as an implementer of an auth server, it's not too important, I'd like to ask for clarification regarding the foreseen reporting domain(s) setup in the (usual) case of many secon

Re: [DNSOP] wrapping up draft-ietf-dnsop-nsec3-guidance

IIRC the vendors agreed on 150 for two reasons: 1. There are still a fair amount of zones using this value. Only a handful of zones where using above 150. 2. Resolvers could still cope with such numbers pretty confidently. I agree lower is better, but let's not pick a number randomly, but hav

Re: [DNSOP] wrapping up draft-ietf-dnsop-nsec3-guidance

On 21-10-2021 13:22, Peter van Dijk wrote: On Wed, 2021-10-20 at 11:24 -0700, Wes Hardaker wrote: So, the question: what's the right FINAL value to put in the draft before LC? I don't know what the -right- value is, but I know what I want: 0 iterations, empty salt, otherwise the NSEC3 gets

Re: [DNSOP] [Technical Errata Reported] RFC6781 (6692)

om the response, and any implementation that does otherwise is not compliant. - Matthijs On 24-09-2021 15:01, Paul Wouters wrote: On Fri, 24 Sep 2021, Matthijs Mekking wrote: Second, I believe the corner case you mentioned is for Figure 15 (the one in Appendix D), and I don't understand

Re: [DNSOP] [Technical Errata Reported] RFC6781 (6692)

Paul, On 23-09-2021 15:52, Paul Wouters wrote: On Thu, 23 Sep 2021, Matthijs Mekking wrote: You are referring to text that describes Figure 10. The following text in Section 4.3.5.1 refers to the figure in Appendix D:    The requirement to exchange signatures has a couple of drawbacks.  It

Re: [DNSOP] [Technical Errata Reported] RFC6781 (6692)

Paul, You are referring to text that describes Figure 10. The following text in Section 4.3.5.1 refers to the figure in Appendix D: The requirement to exchange signatures has a couple of drawbacks. It requires more operational overhead, because not only do the operators have to exchan

Re: [DNSOP] [Technical Errata Reported] RFC6781 (6692)

I believe this errata is correct. On 22-09-2021 16:18, RFC Errata System wrote: The following errata report has been submitted for RFC6781, "DNSSEC Operational Practices, Version 2". -- You may review the report below and at: https://www.rfc-editor.org/errata

Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance

I support the document to become a working group document, and I am willing to review. Best regards, Matthijs On 10-05-2021 10:55, Benno Overeinder wrote: Hi all, As a follow-up to the presentation by Wes Hardaker at the IETF 110 DNSOP meeting, we want to start a call for adoption of draft

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec-ttl-03.txt

Peter, Personally I still think we shouldn't change these SHOULDs to MUSTs. Quoting from RFC 2119: 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. 3. SHOULD This word, or the adjective "RECOMMENDED", mean

Re: [DNSOP] [Ext] Working Group Last Call for draft-ietf-dnsop-nsec-ttl

On 03-02-2021 20:31, Paul Hoffman wrote: For each of these, I'd recommend specifying what a client does in each of the cases, rather than weasel wording the SHOULD with respect to the zone contents to turn this into an implementable protocol. Here, I agree that the draft is unclear. It sho

Re: [DNSOP] new draft: 'NSEC(3) TTLs and NSEC Aggressive Use' (New Version Notification for draft-vandijk-dnsop-nsec-ttl-00.txt)

Hi Peter, I reviewed the draft and it mostly looks good. Some minor comments: 1. Perhaps instead of using ".com" as an example, use ".example" (per RFC 2606)? 2. Shouldn't this document also update some text parts from RFC 8198? 3. About this paragraph: Ralph Dolmans helpfully pointed ou

Re: [DNSOP] [Ext] Call for Adoption: draft-vandijk-dnsop-nsec-ttl

Hi, On 11-12-2020 23:41, Paul Hoffman wrote: On Dec 11, 2020, at 1:42 PM, Tim Wicinski wrote: So this call should be less controversial. I read Peter's draft (thanks for poking us on this) and it does clean up existing documents. With this call, we're only looking to *objections* to adopti

Re: [DNSOP] What is the purpose of NSEC3 "closest encloser" proofs?

Hello Nick, The closest encloser proof is explained in RFC 7129, Section 5.5. https://tools.ietf.org/html/rfc7129#section-5.5 Best regards, Matthijs On 10/9/20 1:46 AM, Nick Johnson wrote: > I'm reading RFC 5155, and I'm a bit puzzled by the requirement for > "closest encloser" proofs to p

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On 2/26/20 11:28 PM, Andrew M. Hettinger wrote: > "DNSOP" wrote on 02/26/2020 08:34:55: > >> From: "Vladimír Čunát" >> To: "dnsop@ietf.org WG" >> Cc: "Andrew M. Hettinger" >> Date: 02/26/2020 08:35 >> Subject: Re:  [External]  [DNSOP] status of the aname and svcb/httpsvc > drafts >> Sent by:

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

, Matthijs On 2/20/20 10:59 AM, Shane Kerr wrote: > Matthijs, > > On 20/02/2020 09.29, Matthijs Mekking wrote: >> >> >> On 2/18/20 5:17 PM, Olli Vanhoja wrote: >>> >>> On Tue, Feb 18, 2020, 16:20 Klaus Malorny >> <mailto:klaus.malo...@knipp.de>

Re: [DNSOP] status of the aname and svcb/httpsvc drafts

On 2/18/20 5:17 PM, Olli Vanhoja wrote: > > On Tue, Feb 18, 2020, 16:20 Klaus Malorny > wrote: > > > I asked myself about the status of the two drafts. I got the > impression a little > bit that the svcb/httpsvc draft successfully killed the aname d

Re: [DNSOP] AD review of draft-ietf-dnsop-multi-provider-dnssec

On 1/27/20 8:34 PM, Shumon Huque wrote: > On Tue, Jan 21, 2020 at 11:41 AM Matthijs Mekking > mailto:matth...@pletterpet.nl>> wrote: > > Shumon, > On 1/21/20 4:05 PM, Shumon Huque wrote: > > > > This also begs the question: should we (in a

Re: [DNSOP] AD review of draft-ietf-dnsop-multi-provider-dnssec

On 1/21/20 6:03 PM, Tony Finch wrote: > Matthijs Mekking wrote: > >> I am not sure how they executed the algorithm rollover precisely. >> Particularly, were there ever two DS records in the root zone with >> different algorithms for these zones? > > I can

Re: [DNSOP] AD review of draft-ietf-dnsop-multi-provider-dnssec

how unbound works, see https://nlnetlabs.nl/documentation/unbound/info-algo/ for more information. Best regards, Matthijs > Shumon. > > On Tue, Jan 21, 2020 at 3:59 AM Matthijs Mekking <mailto:matth...@pletterpet.nl>> wrote: > > Hi Shumon, > > On

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

Late to the party, I am sorry. I am positive about this document, and support publication. I do have one comment on the document, requesting an update. In section 4 it is said it is RECOMMENDED that providers use a common signing algorithm. I think this is too weak and it must be a MUST. The re

Re: [DNSOP] Alissa Cooper's Discuss on draft-ietf-dnsop-obsolete-dlv-01: (with DISCUSS and COMMENT)

Done. Matthijs On 10/30/19 5:52 PM, Warren Kumari wrote: > Hi there authors, > Do you think that you can get a new version posted by tomorrow morning > addressing these points? > W > > On Wed, Oct 30, 2019 at 12:00 PM Alissa Cooper via Datatracker > wrote: >> >> Alissa Cooper has entered the fo

Re: [DNSOP] Obsoleting DLV

Sam, On 7/25/19 1:22 AM, Samuel Weiler wrote: > On Tue, 2 Jul 2019, Matthijs Mekking wrote: > >> Here's a draft with discussion why also the protocol should go >> away. We would like to hear what you think about it. > > The discussion of the private network

Re: [DNSOP] Can an RRSET remain valid past the expiration timestamp on its signing RRSIG?

RFC 4035 says: If the resolver accepts the RRset as authentic, the validator MUST set the TTL of the RRSIG RR and each RR in the authenticated RRset to a value no greater than the minimum of: o the RRset's TTL as received in the response; o the RRSIG RR's TTL as received in the

Re: [DNSOP] Fwd: HTTPSSVC record draft

I was too late to join the virtual queue in the dnsop meeting (fighting with the Meetecho UI), so I'll send a mail to the list: Slide 5 of the presentation (Alias form) basically covers the ANAME case, but still relies on the client to chase the target. The ANAME record is flexible where the targ

Re: [DNSOP] a CDN perspective on ANAME challenges

On 7/23/19 2:33 PM, Ben Schwartz wrote: > > > On Tue, Jul 23, 2019 at 4:39 AM Matthijs Mekking <mailto:matth...@pletterpet.nl>> wrote: > > Hi Erik, > > On 7/22/19 9:31 PM, Erik Nygren wrote: > > Reading the draft again, I think a challen

Re: [DNSOP] a CDN perspective on ANAME challenges

 Authoritative resolvers do a mixture of the following, which is >> Do you mean authoritative name servers here? > > Yes, authoritative nameservers, but also ones that effectively have > to be resolvers in-order to do inline sibling record resolution (and > caching) > and sending ECS. &

Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-04.txt

Hi Petr, On 7/22/19 10:21 PM, Petr Špaček wrote: > Hello, > > this is an attempt to review draft-ietf-dnsop-aname-04 with fresh eyes - Thanks. > I've managed to forget the old versions ;-) Very wise :) Comments below: > On 08. 07. 19 22:05, internet-dra...@ietf.org wrote: >> Filename

Re: [DNSOP] Call for Adoptions: draft-lhotka-dnsop-iana-class-type-yang

On 7/16/19 1:49 AM, Joe Abley wrote: > On Jul 15, 2019, at 19:13, Tim Wicinski wrote: > >> Also, the current draft enumerates DLV >> which needs to be removed. > > Can you explain this? > > I can understand a forthcoming clarification on the use of DLV that > might make it ill-advised to publ

Re: [DNSOP] a CDN perspective on ANAME challenges

Hi Erik, Thanks for sharing this perspective. On 7/12/19 7:52 PM, Erik Nygren wrote: > 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

Re: [DNSOP] ANAME loop detection

Jan, On 7/8/19 11:32 AM, Jan Včelák wrote: > On Thu, Jul 4, 2019 at 4:55 PM Matthijs Mekking wrote: >> On 7/4/19 2:32 PM, Matthew Pounsett wrote: >>> I would say they should rely on that. Why shouldn't they? Isn't our >>> goal to get downstream servers to

Re: [DNSOP] ANAME loop detection

On 7/4/19 5:39 PM, Matthew Pounsett wrote: > > > On Thu, 4 Jul 2019 at 10:54, Matthijs Mekking <mailto:matth...@pletterpet.nl>> wrote: > > Matthew, > > > I would say they should rely on that.  Why shouldn't they?  Isn't our >

Re: [DNSOP] ANAME loop detection

Matthew, On 7/4/19 2:32 PM, Matthew Pounsett wrote: > > > On Thu, 4 Jul 2019 at 05:54, Matthijs Mekking <mailto:matth...@pletterpet.nl>> wrote: > > > > > 1. EDNS "do not follow ANAME" option: The requester would indicate > > t

Re: [DNSOP] ANAME loop detection

Shane, On 7/4/19 2:29 PM, Shane Kerr wrote: >>> 2. QTYPE=ANAME: According to the current version of the draft, server >>> answering to ANAME must include the ANAME and should include the >>> sibling records. Let's modify the behavior and say the server should >>> not (must not) include the sibling

Re: [DNSOP] ANAME loop detection

Jan, I like something like option 2 the best, I'll react to your options below. On 7/4/19 11:37 AM, Jan Včelák wrote: > Hello. > [ ... ] > We had been thinking about how this could be fixed and here is what we > have came with: > > 1. EDNS "do not follow ANAME" option: The requester would indi

[DNSOP] Obsoleting DLV

gards, Matthijs Forwarded Message A new version of I-D, draft-mekking-dnsop-obsolete-dlv-00.txt has been successfully submitted by Matthijs Mekking and posted to the IETF repository. Name: draft-mekking-dnsop-obsolete-dlv Revision: 00 Title:Moving DNSSEC Lookaside Validation

Re: [DNSOP] ANAME in answer or additional section [issue #62]

Brian, On 6/13/19 7:50 PM, Brian Dickson wrote: > > > On Wed, Jun 12, 2019 at 1:11 AM Matthijs Mekking <mailto:matth...@pletterpet.nl>> wrote: > > Brian, > > Thanks for the detailed background on why DNAME worked. There are a few > things that cau

Re: [DNSOP] ANAME in answer or additional section [issue #62]

Brian, Thanks for the detailed background on why DNAME worked. There are a few things that caught my attention: > When a recursive queried an authority server, if it got back a DNAME but did not understand it, it ignored the DNAME but processed the CNAME (as if only the CNAME existed) (plus any o

Re: [DNSOP] ANAME in answer or additional section [issue #62]

On 6/12/19 4:41 AM, Joe Abley wrote: > On Jun 11, 2019, at 20:11, Anthony Eden > wrote: > >> I'm a fan of Michael's suggestion of using EDNS to signal that the >> authoritative should return ALIAS vs synthesizing. Any reason this won't >> work? > > It won't work unless it's implemented. On

[DNSOP] ANAME in answer or additional section [issue #62]

All, While working on the next version of the ANAME draft, one additional question came up: When querying for A or , we want to include the ANAME in the response as a signal to anticipate aliasing. Should we include the ANAME record in the answer section or the additional section? The main

Re: [DNSOP] question regarding draft-ietf-dnsop-aname: aname section & truncation

Hi Klaus, On 5/31/19 1:13 PM, Klaus Malorny wrote: > > Hi all, > > thanks for answering my recent questions so far, but I have to bother > you with another (maybe stupid?) issue. > > I saw that for regular address queries, you moved the ANAME record from > the "answer" section to the "additiona

Re: [DNSOP] question regarding draft-ietf-dnsop-aname-03.txt/authoritative name server response

Hi Klaus, On 5/29/19 9:34 AM, Klaus Malorny wrote: > On 28.05.19 21:14, Matthijs Mekking wrote: >> Hi Klaus, >> > > Hi Matthijs, > >> I provided responses inline. > > I too. > >> >> On 5/28/19 5:49 PM, Klaus Malorny wrote: >>> &g

Re: [DNSOP] question regarding draft-ietf-dnsop-aname-03.txt/authoritative name server response

Hi Ralf, On 5/29/19 7:42 AM, Ralf Weber wrote: > Moin! > > On 28 May 2019, at 21:14, Matthijs Mekking wrote: >> For authoritative servers that receive A or requests, the address >> records shall appear only once: in the answer section. It is correct >> that tho

Re: [DNSOP] question regarding draft-ietf-dnsop-aname-03.txt/authoritative name server response

Hi Klaus, I provided responses inline. On 5/28/19 5:49 PM, Klaus Malorny wrote: > > > Hi all, > > I am working on an experimental implementation of ANAMEs in our > authoritative name server software, which shall perform its own ANAME > lookup. I am a bit puzzled what is really expected to be r

Re: [DNSOP] ANAME TTL considerations [issue #30 #34]

can be found here: https://github.com/each/draft-aname/pull/61/files Best regards, Matthijs On 5/2/19 11:21 AM, Matthijs Mekking wrote: Hi, Another issue that is still open related to ANAME is the TTL considerations. The current draft says that when updating sibling address records with

[DNSOP] ANAME TTL considerations [issue #30 #34]

Hi, Another issue that is still open related to ANAME is the TTL considerations. The current draft says that when updating sibling address records with target address records to reduce the TTL to match the ANAME TTL if it is greater. I propose a change that others have expressed as well, that is

Re: [DNSOP] ANAME precedence [issue #58]

Hi, Jan and everyone else, thanks for your feedback. It feels indeed like we should continue with the behavior that ANAME will take precedence over A and when on the same name. I shall go over the draft and see if the text is correct in that sense. Best regards, Matthijs On 4/30/19 11:56

Re: [DNSOP] ANAME precedence [issue #58]

On 4/25/19 8:34 PM, 神明達哉 wrote: > At Wed, 24 Apr 2019 11:44:37 +0200, > Matthijs Mekking <mailto:matth...@pletterpet.nl>> wrote: > >> I would like to start separate threads on the remaining issues of the >> ANAME draft. One issue that remains to be solved is

[DNSOP] ANAME precedence [issue #58]

Hi, I would like to start separate threads on the remaining issues of the ANAME draft. One issue that remains to be solved is whether having an A or record next to the ANAME should take precedence or not. Draft: https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/ Issue: https://gith

Re: [DNSOP] What should ANAME-aware servers do when target records are verifiably missing?

On 4/12/19 1:05 PM, Tony Finch wrote: > Matthew Pounsett wrote: >> >> I feel like this is creating an even bigger potential problem. What >> happens when the owner of the ANAME target legitimately wants that >> name to go away, but some other zone owner is leaving an ANAME in >> place pointing

Re: [DNSOP] ANAME discussion

, Tony Finch wrote: (Starting a new thread so my mailer doesn't sort the new discussion with messages from November!) Thanks to Matthijs Mekking for the good summary this morning. I am happy for someone else to take over editorial/authorship duties on the draft. There were several useful p

Re: [DNSOP] Minimum viable ANAME

On 3/26/19 5:10 PM, Tony Finch wrote: Matthijs Mekking wrote: I think that would be the wrong direction. I believe there is a need to standardize the ANAME resolution process and so my suggestion would be to reduce the scope by focusing just on how to do that on the provisioning side (and

Re: [DNSOP] Minimum viable ANAME

I stand corrected indeed, I just went to the mailing list to find the latest version of the draft and noticed there were many fundamental arguments. Matthijs On 3/26/19 5:19 PM, Tony Finch wrote: Matthijs Mekking wrote: The last draft did not see a lot of comments. I thought there was

Re: [DNSOP] Minimum viable ANAME

Hi Tony, On 3/26/19 4:32 PM, Tony Finch wrote: I'm overloaded at the moment so I wasn't able to rev the draft in time for IETF 104. I was planning to (basically) re-focus on the meaning of the bits on the wire, and remove any requirements about how zone contents are provisioned. Instead there wo

Re: [DNSOP] Minimum viable ANAME

That was me on the mic. To clarify: DNS open source implementers discussed it earlier this week to see if there is still appetite for ANAME. The last draft did not see a lot of comments. To get things moving again we thought it might be a good idea to make a document with reduced scope. Mat

Re: [DNSOP] Fundamental ANAME problems

Follow-up. tldr: - The first argument is just an issue of wording. - Authoritative servers or provisioning scripts that do ANAME processing should honor the target address records TTL. - Sibling address records should be used as a default if ANAME processing fails. On 11/9/18 6:54 PM, Richar

Re: [DNSOP] Fundamental ANAME problems

On 11/9/18 4:27 AM, Richard Gibson wrote: I have finally reviewed the latest draft directly, and like the overall direction but have a small number of issues (however, the issues theirselves are somewhat fundamental). They broadly break down into concerns about zone transfers and TTL stretchin

Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME

On 11/9/18 1:57 AM, Ray Bellis wrote: On 09/11/2018 07:14, Tony Finch wrote: But remember: the goal is to make the DNS easier to use for people who don’t know about the restrictions on CNAMEs. I'd say the goal is to make the DNS *possible* to use for people who don't know about the restric

Re: [DNSOP] Further ANAME minimization /\ Ray convergence

On 11/6/18 6:28 PM, Tony Finch wrote: But thinking about the discussions from the weekend and yesterday, it occurs to me that it might make sense to simplify ANAME even further: * Make all authoritative processing optional, whether UPDATE style or dynamic on-demand. * The sibling

Re: [DNSOP] Minimum viable ANAME

On 06-11-18 12:39, Ray Bellis wrote: On 06/11/2018 17:58, Matthijs Mekking wrote: That's the crux: A solution that depends on upgrading the resolvers is considered not a (fast enough) deployable solution. The HTTP record does not depend on resolvers being upgraded.   If the br

Re: [DNSOP] Minimum viable ANAME

On 06-11-18 10:19, Ray Bellis wrote: On 06/11/2018 16:15, Matthijs Mekking wrote: As nice and clean the HTTP record draft is, without specifying how to do expansion of the record into address records it is not going to solve the CNAME-at-the-apex problem that DNS providers have, and we

Re: [DNSOP] Minimum viable ANAME

As nice and clean the HTTP record draft is, without specifying how to do expansion of the record into address records it is not going to solve the CNAME-at-the-apex problem that DNS providers have, and we will stick with the proprietary solutions (this may solve a different use case though). B

Re: [DNSOP] Fundamental ANAME problems

Hi Brian, Thanks for your feedback on ANAME. Comments inline. On 01-11-18 23:34, Brian Dickson wrote: Greetings, DNSOP folks. [...] First, there is the issue of imposed update frequency. The requirement on update rate, is imposed externally by whichever entity operates the ANAME target. I

Re: [DNSOP] ANAME TTL vs GCD

changes. As a zone administrator, I prefer not having to care about TTLs too much, so I prefer the ANAME mechanism to do the sensible thing without hand-holding. I had a suggestion (from Matthijs Mekking I think?) of just using the ANAME's TTL to set the TTL of the sibling address records,

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

On 07/05/2018 06:15 PM, Tony Finch wrote: Tim Wicinski wrote: The chairs have decided to set aside some time in Montreal and see if we can work through this problem. We've asked Ondřej from ISC and Willem from NLnetLabs to help guide the talk. I was hoping that there would be another revi

Re: [DNSOP] RFC 6781 Errata?

I think the line: After that DS RR has been published on all servers authoritative for the parent's zone, the zone administrator has to wait at least TTL_DS to make sure that the old DS RR has expired from caches. Could be part of the 'DS change' step. It qualifies as an errata

Re: [DNSOP] mixfr - issue #10 - Client RRSIG logic simplification

Mark, On 04/04/2018 03:52 PM, Mark Andrews wrote: Note that implicit RRSIG deletion is idempotent, so it does not matter if two RRs in the MIXFR trigger it. Not if you are processing the additions on a RR by RR basis. You can add a new RRSIG before you add the covering RR. You need to perf

Re: [DNSOP] mixfr - issue #10 - Client RRSIG logic simplification

Joe, Thanks for sharing your concerns. On 04-04-18 05:31, Joe Abley wrote: On Apr 3, 2018, at 21:32, Frederico A C Neves wrote: On Tue, Apr 03, 2018 at 02:37:12PM +0200, Matthijs Mekking wrote: Hi Frederico, On 03/29/2018 08:45 PM, Frederico A C Neves wrote: I was looking at our server to

Re: [DNSOP] mixfr - issue #10 - Client RRSIG logic simplification

Hi Frederico, On 04-04-18 03:32, Frederico A C Neves wrote: Hi Matthijs, On Tue, Apr 03, 2018 at 02:37:12PM +0200, Matthijs Mekking wrote: Hi Frederico, On 03/29/2018 08:45 PM, Frederico A C Neves wrote: I was looking at our server to evaluate the MIXFR implementation and it seams to me

Re: [DNSOP] mixfr - issue #10 - Client RRSIG logic simplification

On 03-04-18 15:22, Mark Andrews wrote: -- Mark Andrews On 3 Apr 2018, at 22:37, Matthijs Mekking wrote: Hi Frederico, On 03/29/2018 08:45 PM, Frederico A C Neves wrote: I was looking at our server to evaluate the MIXFR implementation and it seams to me that the current text covering

Re: [DNSOP] mixfr - issue #10 - Client RRSIG logic simplification

Hi Frederico, On 03/29/2018 08:45 PM, Frederico A C Neves wrote: I was looking at our server to evaluate the MIXFR implementation and it seams to me that the current text covering dnssec aware client logic don't take in account that a posterior record at the addition section, by an MIXFR DNSSEC

Re: [DNSOP] raising the bar: requiring implementations

:18PM +0200, Matthijs Mekking wrote: As mentioned in the meeting, I am in favor of requiring implementations before drafts become standards. However, I would be opposed to limit acceptable implementations to the few major open source DNS implementations (define major). It should be acceptable for

Re: [DNSOP] A new version of mixfr

Frederico, On 03/28/2018 05:06 PM, Frederico A C Neves wrote: Hi Matthijs, On Wed, Mar 28, 2018 at 03:31:57PM +0200, Matthijs Mekking wrote: All, It's been a while, but I have put up a new version of the MIXFR draft: https://tools.ietf.org/html/draft-mekking-mixfr-02 The IET

Re: [DNSOP] A new version of mixfr

elete a whole RRset. So I do like to have some words to clarify it. But you are right that it is not a requirement. Best regards, Matthijs On 03/28/2018 09:31 AM, Matthijs Mekking wrote: All, It's been a while, but I have put up a new version of the MIXFR draft: https://urldefens

Re: [DNSOP] raising the bar: requiring implementations

On 03/28/2018 05:19 PM, Mukund Sivaraman wrote: On Wed, Mar 28, 2018 at 10:55:13AM -0400, tjw ietf wrote: I would say that most things we have adopted in the past few years do have some implementations to reference. Not when drafts are adopted, but generally before we head to WGLC I've always

Re: [DNSOP] A new version of mixfr

Pieter, On 03/28/2018 04:43 PM, Pieter Lexis wrote: Hi Matthijs, On Wed, 28 Mar 2018 15:31:57 +0200 Matthijs Mekking wrote: It's been a while, but I have put up a new version of the MIXFR draft: https://tools.ietf.org/html/draft-mekking-mixfr-02 The draft speaks of an OPCode i

Re: [DNSOP] A new version of mixfr

Tony, On 03/28/2018 04:08 PM, Tony Finch wrote: Matthijs Mekking wrote: It's been a while, but I have put up a new version of the MIXFR draft: https://tools.ietf.org/html/draft-mekking-mixfr-02 I've had a quick skim and it looks nice. Thanks. Suggestions for 2nd pa

[DNSOP] A new version of mixfr

All, It's been a while, but I have put up a new version of the MIXFR draft: https://tools.ietf.org/html/draft-mekking-mixfr-02 The IETF 101 Hackathon lead to the revival of this draft. Changes after the three year sleep: - I removed the IXFR Gone Wild section. This document should focus i

Re: [DNSOP] DNS Camel Viewer

Nice viewer :) What immediately catches my eye is that the DNSSEC RFCs 4033-4034-4035 are a Proposed Standard, and RFC 5011 is an Internet Standard. In fact, RFC 5011 is the only DNSSEC Internet Standard. That can't be right, right? :) Matthijs On 24-03-18 17:51, bert hubert wrote: Hi ev

Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

On 24-03-18 14:48, Joe Abley wrote: On Mar 24, 2018, at 13:49, Jared Mauch wrote: isc/bind can and perhaps should implement logging for these rrtypes that say they may be going away so folks can see the impact. I'm actually surprised to see that support for rarely-used RRTypes is reall

Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

Other candidates: MD, NXT, MAILA - They are obsolete too according to the IANA DNS parameters. Also, if you want to deprecate MB, MG, you might want to consider deprecating MAILB too. - Matthijs On 23-03-18 13:11, Ondřej Surý wrote: Heya, this is a first attempt to start reducing the load

Re: [DNSOP] Multi Provider DNSSEC Models

I agree, model 1 and model 2 seems doable. Note that RFC 6781 has some text for model 2 on rollover when changing DNS operators. https://tools.ietf.org/html/rfc6781#section-4.3.5 Matthijs On 22-03-18 13:50, Tony Finch wrote: Olafur Gudmundsson wrote: I think only Model #1 makes sense, i.e

Re: [DNSOP] Status of draft-ietf-dnsop-terminology-bis

On 19-03-18 20:08, Matthew Pounsett wrote: On 19 March 2018 at 08:21, Matthijs Mekking <mailto:matth...@pletterpet.nl>> wrote: I and some others have been using the term 'Negative response' to indicate that the response does not contain any records in the

Re: [DNSOP] Status of draft-ietf-dnsop-terminology-bis

Hi, While I was not waiting for WG last call, it is a while ago since I have read this draft. Positive is that I read it without it leading to a lot of confusion or outrage. I have some small comments though. Negative response: I and some others have been using the term 'Negative response

Re: [DNSOP] [Technical Errata Reported] RFC6781 (5273)

All, I think this errata is incorrect: For an algorithm rollover it is intended that at the "DNSKEY removal" step, the DNSKEYs are removed from the zone, but the signatures stay. This is to play nicely with conservative validators: The conservative approach interprets this section very st

Re: [DNSOP] 5011-security-considerations and the safetyMargin

Wes, My preference is to include safetyMargin and have text to explain it exists because of network delays etcetera, and also reference to RFC 5011's retryTime. So that's some mix of 1B 1C or 2B I guess :) Best regards, Matthijs On 15-11-17 02:49, Wes Hardaker wrote: The discussion has b

Re: [DNSOP] [Technical Errata Reported] RFC6781 (5174)

Hi, This errata appears to be valid. In addition, the following text must also be corrected, from: The rest of the zone data has the same signature as the SOA record, i.e., an RRSIG created with DNSKEY_K_14. to: The rest of the zone data has the same signature as the SOA record,

Re: [DNSOP] requesting WGLC for 5011-security-considerations

Wes, On 06-09-17 18:05, Wes Hardaker wrote: > Matthijs Mekking writes: > > Thanks for all your points, and I've gone through and handled them all > in the text (including discussing that we update 7583 per your request). > >> 2. waitTime only adds one queryInterv

Re: [DNSOP] requesting WGLC for 5011-security-considerations

Wes, It's been a while since I have had a look at this draft, my apologies. I don't think it is ready for WGLC because I am not convinced the math is correct. Section 6 defines the waitTime: waitTime = addHoldDownTime + (DNSKEY RRSIG Signature Validity) + MAX

Re: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dns-opportunistic-refresh-00.txt

On 04-07-17 10:35, Mukund Sivaraman wrote: BIND's resolver ECS does not cache SOA against an address prefix, but on the authoritative side, note that there is no master file or zone representation for zones with ECS. It is quite possible that if the auth side is using different zone sources for

  1   2   3   >