[{"author": "Jean Queralt", "text": "

Greetings from Malaysia.

", "time": "2023-07-24T16:30:58Z"}, {"author": "Andrew Campling", "text": "

Good morning DNSOPs

", "time": "2023-07-24T16:33:33Z"}, {"author": "Suzanne Woolf", "text": "

Good morning/afternoon/evening to everyone, wherever you are thanks for joining us!

", "time": "2023-07-24T16:34:33Z"}, {"author": "Shane Kerr", "text": "

We can recommend DF flag set if we make the text a Best Aspirational Practice instead of a Best Common Practice document, right?

", "time": "2023-07-24T16:42:32Z"}, {"author": "Benno Overeinder", "text": "

cds-consistency presentation is up.

", "time": "2023-07-24T16:52:52Z"}, {"author": "Lars-Johan Liman", "text": "

@charis: Tim mentioned structured error messages, and that he didn't want to mess with stuff that was still in motion. I disagree. I think it far more advantageous to \"fix\" the protocol _before_ it's cast in stone and everybody has implemented it. If there already is a new and better \"version\", let's make sure _that's_ what gets deployed, and not the intermediary \"less optimal\" version. Yes, it will delay deployment of the current spec, but it may lead to a sooner deployment of the better version. IMHO.

", "time": "2023-07-24T16:53:11Z"}, {"author": "Tim Wicinski", "text": "

currently requesting IETF creates \"Best Aspirational Practice\" document

", "time": "2023-07-24T16:53:23Z"}, {"author": "Tim Wicinski", "text": "

@lars: I am in favor of fixing the protocol. before cast in stone! I was trying to say I want to see more operational experience so we. can fix anything which is not working

", "time": "2023-07-24T16:54:40Z"}, {"author": "Warren Kumari", "text": "

NOc knows ; they are seeing lots of TX errors on the AP in front right of room

", "time": "2023-07-24T16:54:43Z"}, {"author": "Benno Overeinder", "text": "

Thanks Warren.

", "time": "2023-07-24T16:55:21Z"}, {"author": "Lars-Johan Liman", "text": "

@Tim Wicinski : Ah! Got it. Then we're in agreement!

", "time": "2023-07-24T16:55:52Z"}, {"author": "Paul Hoffman", "text": "

Reminder to folks: if you want to go to the mic, you need to raise your hand in Meetecho. Your minutes-taker thanks you.

", "time": "2023-07-24T16:56:28Z"}, {"author": "Andrew Sullivan", "text": "

It pains me to say that the CDS consistency draft is yet another piece of evidence that DNSSEC is exceptionally risky in real operational practice. :(

", "time": "2023-07-24T16:56:39Z"}, {"author": "Viktor Dukhovni", "text": "

Au contraire, DNSSEC is the only mechanism to authenticate e.g. CSYNC updates. Need of due care in multi-provider setups (rare) does not mean that DNSSEC is risky, it is just evidence that multi-provider is complex.

", "time": "2023-07-24T16:58:46Z"}, {"author": "Anthony Somerset", "text": "

i don't think risky is the correct word to use - but yes far from simple that there are huge opportunities for errors and failures

", "time": "2023-07-24T16:58:56Z"}, {"author": "Tim Wicinski", "text": "

I would argue there will/should be more and more multi-provider setups, but I am just an operator who worries about everything

", "time": "2023-07-24T16:59:37Z"}, {"author": "Anthony Somerset", "text": "

these are uncommon today but i am seeing an uptick on requirements to do multi provider at DNS level if not self hosting

", "time": "2023-07-24T17:00:30Z"}, {"author": "Viktor Dukhovni", "text": "

I'm in favour of validating updated CSYNC names.

", "time": "2023-07-24T17:00:58Z"}, {"author": "Andrew Sullivan", "text": "

Well, this is sort of my point (it's not a comment on the draft, which given my usual hat I refuse to have an opinion about). DNSSEC may just have made DNS too brittle, and the work that has to be done to make it work in a realistic operational world may be evidence that we actually do need to muddle out a way to replace the DNS for real.

", "time": "2023-07-24T17:02:49Z"}, {"author": "Tim Wicinski", "text": "

Sounds like time for the blockchain Mr Sullivan

", "time": "2023-07-24T17:03:48Z"}, {"author": "Anthony Somerset", "text": "

i do personally prefer the idea that if we can encrypt the dns communication transmission end to end we can alternatively mitigate a lot of the original cause for DNSSEC in the first place.

", "time": "2023-07-24T17:05:58Z"}, {"author": "Anthony Somerset", "text": "

aka DoT/DoH for auth servers

", "time": "2023-07-24T17:06:33Z"}, {"author": "Matthew Pounsett", "text": "

In that environment, nothing stops any step along the way from modifying answers. Channel and data security solve different problems.

", "time": "2023-07-24T17:06:53Z"}, {"author": "Andrew Campling", "text": "

@Anthony Surely encryption of the DNS solves a different problem to DNSSEC as it does not guarantee the validity of the response, simply prevents them from being observed?

", "time": "2023-07-24T17:07:20Z"}, {"author": "Anthony Somerset", "text": "

yes on both counts - you have to trust the recursive resolver

", "time": "2023-07-24T17:08:16Z"}, {"author": "Warren Kumari", "text": "

The NOC says that there are 3-5 phones nearby the APs using 80Mhz channels. Because we are near the SFO port, we cannot use the DFS 5Ghz channels (because of RADAR interference). They are still looking...

", "time": "2023-07-24T17:09:07Z"}, {"author": "Andrew Fregly", "text": "

Has anybody considered that a block chain might be a good solution to to the problem CSYNC is trying to solve?

", "time": "2023-07-24T17:09:52Z"}, {"author": "Anthony Somerset", "text": "

Warren Kumari said:

\n
\n

The NOC says that there are 3-5 phones nearby the APs using 80Mhz channels. Because we are near the SFO port, we cannot use the DFS 5Ghz channels (because of RADAR interference). They are still looking...

\n
\n

are we that close that this would cause a real issue?

", "time": "2023-07-24T17:09:55Z"}, {"author": "Vittorio Bertola", "text": "

Channel security implies data security if and only if you decide to have absolute faith in the resolver you are using, which is the implicit assumption in the original browser deployment model.

", "time": "2023-07-24T17:10:04Z"}, {"author": "Warren Kumari", "text": "

Whoever has a device called Pixel_9871, it would be great if you could turn off your hotspot... It's using an 80Mhz channel that overlaps with the channels that the IETF is using...

", "time": "2023-07-24T17:11:49Z"}, {"author": "Gabriel Andrews", "text": "

Guilty - handling.

", "time": "2023-07-24T17:12:02Z"}, {"author": "Andrew Sullivan", "text": "

DNSSEC does not require you to trust your recursive, and I don't think it would be an improvement to require that we do.

", "time": "2023-07-24T17:14:16Z"}, {"author": "Warren Kumari", "text": "
", "time": "2023-07-24T17:14:24Z"}, {"author": "Warren Kumari", "text": "

Ta!

", "time": "2023-07-24T17:14:29Z"}, {"author": "Warren Kumari", "text": "

Thank you! Should be better now...

", "time": "2023-07-24T17:15:18Z"}, {"author": "Shane Kerr", "text": "

NS1 does not have code queued up for NXNAME, BTW. I haven't really looked to see the level of effort.

", "time": "2023-07-24T17:16:19Z"}, {"author": "Warren Kumari", "text": "

All better now -- https://cdn.wkumari.dev/dnsop_wifi2.png
\nNOC sees TX errors decreasing. Thanks!

\n
", "time": "2023-07-24T17:17:01Z"}, {"author": "Shane Kerr", "text": "

We do not have to fix this non-problem. ;-)

", "time": "2023-07-24T17:19:25Z"}, {"author": "Shane Kerr", "text": "

It's been operational for years and the world has not ended, IMHO.

", "time": "2023-07-24T17:19:38Z"}, {"author": "Benno Overeinder", "text": "

Shane, your comments for Issue 4?

", "time": "2023-07-24T17:20:10Z"}, {"author": "Shane Kerr", "text": "

Yes, that's correct.

", "time": "2023-07-24T17:20:49Z"}, {"author": "Puneet Sood", "text": "

Issue 5: Strongly prefer recommending following RFC 4470

", "time": "2023-07-24T17:20:49Z"}, {"author": "Puneet Sood", "text": "

for new implementations.

", "time": "2023-07-24T17:20:57Z"}, {"author": "Anthony Somerset", "text": "

if pre-existing standards solve the problem correctly then surely that is the the guidance to give - go deploy as per the correct standards

", "time": "2023-07-24T17:20:58Z"}, {"author": "Puneet Sood", "text": "

thanks Tale for saying that.

", "time": "2023-07-24T17:24:08Z"}, {"author": "Anthony Somerset", "text": "

concur with adoption

", "time": "2023-07-24T17:30:37Z"}, {"author": "Wes Hardaker", "text": "

You know............ If we just filed an errata with the original spec and say it was supposed to be 1 bit not 16 bits then we have 15 new bits to use for other things!!!!!

", "time": "2023-07-24T17:35:45Z"}, {"author": "Shane Kerr", "text": "

We can get rid of source port randomization! Good idea, Wes. ;-)

", "time": "2023-07-24T17:36:15Z"}, {"author": "Warren Kumari", "text": "

@Ted Lemon: What about keeping all of the \"interesting\" bits in an Appendix?

", "time": "2023-07-24T17:36:29Z"}, {"author": "Matthew Pounsett", "text": "

Wes-From-The-Past has an excellent bad idea. :)

", "time": "2023-07-24T17:36:44Z"}, {"author": "Warren Kumari", "text": "

@Shane Kerr New source of entropy... ? :-P

", "time": "2023-07-24T17:36:56Z"}, {"author": "Eric Orth", "text": "

+1 that the document includes a bunch of background/reasoning that really only makes sense in an informational. This doc should just say very simply, \"QDCOUNT MUST be 0 or 1\" and maybe at most say required by operational practices by assumptions in the ecosystem.

", "time": "2023-07-24T17:37:05Z"}, {"author": "Tim Wicinski", "text": "

Agree with interesting bits in the Appendix

", "time": "2023-07-24T17:38:21Z"}, {"author": "Wes Hardaker", "text": "

that's odd... so the past-116 me was done using the meetecho chat tool on a phone.

", "time": "2023-07-24T17:38:26Z"}, {"author": "Eric Orth", "text": "

Much as I disagree with all the arguments around unable to differentiate errors and such, only asking one question is a defacto standard at this point, so let's codify it for the one way that'll work with all the existing implementations.

", "time": "2023-07-24T17:38:33Z"}, {"author": "Wes Hardaker", "text": "

Now I'm in the future

", "time": "2023-07-24T17:38:46Z"}, {"author": "Peter Koch", "text": "

DNS-SD is not the DNS, robustness principle applies, +1 to Liman

", "time": "2023-07-24T17:40:18Z"}, {"author": "Eric Orth", "text": "

\"QDCOUNT MUST be at most 1. Otherwise response behavior is unpredictable due to historically being undefined and ambiguous.\"

", "time": "2023-07-24T17:43:34Z"}, {"author": "Peter Thomassen", "text": "

How about making QDCOUNT<=1 a BCP? Seems to me that would help manage expectations of those trying creative implementations, while not completely blocking the road in case something comes around the corner in the future where we wouldn't want to be as strict. (Best Current Practice.)

", "time": "2023-07-24T17:43:43Z"}, {"author": "Peter Thomassen", "text": "

BCP would also be \"informational\" enough to contain all the analysis bits in an appendix.

", "time": "2023-07-24T17:44:18Z"}, {"author": "Jim Reid", "text": "

+1 to Eric

", "time": "2023-07-24T17:45:17Z"}, {"author": "John Levine", "text": "

I prefer to codify the reality that only 0 and 1 work. It's a little bit of anti-amel.

", "time": "2023-07-24T17:45:29Z"}, {"author": "John Levine", "text": "

anti-camel

", "time": "2023-07-24T17:46:00Z"}, {"author": "Shane Kerr", "text": "

MUST NOT statements save lives! :-D

", "time": "2023-07-24T17:46:32Z"}, {"author": "Matthew Pounsett", "text": "

Any implementation of QDCOUNT > 1 would hit so many weird corner cases \u2014which make responses useless\u2014that anyone who wants to do that should use a separate mechanism. Hence Ray's multi-qtypes draft.

", "time": "2023-07-24T17:48:09Z"}, {"author": "Matthew Pounsett", "text": "

So better to just outlaw it and push people to EDNS

", "time": "2023-07-24T17:48:29Z"}, {"author": "Lars-Johan Liman", "text": "

I still think that text along the lines of \"> 1 is not well defined in public DNS documents, and should only be used in situations where both client and server agree on the semantics. In normal cases DNS servers are expected to respond with FORMERR.\"

", "time": "2023-07-24T17:48:58Z"}, {"author": "Jim Reid", "text": "

Shane, MUST NOT saves millions of lines of code too. :-)

