Is there an RFC specifying precisely what are considered the proper precautions?
"precautions" should ideally be enabled in BIND by default.
Not of which I'm aware. I'm happy to contribute to any efforts you or anyone else are volunteering to coordinate on this topic, as it's important work which ought to be done sooner & not later.
;>
My point here is that... splitting recursive service and cordoning off recursive service by
using a firewall
Using a stateful firewall is contraindicated.
or ACL based on IP address, is only a partially effective operational workaround to a serious defect in the protocol.
It's actually a combination of serious defects in a number of protocols, starting with IPv4 itself.
IPv4 went into service ~27 years ago as testbed protocol. The first formal security assessment of the IPv4 core protocols was completed last month.
IPv6 inherits all the security problems inherent in IPv4, & introduces new ones - the ND mess & the untold billions of dollars in opex costs that the consonance of the letters 'B', 'C', 'D', & 'E' will entail are just two glaring examples.
So, if we're looking for protocol architecture dragons to slay, there're far more basic issues in need of a strong sword-arm before we even get to outliers like the DNS, heh.
Authoritative service is as subject to DoS as ever, especially with IPv6 and DNSSEC
deployments.
And there are deployment & operational BCPs which can mitigate DDoS of authoritative DNS services, from logical separation of functions (see <https://files.me.com/roland.dobbins/m4g34u> for an example) to S/RTBH to flowspec to commercial IDMS solutions.
[Full disclosure: my employer is a vendor of such solutions.]
The DNS protocol should be fixed so we don't need this workaround.
By all means.
In the meantime, it's important to realize that many of the resource constraints which were extant at the time the DNS was designed no longer hold sway. DNS reflection/amplification attacks can be eliminated by the simple (and, nowadays, practical, IMHO) expedient of re-configuring resolver-facing DNS servers to force the use TCP by default.
The best part is that DNS operators can start doing this today, without recourse to standards bodies, working groups, et. al. No need for any inter-organizational coordination at all - each can move at his own pace, within his own span of administrative control.
As an aside, it should be noted that switching the DNS over to TCP by default would accomplish a great deal of what DNSSEC is intended to provide, with far less in the way of architectural, operational, & administrative complexity.
Most folks who still misguidedly filter TCP/53 are unlikely to support EDNS0, either, so they're already hurting - a widespread switch to TCP would likely finally force them out of their jungle fastnesses and out blinking into the sunlight.
;>
Standardization effort should concentrate on changing the protocol.
It's important to keep in mind how long the last substantive changes to the DNS have required, as opposed to the near-term expedient of implementing BCPs & switching to TCP.
Restricting recursive service is a good short term solution, but it is not for every case.
Concur 100%. Meanwhile, we continue to resolve with the DNS we have until the new, improved version is designed, tested, & generally deployed.
;>
The workaround is not a best practice, it is evidence that the DNS protocol should be changed.
There's a reason proof-of-work solutions have never been widely deployed - in the final analysis, they all too often end up simply a form of cost-shifting which leaves the system in question just as vulnerable (if not more so) to DoS as it was in the first place, just within a different transaction path/layer.
So, while I agree with you that changes are called for, implementing proofs-of-work into the DNS transactional model isn't one I'd personally recommend, FWIW.