Finer control over REFUSED, e.g. root referrals

[Fred Morris]

"Our society has ordered itself to be responsible, but also so that no
one person is responsible."

Ondřej you're not going to like my reply, but I'd like it to be
adequately reasoned. It will be debatable. I'm not even sure this is the
best venue, maybe dns-operations at dns-oarc.net would be a better choice,
open to suggestions. I would hope that it is somewhere Andrew Pavlin is
subscribed to, and also others.

So, this is not my proper reply, it is a request for information. I
invite anyone who is "birds of a feather" or who has pertinent technical
documentation or proceedings which inform this to send /contact me off list.

On 9/7/25 11:28 PM, Ondřej Surý wrote:
> I can definitely say this is not going to be implemented and nobody should.

The pivot for this is farther below: a DNS spoofing opportunity. I hear
you, but the cat is out of the barn, the horse is out of the bag. ISC
gave me a horse to ride on (rpz-drop) and no other choice (the
hypothetical rpz-refused), so I'm riding it and not looking back. We're
in a war, and individual operators need tactical levers, we can't wait
for (or afford) help which never arrives. BIND appears to have some
embedded business logic with no tactical levers.

If this is a third rail, it needs to be examined. A followup poster
(Michael Richardson) has already observed:

> Surely I'm allowed to *not* run a DNS server on an IP address, and dropping
> replies surely fits into that space 
I have much more bitter things to say. (Maybe I'll temper that. TBD.)

Ondřej again:

> Not returning answer is a protocol violation that can lead to DNS spoofing window being much larger.

This really needs to be unpacked and informed by the post-Mockapetris
era. And the post-Kaminsky era. And the Shriver / Vixie era. I'm sure
I've missed something.

I would appreciate references.

> There are also servers like BIND 9 that maintain a state per server/IP address and an attacker can point her domain name to your server and use this to manipulate the remote server state by asking for such name at the victim resolver.
Definitely need references to consider this credible. If it's credible,
seems worth defending against, no?
> This is extremely bad idea and there are good reasons why this hasn’t been implemented and why this ever won’t be implemented.
>
> Ondrej

If it's necessary, somebody will implement it for you.


Respectfully...

--

Fred Morris, internet plumber