Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting

[Roy Arends]

> 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

[Dick Franks]

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

[Dick Franks]

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

[Roy Arends]

> 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

[Dick Franks]

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)

[John Levine]

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"

[Edward Lewis]

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"

[Edward Lewis]

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

[Peter Thomassen]

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

[Paul Wouters]

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

[Peter Thomassen]

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)

[Peter Thomassen]

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)

[Peter Thomassen]

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)

[Paul Wouters]

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)

[Paul Wouters]

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)

[Peter Thomassen]

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)

[Matthijs Mekking]

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)

[John Levine]

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

[Benno Overeinder]

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

[Dick Franks]

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

[Roy Arends]

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

[Roy Arends]

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

[Willem Toorop]

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"

[Vladimír Čunát]

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

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

[Matthijs Mekking]

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 


https://datatracker.ietf.org/doc/html/draft-dsawp-notify-00 



Mr Thomassen's draft is a bit more ambitious than Mr. Levine's draft, 
but both appear to work on the problem space of DNSSEC update 
automation.  The chairs are big fans of work around making DNSSEC 
deployment more operationally resilient.


We have some questions for the WG - if DNSOP adopted one of these, would 
DNS server vendors implement it down the road? (We think so)


I would definitely want to implement a CDS notify to the parent. It 
would help getting rid of the wasteful polling and we can reuse existing 
NOTIFY code. It feels like a good Hackathon project :)


It looks to me that this mechanism consists of three parts:

1. Notify the parent of a CDS/CDNSKEY/CSYNC change.
2. Notify a signer in a multi-signer group of DNSKEY/CDS/CDNSKEY change.
3. Locating the server to notify (NOTIFY record).

It seems that John Levine's draft is mainly covering part 1, while the 
draft from Johan and Peter covers all three.


I don't know if all three parts should be covered in one document, 
although they are strongly connected to each other.


I think the part about multi-signer may face the biggest challenges (see 
my comments on the Generalized DNS Notifications draft), so I if that 
turns out to slow down things, I wouldn't mind focusing on DS automation 
first, and perhaps a successor document that can tackle the multi-signer 
scenario.


Best regards,

Matthijs

The ICANN SSAC has been looking at this issue, so the ICANN meeting this 
coming week may be a good time for technical folks to discuss some of 
these ideas.


Feedback Welcome

thanks
tim



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

[Matthijs Mekking]

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


For the sender of the notifies, this may be cumbersome to do different 
lookups that probably end up being the same target.


Related to this, when it comes to the multi-signer model, you do not 
only need to send DNSKEY notifications, but also CDS and CSYNC 
notifications to the other signers, especially if you want these RRsets 
to be consistent with each other. Follwing up on the example in Section 
5.1 that would mean we need additional NOTIFY records:


child.parent. IN NOTIFY DNSKEY 1 5361 scanner.signerA.
child.parent. IN NOTIFY DNSKEY 1 5361 scanner.signerB.
child.parent. IN NOTIFY DNSKEY 1 5361 ctrl.multi-signer.example.
child.parent. IN NOTIFY CDS 1 5361 scanner.signerA.
child.parent. IN NOTIFY CDS 1 5361 scanner.signerB.
child.parent. IN NOTIFY CDS 1 5361 ctrl.multi-signer.example.
child.parent. IN NOTIFY CSYNC 1 5361 scanner.signerA.
child.parent. IN NOTIFY CSYNC 1 5361 scanner.signerB.
child.parent. IN NOTIFY CSYNC 1 5361 ctrl.multi-signer.example.

That becomes quite a set already.

Perhaps we should differentiate on type of server (parent, signer, ...) 
rather than RRtype?




Finally, about the open question for DNSKEY notifications. You say: As 
the number of signers for a particular zone is low, there is no major 
problem caused by not knowing which signer sent the notification and 
instead always check all the signers for updates to the DNSKEY RRset.


How would you identify which is the newer DNSKEY RRset? If the 
multi-signer controller checks two signers and receives the following 
RRsets:


example.nl. 3600 IN DNSKEY 257 3 13 I5Cq...
example.nl. 3600 IN DNSKEY 257 3 13 Hkpb...

example.nl. 3600 IN DNSKEY 257 3 13 I5Cq...
example.nl. 3600 IN DNSKEY 257 3 13 Hkpb...
example.nl. 3600 IN DNSKEY 257 3 13 1Wut...

How would it know if a DNSKEY was added or removed from the RRset. This 
obviously requires some state. And I suspect it works slightly different 
again in a decentralized model.


This likely can all be solved, but it needs to be specified, and cannot 
be dismissed as "probably not a major problem".




Best regards,

Matthijs



On 2/20/23 13:20, Peter Thomassen wrote:

Dear DNSOP,

Thank you for the very helpful feedback provided by several people on 
the -00 revision back in November.


Johan and I made changes to the document that incorporate the insights 
from the crowd, and resolved some other issues. The result is -01, 
attached below. If you are interested, please take a read.


We're looking forward to further feedback here and/or at IETF 116. Thanks!

Best,
Peter



 Forwarded Message 
Subject: New Version Notification for 
draft-thomassen-dnsop-generalized-dns-notify-01.txt

Date: Fri, 10 Feb 2023 08:25:23 -0800
From: internet-dra...@ietf.org
To: Johan Stenstam , Peter 
Thomassen 



A new version of I-D, draft-thomassen-dnsop-generalized-dns-notify-01.txt
has been successfully submitted by Peter Thomassen and posted to the
IETF repository.

Name:    draft-thomassen-dnsop-generalized-dns-notify
Revision:    01
Title:    Generalized DNS Notifications
Document date:    2023-02-10
Group:    Individual Submission
Pages:    16
URL:
https://www.ietf.org/archive/id/draft-thomassen-dnsop-generalized-dns-notify-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-thomassen-dnsop-generalized-dns-notify/
Html:   
https://www.ietf.org/archive/id/draft-thomassen-dnsop-generalized-dns-notify-01.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-thomassen-dnsop-generalized-dns-notify
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-thomassen-dnsop-generalized-dns-notify-01


Abstract:
    Changes in CDS/CDNSKEY, CSYNC, and other records related to
    delegation maintenance are usually detected through scheduled scans
    run by the consuming party (e.g. top-level domain registry),
    incurring an uncomfortable trade-off between scanning cost and update
    latency.

    A similar problem exists when scheduling zone transfers, and has been
    solved using the well-known DNS NOTIFY mechanism ([RFC1996]).  This
    mechanism enables a primary nameserver to proactively inform
    secondaries about zone changes, allowing the secondary to initiate an
    ad-hoc transfer independently of when the next SOA check would be
    due.

    This document extends the use of DNS NOTIFY beyond conventional zone
    transfer hints, bringing the benefits of ad-hoc notifications to DNS
    delegation maintenance in general.  Use cases include DNSSEC