Hi Paul, > On 25 Oct 2023, at 16:10, Paul Vixie <paul=40redbarn....@dmarc.ietf.org> > wrote: > > see inline. > > Johan Stenstam wrote on 2023-10-25 01:09: >> Greetings Working Group, >> As many of you are aware Peter Thomassen, John Levine and I have been >> working on the generalised notifications for a while. The key idea there is >> obviously that a NOTIFY(CDS) or NOTIFY(CSYNC) sent from the child to the >> parent scanner will allow the scanner to fast track the scan of that >> particular child thereby making everything converge faster and presumably >> make the child happier.
>> But scanners still suck in general. > > can you more closely define "scan" in this context? i would expect a query > for the notified type at the notified name, but not some kind of enumeration > of multiple possibilities. With “scanners” I refer to CDS scanners and CSYNC scanners. These things issue a gazillion DNS queries, over and over and over, with an extremely small catch of “new CDS” or “new CSYNC” records. They get hit by rate limiting measures from the large DNS providers (for good reason, given the query volumes) and they are still slow. The issue is not the one query for "redbarn.org. CDS” or for “johani.se. CSYNC”, but the queries for CDS and CSYNC RRs for *all* the delegations for .SE (both signed and unsigned), over and over. And not only from one vantage point but from several, located around the world. Furthermore, for unsigned delegations, all the nameservers are queried. Every time. It’s a lot of DNS queries. You’re the author of RFC1996 which we build upon. Of course you have to agree that “push” is a better mechanism than “pull” when it comes to propagating information about a change in one end to the other end. >> So now there’s a new draft, that further extends the same core idea (locate >> the target for the information being sent via a DNS lookup in the parent >> zone). However, the new draft >> (draft-johani-dnsop-delegation-mgmt-via-ddns-00) proposes that instead of >> sending a NOTIFY (triggering a scan from the recipient) the child sends a >> DNS UPDATE containing the exact change with a signature that can be verified >> by the recipient. >> The recipient is typically not the primary name server for the parent, but >> rather a small service that does the same policy verifications, etc, that a >> scanner would do before committing the change. > > i am uncomfortable using the UPDATE RCODE for a purpose unrelated to zone > modification. perhaps propose a new RCODE having the same message form as > UPDATE? Why is this unrelated to zone modification? Au contraire, zone modification is absolutely the intent. But I don’t think you meant RCODE, you meant a new message type? And, sure, that would of course also work. But I think it is unnecessary. >> There are two key advantages to this alternative: >> 1. ... >> 2. No requirement for DNSSEC. Great as DNSSEC is, being able to automate the >> management of delegation information for *all* zones, regardless of whether >> the parent is signed or not, regardless of whether the child is signed or >> not, is an advantage. > > some years back this working group adopted a ubiquity regime for DNSSEC in > that all new specifications "must" expect DNSSEC to be in use and "should" > depend on it when in-scope functionality is needed. has that changed? That’s not my decision to make. However, I do note that it’s been 13 years since the root zone was signed and today, .SE, which is one of the TLDs with the highest percentage of DNSSEC deployment worldide, has a DNSSEC adoption ratio of… less than 60%. In the rest of the world the situation is even worse. So there are many, many, many zones out there that are still not signed. And that’s not their fault, it’s our fault for failing to make the DNSSEC value proposition sufficiently attractive. In some cases the reason they are not signed is because the value proposition simply doesn’t work out, attractive or not. For example, any major organisation with internal delegations will have to think long and hard about running DNSSEC-signed internal zones. It can certainly be done, and I’ve done it myself. But do I know of any real life large scale deployments of DNSSEC for corporate internal zones? No, I don’t. Would all those internal zones benefit from automatic maintenance of the delegation information? Yes they would. I’m all in favour of DNSSEC, but if we actively choose NOT to do something that would eliminate an age-old source of problems (delegation information getting out of sync) BECAUSE it just happens to work nicely also for the non-DNSSEC use case… then I think we need to take a hard look in the mirror to ensure that we’re part of the solution and not the problem. Johan
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
