[SOLVED] Bind - zones - PTR IPv6 question

[RamSense]

Hi,

I am since very recently running my opnsense with Bind instead of Unbound. No upstream DNS.
In Bind there is no auto Register DHCP static mappings. So you have to make a zone file and record to make a PTR / Reverse dns check.

My opnsense ipv4 is: 192.168.1.1 and ipv6: 2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240

I have created a reverse zone file and record for ipv4 and ipv6

when using dix -x 192.168.1.1 I get 2 different results. working for ipv4 and not working for ipv6. When switching back to Unbound as my system was before using Bind, the result is the same.

good:
; <<>> DiG 9.10.6 <<>> -x 192.168.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36225
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;1.1.168.192.in-addr.arpa.   IN   PTR

;; ANSWER SECTION:
1.1.168.192.in-addr.arpa. 10   IN   PTR   LapStart.localdomain.
1.1.168.192.in-addr.arpa. 10   IN   PTR   LapStart.

;; Query time: 1 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Mon Dec 05 17:19:53 CET 2022
;; MSG SIZE  rcvd: 98

Wrong:
; <<>> DiG 9.10.6 <<>> -x 192.168.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7730
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;1.1.168.192.in-addr.arpa.   IN   PTR

;; AUTHORITY SECTION:
1.1.168.192.in-addr.arpa. 10   IN   SOA   fake-for-negative-caching.adguard.com. hostmaster.1.1.168.192.in-addr.arpa. 100500 1800 900 604800 86400

;; Query time: 49 msec
;; SERVER: 2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240#53(2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240)
;; WHEN: Mon Dec 05 17:19:51 CET 2022
;; MSG SIZE  rcvd: 174


This makes me believe it has something to do with the IPV6 / port forward or ipv6 related? Or an Adguard Home issue?

See also attached screenshots

Who can help me out here?

[Patrick M. Hausen]

The point I was repeating in our private conversation is that you need to debug which server delivers which result without getting into the port forwarding mess, first.

You are not querying for some IPv6 reverse information. The "zone" stuff we discussed. This is not at all related to IPv6 PTR records. You are querying a PTR record for 192.168.1.1 on both occasions, but one time you are asking *some* name server at an IPv4 address and another time *some* name server at an IPv6 address.

These are probably by some mistake simply not the same one.

So let's check the basics. I assume you want to redirect all client queries to AdGuard Home? And AGH uses BIND as its forwarder (old-fashioned wording, upstream recursive DNS server, rather)?

Check the zone in BIND. SSH to your OPNsense and use

Code Select Expand

drill -p <port of BIND> -x @127.0.0.1 <some IPv4 address>
drill -p <port of BIND> -x @127.0.0.1 <some IPv6 address>

If you have reverse zones for both the IPv4 and the IPv6 address in question you should get a valid result.

Please report back and let's work from there.

[RamSense]

Thanks for your guidance to look further into this. drill results:

So let's check the basics. I assume you want to redirect all client queries to AdGuard Home? And AGH uses BIND as its forwarder (old-fashioned wording, upstream recursive DNS server, rather)?

-> that is correct.
Adguard home listens to port 53, Bind to port 5353, adguard home [upstream DNS servers]: 127.0.0.1:5353 and
[::1]:5353, the same for [bootstrap dns servers] and [Private reverse dns servers]


IPv4:
# drill -p 5353 -x @127.0.0.1 192.168.1.1
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 27843
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; 1.1.168.192.in-addr.arpa.   IN   PTR

;; ANSWER SECTION:
1.1.168.192.in-addr.arpa.   86400   IN   PTR   LapStart.localdomain.

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 127.0.0.1
;; WHEN: Tue Dec  6 07:21:13 2022
;; MSG SIZE  rcvd: 76

IPv6:
# drill -p 5353 -x @127.0.0.1 2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 63763
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION
;; 0.4.2.6.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa.   IN   PTR

;; ANSWER SECTION:
0.4.2.6.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa.   3600   IN   PTR   2001-xxxx-xxxx-xxxx-xxxx-xxxx-xxxx-6240.cable.dynamic.v6.ziggo.nl.

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 1996 msec
;; SERVER: 127.0.0.1
;; WHEN: Tue Dec  6 07:23:38 2022
;; MSG SIZE  rcvd: 169
=======

ziggo is my isp.

both ip's ipv4 and ipv6 where for the LAN interface.
interfaces: LAN : IPv4 Configuration Type: Static IPv4
interfaces: LAN : IPv6 Configuration Type: Track Interface

[Patrick M. Hausen]

