rbldnsd and DNSSEC compatibility issues - any suggestions?

Rob McEwen rob at invaluement.com
Fri Sep 11 01:13:14 UTC 2020


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 <rob at 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 at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users


-- 
Rob McEwen
https://www.invaluement.com
+1 (478) 475-9032




More information about the bind-users mailing list