", "time": "2023-07-24T17:49:19Z"}, {"author": "Matthew Pounsett", "text": "

Anyone who wants to write a DNS server that doesn't need to interoperate with other DNS servers is free to ignore any RFC they wish.

", "time": "2023-07-24T17:49:45Z"}, {"author": "Jim Reid", "text": "

I prefer QDcount must be <2. That can be revisited If/when someone comes up with a reasonable use case for QDcount >= 2.

", "time": "2023-07-24T17:51:22Z"}, {"author": "Peter Thomassen", "text": "

Why is a standards document better than a BCP (which would be easier to revise iff needed)?

", "time": "2023-07-24T17:51:55Z"}, {"author": "Jaime Jimenez", "text": "

About DOTS: it\u2019s based in CoAP and there are many CoAP client/server libraries.

", "time": "2023-07-24T17:52:48Z"}, {"author": "Mohamed Boucadair", "text": "

You may look at https://github.com/nttdots/go-dots

", "time": "2023-07-24T17:54:23Z"}, {"author": "Puneet Sood", "text": "

Peter Thomassen said:

\n
\n

Why is a standards document better than a BCP (which would be easier to revise iff needed)?

\n
\n

Agreed. Not seeing the value to having this as a standards track or WG RFC

", "time": "2023-07-24T17:54:35Z"}, {"author": "David Lawrence", "text": "

