On Jul 8, 2019, at 1:27 PM, Michael J. Sheldon <mshel...@godaddy.com> wrote: > I agree it's somewhat legit to answer for it, but it's a literal > maintenance nightmare when you're dealing with a very large number of > zones. Things like that tend to get put in place, then never removed.
Right, but as I said, it’s dead easy to automate. It’s only a maintenance nightmare because you haven’t done that automation. I could write you a python script to do it in a week. And registrations cost money, which means that they will go away on their own. > And it still leaves the issue that recursives should not just keep > hammering the lame delegations when they've gotten a REFUSED response. > That is a definitive legitimate response, and should be honored for a > reasonable period of time. That’s not a solvable problem. The right solution to this problem is actually to set up a way that the operator of an auth server can signal to the registrar that the delegation is refused. If you want to spend some effort on process, that’s the place I’d suggest putting it. Getting every resolver on the Internet to stop doing something that every resolver on the Internet currently does is not likely to actually change what you experience as an operator in the relatively short term. Also, of course, you mentioned that it didn’t seem legit to respond authoritatively, but if we take REFUSED as an authoritative answer, then that’s not legit either. BTW, it would also be perfectly legitimate for an authoritative server that doesn’t provide recursion to respond with NXDOMAIN for any query within a domain that’s delegated to it, and this would be quite easy to implement, although perhaps harder than my python script. Just do the lookup for the delegation, and if it points to you, respond authoritatively. Although now that I think about this, another problem we’d face here is that DNSSEC would break this completely. If you have a secure delegation, but don’t have the ability to sign the zone, you can’t respond authoritatively even if the delegation is pointing at your server. So here the only real fix is at the registrar.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
