OPNsense Forum
Archive => 23.1 Legacy Series => Topic started by: aida on April 14, 2023, 09:18:03 am
-
Hi,
I've been unable to crack this one.
I can get BIND working, and if I do a query ie:
drill -p 53530 rt1.home.arpa
I get the correct result. The issue is that I'm having trouble getting Unbound to forward queries to BIND.
The idea is that Unbound will forward .home.arpa queries to my local BIND server and everything else to an external DNS server.
Ie I have:
(https://i.imgur.com/Veu4IdU.png)
# cat /var/unbound/etc/dot.conf
server:
do-not-query-localhost: no
# Forward zones
forward-zone:
name: "."
forward-addr: 10.0.254.2@53
forward-zone:
name: "home.arpa"
forward-addr: 127.0.0.1@53530
I've tried by making sure the forward zone was . instead of home.arpa but nothing seems to work. I've disabled my overrides, I read in another thread that was necessary.
-
Could you try a domain override instead? I don't use Unbound much, so I'm guessing.
-
I hadn't tried that, but I'm not sure I can specify the port there for BIND.
(https://i.imgur.com/C7NOoZF.png)
One other thing I should mention I made sure to put home.arpa in the "Private Domains" section and "Insecure Domains".
-
I should mention the only reason I am introducing BIND to my setup is because I want to use the ACME plugin and the DNS-01 challenge (https://smallstep.com/docs/step-ca/acme-basics/index.html#acme-challenge-types) for that uses the OPNSense BIND API (https://docs.opnsense.org/development/api/plugins/bind.html).
Ie as I mentioned in this post (https://forum.opnsense.org/index.php?topic=33256.msg160904#msg160904):
(https://i.imgur.com/Dqmgpvx.png)
If you think I'm off track and there's a better way..... happy to hear it.
I should have clicked on Full Help as it says:
IP address of the authoritative DNS server for this domain, e.g. '192.168.100.100'. To use a nondefault port for communication, append an '@' with the port number.
So I entered this:
(https://i.imgur.com/RzLIS38.png)
Still not working hmm.
-
tcpdump the packets ...
I am using a similar setup with BIND and AdGuard Home. AdGuard Home forwarding to BIND on 127.0.0.1:53.
I have both services bound to 127.0.0.1 only and use port forwarding NAT rules to direct client requests per interface to either AGH or BIND, bypassing AGH ...
Kind regards,
Patrick
-
That does sound like the reverse of what I have.
Are there any benefits I wonder to having BIND listen locally, with authoritative zones, and then that forward to unbound -> external DNS? Maybe that would be a better approach.
-
AGH is the general resolver and forwards to BIND here. BIND has authoritative primary and secondary zones.
A NAT port forward rule for LAN directs all DNS requests to AGH. A NAT port forward rule in the server network directs all requests directly to BIND, because why would I want an ad block in front of a server?
-
tcpdump the packets ...
I dumped that on localhost port 53530:
length 67: (tos 0x0, ttl 64, id 29113, offset 0, flags [none], proto UDP (17), length 63, bad cksum 0 (->af3)!)
127.0.0.1.39558 > 127.0.0.1.53530: [bad udp cksum 0xfe3e -> 0x2095!] UDP, length 35
length 83: (tos 0x0, ttl 64, id 64085, offset 0, flags [none], proto UDP (17), length 79, bad cksum 0 (->8246)!)
What is interesting is I don't see an invalid record returned, just nothing dead quiet. It looks the same even if a real record is returned. For example:
drill -p 53530 rt1.home.arpa
rt1.home.arpa. 86400 IN A 192.168.31.1
I also tried a record that doesn't exist.
drill -p 53530 doest-exist.rt1.home.arpa
rt1.home.arpa. 3600 IN SOA ns1.rt1.home.arpa. admin.srv1.home.arpa. 2304110436 21600 3600 3542400 3600
If I look at a successful packet being returned on Unbound with a Host Override I see:
length 74: (tos 0x0, ttl 64, id 21684, offset 0, flags [none], proto UDP (17), length 70, bad cksum 0 (->27f1)!)
127.0.0.1.22926 > 127.0.0.1.53: [bad udp cksum 0xfe45 -> 0xbd2d!] 48201+ A? arch.srv1.home.arpa. (42)
length 90: (tos 0x0, ttl 64, id 26192, offset 0, flags [none], proto UDP (17), length 86, bad cksum 0 (->1645)!)
127.0.0.1.53 > 127.0.0.1.22926: [bad udp cksum 0xfe55 -> 0x76c3!] 48201* q: A? arch.srv1.home.arpa. 1/0/0 arch.srv1.home.arpa. A 192.168.50.253 (58)
An unsuccessful lookup (because it doesn't exist) like looks like:
length 77: (tos 0x0, ttl 64, id 27142, offset 0, flags [none], proto UDP (17), length 73, bad cksum 0 (->129c)!)
127.0.0.1.50527 > 127.0.0.1.53: [bad udp cksum 0xfe48 -> 0x9789!] 26298+ A? doesnt-exist.srv2.home.arpa. (45)
length 136: (tos 0x0, ttl 64, id 23218, offset 0, flags [none], proto UDP (17), length 132, bad cksum 0 (->21b5)!)
127.0.0.1.53 > 127.0.0.1.50527: [bad udp cksum 0xfe83 -> 0xe7fd!] 26298 NXDomain* q: A? doesnt-exist.srv2.home.arpa. 0/1/0 ns: home.arpa. SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 (104)
When I try to query Unbound for a record that is in BIND this is what I see:
length 63: (tos 0x0, ttl 64, id 19475, offset 0, flags [none], proto UDP (17), length 59, bad cksum 0 (->309d)!)
127.0.0.1.41417 > 127.0.0.1.53: [bad udp cksum 0xfe3a -> 0x25ed!] 5216+ A? rt1.home.arpa. (31)
length 122: (tos 0x0, ttl 64, id 11664, offset 0, flags [none], proto UDP (17), length 118, bad cksum 0 (->4ee5)!)
127.0.0.1.53 > 127.0.0.1.41417: [bad udp cksum 0xfe75 -> 0x8461!] 5216 NXDomain* q: A? rt1.home.arpa. 0/1/0 ns: home.arpa. SOA localhost. nobody.invalid. 1 3600 1200 604800 10800 (90)
localhost. nobody.invalid is returned by Unbound not BIND, because I see the same thing if i search for some other domain. like the one above.
I'm not sure what to try next. hmm.
-
Could you try a domain override instead? I don't use Unbound much, so I'm guessing.
I've tried that again, and it doesn't seem to work any better.
The documentation seems to indicate domain overrides are deprecated https://docs.opnsense.org/manual/unbound.html#domain-override-settings
Domain overrides has been superseded by Query Forwarding. Query forwarding also allows you to forward every single request.
.
I tried replacing it with 8.8.8.8 and when doing https://www.dnsleaktest.com/ I noticed Google's servers in there, so that seems to be working.
I tried replacing the forwarding IP with 192.168.31.1 (IP of the router), and the listen IP on BIND and that didn't work either.
Just seems that unbound refuses to use BIND for lookups.
I don't think it's a firewall issue anyway because I see on the Unbound logs:
Loopback 2023-04-16T15:23:42 127.0.0.1:53 127.0.0.1:21181 udp let out anything from firewall host itself
Loopback 2023-04-16T15:23:42 127.0.0.1:21181 127.0.0.1:53 udp let out anything from firewall host itself
If I specify port 53530 with drill:
Loopback 2023-04-16T15:52:42 127.0.0.1:53530 127.0.0.1:7476 udp let out anything from firewall host itself
Loopback 2023-04-16T15:52:42 127.0.0.1:7476 127.0.0.1:53530 udp let out anything from firewall host itself
What I should see is a pair of those, in succession ie if i look for rt1.home.arpa on 127.0.0.1 53 ie with Unbound, as it should be at least attempting to search unbound for this domain instead of failing instantly with:
home.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800
-
I installed DNSCrypt-proxy to test that. I can make queries with
drill -p 5353 @::1 google.com
.
But as soon as I try to get unbound to do it. I get no replies. That leads me to believe this is an unbound issue and not BIND.
(https://i.imgur.com/cgaK3w7.png)
-
Does Unbound have any IPv6 listen address active? Could you switch to 127.0.0.1 instead?
Edit: thnking about that idea - do you have unbound configured for specific interfaces only? Could you change that back to "Any (recommended)"?
-
Does Unbound have any IPv6 listen address active? Could you switch to 127.0.0.1 instead?
It does, and it was the same result with 127.0.0.1. I started with 127.0.0.1 but noticed the same thing with ::1. (That was less characters to type so I stuck with it).
Edit: thnking about that idea - do you have unbound configured for specific interfaces only? Could you change that back to "Any (recommended)"?
"Network Interfaces", is set to all of my LAN side interfaces, VLANs etc. "Outgoing Network Interfaces" is set to my VPN Tunnel.
That shouldn't effect localhost though, in fact there's no option to select "lo". I think based on this reply (https://github.com/opnsense/core/issues/6282#issuecomment-1409862521), you have to have localhost.
-
Remove all the network interfaces to let it switch back to "any" or "all" however that is phrased - just for a test, please.
-
Remove all the network interfaces to let it switch back to "any" or "all" however that is phrased - just for a test, please.
Sure. I let the "Network Interfaces" and "Outgoing Network Interfaces" go back to "All (Recommended)" same issue.
Querying domain in Unbound.
# dig +short version.bind chaos txt
"unbound 1.17.1"
# drill rt1.home.arpa
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 43511
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; rt1.home.arpa. IN A
;; ANSWER SECTION:
;; AUTHORITY SECTION:
home.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800
;; ADDITIONAL SECTION:
;; Query time: 0 msec
;; SERVER: 127.0.0.1
;; WHEN: Mon Apr 17 00:10:31 2023
;; MSG SIZE rcvd: 90
Querying BIND directly:
# dig +short version.bind chaos txt -p 53530
"9.16.36"
# drill -p 53530 rt1.home.arpa
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 34820
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; rt1.home.arpa. IN A
;; ANSWER SECTION:
rt1.home.arpa. 86400 IN A 192.168.31.1
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 0 msec
;; SERVER: 127.0.0.1
;; WHEN: Mon Apr 17 00:10:53 2023
;; MSG SIZE rcvd: 47
These settings
(https://i.imgur.com/DzDNDmc.png)
I'm starting to pull my hair out... as I'm running out of ideas.
In this case the second DNS server there 10.0.254.2 is my VPN server's DNS server (https://www.ivpn.net/knowledgebase/troubleshooting/what-is-the-ip-address-of-your-dns-servers/)
-
I'm wondering whether or not I shouldn't be using a forward zone, and instead should be using a stub zone? I wish the documentation on OPNSense's manual was a bit more detailed. This particular guide (https://calomel.org/unbound_dns.html) mentioned:
Unbound DNS cluster with BIND or NSD master server
Unbound is the perfect front line soldier for DNS queries from LAN clients. It is fast, reliable, stable and very secure. BIND (named) or NSD (Name Server Daemon) can be kept on the back end network to be an authoritative DNS to the Unbound cluster. This way you keep your primary DNS data segregated and unencumbered on the BIND or NSD server while the Unbound cluster servers do the resolving, caching and validation of zones for clients.
The idea is to have a few Unbound validating, recursive and caching DNS servers which LAN clients can query. Then use BIND (named) as an authoritative server which can resolve internal LAN names only. LAN clients will NEVER access the BIND DNS server and BIND will never go out to the Internet. BIND's only job is to serve internal names to the Unbound DNS server cluster. The Unbound cluster will serve all LAN clients. If Unbound needs to resolve a private ip it will ask the BIND server for ips and then cache the response. If the client needs an external ip, lets say from google.com or cnn.com, Unbound will recursively query the Internet root DNS servers and cache the response.
Lets say our private NSD or BIND server is authoritative for this internal LAN domain:
We need to tell the Unbound cluster servers that if they are looking for the private home.lan domain to ask the authoritative DNS server, otherwise go check with the root DNS servers. The NSD server's ip is 10.0.0.111 as in the ASCII diagram.
Pay special attention to the stub-zone directive we are using. Stub-zone is only used to point queries to an authoritative server like a NSD dns server. The forward-zone directive can only be used to point queries to a resolving dns server like OpenDNS.com or you local ISP's caching server. The two are not interchangeable.
## Add this to the bottom of example #2's unbound.conf configuration
## Check out our NSD Tutorial at https://calomel.org/nsd_dns.html
# This local-zone line will tell unbound that private addresses like
# 10.0.0.0/8 can send queries to a stub zone authoritative server like NSD.
local-zone: "10.in-addr.arpa." nodefault
# This is the FORWARD lookup stub zone pointing to the NSD authoritative
# server. When a client queries for firewall.home.lan the question is sent
# to the NSD server located at 10.0.0.111 and NSD returns the answer
# "10.0.0.1".
stub-zone:
name: "home.lan"
stub-addr: 10.0.0.111
# This is the REVERSE (rDNS) dns lookup for the home.lan zone. When a client
# asks for the hostname belonging to the ip address 10.0.0.1 the NSD
# authoritative server at 10.0.0.111 will send back the answer
# "firewall.home.lan".
stub-zone:
name: "10.in-addr.arpa."
stub-addr: 10.0.0.111
That's about it. A client asking for an internal dns hostname like, laptop.home.lan.lan will make Unbound query the NSD server (10.0.0.111); the answer will be cached by Unbound for later queries. Any other queries for external hostnames (calomel.org for example) from LAN clients will have Unbound go to Internet servers for the answer. Clients can now query the Unbound cluster for any hostnames they want and we do not have to worry about our primary NSD dns servers being abused or overloaded. This setup is mainly designed to segregate the authoritative server off by itself and keep the primary DNS configuration safe.
I didn't see any way to add stub-zones in the Unbound interface, so I would probably need to use some kind of advanced configuration (https://docs.opnsense.org/manual/unbound.html#advanced-configurations) for that?
-
It's dawning at me ... do you have home.arpa set as the local domain of your firewall? There's quite some "magic" in the unbound setup pulling configuration bits from all possible places, not only Services > Unbound as one might expect but also System > Settings > General.
And if I am not completely wrong - and the SOA returned by your query example corroborates that - your Unbound thinks it's authoritative for home.arpa and neither the domain override nor the forward domain entry actually override that.
Since it doesn't really matter what the firewall itself thinks its domain is, you can set that to some other arbitrary value and still hand out home.arpa explicitly with DHCP.
That's my last idea but it is at least perfectly consistent with your observation that the forward queries just never happen.
HTH,
Patrick
-
Slightly off-topic but since Patrick is here as well... in 23.1.6 you will be able to run BIND (or Dnscrypt-proxy) as a stand-alone core DNS server when using both of the listening addresses 0.0.0.0:53 and [::]:53 at the same time.
So juggling Unbound to forward might not even be necessary anymore.
Cheers,
Franco
-
I'm using Unbound with local zones in Bind successfully for many OPNsense releases, should be straight forward. While I still use the "Domain Overrides" option in Unbound, just tested it with a domain defined in "Query Forwarding" which also works flawless. Things to check:
Unbound
- Listen on all interfaces
- Use System Nameservers (disabled)
- Query Forwarding:
- Domain: domain.tld
- Address: 127.0.0.1
- Port: 53053 (whatever you running Bind on)
BIND
- Create ACL
- Name: BIND-LOCALHOST
- Networks: 127.0.0.1,::1
- Master Zone
- Zone Name: domain.tld
- Allow Query: BIND-LOCALHOST (ACL created above)
- [other zone options]
- Records
- Create a valid zone file with NS records (127.0.0.1) and your hosts, be sure to finish FQDN's with a . (dot)
- Optional create reverse zones (in-addr.arpa) as master
Query from OPNsense shell to Unbound
dig ns.domain.tld
; <<>> DiG 9.18.13 <<>> ns.domain.tld
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 493
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;ns.domain.tld. IN A
;; ANSWER SECTION:
ns.domain.tld. 86343 IN A 127.0.0.1
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Sun Apr 16 20:34:33 CEST 2023
;; MSG SIZE rcvd: 58
Query from OPNsense shell to BIND directly:
dig @127.0.0.1 -p 53053 ns.domain.tld
; <<>> DiG 9.18.13 <<>> @127.0.0.1 -p 53053 ns.domain.tld
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47716
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 1fe998ef4f90f8d001000000643c3fe6bf801d59489e799b (good)
;; QUESTION SECTION:
;ns.domain.tld. IN A
;; ANSWER SECTION:
ns.domain.tld. 86400 IN A 127.0.0.1
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53053(127.0.0.1) (UDP)
;; WHEN: Sun Apr 16 20:35:18 CEST 2023
;; MSG SIZE rcvd: 86
Query from random client OPNsense internal network to Unbound:
dig ns.domain.tld
; <<>> DiG 9.10.6 <<>> ns.domain.tld
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14726
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;ns.domain.tld. IN A
;; ANSWER SECTION:
ns.domain.tld. 86135 IN A 127.0.0.1
;; Query time: 51 msec
;; SERVER: 10.10.10.254#53(10.10.10.254)
;; WHEN: Sun Apr 16 20:38:01 CEST 2023
;; MSG SIZE rcvd: 58
Be sure to check your BIND logs if your zone is successfully loaded.
-
do you have home.arpa set as the local domain of your firewall? There's quite some "magic" in the unbound setup pulling configuration bits from all possible places, not only Services > Unbound as one might expect but also System > Settings > General.
And if I am not completely wrong - and the SOA returned by your query example corroborates that - your Unbound thinks it's authoritative for home.arpa and neither the domain override nor the forward domain entry actually override that.
Since it doesn't really matter what the firewall itself thinks its domain is, you can set that to some other arbitrary value and still hand out home.arpa explicitly with DHCP.
That's my last idea but it is at least perfectly consistent with your observation that the forward queries just never happen.
I thought System A/AAAA records (http://"https://docs.opnsense.org/manual/unbound.html#general-settings") would fix that. The stub-zone thing does sound like what I want. That guide (https://calomel.org/unbound_dns.html) says there is an expectation that Query Forwarding expects to be able to recurse up to the internet root servers.
In my case I am not doing that. The below description describes what I'm trying to do 100%.
The idea is to have a few Unbound validating, recursive and caching DNS servers which LAN clients can query. Then use BIND (named) as an authoritative server which can resolve internal LAN names only. LAN clients will NEVER access the BIND DNS server and BIND will never go out to the Internet. BIND's only job is to serve internal names to the Unbound DNS server cluster. The Unbound cluster will serve all LAN clients. If Unbound needs to resolve a private ip it will ask the BIND server for ips and then cache the response. If the client needs an external ip, lets say from google.com or cnn.com, Unbound will recursively query the Internet root DNS servers and cache the response.
Here is a rough ASCII diagram of the setup. LAN Clients are all the internal machines of the local area network (LAN). The Internet DNS is basically any external DNS server. The entries for Unbound #1 through #3 are separate machines with Unbound running on them. The final machine is the Private BIND LAN DNS.
Stub-zone is only used to point queries to an authoritative server like a NSD dns server. The forward-zone directive can only be used to point queries to a resolving dns server like OpenDNS.com or you local ISP's caching server. The two are not interchangeable.
INTERNET
|
|
-- Unbound #1 --
/ \ private authoritative only
LAN Clients -- --- Unbound #2 -- -- BIND or NSD dns server
\ / ( 10.0.0.111 )
-- Unbound #3 --
I have this subnet which currently has rules that work: ie if I query BIND directly with -p 53530
I decided to test out the stub-zone method above, in fact I found this gist (https://gist.github.com/mischief/3293008ebe1588a3f9914e2f4487bac6) which looks to be much the same thing. In this case the user has forwarded their LAN zone to dnsmasq instead.
/usr/local/etc/namedb/master/31.168.192.in-addr.arpa.db
$TTL 86400
@ IN SOA ns1.rt1.home.arpa. admin.srv1.home.arpa. ( 2304171944 21600 3600 3542400 3600 )
NS ns1.rt1.home.arpa.
1 PTR rt1.home.arpa.
1 PTR ns1.rt1.home.arpa.
1 PTR opnsense.rt1.home.arpa.
/usr/local/etc/namedb/master/home.arpa.db
$TTL 86400
@ IN SOA ns1.rt1.home.arpa. admin.srv1.home.arpa. ( 2304172310 21600 3600 3542400 3600 )
A 192.168.31.1
NS ns1
ns1 A 192.168.31.1
opnsense A 192.168.31.1
So the stub zone I created was using the advanced configuration (http://"https://docs.opnsense.org/manual/unbound.html#advanced"):
/usr/local/etc/unbound.opnsense.d
# Local DNS options
do-not-query-localhost: no
private-domain: "home.arpa"
domain-insecure: "home.arpa"
stub-zone:
name: "home.arpa"
stub-addr: 127.0.0.1@53530
local-zone: "10.168.192.in-addr.arpa." nodefault
domain-insecure: "10.168.192.in-addr.arpa"
private-address: 192.168.10.0/24
stub-zone:
name: "10.168.192.in-addr.arpa."
stub-addr: 127.0.0.1@53530
What I found was when saving the advanced configuration, my query forwarding stopped working period, all DNS lookups failed.
I think I am close but haven't quite cracked this...
The settings netnut describes there look to me much what I tried before going the stub-zone method.
I think that will only work if you let BIND query internet servers. I didn't really want to do that.
-
The settings netnut describes there look to me much what I tried before going the stub-zone method.
Instead of using "advanced" configs you only need to use the built in capabilities of the standard OPNsense web interface. Your use-case isn't that special, all you want to do is configurable with a few clicks in the OPNsense GUI.
I think that will only work if you let BIND query internet servers. I didn't really want to do that.
No, in my example only Unbound does query internet servers and will contact your local BIND instance when you request (local) domains defined in the "Domain Override" and/or "Query Forwarding" config.
Again, what your trying to do is pretty straight forward. I suggest you start with a clean config and create both Unbound and BIND configs in the web interface (it's all there). When that's working you always can tweak your config with manual custom stuff (but I don't see any reason, because it's all there in the GUI).
-
The settings netnut describes there look to me much what I tried before going the stub-zone method.
Instead of using "advanced" configs you only need to use the built in capabilities of the standard OPNsense web interface. Your use-case isn't that special, all you want to do is configurable with a few clicks in the OPNsense GUI.
That would be my preference as I wouldn't need to store any configuration files elsewhere. I like them being backed up in the single XML file that OPNSense makes.
I think that will only work if you let BIND query internet servers. I didn't really want to do that.
No, in my example only Unbound does query internet servers and will contact your local BIND instance when you request (local) domains defined in the "Domain Override" and/or "Query Forwarding" config.
Again, what your trying to do is pretty straight forward. I suggest you start with a clean config and create both Unbound and BIND configs in the web interface (it's all there). When that's working you always can tweak your config with manual custom stuff (but I don't see any reason, because it's all there in the GUI).
I did think so however I have no idea why it doesn't work for me.
Unbound seems to return a SOA localhost. nobody.invalid. for anything in my BIND instance.
There also seems to be nothing in the logs when doing a .home.arpa query to Unbound, even on level 5 verbosity. This is the configuration I tried.
(https://i.imgur.com/g1YC0qQ.png)
(https://i.imgur.com/FqiAIvw.png)
(https://i.imgur.com/RktdkPk.png)
(https://i.imgur.com/bjysgm1.png)
Really not sure why this is so complex. Nothing I've tried seems to get unbound to query the BIND instance.
-
I decided to test this on my archlinux machine and was able to reproduce. I was able to fix it and the problematic parts of the unbound config was this:
# By default, for a number of zones a small default 'nothing here'
# reply is built-in. Query traffic is thus blocked. If you
# wish to serve such zone you can unblock them by uncommenting one
# of the nodefault statements below.
# You may also have to use domain-insecure: zone to make DNSSEC work,
# unless you have your own trust anchors for this zone.
# local-zone: "localhost." nodefault
# local-zone: "127.in-addr.arpa." nodefault
# local-zone: "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa." nodefault
local-zone: "home.arpa." nodefault
By default it seems unbound does something with home.arpa domains. I didn't see a method to uncomment that last line in the opnsense web interface.
-
That's why I have never beeb able to reproduce this problem. Jesus tapdancing christ! Special treatment of any particular zone by "magic" should be punished. In BIND you setup regular zone files for e.g. localhost.
Another remark: I always recommend using a subdomain of a real domain name for internal networks. This way you won't get a conflict when your "private" domain unexpectedly has some special meaning (".local") or a new top level domain is introduced or suddenly you need split DNS because you run AD but marketing insists the external webserver must be "company.com", etc.
So the name and domain of my company is punkt.de. Our internal network is intern.punkt.de. No entry for anything in intern.punkt.de is published on the Internet. My private domain is hausen.com. My homelab uses ettlingen.hausen.com, the place where I live. Again no ettlingen.hausen.com anywhere public.
HTH,
Patrick
-
Special treatment of any particular zone by "magic" should be punished.
I actually think it violates the Section 3 of RFC 8375 Special-Use Domain 'home.arpa.' (https://www.rfc-editor.org/rfc/rfc8375.html#section-4)
1. Users can use names ending with '.home.arpa.' just as they would
use any other domain name. The 'home.arpa.' name is chosen to be
readily recognized by users as signifying that the name is
addressing a service on the homenet to which the user's device is
connected.
2. Application software SHOULD NOT treat names ending in
'.home.arpa.' differently than other names. In particular, there
is no basis for trusting names that are subdomains of
'home.arpa.' (see Section 6).
3. Name resolution APIs and libraries MUST NOT recognize names that
end in '.home.arpa.' as special and MUST NOT treat them as having
special significance, except that it may be necessary that such
APIs not bypass the locally configured recursive resolvers.
In BIND you setup regular zone files for e.g. localhost.
Which I have done.
Anyway I was able to disable this with:
printf 'server:\n\tlocal-zone: "home.arpa." nodefault\n' > /usr/local/etc/unbound.opnsense.d/local-zone.conf
Anyway I found that wasn't working correctly as the A record shows up as empty. That was because I had the Outgoing Interface set to my VPN interface which sets:
# Outgoing interfaces to be used
outgoing-interface: 10.82.40.3
The intention here was to prevent leaking to my ISP. It seems it always did regardless of if " Use System Nameservers" was selected or not. In hindsight, it would have been better to do something like https://forum.opnsense.org/index.php?topic=9245.0
When I had that set to any I was finding
This seems related to the outgoing interface, because I was using my VPN provider's internal interface.
Another remark: I always recommend using a subdomain of a real domain name for internal networks. This way you won't get a conflict when your "private" domain unexpectedly has some special meaning (".local") or a new top level domain is introduced or suddenly you need split DNS because you run AD but marketing insists the external webserver must be "company.com", etc.
So the name and domain of my company is punkt.de. Our internal network is intern.punkt.de. No entry for anything in intern.punkt.de is published on the Internet. My private domain is hausen.com. My homelab uses ettlingen.hausen.com, the place where I live. Again no ettlingen.hausen.com anywhere public.
That is one option, but as this is a small home network with only internal services, I didn't really want to register a domain just for that.
-
That is one option, but as this is a small home network with only internal services, I didn't really want to register a domain just for that.
Good you have it fixed, because you're in full control of your name resolution you can use any domain you like (except .arpa off course 8)). Like pmhausen already addressed stay away from specials like .local , but you're free to make up anything you like, for instance .lan , .home , .internal , .l33t etc.
I hijack several public domains locally just because I like the name or need to emulate/demo stuff.
-
We had another user report problems trying to use .lan as the local domain and host names directly under that. As soon as they switched to .myname.lan everything worked as expected. Ah ... yes, I remember: browsers do not accept wildcard certificates for TLDs like *.lan.
Possibly it's only .home.arpa that gets a special treatment but .myname.home.arpa works ok?
-
Ah ... yes, I remember: browsers do not accept wildcard certificates for TLDs like *.lan.
With a public CA (like Lets Encrypt), no, you never get a certificate for non-existent domains or IP addresses in the CN or SAN...
But if you run your own DNS, your next step could be running your own Private / Corporate PKI. Browers will check certificate based on address (valid if you run your own DNS), Date/Time and Trusted Root CA.
So with your private CA you can sign valid certs with IP addresses or, in this case when running your private DNS, non-public domain names. I'm even running my internal OCSP responder on a domain with a .PKI tld. It's shady and non-standard, but you sure can have a fully functional PKI without public validated domain names.
Possibly it's only .home.arpa that gets a special treatment but .myname.home.arpa works ok?
Yeah, never knew Unbound is that picky about .arpa, so thanks aida for the insight ;-). Thinking about it, it makes sense not f***ing up your reverse zones by accident.
-
@netnut, even with a private CA the browser will not accept a wildcard cert for *.lan, only for *.foo.lan ... that was the problem of that other person as it turned out.
-
but you're free to make up anything you like, for instance .lan , .home , .internal , .l33t etc.
Yeah best not to do that .home.arpa is intended for homenets. I am pretty sure I've seen recommendations against using .home and .internal on HN, partly because of old Microsoft documentation suggested that.
We had another user report problems trying to use .lan as the local domain and host names directly under that. As soon as they switched to .myname.lan everything worked as expected. Ah ... yes, I remember: browsers do not accept wildcard certificates for TLDs like *.lan.
Possibly it's only .home.arpa that gets a special treatment but .myname.home.arpa works ok?
No the point is .home.arpa should not get any special treatment behind being non routable upstream. The RFC is only from 2018 so people are a little stuck in the past.
@netnut, even with a private CA the browser will not accept a wildcard cert for *.lan, only for *.foo.lan ... that was the problem of that other person as it turned out.
.home.arpa certainly works with Chrome and Firefox if you have your own root.
But yes, the TLDR of this thread is that local-zone should be configurable in the web UI for Unbound. When you use a host-override that automatically overrides it, but if you're using a nameserver upstream like BIND you'll need to have that set to nondefault.
printf 'server:\n\tlocal-zone: "home.arpa." nodefault\n' > /usr/local/etc/unbound.opnsense.d/local-zone.conf
-
So I had another look at this.
Without using the Outgoing Interface on Unbound, I need a rule which directs this traffic into my VPN. If I use the Outgoing Interface as my Wireguard tunnel (so that requests go over the VPN), then the issue is that I can't access the BIND instance on localhost. I tried the policy match rule on anything from localhost with a destination port of 53, but it seems to be not picked up.
On a separate note:
I used this method (https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html) to redirect all IPv4 DNS unencrypted requests to my OPNSense router. This is because some devices are hardcoded to use things like 8.8.8.8. Unfortunately the same method did not work for IPv6.
-
I am sorry if I am breaking forum etiquette by posting in this thread, but the thread has the same topic as my problem. Unfortunately the information within has not helped me find a solution.
My configuration is basically the config that netnut describes, with the addition that I've also enabled DNS over TLS.
What I want to achieve is that any query on the local domain goes to bind, everything else (i.e. the Internet) is forwarded by DoT.
I've come so far that I get correct answers if I am querying bind directly, but I am unable to get unbound to forward the local queries to bind. In my unbound log the only trace I find is:
info: resolving local.domain.tld. A IN
But no answer is gained.
I am quite at a loss how to debug this.
The domain in question is under a CCTLD.
Unbound
- Listen on all interfaces on port 53
- Enable DNSSEC Support (enabled)
- Register DHCP Leases (enabled)
- Register DHCP Static Mappings (enabled)
- Use System Nameservers (disabled)
- Query Forwarding:
- Domain: local.domain.tld
- Address: 127.0.0.1
- Port: 53530
- DNS over TLS
- Domain: .
- Address: Quad9 IPv4 and IPv6
BIND
- Listen on 127.0.0.1:53530
- Recursion: RFC1819 (ACL defined bellow)
- Allow Query: RFC1819 (ACL defined bellow)
- DNSSEC Validation: Auto
- ACL
- Name: RFC1918
- Networks: RFC1918 and 127.0.0.0/24
- Master Zone
- Zone Name: local.domain.tld
- Allow Query: RFC1918
- [other zone options]
- Records
- Zone file with NS records (127.0.0.1) and hosts (FQDN's finished with a . (dot))
Any and all help is greatly appreciated.