Lamp :rolling_on_the_floor_laughing:

", "time": "2023-07-24T17:55:29Z"}, {"author": "Lars-Johan Liman", "text": "

Puneet Sood said:

\n
\n

Peter Thomassen said:

\n
\n

Why is a standards document better than a BCP (which would be easier to revise iff needed)?

\n
\n

Agreed. Not seeing the value to having this as a standards track or WG RFC

\n
\n

I can go with a BCP. That makes sense to me.

", "time": "2023-07-24T17:55:42Z"}, {"author": "David Lawrence", "text": "

Urg autocorrect ... Snmp :rolling_on_the_floor_laughing:

", "time": "2023-07-24T17:55:52Z"}, {"author": "Jean Queralt", "text": "

Anyone from Meetecho to report bugs?

", "time": "2023-07-24T17:57:39Z"}, {"author": "Lorenzo Miniero", "text": "

What's wrong Jean?

", "time": "2023-07-24T17:57:56Z"}, {"author": "Jean Queralt", "text": "

Users with Private Chat (seemingly) disabled do show up on the \"tab\" list on top of the chat though no actual chatting is possible. My take is the Private Chat should not show for such users and the \"tab\" should also not appear.

", "time": "2023-07-24T17:59:26Z"}, {"author": "Shane Kerr", "text": "

