[SOLVED] Bind - zones - PTR IPv6 question

[Patrick M. Hausen]

Yes and yes. Every zone needs at least one NS record. If you don't run any secondary DNS servers, there is only one and that's the name of your OPNsense.

Trailing dot is needed on the right hand side to tell BIND not to append the zone name after what you put in there. It is common practice to only use short names on the left hand side. So when I put

opnsense IN A 192.168.1.1

into the zone ettlingen.hausen.com that gets expanded to opnsense.ettlingen.hausen.com.

Specifically in the reverse zones you don't want to end up with e.g. cisco.ettlingen.hausen.com.1.168.192.in-addr.arpa. Hence the dot on the right.

The NS record is the nameserver in control of the zone - it's not dependent on the zone name but just the FQDN of the machine. That's why it's frequently the same for all zones.

If the name on the right of the NS record is in the same zone as the NS record proper, e.g. opnsense.ettlingen.hausen.com in the zone ettlingen.hausen.com, it's mandatory to have an A record for opnsense aka opnsense.ettlingen.hausen.com_._ (trailing dot for the full name, no trailing dot for the short name in the zone context).

These are called glue records. But don't put that in any other zone. Only in the localdomain one.

And last: no, with the BIND plugin nothing is created automatically. Full control, full responsibility.

[RamSense]

Hi Patrick, i think i managed the opnsense part now :-). Thnx for the screenshots. That helped me get the aha moment.

opnsense with ssh:
# drill -p 5353 -x @127.0.0.1 192.168.1.1
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 3934
;; 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: Fri Dec  9 18:25:40 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: 29204
;; flags: qr aa 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.   86400   IN   PTR   lapstart.localdomain.

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 127.0.0.1
;; WHEN: Fri Dec  9 18:28:50 2022
;; MSG SIZE  rcvd: 124

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

No errors, looking good, right?!

On macbook pro terminal and specifying dns to opnsense lan ipv4, also correct!
$ dig -x 192.168.1.1 @192.168.1.1
; <<>> DiG 9.10.6 <<>> -x 192.168.1.1 @192.168.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42655
;; 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: 58 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Dec 09 18:32:55 CET 2022
;; MSG SIZE  rcvd: 98

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

only ipv6 gets weird....

Still the terminal on macbook pro gives this error with the lan/opnsense ipv6 ip:

dig -x 192.168.1.1 @2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240

; <<>> DiG 9.10.6 <<>> -x 192.168.1.1 @2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 47056
;; 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: 57 msec
;; SERVER: 2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240#53(2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240)
;; WHEN: Fri Dec 09 18:33:10 CET 2022
;; MSG SIZE  rcvd: 174

Makes me wonder what this can cause? does ipv6 dns not get properly forwarded to adguard home? something else?

[Patrick M. Hausen]

lapstart. looks wrong to me.

The AdGuard via IPv6 might relate to this discussion:
https://github.com/AdguardTeam/AdGuardHome/issues/3789

Looks like some AGH magic going on.

What about asking for IPv6 reverse information from the Macbook - via v4 and via v6?

[RamSense]

ok, here they are, both @ipv4 and @ipv6 went correct:

$ dig -x 2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240 @192.168.1.1

; <<>> DiG 9.10.6 <<>> -x 2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240 @192.168.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4063
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; 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. 86400   IN PTR lapstart.localdomain.

;; Query time: 39 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Dec 09 20:58:21 CET 2022
;; MSG SIZE  rcvd: 135

============================ipv6 ============

$ dig -x 2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240 @2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240

; <<>> DiG 9.10.6 <<>> -x 2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240 @2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53387
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; 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. 86400   IN PTR lapstart.localdomain.

;; Query time: 42 msec
;; SERVER: 2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240#53(2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240)
;; WHEN: Fri Dec 09 21:01:33 CET 2022
;; MSG SIZE  rcvd: 135

[RamSense]

and to continue on the last post, when $ dig -x 192.168.1.1 @192.168.1.1 -> Adguard home shows a rewrite(?) in the queries, while there is no rewrite rule made by me!:

Response details
Status
Rewritten
Elapsed
0.11 ms
Response code
NOERROR
Rule(s)

    192.168.1.1 lapstart.localdomain lapstart
    192.168.1.1 lapstart.localdomain lapstart
System hosts files

Response
PTR: lapstart.localdomain. (ttl=10)
PTR: lapstart. (ttl=10)

[Patrick M. Hausen]

I'd take that topic to the AGH folks, now.

[RamSense]

Ok, I submitted it here: https://github.com/AdguardTeam/AdGuardHome/issues/5254
hope I described it correct and let's see what happens...

N.B. System with Bind is running flawless and I added the PTR records of the devices i want, also added the PTR for the wireguard 10.10.10.x devices also. So thank you very much for your patience and help!

[RamSense]

Solved. There is an adguard home config field for it. In the AdGuardHome.yaml file, ad your ip range to private_networks field what is empty by default.

When I added:

private_networks:
    - 2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240/64
    - 192.168.1.0/24

all is working as supposed!