Ray Bellis writes: > Serve stael must not become a vector whereby malware can keep its C&C > systems artificially alive even if the parent has removed the C&C domain > name.
I wholeheartedly agree with this ideal, and am very open to considering text improvements. The document already has guidance on this point, but it is admittedly in a considerations section and not in standards action, and is a weaker "SHOULD" versus "MUST" right now. Would the WG prefer that a line like this be put into the Standards Action section? When no authorities for a name are able to be reached, the resolver MUST attempt to refresh the delegation. I like the basic idea but am a little stuck on the wording because of the endless loop it implies. This is probably why it appears as "SHOULD" already (but I honestly don't remember, so there's that). It seems to me that the risk is very low, even as currently written in the draft. Not only do I have a lot of confidence in the implementers of the most widely used resolvers in the world, as they're right here participating too and have in the past shown good conscientiousness in this area, but the practical attack is still hard to make meaningful. If "the parent has removed the C&C domain name" as you said, serve-stale shouldn't even kick in. NxDomain, problem solved. Various other scenarios come to mind, even with obstinate parents that won't remove the delegation and the zone's NSs have gone dark, but those scenarios have other possible remedies. And fast flux using long TTL NS RRsets are an issue no matter whether serve-stale is in play or not. So text regarding refreshing delegations could be given even more words to describe backoff intervals and such, but to what end? What's the scenario? And wouldn't it be handled better by reviving resimprove to talk about the generalized problem? (To be clear, I'm quite okay with politely being shown that I'm wrong and there is a vector by which serve-stale becomes uniquely interesting, and would certainly endeavour to make sure it is addressed.) _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