Perl scripts that are hard to maintain? Hard to believe! ;-)

", "time": "2023-07-24T17:59:31Z"}, {"author": "Anthony Somerset", "text": "

moral of the story, don't drink and code perl scripts :D

", "time": "2023-07-24T18:01:29Z"}, {"author": "Andrew Sullivan", "text": "

I don't know how the machines know what date and time it is where you are, but they do.

", "time": "2023-07-24T18:01:36Z"}, {"author": "Nigel Hickson", "text": "

Hope you perhaps discussed issues of failure with ICANN ccNSO

", "time": "2023-07-24T18:01:45Z"}, {"author": "Anthony Somerset", "text": "

this does kind of make sense as a BCP or informational

", "time": "2023-07-24T18:02:32Z"}, {"author": "Anthony Somerset", "text": "

happy to offer a review

", "time": "2023-07-24T18:10:26Z"}, {"author": "Anthony Somerset", "text": "

question what track?

", "time": "2023-07-24T18:10:37Z"}, {"author": "Tim Wicinski", "text": "

I have to concur there are a large field of non-TLDs with many different organizations underneath them.

", "time": "2023-07-24T18:21:09Z"}, {"author": "Anthony Somerset", "text": "

i vote to adopt - definitely agree to also note the historical DoS concerns as a security consideration - the implementations have support to control who to accept NOTIFY from

", "time": "2023-07-24T18:21:42Z"}, {"author": "Matthew Pounsett", "text": "

We tried the side-channel for this with draft-ietf-regext-dnsoperator-to-rrr-protocol ... it didn't get much traction. I think this has a better chance of succeeding.

", "time": "2023-07-24T18:21:49Z"}, {"author": "Tim Wicinski", "text": "

\"The real answer is another TXT Record\" Bad-Idea-Tim

", "time": "2023-07-24T18:23:23Z"}, {"author": "Jim Reid", "text": "

TXT records solve everything. :-)

", "time": "2023-07-24T18:23:56Z"}, {"author": "Paul Hoffman", "text": "

Thoe the folks in the mic queue now: we are already over time.

", "time": "2023-07-24T18:32:31Z"}, {"author": "Benno Overeinder", "text": "

Meetecho session can be closed any moment.

", "time": "2023-07-24T18:33:32Z"}, {"author": "Lorenzo Miniero", "text": "

We don't close sessions automatically

", "time": "2023-07-24T18:33:50Z"}, {"author": "Lorenzo Miniero", "text": "

We wait for people to leave :)

", "time": "2023-07-24T18:33:59Z"}, {"author": "Lorenzo Miniero", "text": "

Unless you never do, of course! :D

", "time": "2023-07-24T18:34:08Z"}, {"author": "Benno Overeinder", "text": "

Thanks! We will manage it and close DNSOP in couple of minutes

", "time": "2023-07-24T18:34:26Z"}, {"author": "Matthew Pounsett", "text": "

The thing that concerns me about this proposal is the lack of any standardized signal for algorithm status, and how this interacts with the long tail of embedded systems, etc.

", "time": "2023-07-24T18:35:53Z"}]