I don't actually know what you mean.
With the following (wall of) text I'd like to thoroughly describe my issue and (hopefully) answer your question(s).
The file 99-local_servers.conf contains mappings of internal domains and where the specified domains should be resolved from.
See Man page of DNSMASQ (look for --server)
Quote:
Specify IP address of upstream servers directly. Setting this flag does not suppress reading of /etc/resolv.conf, use --no-resolv to do that. If one or more optional domains are given, that server is used only for those domains and they are queried only using the specified server. This is intended for private nameservers: if you have a nameserver on your network which deals with names of the form xxx.internal.thekelleys.org.uk at 192.168.1.1 then giving the flag --server=/internal.thekelleys.org.uk/192.168.1.1 will send all queries for internal machines to that nameserver, everything else will go to the servers in /etc/resolv.conf. DNSSEC validation is turned off for such private nameservers, UNLESS a --trust-anchor is specified for the domain in question. An empty domain specification, // has the special meaning of "unqualified names only" ie names without any dots in them. A non-standard port may be specified as part of the IP address using a # character. More than one --server flag is allowed, with repeated domain or ipaddr parts as required.
Same can also be found on https://linux.die.net/man/8/dnsmasq (look for --server).
So, the following configuration
root@pihole:/home/steffen# cat /etc/dnsmasq.d/99-local_servers.conf
server=/servers.local/10.10.10.3
server=/lit.int/10.10.30.3
server=/home/10.10.40.1
server=/dmz/10.1.1.1
server=/rw/10.10.60.1
equals to
--server=/servers.local/10.10.10.3 --server=/lit.int/10.10.30.3 --server=/home/10.10.40.1 --server=/dmz/10.1.1.1 --server=/rw/10.10.60.1
Means in conclusion:
*.servers.local (eg myhostname.servers.local) will be resolved from 10.10.30.3, *.lit.int (eg another-host-name.lit.int) will be resolved from 10.10.30.3, and so forth.
I have multiple "vanilla" dnsmasq servers configured with those directives - they resolve perfectly fine.
See the following demonstration:
root@OpenWrt.lan:~$ for host in openwrt.lan openwrt.dmz openwrt.home dns.lit.int dns.servers.local; do dig $host; grep $host /var/log/dnsmasq/dnsmasq.log; done
; <<>> DiG 9.11.2-P1 <<>> openwrt.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57398
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;openwrt.lan. IN A
;; ANSWER SECTION:
openwrt.lan. 0 IN A 10.10.20.1
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 23 19:29:44 CET 2019
;; MSG SIZE rcvd: 56
Dec 23 19:29:44 dnsmasq[11011]: 28113 127.0.0.1/46064 query[A] openwrt.lan from 127.0.0.1
Dec 23 19:29:44 dnsmasq[11011]: 28113 127.0.0.1/46064 /tmp/hosts/dhcp.cfg01411c openwrt.lan is 10.10.20.1
; <<>> DiG 9.11.2-P1 <<>> openwrt.dmz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46336
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;openwrt.dmz. IN A
;; ANSWER SECTION:
openwrt.dmz. 0 IN A 10.1.1.1
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 23 19:29:44 CET 2019
;; MSG SIZE rcvd: 56
Dec 23 19:29:44 dnsmasq[11011]: 28114 127.0.0.1/33565 query[A] openwrt.dmz from 127.0.0.1
Dec 23 19:29:44 dnsmasq[11011]: 28114 127.0.0.1/33565 forwarded openwrt.dmz to 10.1.1.1
Dec 23 19:29:44 dnsmasq[11011]: 28114 127.0.0.1/33565 reply openwrt.dmz is 10.1.1.1
; <<>> DiG 9.11.2-P1 <<>> openwrt.home
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35273
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;openwrt.home. IN A
;; ANSWER SECTION:
openwrt.home. 0 IN A 10.10.40.1
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 23 19:29:44 CET 2019
;; MSG SIZE rcvd: 57
Dec 23 19:29:44 dnsmasq[11011]: 28115 127.0.0.1/34894 query[A] openwrt.home from 127.0.0.1
Dec 23 19:29:44 dnsmasq[11011]: 28115 127.0.0.1/34894 forwarded openwrt.home to 10.10.40.1
Dec 23 19:29:44 dnsmasq[11011]: 28115 127.0.0.1/34894 reply openwrt.home is 10.10.40.1
; <<>> DiG 9.11.2-P1 <<>> dns.lit.int
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24210
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;dns.lit.int. IN A
;; ANSWER SECTION:
dns.lit.int. 604568 IN A 10.10.30.3
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 23 19:29:44 CET 2019
;; MSG SIZE rcvd: 56
Dec 23 19:25:52 dnsmasq[11011]: 27066 127.0.0.1/37659 query[A] dns.lit.int from 127.0.0.1
Dec 23 19:25:52 dnsmasq[11011]: 27066 127.0.0.1/37659 forwarded dns.lit.int to 10.10.30.3
Dec 23 19:25:52 dnsmasq[11011]: 27066 127.0.0.1/37659 reply dns.lit.int is 10.10.30.3
Dec 23 19:29:44 dnsmasq[11011]: 28116 127.0.0.1/36636 query[A] dns.lit.int from 127.0.0.1
Dec 23 19:29:44 dnsmasq[11011]: 28116 127.0.0.1/36636 cached dns.lit.int is 10.10.30.3
; <<>> DiG 9.11.2-P1 <<>> dns.servers.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: NOERROR, id: 13148
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;dns.servers.local. IN A
;; ANSWER SECTION:
dns.servers.local. 604557 IN A 10.10.10.3
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 23 19:29:44 CET 2019
;; MSG SIZE rcvd: 62
Dec 23 19:25:41 dnsmasq[11011]: 27062 127.0.0.1/55127 query[A] dns.servers.local from 127.0.0.1
Dec 23 19:25:41 dnsmasq[11011]: 27062 127.0.0.1/55127 forwarded dns.servers.local to 10.10.10.3
Dec 23 19:25:41 dnsmasq[11011]: 27062 127.0.0.1/55127 reply dns.servers.local is 10.10.10.3
Dec 23 19:29:44 dnsmasq[11011]: 28117 127.0.0.1/56825 query[A] dns.servers.local from 127.0.0.1
Dec 23 19:29:44 dnsmasq[11011]: 28117 127.0.0.1/56825 cached dns.servers.local is 10.10.10.3
root@OpenWrt.lan:~$
and the corresponding dnsmasq configuration:
root@OpenWrt.lan:~$ grep -Ev '#|^$' /etc/dnsmasq.conf dhcp-option=252,"\n" log-facility=/var/log/dnsmasq/dnsmasq.log log-async=15 pid-file=/var/run/dnsmasq/dnsmasq.pid server=/servers.local/10.10.10.3 server=/lit.int/10.10.30.3 server=/home/10.10.40.1 server=/dmz/10.1.1.1 server=/rw/10.10.60.1 server=1.1.1.1 root@OpenWrt.lan:~$
I ported the exact same configuration (besides the dhcp stuff, as pi-hole is not acting as dhcp server in the network) to the dnsmasq instance, which is used from pi-hole. I would have specified it directly in
/etc/dnsmasq.conf, but I thought that it might get overwritten during an upgrade, hence the file 99-local_servers.conf
With that "demonstration" I just wanted to show, that my approach is indeed an intended behavior from dnsmasq, which works and therefore - in my personal opinion - should be working within pi-hole as well.
The only part, where I am not "conform" with the specifications is the servers.local domain (.local domain), which actually is reserved for mDNS (according to RFC 6762 - Multicast DNS)
But then again:
Any DNS query for a name ending with ".local." MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6 equivalent FF02::FB). The design rationale for using a fixed multicast address instead of selecting from a range of multicast addresses using a hash function is discussed in Appendix B. Implementers MAY choose to look up such names concurrently via other mechanisms (e.g., Unicast DNS) and coalesce the results in some fashion. Implementers choosing to do this should be aware of the potential for user confusion when a given name can produce different results depending on external network conditions (such as, but not limited to, which name lookup mechanism responds faster).
dnsmasq will resolve the domain properly unless you specify stop-dns-rebind without whitelisting the domain(s) using rebind-domain-ok=/servers.local/. (Also described in Man page of DNSMASQ and https://linux.die.net/man/8/dnsmasq).
Thanks for your help!
//EDIT
Where is the IP to name mapping set up?
I think I now understand your question. The IP to name mapping is done on the respective dns for the specified domains.
For example:
- office-printer.lan has a DNS entry on the "authoritive" resolver for that domain, in this case openwrt.lan (10.10.20.1)
- access-point.home has a DNS entry on the "authoritive" resolver for that domain, in this case openwrt.home (10.10.40.1)
- ansible.lit.int has a DNS entry on the "authoritive" resolver for that domain, in this case dns.lit.int (10.10.30.3)
- etc
Hope this helps?
