On Sun, Jun 04, 2023 at 01:19:18PM -0700, William Herrin wrote:
Perhaps you missed my subsequent message where I pointed out that the
I did not.
IP address is hard-coded in Bind which will use it by default unless configured not to.
It is not "hard coded." It is a default configuration. You can change it. You are *supposed* to change it.
It's also not a vulnerability. A vulnerability, as defined by MITRE for CVE is:
"A weakness in the computational logic (e.g., code) found in software and hardware components that, when exploited, results in a negative impact to confidentiality, integrity, or availability.
At an absolute minimum there's an impact to confidentiality since it causes Bind to announce itself to an IP address that is not a root server. If the user configured bind with DNSSEC validation disabled, it's also a negative impact to integrity and availability since the potential false responder can steer bind away from the true DNS tree.
First, you have completely ignored the argument: THERE IS NO FLAW IN COMPUTATIONAL LOGIC. There is no vulnerability. Second, the DNS protocol offers no guarantee of confidentiality. Is the protocol itself a vulnerability? Would you like to file a CVE against that? You are recommending embarking on a ludicrous journey ad absurdum. How about the web browser that makes a GET request via HTTP on port 80 before being 301'd over to HTTPS on 443? Or the web server that defaults to LISTEN on 80 and offer its success page without further configuration? Do I even need to cast a sideways glance at BGP? Perhaps you missed my message where I advised against abusing the already fragile de facto security notification mechanisms to propagate your desired configuration change. If the CVE process becomes inundated with configuration change notifications, it will cease to enjoy the timely attention which ought to be reserved for real, pants-soiling zero day vulnerabilities. But let's indulge a what-if: If some malicious party were to somehow wrestle control of the old address and begin offering false returns (which I cannot believe to be any worse than that some members on here already do with NXDOMAINs to their customers,) that situation will be handled by simply repeating the advisory of a configuration change. There exist mechanisms for notifying about network configuration changes. You are participating in at least one right now. In summary, it's not a vulnerability. Stop pushing CVE as an answer. It breaks far more than it would fix. All IANA can do (or is supposed to do) is publish the notice. -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__