Mark,
Most invaluement subscribers do direct queries - to hostnames that end
with my own valid domain names that don't have this DNSSEC issue - those
are the ONE ones that make use of public DNS and are broadcast across
the internet.
Our usage of ".local" zones for those who are RSYNC'ing our data - dates
back to something like 2007, and the RFC you referred to is from 2013.
By the time this RFC had been published, we'd already had customer using
the ".local" for 6 years. At the time that came out in 2013, I assessed
whether I needed to get my clients to change that, but it didn't seem to
effect anyone. Again, those of our subscribers who RSYNC our data and
use the ".local" zone names - are just using that for 100% local usage,
and are not trying to broadcast it across the internet. And in many of
THOSE cases, if the BIND and RBLDND are on the same computer, as is
often the case, it doesn't even go out to the LAN - this is all on one
single computer.
So are you claiming that if I simply changed the zone naming form ending
in ".local" - to something else - such as ".dnsbl" - then all my
problems would go away? And the forwarder will start working? (even
though rbldnsd doesn't do DNSSEC)
That would be EXCELLENT news! Or, if that doesn't actually fix my
problem, do you have any suggestions that actually address my actual
question?
Rob McEwen
On 9/10/2020 7:37 PM, Mark Andrews wrote:
.local is for mDNS (RFC 6762). Do not use it for other purposes as you are
hijacking the namespace.
The best solution is to NOT change the name of the zones from those that you
use publicly. That way they have the correct DNSSEC chain of trust down from
the root. If you want to use different zone names then create delegations to
empty unsigned zones (SOA and NS records only) like those done for
10.IN-ADDR.ARPA in a zone you control. That breaks the DNSSEC chain of trust
at the delegation point. If you later decide you want to sign these zones you
can do so and link them into the DNSSEC chain of trust. Just sign both the
rbldsnd-formatted files and the empty zones.
If you absolutely must continue to hijack the .local namespace, which is
allocated for a different purpose, then add validate-except entries to
named.conf
Mark
On 11 Sep 2020, at 01:56, Rob McEwen <r...@invaluement.com> wrote:
I manage an anti-spam DNSBL and I've been running into an issue in recent years
- that I'm FINALLY getting around to asking about. I just joined this list to
ask this question. Also, I checked the archives, but couldn't find an answer -
at least, not one I understood.
So basically, while most of our users do direct queries and don't have this issue - some
of our larger subscribers RSYNC the rbldsnd-formatted files, and then they typically run
rbldnsd on the same server as their BIND server that is answering their DNSBL queries.
Then, their invaluement zone names will all end with "invaluement.local".
Typically, their RBLDNSD server is set up to listen on 127.0.0.2 - and then they use BIND
for answering their DNSBL queries, and so they tell BIND to get its answers for THOSE
invaluement dnsbl queries by doing a DNS forwarder, telling bind to get the answers for
THOSE zones from 127.0.0.2 - as shown below:
zone "invaluement.local" in {
type forward;
forward only;
forwarders { 127.0.0.2; };
};
This works perfectly - so long as DNSSEC is turned off. And since most of our
subscribers are running a dedicated instance of BIND that is ONLY used for
DNSBL queries, they don't mind turning DNSSEC off.
But, occasionally, we have a customer who cannot turn DNSSEC off. So I was
hoping that THIS command would work:
dnssec-must-be-secure "invaluement.local" no;
But it doesn't seem to be helping at all. Is that command suppose to disable DNSSEC checking for a
particular zone? If yes, what did I do wrong? If not, what does "dnssec-must-be-secure"
set to "no" do?
I've heard that there is NOT a way to get this to work - and that such
subscribers much use DNS Delegation, instead. But I really wish this
could be done by simply turning off DNSSEC for a particular zone. That could be
useful for MANY various types of internal zones that need this. But if this is
that case, how would that DNS Delegation look, to get the above forwarding
example to work using delegation instead?
Thanks in advance for your help!
--
Rob McEwen, invaluement
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Rob McEwen
https://www.invaluement.com
+1 (478) 475-9032
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
