Bind9 name/srv resolution with .local domain

Question

I’ll start off by saying I am new to bind9 and I have inherited an environment that uses a .local domain. I know that using .local is bad, but I cannot change it. It is what it is. I have a requirement to use bind9 for local DNS caching (specifically for SRV records). Each time I try dig it fails to fully resolve. I see comment “WARNING: .local is reserved for Multicast DNS”

# dig prod.voip.local
; <<>> DiG 9.16.48-Debian <<>> prod.voip.local
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 48192
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: a11a15c488caedf7010000006667a78480d395b756e49357 (good)
;; QUESTION SECTION:
;prod.voip.local. IN  A
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jun 11 11:25:24 AEST 2024
;; MSG SIZE  rcvd: 90

/etc/bind/named.conf.local

  GNU nano 5.4
//
// Do any local configuration here
//
zone "prod.voip.local" {
   type forward;
   forwarders {
    10.2.1.135; // Internal DNS servers
    10.2.129.135;
    10.2.1.136;
    10.2.129.136; };
};

I joined this forum to try and ask/comment on this other post Bind9 .local stub zone if they got a resolution, but have not enough rep to comment. So I posted similar question instead. So hopefully someone can point me if a helpful direction. Thanks in advance of any help.

telcoM · Answer 1 · 2024-06-12T23:37:35.810

At least your .local subzone uses three-element names, which makes it somewhat distinguishable from mDNS. Not ideal, but not completely hopeless.

But the BIND is apparently responding with a SERVFAIL error.

Will the configured forwarders answer when your server asks? Test with dig:

dig prod.voip.local @10.2.1.135
dig prod.voip.local @10.2.129.135
dig prod.voip.local @10.2.1.136
dig prod.voip.local @10.2.129.136

What do the logs say?

You might want to add something like this to your named.conf.local for improved logging:

logging {
        // Predefined channels: default_syslog, default_debug, 
        // default_stderr and null.
        channel update_info {
                file "/var/log/named/update.log";
                severity  info;
                print-category yes;
                print-severity yes;
                print-time     yes;
        };
        channel security_info    {
                file "/var/log/named/security.log";
                severity  info;
                print-category yes;
                print-severity yes;
                print-time     yes;
        };
        channel query_log       {
                file "/var/log/named/query.log";
                severity info;
                print-category yes;
                print-severity yes;
                print-time     yes;
        };
    category update { update_info; };
    category security { security_info; };
    category dnssec { security_info; };
    category queries { query_log; };

};

If you have rndc set up, use rndc querylog on to enable query logging for troubleshooting, and rndc querylog off to disable it, while BIND is running.

If your system is a RHEL or something else that uses SELinux, you'll need to assign appropriate SELinux labels to the log files:

semanage fcontext -a -t named_log_t '/var/log/named/.*\.log'
restorecon -rv /var/log/named

Debian and related distributions might have AppArmor instead, in which case you'll need to edit /etc/apparmor.d/local/usr.sbin.named to add the line:

/var/log/named/*.log rw,

and then run:

apparmor_parser -r /etc/apparmor.d/usr.sbin.named

This will reload the main AppArmor profile for BIND9. It will have an #include that will pick up the corresponding file in the local/ subdirectory if it exists.

Bind9 name/srv resolution with .local domain

1 Answers1