What are the contents of your reverse zones for IPv4 and IPv6, respectively?

Besides, you do not need [::1]:5353 as upstream in AGH. There is no need to query via IPv6 to resolve IPv6 addresses. Similarly you do not need private reverse DNS servers - everything that AGH does not already know is forwarded to BIND.

HTH,
Patrick

[RamSense]

ah yes that is from the old config still being there in adguard home with different upstream servers and added reverse and private dns to opnsense. The ::1 was for me looking into what the system / Adguard home would be prefering for the queries. Ipv4 or if IPv6 would be preferred. But both are the same to opnsense indead.

zone IPv4 with dns zone LapStart.localdomain
Record IPv4
Zone IPv6 with dns zone LapStart.localdomain
record Ipv6
and ACL
are attached and where my opnsense ipv4 is: 192.168.1.1 and ipv6: 2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240

[RamSense]

ipv6-record
(could not attach it in 1 posting)

[Patrick M. Hausen]

You only showed the PTR records. Do you have NS records in your zones? They are mandatory, you know?  ;)

[RamSense]

Sorry, here the NS records IPv4 and IPv6.

I tried also:
Name: @
Type: NS
Value:LapStart.localdomain. and Value: 192.168.1.1 or ipv6

With the same result, so maybe it is the NS record what i messed up?

[Patrick M. Hausen]

Both zones - for IPv4 and for IPv6 need at least one NS record. The name is either empty or "@". For the value you can enter some arbitrary FQDN but the most reasonable is the one of your OPNsense. Don't forget to terminate with a "."

[RamSense]

Ok,

tried record in ipv4 and ipv6 with:
Name: @
Type: NS
Value: LapStart.localdomain.

same result so far :-(

n.b. when:
nslookup 192.168.1.1 2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240
Server:      2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240
Address:   2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240#53

** server can't find 1.1.168.192.in-addr.arpa: NXDOMAIN

------

$ nslookup 192.168.1.1 192.168.1.1
Server:      192.168.1.1
Address:   192.168.1.1#53

Non-authoritative answer:
1.1.168.192.in-addr.arpa   name = LapStart.localdomain.
1.1.168.192.in-addr.arpa   name = LapStart.

Authoritative answers can be found from:

[Patrick M. Hausen]

This is one step too quick. Please check at the 127.0.0.1 address on the OPNsense proper that the reverse records for IPv4 and IPv6 are returned. Then we can take care of the different routing of these requests via IPv4 or IPv6 from outside.

Use exactly drill -x -p 5353 @127.0.0.1 ... etc. as you did before.

[RamSense]

# drill -x -p 5353 @127.0.0.1 192.168.1.1
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 25103
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; 1.1.168.192.in-addr.arpa.   IN   PTR

;; ANSWER SECTION:
1.1.168.192.in-addr.arpa.   86400   IN   PTR   LapStart.localdomain.

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 127.0.0.1
;; WHEN: Tue Dec  6 21:53:21 2022
;; MSG SIZE  rcvd: 76

====================================

# drill -p 5353 -x @127.0.0.1 2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 43371
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; 0.4.2.6.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.2.ip6.arpa.   IN   PTR

;; ANSWER SECTION:
0.4.2.6.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.2.ip6.arpa.   1212   IN   PTR   2001-xxxx-xxxx-xxxx-xxxx-xxxx-xxxx-6240.cable.dynamic.v6.ziggo.nl.

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 127.0.0.1
;; WHEN: Tue Dec  6 21:54:35 2022
;; MSG SIZE  rcvd: 169

[Patrick M. Hausen]

Ok, something is still wrong with your zones. Talk more tomorrow.

[RamSense]

I added a screenshot of all the records in the zones, hope that helps and maybe i forgot something to add?
Also Adguard Home had an update today with a new option of clearing the cache, what i did just in case to see, but no difference. :

[Patrick M. Hausen]

For one don't put A and AAAA records in your reverse zones. They need SOA, NS and PTR only. The A and AAAA records go into the "localdomain" zone, if you want to name it that.

If you don't want to publish your IP addresses here, you can send me an archive of the /usr/local/etc/namedb/named.conf file and the /usr/local/etc/namedb/master directory and all files in there.

You probably got that right now but as a reminder: don't conflate querying BIND over IPv4 vs. IPv6 with querying for information about IPv4 vs. IPv6 zones and records.

It's perfectly sufficient to just use 127.0.0.1 to debug the zone problem first. You can query for IPv6 info via IPv4 and vice versa. Once we got that tackled we will look at the packet flow and forwarding issues.