Messages

1

23.1 Legacy Series / Re: Routing opnsense's DNS queries through second WAN with Firewall?

« on: June 28, 2023, 02:11:57 pm »

The solution for this was to simply put a routing rule in like



ie route 10.0.254.0/30 which includes 10.0.254.1 - 10.0.254.3 to the gateway.

I'm using NAT rules to redirect DNS queries to 8.8.8.8 to my router's IP. Unbound forwards upstream to the VPN provider's DNS servers.


The DNS servers are static, I don't really have to worry about "other" DNS servers Unbound only has BIND and the VPN provider's servers.

2

23.1 Legacy Series / Routing opnsense's DNS queries through second WAN with Firewall?

« on: April 30, 2023, 03:50:14 pm »

My OPNSense firewall is currently running Unbound. I have two DNS servers, a local BIND server which has all my .home.arpa zones, and an upstream server via the Query Forwarding option. I want to route packets out of a specific WAN port, when they originate from the OPNSense machine itself. I have been able to use policy matching for requests originating from my LAN side successfully. I have had trouble when the request originates from the OPNSense machine, ie Unbound. According to the firewall logs that traffic still tries to route through my primary WAN and not my Wireguard tunnel (IVPN_Gateway_GW).

Using the "Outbound Interface" is option in Unbound is not what I want because if the Wireguard tunnel goes down, Unbound defaults back to my primary WAN. Also that prevents me from sending requests to my local BIND instance. There doesn't appear to be an option to select a "localhost" interface.

The problem appears to be the blue circled rule below which should force DoT traffic originating from the router out IVPN_Gateway, ie my second WAN.

I am currently using 3 Outbound NAT rules:



The 1st and 2nd rule route to my Wireguard tunnel which is assigned to "IVPN_Gateway". The second rule there simply routes the remaining networks to my primary WAN. Here is what is actually in that rule:



The LAN side of my network both VLANs that are go out the primary WAN, and the others that are go out IVPN_Gateway. Here's an overview of that table:

• The first rule there simply allows access to the firewall itself (web interface)
• The second rule allows access to some hosts on my LAN, for example BMC of my server and other administritive interfaces.
  
• Third and Fourth are are IPv4 and IPv6 rules which route to the respective Wireguard WAN. They also set the respective tag vpn_only_ipv4 or vpn_only_ipv6.

Finally my floating table:



The first two rules are redirect rules that will redirect any traffic destined for port 53 to localhost for both IPv4 and IPv6. This is to prevent some gear on my network which is hardcoded to use 8.8.8.8 for example.

They match with these NAT Port Forward rules which redirect to the local IP


The last two rules simply block anything from entering the WAN inteface that has the above vpn_only_ipv4 and vpn_only_ipv6 tag match.

The problematic rule (circled in blue) is:



What I am trying to achieve here is anything that has a destination of 853 (so DoT from the OPNSense) will be directed into IVPN_Gateway_GW (when the rule is enabled). Instead what happens is the traffic still tries to go out the WAN port and is blocked.

I want to do the same for my VPN Provider's DNS servers which are hosted on 10.0.254.1 - 10.0.254.3. From my LAN side I can correctly query/ping these servers, but I cannot on my OPNSense router as it wants to go out the wrong WAN port.

If anyone has any ideas on how to improve this setup.

3

Tutorials and FAQs / Re: HOWTO - Redirect all DNS Requests to Opnsense

« on: April 26, 2023, 07:28:14 pm »

  from chris42

How would this work on ipv6? I tried to mimic the NAT rules for ipv6, however then the DNS queries fail completely

Excellent question what would be the destination for IPv6 or what is the equivalent to 127.0.0.1 for IPv6?

would it be ::1 for the loopback like 127.0.0.1 is for IPv4 loopback?

Normally ::1 is the IPv6-localhost-Address. I must configure the IPv6-Address of the Interface (created an Alias) instead of ::1 in the NAT Rule and then it works. The clients resolves DNS-Records even if using his own IPv6-DNS-Servers.

