Hi Peter, > On 10/25/23 18:19, Johan Stenstam wrote: >> 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 > > If that's the case, there's a significant problem. Do you have numbers on the > extent of the problem / how much of an issue that is for your daily runs at > .se?
Not really. Sorry. There are several reasons for this. One is that our “production scanners” are designed to be really slow (largely to avoid rate limiting). Another is that a prototype fast scanner (that I wrote) ran into so much rate limiting issues as to be more or less useless. So I implemented adaptive delays per target destination to scale back the query frequency based on how much rate limiting was hurting me in the previous scan. But that also wasn’t enough so we’ve talked to the largest providers to have them whitelist our scanning. To be fair I should mention that my scanner queried for more things than just CDS and CSYNC. So my query volume is noticeably higher than a “pure” CDS and/or CSYNC scanner would have. >> And not only from one vantage point but from several, located around the >> world. > > That's only needed for unauthenticated bootstrapping; both authenticated > bootstrapping and CDS-induced DS updates don't need multiple vantage points. > > Extra vantage points are a mitigation for the (prevalent) lack of signatures > during bootstrapping; once authentication is handled, there's no need for it. I get that. But, as you know from both the draft and the presentation I made at OARC some weeks ago, this is really not about how to make scanners slightly less inefficient. I don’t think that any new mechanism for how to automate the management of delegation information will replace the CDS and CSYNC scanners in the TLD registries. The registry scanners are here to stay. And that’s why you, John Levine and I have a draft about improving the scanner efficiency via generalised notifications. THIS draft, on the other hand, is is not about scanners at all. It is about how to automate delegation management for perhaps a million parent zones that do not run scanners today, don’t want to or are unable to run scanners tomorrow and in general would benefit from a much less complex solution to the problem. >> Furthermore, for unsigned delegations, all the nameservers are queried. >> Every time. It’s a lot of DNS queries. > > Where's that written? > > I don't think it's correct. For example, if you find on the same nameserver > that you queried a CDS/CDNSKEY RRset that indicates no change over the > existing DS record, then there's no point in looking at other nameserver. > (They would either confirm that no update should happen, or they would be > contradictory, in which case no update should happen.) I have to admit that I haven’t looked at the requirements, I only looked at the implementation for our production scanner (that I did not write). So I want to revisit the design of the current scanner regardless and I’ll make sure to look at this issue also. > Together with the vantage-point considerations, I think the actual number of > queries is about 10x lower than if all NS are always asked from several > vantage points. I’m sure you’re right. But I don’t see how that matters from the POV of this draft. But I have to ask: is your point just that I should get my math right or is your point that scanners are fine, every parent should run one and there is no problem to solve? >> But do I know of any real life large scale deployments of DNSSEC for >> corporate internal zones? > > I may be wrong, but I believe Salesforce to be an example. Aha. Interesting. Let’s see if someone would like to confirm that. Regards, Johan
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
