[{"author": "Jerry Lundstr\u00f6m", "text": "

no cam on Warren :( missing stuff now

", "time": "2023-11-10T08:39:18Z"}, {"author": "Jerry Lundstr\u00f6m", "text": "

thanks :)

", "time": "2023-11-10T08:39:42Z"}, {"author": "Anthony Somerset", "text": "

@Tim Wicinski i don't mind throwing my hand in the ring at the author slot if you can't find anyone better qualified

", "time": "2023-11-10T08:50:07Z"}, {"author": "Benno Overeinder", "text": "

@anthony can you reach out to Shuman?

", "time": "2023-11-10T08:51:31Z"}, {"author": "Benno Overeinder", "text": "

Sorry Shumon

", "time": "2023-11-10T08:51:46Z"}, {"author": "Suzanne Woolf", "text": "

@Anthony Somerset you're hired, talk to your new co-author :-)

", "time": "2023-11-10T08:52:06Z"}, {"author": "Chris Box", "text": "

In case anyone\u2019s not clear, DNSSD isn\u2019t proposing to set QDCOUNT=2, but to keep it at 1 and possibly take forward Ray\u2019s extension proposal which supplies additional QTYPEs being asked, all for the same name. The reason is to save capacity on Thread networks.

", "time": "2023-11-10T08:53:33Z"}, {"author": "Vladim\u00edr \u010cun\u00e1t", "text": "

Thanks for the clarification :smile:

", "time": "2023-11-10T08:54:20Z"}, {"author": "Shane Kerr", "text": "

Changes needed in the parent are rare, so I don't think even systems using IPAM and automation have most of their bits of updating at the parent automated. (Of course domain hosting sites and similar will, but for the rest...)

", "time": "2023-11-10T08:57:41Z"}, {"author": "Adam Burns", "text": "

policy based SIG(0) FTW ? :grinning:

", "time": "2023-11-10T08:59:37Z"}, {"author": "Shane Kerr", "text": "

I don't think that having the child use DDNS will remove the complexity too much, since the child will have to account for outages and problems updating and so on. But the benefit is mostly for the child so the child will be more motivated to pay the costs. Also, it distributes the complexity and server load, which is basically good.

\n

This is a cool idea! :laughing:

", "time": "2023-11-10T08:59:44Z"}, {"author": "Benjamin Schwartz", "text": "

DNS Error Reporting has the terminology of an \"agent domain\" to describe auth-affiliated endpoints for upstream data flows. That seems like a useful term for these proposals too.

", "time": "2023-11-10T09:07:35Z"}, {"author": "Benjamin Schwartz", "text": "

I wonder if we could flip this and make it easier for organizations to spin up an EPP endpoint for their internal use.

", "time": "2023-11-10T09:11:36Z"}, {"author": "David Lawrence", "text": "

I'd be really surprised to see that (epp) get traction

", "time": "2023-11-10T09:12:58Z"}, {"author": "Jim Reid", "text": "

Making it easier for organisations to have an EPP endpoint doesn't mean they'd do it.

", "time": "2023-11-10T09:13:28Z"}, {"author": "Benjamin Schwartz", "text": "

If it was built-in to their DNS packages (child and parent) so its just a config option, I feel like it might get used.

", "time": "2023-11-10T09:14:12Z"}, {"author": "Vladim\u00edr \u010cun\u00e1t", "text": "

Maybe the document should say that people should use an XML parser? Though I personally would assume it implicitly.

", "time": "2023-11-10T09:18:28Z"}, {"author": "Ozan Sahin", "text": "

Link to the public comment: https://www.icann.org/en/public-comment/proceeding/draft-report-of-the-root-zone-dnssec-algorithm-rollover-study-19-10-2023

", "time": "2023-11-10T09:19:05Z"}, {"author": "Hafiz Farooq", "text": "

Vladim\u00edr \u010cun\u00e1t said:

\n
\n

Maybe the document should say that people should use an XML parser? Though I personally would assume it implicitly.

\n
\n

i agree it's the time to switch to json

", "time": "2023-11-10T09:22:54Z"}, {"author": "Stefan Ubbink", "text": "

Hafiz Farooq said:

\n
\n

i agree it's the time to switch to json

\n
\n

But json cannot easily contain comments :sad:

", "time": "2023-11-10T09:24:03Z"}, {"author": "Yoshitaka Aharen", "text": "

{\"_comment_do_not_interpret_this_key\": \"blahblahblah\"} ?

", "time": "2023-11-10T09:24:55Z"}, {"author": "Shane Kerr", "text": "

In this case we can add comments as members of the JSON object, explicitly:

\n
{\n  "fancy-icann-data": "ABD99324FF00...",\n  "notice": "remember to stop and smell the roses",\n    ...\n}\n
", "time": "2023-11-10T09:25:54Z"}, {"author": "Anthony Somerset", "text": "

sounds like we need to update 7159 to support comments in a standard way :D

", "time": "2023-11-10T09:26:05Z"}, {"author": "Stefan Ubbink", "text": "

that's why I said 'cannot easily' ;-)

", "time": "2023-11-10T09:26:10Z"}, {"author": "Shane Kerr", "text": "

Stefan Ubbink said:

\n
\n

that's why I said 'cannot easily' ;-)

\n
\n

Fair enough. It's why I usually use YAML, in spite of all the haters. :shrug:

", "time": "2023-11-10T09:27:06Z"}, {"author": "Stefan Ubbink", "text": "

YAML with the norway problem ;-)

", "time": "2023-11-10T09:28:14Z"}, {"author": "Vladim\u00edr \u010cun\u00e1t", "text": "

YAML isn't bad for humans. But I probably wouldn't choose it for very widely machine-consumed stuff.

", "time": "2023-11-10T09:28:31Z"}, {"author": "Benjamin Schwartz", "text": "

Is this is all to reduce response size from the parent vs. White Lies? It doesn't save CPU, and I can't think of any other reason.

", "time": "2023-11-10T09:28:57Z"}, {"author": "Vladim\u00edr \u010cun\u00e1t", "text": "

Reducing NSEC* counts in answers will reduce CPU usage as well, if you sign online.

", "time": "2023-11-10T09:29:44Z"}, {"author": "Benjamin Schwartz", "text": "

One of the two NSECs (the wildcard) is basically static and highly cacheable, so effectively White Lies only requires one online signature.

", "time": "2023-11-10T09:30:17Z"}, {"author": "Vladim\u00edr \u010cun\u00e1t", "text": "

Well, yes, my personal opinion is that this draft isn't worth it... but I'm primarily validator/resolver and prefer offline signing anyway.

", "time": "2023-11-10T09:31:09Z"}, {"author": "Christian Elmerot", "text": "

There is additionally significant CPU savings to be had if you run a resolver as there is now only the need to validate one signature

", "time": "2023-11-10T09:41:10Z"}, {"author": "Vladim\u00edr \u010cun\u00e1t", "text": "

Oh right, that's a good point. I mean, DELEG might eventually enable protocols that cover these use cases better, but that's a completely different level of complexity and time horizon.

", "time": "2023-11-10T09:43:23Z"}, {"author": "Shane Kerr", "text": "

As far as complexity for compact answers... the resolvers run unmodified, so I'm not sure what the actual concern is on that regard? :thinking:

", "time": "2023-11-10T09:44:05Z"}, {"author": "Benjamin Schwartz", "text": "

@Shane Kerr Authoritative server complexity (and DNS Camel cognitive overhead. What's a NXNAME?)

", "time": "2023-11-10T09:44:47Z"}, {"author": "Vladim\u00edr \u010cun\u00e1t", "text": "

I assume that you want resolvers to differentiate between NXNAME case and normal black-lie NODATA.

", "time": "2023-11-10T09:45:24Z"}, {"author": "Vladim\u00edr \u010cun\u00e1t", "text": "

If not, I don't think you need this draft at all, right? (except informational/BCP) Cloudflare's answers (and clones) seemed OK for many years.

", "time": "2023-11-10T09:46:17Z"}, {"author": "Yoshitaka Aharen", "text": "

possibly EDNS EXPIRE option would somewhat help on adjusting the TTL?

", "time": "2023-11-10T09:46:57Z"}, {"author": "Erik Nygren", "text": "

It would be good to document the \"Authoritative Forwarding\" use-case as it is more common.
\nAn important thing we really should define is safeguards for loop prevention (eg, an EDNS0 hop-count limit or something like rfc8586 which defines CDN-Loop). Doing this without Loop Prevention is dangerous.

", "time": "2023-11-10T09:50:30Z"}, {"author": "Vladim\u00edr \u010cun\u00e1t", "text": "

I think it's an important point. For somewhat important auth servers, the scaling isn't related to normal traffic, it's just for (D)DoS attempts.

", "time": "2023-11-10T09:53:04Z"}, {"author": "Evan Hunt", "text": "

the EDNS pseudorecord is displayed in dig, just no as an RR (because there's no presentation format for OPT)

", "time": "2023-11-10T09:56:13Z"}, {"author": "Evan Hunt", "text": "

s/no/not/

", "time": "2023-11-10T09:56:25Z"}, {"author": "Shane Kerr", "text": "

Who thought not having a presentation format for OPT was a good idea?!?!

", "time": "2023-11-10T09:57:02Z"}, {"author": "Evan Hunt", "text": "

shrug. vixie? he wrote 2671

", "time": "2023-11-10T09:57:39Z"}, {"author": "Shane Kerr", "text": "

Feels like a Vixie thing, indeed.

", "time": "2023-11-10T09:58:01Z"}, {"author": "Jim Reid", "text": "

Who's vixie?

", "time": "2023-11-10T09:58:15Z"}, {"author": "Evan Hunt", "text": "

wrong answers only

", "time": "2023-11-10T09:58:28Z"}, {"author": "Hafiz Farooq", "text": "

came across \"dog\" which is json based dig https://github.com/ogham/dog

", "time": "2023-11-10T09:58:58Z"}, {"author": "Tim Wicinski", "text": "

I spend all day at work telling people not to use nslookup but the CCNA tests all test for nslookup

", "time": "2023-11-10T10:02:37Z"}, {"author": "Anthony Somerset", "text": "

am i looking correctly - that there are still some ICANN TLD's on v4 only?

", "time": "2023-11-10T10:04:11Z"}, {"author": "Hafiz Farooq", "text": "

nslookup can easily win heavily-used worst-ever tool award

", "time": "2023-11-10T10:04:54Z"}, {"author": "Yoshitaka Aharen", "text": "

https://itp.cdn.icann.org/en/files/registry-agreements/base-registry-agreement-30-04-2023-en.pdf#page=80

\n
\n

Operator shall offer public IPv6 transport for, at least, two of the Registry\u2019s
\nname servers listed in the root zone with the corresponding IPv6 addresses
\nregistered with IANA.

\n
", "time": "2023-11-10T10:05:59Z"}, {"author": "Vladim\u00edr \u010cun\u00e1t", "text": "

I hate the nslookup provided by busybox.

", "time": "2023-11-10T10:06:13Z"}, {"author": "Suzanne Woolf", "text": "

Guessing some ccTLDs may still be ipv4-only

", "time": "2023-11-10T10:06:38Z"}, {"author": "Anthony Somerset", "text": "

Yoshitaka Aharen said:

\n
\n

https://itp.cdn.icann.org/en/files/registry-agreements/base-registry-agreement-30-04-2023-en.pdf#page=80

\n
\n

Operator shall offer public IPv6 transport for, at least, two of the Registry\u2019s
\nname servers listed in the root zone with the corresponding IPv6 addresses
\nregistered with IANA.

\n
\n
\n

maybe its time to make that ALL ?

", "time": "2023-11-10T10:06:43Z"}, {"author": "Jan V\u010del\u00e1k", "text": "

@Benjamin Schwartz The static NSEC for wildcard is useless alone. The server always has to prove to the client that there is no better match than the wildcard so there will always be the second NSEC for that. But why would you do that if you can pretend there is no wildcard and always have just one NSEC?

", "time": "2023-11-10T10:07:53Z"}, {"author": "Suzanne Woolf", "text": "

ccTLDs aren't subject to the RA at all, and modifying the terms of the RA for gTLDs is a massive process.

", "time": "2023-11-10T10:08:08Z"}, {"author": "Jan V\u010del\u00e1k", "text": "

As for complexity of these online signing solutions: I have experience implementing both offline and online signers. The later are much simpler.

", "time": "2023-11-10T10:09:34Z"}, {"author": "Shane Kerr", "text": "

I wrote this a few years back to find IPv4-only TLD:
\nhttps://github.com/shane-kerr/tldIPv6

", "time": "2023-11-10T10:09:41Z"}, {"author": "Benjamin Schwartz", "text": "

@Jan V\u010del\u00e1k We are adding a new mechanism and complexity to the DNS, making the whole system harder to understand. I don't think we should do that without a pretty clear reason. It seems like that reason is \"online signing caches can't be made big enough to cache all the wildcard NSEC signatures on nameservers with millions of domains\", which is a fine reason but we should still be careful about imposing complexity costs on the rest of the system for the benefit of the hyperscalers.

", "time": "2023-11-10T10:10:26Z"}, {"author": "Anthony Somerset", "text": "

DoT/DoH/DoQ by default instead of Do53 (UDP) ?

", "time": "2023-11-10T10:10:43Z"}, {"author": "Shane Kerr", "text": "

@Benjamin Schwartz s/adding/added/ (since compact answers have been used at large scale deployments for many years)

", "time": "2023-11-10T10:11:31Z"}, {"author": "Anthony Somerset", "text": "

+1 to Wes and Geoff

", "time": "2023-11-10T10:11:55Z"}, {"author": "Jim Reid", "text": "

If RFC3910 hasn't moved the needle on IPv6-capable DNS servers, I doubt RFC3910-bis would change that.

", "time": "2023-11-10T10:12:39Z"}, {"author": "Benjamin Schwartz", "text": "

@Shane Kerr Those deployments have worked without complexifying the protocol. In this case, we are adding complexity in order to restore NXDOMAIN capability that those large scale deployments evidently decided they didn't need. I'm pretty doubtful about the cost/benefit tradeoff here.

", "time": "2023-11-10T10:12:47Z"}, {"author": "Shane Kerr", "text": "

Speaking of Vixie, wasn't he the one who says that NXDOMAIN is important? I don't know, and honestly don't have much of an opinion. I'm quite happy with the document as an informational RFC just to document existing practices, but that was the original idea I think, and here we are...

", "time": "2023-11-10T10:14:14Z"}, {"author": "Peter van Dijk", "text": "

NXDOMAIN used to be important. Today it mostly is not, is my impression, except where it provides caching benefits - which I think is the point of the NXNAME sentinel

", "time": "2023-11-10T10:14:48Z"}, {"author": "Benjamin Schwartz", "text": "

NODATA is also cacheable, so what's the difference?

", "time": "2023-11-10T10:15:18Z"}, {"author": "Vladim\u00edr \u010cun\u00e1t", "text": "

Say, QNAME-minimizing deep into the NODATA swamp from black lies?

", "time": "2023-11-10T10:15:49Z"}, {"author": "Benjamin Schwartz", "text": "

I guess NXDOMAIN gets you the other RR types and \"nothing underneath\".

", "time": "2023-11-10T10:15:58Z"}, {"author": "Jan V\u010del\u00e1k", "text": "

@Benjamin Schwartz I agree the caching is more difficult. But the online signing also has benefits and it doesn't require resolver modification. As for NXNAME, I don't mind about restoring the NXNAME signal to resolvers. I see it as a diagnostic utility.

", "time": "2023-11-10T10:16:42Z"}, {"author": "Jim Reid", "text": "

NXDOMAIN means the qname doesn't exit => opportunities to sell domain names. NOHOST doesn't offer that.

", "time": "2023-11-10T10:16:51Z"}, {"author": "Vladim\u00edr \u010cun\u00e1t", "text": "

NODATA gives you all RR type existence already, at least if you don't lie about them and do aggressive caching.

", "time": "2023-11-10T10:17:00Z"}, {"author": "Jim Reid", "text": "

s/exit/exist/

", "time": "2023-11-10T10:17:24Z"}, {"author": "Benjamin Schwartz", "text": "

@Jan V\u010del\u00e1k I'm not arguing against online signing. I'm questioning whether it's worthwhile to add complexity over the pre-existing online signing behaviors, which worked within the existing DNS protocol and were evidently deployable and functional.

", "time": "2023-11-10T10:17:48Z"}, {"author": "Shane Kerr", "text": "

The NXNAME complexity is not great on the authoritative side at least. But I guess like most things in DNS maybe it makes resolvers more difficult.

", "time": "2023-11-10T10:17:53Z"}, {"author": "Erik Nygren", "text": "

NIST has an IPv6 and DNSSEC deployment tracker: https://fedv6-deployment.antd.nist.gov/cgi-bin/generate-com
\nFor the tracked \"industry\" domains (still US-centric), IPv6 has gone from 10% IPv6 for DNS authorities to over 70% and is still growing. (DNSSEC-signed is still well below 10%). At least some governments are also requiring IPv6 DNS authorities for everything in the resolution chain, at least for some industries.

", "time": "2023-11-10T10:20:58Z"}, {"author": "Ties de Kock", "text": "

Risky BIZness: Risks Derived from Registrar Name Management, Akiwate/Savage/Voelker/Claffy

", "time": "2023-11-10T10:23:07Z"}, {"author": "Shumon Huque", "text": "

NXDOMAIN visibility is mainly to help non nameserver software, such as traffic characterization, security tools etc. Some of them may be updated to recognize NXNAME, others may not be because they only examine RCODE, needing the additional signaled RCODE restoration. These issues do some up very regularly and compact answer implementations have negatively affected all of those tools.

", "time": "2023-11-10T10:28:05Z"}, {"author": "Carsten Bormann", "text": "

As I'm behind the end of the queue:

", "time": "2023-11-10T10:32:09Z"}, {"author": "Carsten Bormann", "text": "

I'm sure we'll have a CORE interim soon where we'll discuss this. I'll make sure we keep dnsop in the loop about when this happens. If you care, please come!

", "time": "2023-11-10T10:33:20Z"}, {"author": "Jerry Lundstr\u00f6m", "text": "

Why try to represent DNS in CBOR if it's for special use-case?

", "time": "2023-11-10T10:33:49Z"}, {"author": "Benjamin Schwartz", "text": "

@Carsten Bormann I'm not convinced that alternate representations of DNS can happen outside of DNSOP.

", "time": "2023-11-10T10:34:06Z"}, {"author": "Carsten Bormann", "text": "

Why use DNS at all?

", "time": "2023-11-10T10:34:11Z"}, {"author": "Tim Wicinski", "text": "

thanks aqll

", "time": "2023-11-10T10:34:19Z"}]