I tested this with my Android Phone. This has the App DNSChanger installed
https://play.google.com/store/apps/details?id=com.frostnerd.dnschanger
with this App you can use other DNS-Server. With the IPv6 DNS NAT Rule you can farther resolve your own DNS-Records in the Override Tab from Unbound DNS. Normally when using a external DNS-Server you can't resolve internal DNS-Records.

Normally ::1 is the IPv6-localhost-Address. I must configure the IPv6-Address of the Interface (created an Alias) instead of ::1 in the NAT Rule and then it works. The clients resolves DNS-Records even if using his own IPv6-DNS-Servers.

Hey p1n0ck10, could you go in to a little more detail regarding this?

NAT redirects now use floating rules when the rule's running across multiply interfaces.

You saying I'm going to have to create individual rules & aliases for each interfaces ipv6 address?

Currently I've got a floating ipv6 NAT rule redirecting to ::1, and it's clearly not working.

Did either of you find a solution for IPv6. I was having the exact same issue as dave.

4

23.1 Legacy Series / Re: Unbound forward to BIND tips and tricks?

« on: April 26, 2023, 07:17:16 pm »

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 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.

5

23.1 Legacy Series / Re: Unbound forward to BIND tips and tricks?

« on: April 25, 2023, 08:49:37 am »

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.

Code: [Select]

printf 'server:\n\tlocal-zone: "home.arpa." nodefault\n' > /usr/local/etc/unbound.opnsense.d/local-zone.conf

6

23.1 Legacy Series / Re: Unbound forward to BIND tips and tricks?

« on: April 24, 2023, 06:05:57 pm »

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.'

   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:

Code: [Select]

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:

Code: [Select]

# 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.

7

23.1 Legacy Series / Re: Unbound forward to BIND tips and tricks?

« on: April 23, 2023, 06:57:28 pm »

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:

Code: [Select]


 # 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.

8

23.1 Legacy Series / Re: Unbound forward to BIND tips and tricks?

« on: April 23, 2023, 03:35:32 pm »

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.









Really not sure why this is so complex. Nothing I've tried seems to get unbound to query the BIND instance.

9

23.1 Legacy Series / Re: Unbound forward to BIND tips and tricks?

« on: April 18, 2023, 06:16:06 pm »

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 would fix that. The stub-zone thing does sound like what I want. That guide 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.

Code: [Select]

                 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 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

Code: [Select]

$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

Code: [Select]

$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:
/usr/local/etc/unbound.opnsense.d

Code: [Select]

# 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.

10

23.1 Legacy Series / Re: Unbound forward to BIND tips and tricks?

« on: April 16, 2023, 04:58:54 pm »

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 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:

• home.lan

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.

Code: [Select]

## 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 for that?

11

23.1 Legacy Series / Re: Unbound forward to BIND tips and tricks?

« on: April 16, 2023, 04:48:07 pm »

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.

Code: [Select]

# 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:

Code: [Select]

# 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



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

12

23.1 Legacy Series / Re: Unbound forward to BIND tips and tricks?

« on: April 16, 2023, 04:26:34 pm »

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, you have to have localhost.

13

23.1 Legacy Series / Re: Unbound forward to BIND tips and tricks?

« on: April 16, 2023, 01:39:54 pm »

I installed DNSCrypt-proxy to test that. I can make queries with

Code: [Select]

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.

14

23.1 Legacy Series / Re: Unbound forward to BIND tips and tricks?

« on: April 16, 2023, 10:53:00 am »

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:

Code: [Select]

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:

Code: [Select]

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:

Code: [Select]

home.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800

15

23.1 Legacy Series / Re: Unbound forward to BIND tips and tricks?

« on: April 15, 2023, 10:39:33 am »

tcpdump the packets ...

I dumped that on localhost port 53530:

Code: [Select]

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:

Code: [Select]

drill -p 53530 rt1.home.arpa


Code: [Select]

rt1.home.arpa. 86400 IN A 192.168.31.1

I also tried a record that doesn't exist.

Code: [Select]

drill -p 53530 doest-exist.rt1.home.arpa


Code: [Select]

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:

Code: [Select]

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:

Code: [Select]

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:

Code: [Select]

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.