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