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 ke

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

[Matthijs Mekking]

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 server chooses to keep the CDS and 
CDNSKEY RRset published, keeping it in sync with the DS RRset, and the 
other removes the CDS and CDNSKEY records as soon as you detect that the 
desired DS RRset is published.


The existing documents lack any words on where specifically to query for 
CDS/CDNSKEY, and also what to do in case of inconsistencies.


Therefor, I support adoption of this draft and am willing to review.

Matthijs


On 6/7/23 17:52, Tim Wicinski wrote:


All,

We've had this document in DNSOP for a bit and Peter has presented three 
different meetings. When I went back and looked at the minutes, the 
feedback was good.  But when the chairs and Warren discussed it, we had 
confused ourselves on this document, which is our bad.  We decided to 
stop confusing ourselves and let the working group help us out.


What I did was to pull the comments on this document from the minutes of 
the meetings and include them below to make it easier to remember what 
was said.



This starts a Call for Adoption for draft-thomassen-dnsop-cds-consistency

The draft is available here: 
https://datatracker.ietf.org/doc/draft-thomassen-dnsop-cds-consistency/ 



Please review this draft to see if you think it is suitable for adoption
by DNSOP, and send any comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 21 June 2023

Thanks,
tim wicinski
For DNSOP co-chairs

Minutes from past meetings on "Consistency for CDS/CDNSKEY and CSYNC is 
Mandatory"




114
     Mark: CDS records are no different than any others
         One NS might be down, which would stop the
         Peter: This is telling the parent how to act when faced with
inconsistent information
     Viktor: There might be hidden masters
         Don't want to get stuck
         Peter: Wording could be changed to allow servers down
     Ben: There is a missing time constant
         When do I recheck if I get an inconsistent set?
         Peter: 7344 doesn't put any time limit
         Ben: Should suggest some time to retry when there is an
inconstancy

115
     Wes: Supports this
         Likes mandating checking everywhere
     Ralf: Supports this
         Can't ask "all" servers in anycast
         What if you don't get a response
         Peter: Ask each provider
             Is willing to add in wording about non responses
         Paul Wouters: This wasn't in CSYNC, our bug
     Viktor: Concern was hidden masters and nameservers that are gone
and are never going to come back


116
     Viktor: Corner case: if someone is moving to a host that doesn't
do DNSSEC
         Peter: Could add a way to turn off DNSSEC on transfer
     Johan Stenstram: Breaks the logic that "if it is signed, it is
good"
         Doesn't like "if this is really important"
         Let's not go there
         Authoritative servers are proxies for the registrant
         Out of sync is reflection on the registrant: business issues
     Wes: CSYNC was for keeping DNS up and running
         CSYNC can't fix the business problems
     Peter: Agrees that one signature should be OK
         Other parts of the spec also suggest asking multiple places


___
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] Call for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory

[Geoff Huston]

> 
> This starts a Call for Adoption for draft-thomassen-dnsop-cds-consistency
> 
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-thomassen-dnsop-cds-consistency/ 
> 
> 
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and send any comments to the list, clearly stating your view.
> 
> Please also indicate if you are willing to contribute text, review, etc.

I support adoption of this draft, and I am willing to review

thanks,

  Geoff

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[libor.peltan]

Hi,

I like the ideas in this document and I support its adoption, willing to 
comment its contents.


Libor

Dne 07. 06. 23 v 17:52 Tim Wicinski napsal(a):


All,

We've had this document in DNSOP for a bit and Peter has presented 
three different meetings. When I went back and looked at the minutes, 
the feedback was good.  But when the chairs and Warren discussed it, 
we had confused ourselves on this document, which is our bad.  We 
decided to stop confusing ourselves and let the working group help us out.


What I did was to pull the comments on this document from the minutes 
of the meetings and include them below to make it easier to remember 
what was said.



This starts a Call for Adoption for draft-thomassen-dnsop-cds-consistency

The draft is available here: 
https://datatracker.ietf.org/doc/draft-thomassen-dnsop-cds-consistency/


Please review this draft to see if you think it is suitable for adoption
by DNSOP, and send any comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 21 June 2023

Thanks,
tim wicinski
For DNSOP co-chairs

Minutes from past meetings on "Consistency for CDS/CDNSKEY and CSYNC 
is Mandatory"




114
    Mark: CDS records are no different than any others
        One NS might be down, which would stop the
        Peter: This is telling the parent how to act when faced with
inconsistent information
    Viktor: There might be hidden masters
        Don't want to get stuck
        Peter: Wording could be changed to allow servers down
    Ben: There is a missing time constant
        When do I recheck if I get an inconsistent set?
        Peter: 7344 doesn't put any time limit
        Ben: Should suggest some time to retry when there is an
inconstancy

115
    Wes: Supports this
        Likes mandating checking everywhere
    Ralf: Supports this
        Can't ask "all" servers in anycast
        What if you don't get a response
        Peter: Ask each provider
            Is willing to add in wording about non responses
        Paul Wouters: This wasn't in CSYNC, our bug
    Viktor: Concern was hidden masters and nameservers that are gone
and are never going to come back


116
    Viktor: Corner case: if someone is moving to a host that doesn't
do DNSSEC
        Peter: Could add a way to turn off DNSSEC on transfer
    Johan Stenstram: Breaks the logic that "if it is signed, it is
good"
        Doesn't like "if this is really important"
        Let's not go there
        Authoritative servers are proxies for the registrant
        Out of sync is reflection on the registrant: business issues
    Wes: CSYNC was for keeping DNS up and running
        CSYNC can't fix the business problems
    Peter: Agrees that one signature should be OK
        Other parts of the spec also suggest asking multiple places


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

[Masataka Ohta]

Paul Hoffman wrote:


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.


I can't see any problem with "lame" delegation than a "secondary"
or "slave" server, because of the history of racial discrimination
in US.

Both "lame" and "secondary" has negative meaning and, according to
google search, "secondary" means "less important than", which is
how colored people was and still is treated in US.

The fact is that, for about 100 years after slavery was illegalized
in US, colored people in US had been legally treated as "secondary"
citizens, which was what Martin Luther King protested against.

That the discrimination, though somewhat but not sufficiently
illegally, still continues, as is demonstrated by BLM, is the
problem not addressed but rather obfuscated by not saying
"slave" or "secondary". Same for "lame".


Masataka Ohta

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

[Benno Overeinder]

Hi all, Paul,

On 17/06/2023 22:59, Paul Hoffman wrote:
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.


Thank you for reminding the WG to go over the discussion threads and 
review the opinions expressed.


I will prepare two to three slides summarizing the discussions, 
including the most recent discussion on the meaning of "lame," to help 
focus the meeting.



FWIW, I'm glad I'm not the one who will be deciding consensus here; the 
chairs will be.


You are welcome Paul.  :-)

Looking forward to a productive meeting.

Best,

-- Benno



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


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop