Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
> On 20 Jun 2023, at 23:35, Dick Franks wrote: > > On Tue, 20 Jun 2023 at 22:20, Roy Arends wrote: >> 8 > >> >> The change was from -03 to -04 and discussed in the WG IIRC. The specific >> sentence your refer to was a lingering oversight in the changes from -03 to >> -04. I have consulted many developers on this, and so far I had no push back. >> >>> explicitly querying the authoritative server for the appropriate >>> report channel to a dependence on authoritatives attaching an >>> (unsolicited) EDNS0 report channel option to each and every query. >> >> No. >> >> An authoritative server includes the option if configured to do so AND if it >> has the a non-null domain name configured as the reporting channel. It will >> then reply to each query. This is IMHO better than having a resolver include >> the option each and every time. Note that resolvers will ignore options that >> are unknown to them. > > 6.2. Authoritative server specification > Contains not a shred of normative language saying any of that. > > The preliminary waffle in the overview could apply to either the > solicited or unsolicited regime. > >>> I withdraw my earlier statement that the document is almost ready. >>> Now, clearly it is not. >> >> I hear you. I do not agree though, and I hope you reconsider > Not without further work Please send text. Roy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
On Tue, 20 Jun 2023 at 22:20, Roy Arends wrote: >8 > > The change was from -03 to -04 and discussed in the WG IIRC. The specific > sentence your refer to was a lingering oversight in the changes from -03 to > -04. I have consulted many developers on this, and so far I had no push back. > > > explicitly querying the authoritative server for the appropriate > > report channel to a dependence on authoritatives attaching an > > (unsolicited) EDNS0 report channel option to each and every query. > > No. > > An authoritative server includes the option if configured to do so AND if it > has the a non-null domain name configured as the reporting channel. It will > then reply to each query. This is IMHO better than having a resolver include > the option each and every time. Note that resolvers will ignore options that > are unknown to them. 6.2. Authoritative server specification Contains not a shred of normative language saying any of that. The preliminary waffle in the overview could apply to either the solicited or unsolicited regime. > > I withdraw my earlier statement that the document is almost ready. > > Now, clearly it is not. > > I hear you. I do not agree though, and I hope you reconsider Not without further work --rwf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
Correction Deleting that one sentence changes the meaning of the proposal from explicitly querying the authoritative server for the appropriate report channel to a dependence on authoritatives attaching an -(unsolicited) EDNS0 report channel option to each and every query. +(unsolicited) EDNS0 report channel option to the reply for each and every query. --Dick ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
> On 20 Jun 2023, at 21:39, Dick Franks wrote: > > On Tue, 20 Jun 2023 at 12:21, Roy Arends wrote: >> 8 > >>> On 20 Jun 2023, at 12:14, Willem Toorop wrote: >> 8 > >>> I have one nit. >>> >>> In the Example in section 4.2., a request still "includes an empty ENDS0 >>> report channel". The third paragraph of that same section states something >>> similar: "As support for DNS error reporting was indicated by a empty EDNS0 >>> report channel option in the request". But Section 6.1. Reporting Resolver >>> Specification states: "The EDNS0 report channel option MUST NOT be included >>> in queries." >>> >>> I believe the text in the Example section is a left over from an earlier >>> version and should be corrected. >> >> Ah, yes, I will remove that sentence completely! > > WGLC is supposed to be a review, nit-picking and clarification process. That is correct. > Deleting that one sentence changes the meaning of the proposal from No! The change was from -03 to -04 and discussed in the WG IIRC. The specific sentence your refer to was a lingering oversight in the changes from -03 to -04. I have consulted many developers on this, and so far I had no push back. > explicitly querying the authoritative server for the appropriate > report channel to a dependence on authoritatives attaching an > (unsolicited) EDNS0 report channel option to each and every query. No. An authoritative server includes the option if configured to do so AND if it has the a non-null domain name configured as the reporting channel. It will then reply to each query. This is IMHO better than having a resolver include the option each and every time. Note that resolvers will ignore options that are unknown to them. > That is a fundamental change to the document, and certainly not a nit-pick. This was an older change, though. It was indeed fundamental, but there was a thought behind this. > I withdraw my earlier statement that the document is almost ready. > Now, clearly it is not. I hear you. I do not agree though, and I hope you reconsider. Roy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
On Tue, 20 Jun 2023 at 12:21, Roy Arends wrote: >8 > > On 20 Jun 2023, at 12:14, Willem Toorop wrote: >8 > > I have one nit. > > > > In the Example in section 4.2., a request still "includes an empty ENDS0 > > report channel". The third paragraph of that same section states something > > similar: "As support for DNS error reporting was indicated by a empty EDNS0 > > report channel option in the request". But Section 6.1. Reporting Resolver > > Specification states: "The EDNS0 report channel option MUST NOT be included > > in queries." > > > > I believe the text in the Example section is a left over from an earlier > > version and should be corrected. > > Ah, yes, I will remove that sentence completely! WGLC is supposed to be a review, nit-picking and clarification process. Deleting that one sentence changes the meaning of the proposal from explicitly querying the authoritative server for the appropriate report channel to a dependence on authoritatives attaching an (unsolicited) EDNS0 report channel option to each and every query. That is a fundamental change to the document, and certainly not a nit-pick. I withdraw my earlier statement that the document is almost ready. Now, clearly it is not. --rwf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)
It appears that Peter Thomassen said: >My take is that the parent should create a _signal subdomain (preferably as a >delegation). The per-child target can be queried by prepending, e.g. > > _notify.example._signal.parent. IN NOTIFY CDS scheme port > scanner.registrar.example. > >This way, the parent can announce the registrar's NOTIFY endpoint. This can be >synthesized dynamically, no need to maintain a large zone. >As _signal can be delegated, only one (rather normal) NS RRset is required in >the parent, and the magic can be done on a different >nameserver. While I can see how that might work in principle, I find it hard to imagine registries and registrars making it work. At the least it'd need new EPP stuff to tell the registry what signal records to add or delete. >> I guess if the targets are fairly static, then putting it in the >> configuration rather than sticking it in the DNS will be good enough. > >How would a random DNS operator know the registrar of their customer zones? >How would they learn when it changes? They'd ask the customer "who's your registrar" when they set up the zone. This still misses the hard part about how the notify knows where to expect the notifies from. I suppose by default it could be the delegated NS, but in interestingly large setups, that's not likely to be adequate. If the customer changes registrars, they have to tell the DNS operator but that's easier than the current hacks to try and move DS records from one registrar to another. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Coming soon: WG interim meeting on the definition of "lame delegation"
I’ve just come across this message (I have been out a bit recently)…sorry is this is late. These are suggestions… For the situation where a (an active) nameserver is not configured to answer a query it received (which is the case where my use of lame delegation comes from), I’d suggest the following more accurate labels: “out of bailiwick query” - from the perspective of the server, the query is something it can’t answer “incorrect referral” - from the perspective of the recipient of the answer (= the querier, hopefully) as it was told to go there by some other party (the parent), but it’s a dead end. For the situation where there is a problem related to the delegation of a domain to a set of nameservers: “incorrect delegation” or “malformed delegation” or perhaps “some-other-adjective delegation” - a third party view of a situation stated by one party (the parent zone file) and refuted by another party (the collective landing points of the referral). The latter parenthesized comment is meant to include IP addresses that are not actively hosting something answering on port 53 - in addition to nameservers experiencing “out of bailiwick” queries. From: DNSOP on behalf of Paul Hoffman Date: Saturday, June 17, 2023 at 5:00 PM To: dnsop Subject: [Ext] [DNSOP] Coming soon: WG interim meeting on the definition of "lame delegation" Greetings again. A bunch of you have opinions in this area. In advance of our WG interim meeting on Tuesday, it would be grand if people with opinions would review those opinions and review the threads on the list where other peoples' opinions were expressed. This will make our time together in the interim meeting more valuable. FWIW, I'm glad I'm not the one who will be deciding consensus here; the chairs will be. --Paul Hoffman Begin forwarded message: From: IESG Secretary Subject: [Ext] [DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2023-06-20 Date: June 6, 2023 at 7:19:23 AM PDT To: "IETF-Announce" Cc: dnsop@ietf.org The Domain Name System Operations (dnsop) WG will hold a virtual interim meeting on 2023-06-20 from 20:00 to 21:00 Europe/Amsterdam (18:00 to 19:00 UTC). Agenda: ## Agenda ### Administrivia * Agenda Bashing, Blue Sheets, etc, 5 min ### Current Working Group Business * DNS Terminology and definition "lame delegation" - https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/ - WG Chairs, Paul Hoffman and Kazunori Fujiwara, 55 min - Chairs Action: Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=7e86a1ea-71f7-40c0-8c34-eb16a1a57a6e -- A calendar subscription for all dnsop meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: Coming soon: WG interim meeting on the definition of "lame delegation"
From: DNSOP on behalf of Vladimír Čunát Date: Tuesday, June 20, 2023 at 6:01 AM To: "dnsop@ietf.org" Subject: [Ext] Re: [DNSOP] Coming soon: WG interim meeting on the definition of "lame delegation" >On 19/06/2023 17.00, Masataka Ohta wrote: >>I can't see any problem with "lame" delegation than a "secondary" or "slave" server, because of the history of racial discrimination in US. >Honestly, I'm personally still failing understand the problem of using >slightly offending word when referring to a machine (e.g. "slave" or "lame"). I sympathize, but when communicating, there are three elements - the sender, the medium, and the recipient. Even if the sender doesn’t see a term as problematic, the recipient might, and that can hamper the communication. As the word about the technology with which we surround ourselves spills out into other communities, it’s good to shake off our jargon so that others may understand, accept, listen, and learn what is necessary. The “old labels” may have been arbitrarily applied and, unless you’ve walked the path for a long time, the terms are not accurately descriptive. In this case, that there are multiple meanings to “lame delegation” tell me that it is time to have a more precise labelling, or we will continue to confuse ourselves. In an earlier message, what I experienced as “lame” was the situation where the query seen by a server was one that the server had no answer. “Lame” isn’t all that descriptive, whether or not some may see it as an insulting term. (I’ll leave my soft peddled suggestions for the other message. 😉 ) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPCall for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory
Hi Wes, On 6/9/23 19:43, Wes Hardaker wrote: For lame delegations, I think discussion is needed further. It's unclear from the draft at the moment (and I think it needs to be very clear) about what to do with servers that are lame. It discusses whether or not CDS/CDNSKEY/CSYNC are supposed to do when the server is unresponsive, but not with respect to other errors or situations and I think some clarity would be helpful here. I think it's important that we deal with the multi-signer case, and that point is very clear (and correct). But we also do need to be able, as a child, to update a parent's records when a nameserver has gone offline or stopped responding appropriately. This is very different than one NS taking over -- IE, I agree that this is the principle thing to defend against. But we also need to be able to efficiently recover from operational situations. Nameservers that went offline are taken care of because the mechanism only requires that the received responses are consistent (not that responses are received from all nameservers). Lame delegations and otherwise inappropriately responding nameservers are indeed problematic, and I'm looking forward to explore more. However, my current gut feeling is that such kinds of mess-ups cannot sufficiently reliably be detected and dealt with automatically. For example, you cannot reliably detect the cause of REFUSED (including "expired from nameserver" during provider change, or on-wire manipulation suppressing a conflicting response, or whatever else). As such, I'd think that the goal of the document should be automation of the "proper" case, with broken cases continuing to require manual intervention. Nits as long as I was reading it with a red pen: - Introduction: CSYNC updates both NS *and glue* records Section 3.2 mentions "data records" and lists NS as an example -- but yes, that could be more clear. I'll make a note. - Lame delegations: "on the other hand, if the delegation is not protected by DNSSEC," -- I don't understand this because all three record types require DNSSEC to be in place and valid for any of the records to work. No changes should ever be permitted without both present and valid signatures. Maybe I'm misunderstanding the paragraph though. RFC 8078 Section 3.3 allows turning on DNSSEC without a pre-existing chain of trust. An attacker how hijacked on the nameserver hostnames (after its domain expired) can exploit this mechanism. The delay prescribed there doesn't help in the situation at hand. If consistency across NS is not checked, you'll just have to wait long enough until the parent hits the attacker's nameserver several days in a row, and then DNSSEC is enabled. - Section 3 is likely where service failure / error conditions need to be discussed more fully (IMHO). Ack. - 3.2 CSYNC: There are a few things to check here and all the servers should be consistent with all the records for changes to be made: the CSYNC record itself, the NS records and the glue records. (or since CSYNC is generic: the CSYNC record and any records it is referring to). IE, the CSYNC records could be equal but the NS records need to be checked for equivalence at each server too. This is what the last paragraph of Section 3.2 is trying to say, but apparently it's not clear enough. I'll make a note. Thanks for the feedback. Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Multiple drafts discussing the use of DNS NOTIFY
On Tue, 20 Jun 2023, Peter Thomassen wrote: My thoughts on this as in how to decide who does what, is... in EPP, there is a section that I've coded to look like... The usual drop downs are Yes/No and may require a reason Create a new action, "DS Managed by", give it three options Y=the registrY should manage the CDS scanning (Polling whatever) R=the registraR should manage... N=Implicit management by the Registrar. This would be a change / an extension to the EPP protocol, correct? If so, there's probably not much DNSOP can do about it, but if I'm not mistaken, the REGEXT WG is chartered to address such things. Yes that would be REGEXT. But I don't think this will help either. It's default would have to depend on the registry capability, and then on the registrar capability. That doesn't help the DNS Hoster if it is not the Registrar as well. That is why we are having this problem to begin with. We want DNS Hosters to be able to be the authoritative source of DS, because too many registrars aren't implementing C* There was also a proposal/draft in REGEXT that would allow the Registry to notify the Registrar if a CDS was changed via polling/registry direct communication. I'm not sure if that ever made it to RFC though. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Multiple drafts discussing the use of DNS NOTIFY
Hi Mark, On 6/13/23 16:43, Mark Elkins wrote: There are registries doing CDS scanning now, and registrars testing it. I agree that the flow back to the registrar if the registry does it is ugly so registrar is better where possible. We'll probably end up with both since some registrars aren't up to it. [...] My thoughts on this as in how to decide who does what, is... in EPP, there is a section that I've coded to look like... The usual drop downs are Yes/No and may require a reason Create a new action, "DS Managed by", give it three options Y=the registrY should manage the CDS scanning (Polling whatever) R=the registraR should manage... N=Implicit management by the Registrar. This would be a change / an extension to the EPP protocol, correct? If so, there's probably not much DNSOP can do about it, but if I'm not mistaken, the REGEXT WG is chartered to address such things. Best, Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)
On 6/20/23 17:48, Paul Wouters wrote: 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). Agreed. That's not what the TLDs said during "timers vs triggers". They did not want NOTIFY's towards their production nameservers. The draft does not propose that. That might have changed, but I would like to hear from the big TLDs that they are now in favour of this and would deploy. The drive is this time not coming from the parent side, but from discussions around DS automation at recent ICANN DNSSEC workshops, and DNSSEC multi-signer scenarios. The main two arguments made there were scaling concerns for large parent zones (although I don't think these concerns are supported by data), and better predictability (for child-side entities) of when C* records can be expected to be discovered and processed. It would indeed be interesting to learn what TLD registries have to say, specifically those who already have quite advanced CDS scanners (e.g. SWITCH, who also have implemented authenticated bootstrapping). If not, perhaps a level of indirection via service record should be used to point to a specific server (which could still accept NOTIFY) outside of the parental NS RRset. That's the point of the NOTIFY record (whose field list may be reduced, perhaps eventually to a CNAME, see other postings). Also the registrars did not like being circumvented. While now some registars might have changed their mind (or don't care since they are both registrar and dns hosting for most of their domains), it would be good to hear from them. Agreed; there are various good arguments for why the scanning should be done by the registrar (if there is one). But I don't see why this would be a problem with regards to NOTIFY (we can make it work by prepending the child label to the service record qname). Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)
On 6/20/23 17:51, Paul Wouters wrote: parent. IN NOTIFY CDS scheme port scanner.parent. Why a new RRtype ? Why more stuff in the APEX? Why not: _notify_cds.parent. IN CNAME targetservice.parent. targetservice.parent. IN A . targetservice.parent. IN . Personally, I'm fine with simplifying to your approach; I would only add the child label prefix to allow for per-child flexibility (and if you don't need that, just set a wildcard). The authors' thinking was that a new record type would allow both specifying the port and a scheme field, anticipating that people might appreciate flexibility for future mechanisms and stir discussion about that. But if it's not needed -- the simpler the better! Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)
On Tue, 20 Jun 2023, Matthijs Mekking wrote: If there are different targets for different children of the same parent, then a generic NOTIFY record like below won't work anyway. parent. IN NOTIFY CDS scheme port scanner.parent. Why a new RRtype ? Why more stuff in the APEX? Why not: _notify_cds.parent. IN CNAME targetservice.parent. targetservice.parent. IN A . targetservice.parent. IN . I guess if the targets are fairly static, then putting it in the configuration rather than sticking it in the DNS will be good enough. I would like to not ship such hardcoded lists with my OS :) Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)
On Tue, 20 Jun 2023, 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 to overloading). Agreed. That's not what the TLDs said during "timers vs triggers". They did not want NOTIFY's towards their production nameservers. That might have changed, but I would like to hear from the big TLDs that they are now in favour of this and would deploy. If not, perhaps a level of indirection via service record should be used to point to a specific server (which could still accept NOTIFY) outside of the parental NS RRset. Also the registrars did not like being circumvented. While now some registars might have changed their mind (or don't care since they are both registrar and dns hosting for most of their domains), it would be good to hear from them. A note on where to send CDS and CSYNC notifications. I sort of understand why the NOTIFY record includes a RRtype field, but will parental entities really have a different target for receiving notifies for CDS and CSYNC? I've talked to Peter at some length. The problem is that you will often have different targets for different children of the same parent, i.e., registrars rather than registries, and I don't see any good way of putting per-child info in the parent, particularly a large parent like .ORG or .COM. The DNS hoster needs to reach the DNS parent. Why wouldn't the parent, eg via a single service record, have a service suitable for all of its children? The existing NOTIFY for AXFR is perfectly usable without a mechanical way to say where to send the notifications, so my proposal is to continue not to have one. All of the existing AXFR NOTIFY receivers I know have ACLs to only accept notifications from relevant primary servers, often hidden ones not visible in the DNS, so even if the proposal in 5.1 didn't have scaling problems, it only addresses half the problem. So take it out. So you now have 2 half problems? TLDs need (AFAIK from previous discussion) a way to receive NOTIFYs that's not on the IPs of their NS RRset. Let's give them one. I don't think an ACL is needed, just a rate limit to block abusive IP blocks should be enough? Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)
Hi, On 6/20/23 17:37, Matthijs Mekking wrote: A note on where to send CDS and CSYNC notifications. I sort of understand why the NOTIFY record includes a RRtype field, but will parental entities really have a different target for receiving notifies for CDS and CSYNC? I've talked to Peter at some length. The problem is that you will often have different targets for different children of the same parent, i.e., registrars rather than registries, and I don't see any good way of putting per-child info in the parent, particularly a large parent like .ORG or .COM. If there are different targets for different children of the same parent, then a generic NOTIFY record like below won't work anyway. parent. IN NOTIFY CDS scheme port scanner.parent. My take is that the parent should create a _signal subdomain (preferably as a delegation). The per-child target can be queried by prepending, e.g. _notify.example._signal.parent. IN NOTIFY CDS scheme port scanner.registrar.example. This way, the parent can announce the registrar's NOTIFY endpoint. This can be synthesized dynamically, no need to maintain a large zone. As _signal can be delegated, only one (rather normal) NS RRset is required in the parent, and the magic can be done on a different nameserver. Alternatively, the parent can deploy a static wildcard: *._signal.parent. IN NOTIFY CDS scheme scanner.parent. That would be a very small, static zone. This applies when the parent does the scanning themself, or when they want to forward the NOTIFY to the registrar behind the scenes. (I'm not saying this should be done; I'm saying that this method is suitable for all kinds of scenarios.) The existing NOTIFY for AXFR is perfectly usable without a mechanical way to say where to send the notifications, so my proposal is to continue not to have one. All of the existing AXFR NOTIFY receivers I know have ACLs to only accept notifications from relevant primary servers, often hidden ones not visible in the DNS, so even if the proposal in 5.1 didn't have scaling problems, it only addresses half the problem. So take it out. I guess if the targets are fairly static, then putting it in the configuration rather than sticking it in the DNS will be good enough. How would a random DNS operator know the registrar of their customer zones? How would they learn when it changes? Cheers, Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 to overloading). Agreed. A note on where to send CDS and CSYNC notifications. I sort of understand why the NOTIFY record includes a RRtype field, but will parental entities really have a different target for receiving notifies for CDS and CSYNC? I've talked to Peter at some length. The problem is that you will often have different targets for different children of the same parent, i.e., registrars rather than registries, and I don't see any good way of putting per-child info in the parent, particularly a large parent like .ORG or .COM. If there are different targets for different children of the same parent, then a generic NOTIFY record like below won't work anyway. parent. IN NOTIFY CDS scheme port scanner.parent. The existing NOTIFY for AXFR is perfectly usable without a mechanical way to say where to send the notifications, so my proposal is to continue not to have one. All of the existing AXFR NOTIFY receivers I know have ACLs to only accept notifications from relevant primary servers, often hidden ones not visible in the DNS, so even if the proposal in 5.1 didn't have scaling problems, it only addresses half the problem. So take it out. I guess if the targets are fairly static, then putting it in the configuration rather than sticking it in the DNS will be good enough. Matthijs R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-01)
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 to overloading). Agreed. >A note on where to send CDS and CSYNC notifications. I sort of >understand why the NOTIFY record includes a RRtype field, but will >parental entities really have a different target for receiving notifies >for CDS and CSYNC? I've talked to Peter at some length. The problem is that you will often have different targets for different children of the same parent, i.e., registrars rather than registries, and I don't see any good way of putting per-child info in the parent, particularly a large parent like .ORG or .COM. The existing NOTIFY for AXFR is perfectly usable without a mechanical way to say where to send the notifications, so my proposal is to continue not to have one. All of the existing AXFR NOTIFY receivers I know have ACLs to only accept notifications from relevant primary servers, often hidden ones not visible in the DNS, so even if the proposal in 5.1 didn't have scaling problems, it only addresses half the problem. So take it out. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2023-06-20
Dear WG, We have agenda, slides and meeting details for Meetecho, Zulip, etc., available on datatracker: https://datatracker.ietf.org/meeting/interim-2023-dnsop-01/session/dnsop Best, -- Benno On 06/06/2023 16:19, IESG Secretary wrote: The Domain Name System Operations (dnsop) WG will hold a virtual interim meeting on 2023-06-20 from 20:00 to 21:00 Europe/Amsterdam (18:00 to 19:00 UTC). Agenda: ## Agenda ### Administrivia * Agenda Bashing, Blue Sheets, etc, 5 min ### Current Working Group Business * DNS Terminology and definition "lame delegation" - https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/ - WG Chairs, Paul Hoffman and Kazunori Fujiwara, 55 min - Chairs Action: Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=7e86a1ea-71f7-40c0-8c34-eb16a1a57a6e -- A calendar subscription for all dnsop meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
On Tue, 20 Jun 2023 at 12:14, Willem Toorop wrote: >8 > In the Example in section 4.2., a request still "includes an empty ENDS0 > report channel". The third paragraph of that same section states > something similar: "As support for DNS error reporting was indicated by > a empty EDNS0 report channel option in the request". The only way to discover the destination for the error report is to repeat the original failed query adding the empty EDNS0 report channel option. The subsequent error report relates to the original failed query and in no way depends upon the failure or otherwise of the second attempt. > ... But Section 6.1. > Reporting Resolver Specification states: "The EDNS0 report channel > option MUST NOT be included in queries." - The EDNS0 report channel option MUST NOT be included in queries. + The EDNS0 report channel option MUST NOT be included in report queries. --rwf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
Thank Dick! > On 16 Jun 2023, at 18:33, Dick Franks wrote: > > All > > I have reviewed the document which appears to be almost ready for > submission to IESG. > > > Subsection 6.1.1 uses QNAME to refer to two different entities. > The opening sentence needs to say nothing more than that the report > query is a concatenation of the listed items. > The conflicting usage is easily resolved by rewording the third item. > > 6.1.1. Constructing the Report Query > >The QNAME for the report query is constructed by concatenating the > - following elements, appending each successive element in the list to > - the right-hand side of the QNAME: > + following elements: > >* A label containing the string "_er". > >* The QTYPE that was used in the query that resulted in the extended > DNS error, presented as a decimal value, in a single DNS label. > > - * The QNAME that was used in the query that resulted in the extended > - DNS error. The QNAME may consist of multiple labels and is > - concatenated as is, i.e. in DNS wire format. > + * The list of non-null labels representing the query which is the > + subject of the DNS error report. > >* The extended DNS error, presented as a decimal value, in a single > DNS label. > Much better, will update. Thanks for the review and implementation support! Roy > > Regards > > Dick Franks > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
Hoi Willem, > On 20 Jun 2023, at 12:14, Willem Toorop wrote: > > Op 08-06-2023 om 11:59 schreef Benno Overeinder: >> Dear DNSOP WG, >> >> The authors and the chairs feel this document has reached the stage where >> it's ready for Working Group Last Call. >> >> This starts a Working Group Last Call for: >> draft-ietf-dnsop-dns-error-reporting. > > Dear all, > > I find this is a very valuable addition to the DNS protocol for zone owners > and authoritative operators. It also opens up potential for valuable future > extensions, such as for example dy-run DNSSEC example ;). > > I have spend a few IETF hackathons on Proof of Concept implementations, and I > can report that it is very straight-forward to implement. The draft PR for > Unbound that emerged from those hackathons, is already almost the finished > feature: https://github.com/NLnetLabs/unbound/pull/902 (still pending the > EDNS0 opcode though!) > > I have one nit. > > In the Example in section 4.2., a request still "includes an empty ENDS0 > report channel". The third paragraph of that same section states something > similar: "As support for DNS error reporting was indicated by a empty EDNS0 > report channel option in the request". But Section 6.1. Reporting Resolver > Specification states: "The EDNS0 report channel option MUST NOT be included > in queries." > > I believe the text in the Example section is a left over from an earlier > version and should be corrected. Ah, yes, I will remove that sentence completely! Thanks for the review and the work on the implementations. Roy > > > Thanks to Roy, and all the other people who worked on this! > > -- Willem > >> >> Current versions of the draft is available here: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/. >> >> The Current Intended Status of this document is: Standards Track. >> >> Please review the draft and offer relevant comments. >> If this does not seem appropriate please speak out. >> If someone feels the document is *not* ready for publication, please speak >> out with your reasons. >> Supporting statements that the document is ready are also welcome. >> >> This starts a two week Working Group Last Call process, and ends on: June >> 22nd, 2023. >> >> Thanks, >> >> -- Benno >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
Op 08-06-2023 om 11:59 schreef Benno Overeinder: Dear DNSOP WG, The authors and the chairs feel this document has reached the stage where it's ready for Working Group Last Call. This starts a Working Group Last Call for: draft-ietf-dnsop-dns-error-reporting. Dear all, I find this is a very valuable addition to the DNS protocol for zone owners and authoritative operators. It also opens up potential for valuable future extensions, such as for example dy-run DNSSEC example ;). I have spend a few IETF hackathons on Proof of Concept implementations, and I can report that it is very straight-forward to implement. The draft PR for Unbound that emerged from those hackathons, is already almost the finished feature: https://github.com/NLnetLabs/unbound/pull/902 (still pending the EDNS0 opcode though!) I have one nit. In the Example in section 4.2., a request still "includes an empty ENDS0 report channel". The third paragraph of that same section states something similar: "As support for DNS error reporting was indicated by a empty EDNS0 report channel option in the request". But Section 6.1. Reporting Resolver Specification states: "The EDNS0 report channel option MUST NOT be included in queries." I believe the text in the Example section is a left over from an earlier version and should be corrected. Thanks to Roy, and all the other people who worked on this! -- Willem Current versions of the draft is available here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/. The Current Intended Status of this document is: Standards Track. Please review the draft and offer relevant comments. If this does not seem appropriate please speak out. If someone feels the document is *not* ready for publication, please speak out with your reasons. Supporting statements that the document is ready are also welcome. This starts a two week Working Group Last Call process, and ends on: June 22nd, 2023. Thanks, -- Benno ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Coming soon: WG interim meeting on the definition of "lame delegation"
On 19/06/2023 17.00, Masataka Ohta wrote: I can't see any problem with "lame" delegation than a "secondary" or "slave" server, because of the history of racial discrimination in US. Honestly, I'm personally still failing understand the problem of using slightly offending word when referring to a machine (e.g. "slave" or "lame"). I'll try to keep myself very short, also trying to avoid posting followup reactions. But perhaps some of you could point me to a reference that might help me understand better, as this is recurring in the recent years (also outside DNS). Of course I respect that if a *significant* fraction of people does see a problem, I can also move on to another set of terms, but I feel like I'm missing substance and often the renames come with nontrivial costs. Why would a person take offense when those words are *clearly* about a machine? In reality we treat these machines worse than human slaves were treated. --Vladimir ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop