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: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

Attachment: OpenPGP_0x4931CA5B6C9FC5CB_and_old_rev.asc
Description: application/pgp-keys

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
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

Reply via email to