How to selectively skip DNSSEC validation?

Petr Menšík pemensik at redhat.com
Tue Dec 8 12:54:52 UTC 2020



On 12/7/20 11:02 PM, Andrew P. wrote:
> Greetings, all.
> 
> I'm having an odd problem, and I can't seem to figure out how to get Bind to behave the way I need it to.
> 
> I have a computer with a caching-only Bind instance (version 9.11.24-RedHat-9.11.24-2.fc32), which is used both to access the regular Internet and to access the Amateur Radio Emergency Data Network (AREDN). AREDN is an RF intranet, and it has its own instance of name servers, which do not use encryption (as this is prohibited by national and international amateur radio laws and regulations). As such, I tried to add forwarding entries for the top-level domains in AREDN to my /etc/named.conf file as follows:
> 
> zone "mesh." IN {
>         type forward;
>         delegation-only no;
>         forward only;
>         forwarders { 192.168.0.7; };
> };
> 
> zone "local.mesh." IN {
>         type forward;
>         delegation-only no;
>         forward only;
>         forwarders { 192.168.0.7; };
> };
> 
> zone "10.in-addr.arpa." IN {
>         type forward;
>         forward only;
>         forwarders { 192.168.0.7; };
> };
> 
> The options section of the file specifies
> 
>         recursion yes;
>         dnssec-enable yes;
>         dnssec-validation yes;
> 
> Note that 192.168.0.7 is my local LAN address for my AREDN node (which includes DNS service on standard port 53).
> 
> However, whenever I try to do a lookup of an AREDN mesh domain name, it properly forwards to the AREDN node for service, and then complains to syslog:
> 
> Dec  7 14:54:39 server named[207007]: no valid RRSIG resolving 'aa3e-southwest-230.local.mesh/DS/IN': 192.168.0.7#53
> Dec  7 14:54:39 server named[207007]: no valid DS resolving 'aa3e-southwest-230.local.mesh/A/IN': 192.168.0.7#53

This is because mesh. network has cryptographic proof it does not exist.
Try "delv -t ns mesh." command to check it.
> 
> and returns a SERVFAIL error to the client.
> 
> If I use nslookup directly to the AREDN node, the lookup succeeds. But this won't work for a system that needs arbitrary applications (such as web browsers) to look up both Internet and AREDN names.

Sure, because DNSSEC is unable to validate anything under mesh. domain.
BIND 9.11 does not yet has permanent NTA, so you would have to use
periodic "rndc nta -force mesh.", updated every week. Use cron.weekly
for it.

Or as Mark suggested, start using domain registered on public internet.
That way, you can just make the domain without DS record, thus passing
validation on EVERY resolver as insecure. Without special explicit
configuration. It could work also as public internet gateway, if you wish.

I would suggest using something under arednmesh.org, which is already
registered. net.arednmesh.org or in.arednmesh.org. You can make sure the
domain is not DNSSEC signed, so every validating resolver would work,
even without explicit configuration at each resolver in the network. It
is not so many characters to type, is it? Use search in resolv.conf to
avoid typing it everytime.

Or try to register mesh. TLD domain for this purpose. Don't use it
before you 'own' it.
> 
> I have confirmed that neither the global Internet servers nor the AREDN intranet servers have RRSIG or DS records for the mesh or local.mesh domains. And lookups of Internet domain names (or even my non-secured local private subnet zones) still works successfully.
> 
> So, how can I configure Bind to skip the DNSSEC checks _only_ when going to the specific AREDN server, or, alternatively, only for the zones mentioned above? Either method would be acceptable; ideal would be to restrict it to the intersection of both server and zones. Given the number of criminals and identity thieves on the Internet, I can't just turn off DNSSEC checks globally. And I can't use separate computers with separate Bind instances because I need to be able to selectively relay traffic between the Internet and AREDN.
> 
> The use of "delegation-only no;" in the above zone definitions was an attempt to work around the problem, but it didn't change the behavior over not having the option there. The version of Bind I am using does not permit putting the "dnssec-enable" and "dnssec-validation" options inside a zone definition.
> 
> I look forward to your advice in this matter.
> 
> Andrew Pavlin, KA2DDO
> member, Amateur Radio Emergency Service

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik at redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x4931CA5B6C9FC5CB_and_old_rev.asc
Type: application/pgp-keys
Size: 9364 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20201208/252556bd/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20201208/252556bd/attachment-0001.bin>


More information about the bind-users mailing list