OPNsense Forum
English Forums => General Discussion => Topic started by: RamSense on December 05, 2022, 05:46:06 pm
-
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?
-
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
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.
-
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
-
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
-
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
-
ipv6-record
(could not attach it in 1 posting)
-
You only showed the PTR records. Do you have NS records in your zones? They are mandatory, you know? ;)
-
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?
-
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 "."
-
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:
-
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.
-
# 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
-
Ok, something is still wrong with your zones. Talk more tomorrow.
-
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. :
-
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.
-
Thanks! I have just sent you a PM with the files.
-
You must not terminate the zone names with a dot.
Remove the A and AAAA records from the reverse zones.
"LapStart.localdomain" is the name of your OPNsense?
-
"LapStart.localdomain" is the name of your OPNsense?
, i think so -> system-settings-general :
Hostname: LapStart
Domain: localdomain
In the zones, in the field dns server: LapStart.localdomain.
terminated with a . now.
removed the A and AAA fields in the records.
dig -x 192.168.1.1, still gave the same results (i did a adguard home - clear cache, just in case)
-
Did you change the zone names?
In your named.conf you have:
zone "1.168.192.in-addr.arpa."
That must read:
zone "1.168.192.in-addr.arpa"
without the trailing dot. The name of the zone, not anything in there.
-
zone name: 1.168.192.in-addr.arpa
dns server: LapStart.localdomain.
in records
Zone:1.168.192.in-addr.arpa
name: 1
type: PTR
Value: LapStart.localdomain.
still the same.
When i disable Adguard home, enable bind and listening on port 53, and Listen IPs added 192.168.1.1/24 i get:
; <<>> DiG 9.10.6 <<>> -x 192.168.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3143
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;1.1.168.192.in-addr.arpa. IN PTR
;; Query time: 8 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Dec 08 12:33:28 CET 2022
;; MSG SIZE rcvd: 53
=======ipv6 ========
; <<>> DiG 9.10.6 <<>> -x 2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 6415
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; 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
;; Query time: 9 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Dec 08 12:34:31 CET 2022
;; MSG SIZE rcvd: 101
===================
seems right? (only i see this: WARNING: recursion requested but not available )
-> fixed this, whas a faulty ACL. 192.168.0.0/24 instead of 192.168.1.0/24 :
; <<>> DiG 9.10.6 <<>> -x 192.168.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 53750
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;1.1.168.192.in-addr.arpa. IN PTR
;; Query time: 5 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Dec 08 15:02:38 CET 2022
;; MSG SIZE rcvd: 53
========
So am I correct it looks like an adguard home thing?
(System now back to bind port 5353, removed Listen IPs 192.168.1.0/24 and only 127.0.0.1 and ::1)
-
As I repeatedly said: first we need to make sure your BIND has syntactically and semantically valid zones. Use SSH to logon to your firewall and directly test BIND at 127.0.0.1 port 5353.
Unless that works all messing around with AdGuard is useless - just way too many moving parts.
If BIND does not return correct answers how do you assume AdGuard will ever get them?
So please please please stick to fixing the zone names and the zone contents until you get a valid reverse lookup from 127.0.0.1 on your firewall. Thank you.
-
# drill -x -p 5353 @127.0.0.1 192.168.1.1
;; ->>HEADER<<- opcode: QUERY, rcode: SERVFAIL, id: 54445
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; 1.1.168.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 0 msec
;; SERVER: 127.0.0.1
;; WHEN: Thu Dec 8 17:23:04 2022
;; MSG SIZE rcvd: 42
===============
# drill -p 5353 -x @127.0.0.1 2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 34198
;; 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. 3438 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: Thu Dec 8 17:25:11 2022
;; MSG SIZE rcvd: 169
-
Logon to the firewall via SSH as root or become root via sudo. 2 sessions.
First session:
tail -f /var/log/named/named.log
Second session:
rndc reload
If everything is ok with your zones you should see something like this:
08-Dec-2022 18:10:30.243 general: info: reloading configuration succeeded
08-Dec-2022 18:10:30.254 general: info: reloading zones succeeded
08-Dec-2022 18:10:30.276 general: notice: all zones loaded
08-Dec-2022 18:10:30.276 general: notice: running
If there's anything wrong with any of the zones, you will see that, too.
HTH,
Patrick
-
first session
# tail -f /var/log/named/named.log
08-Dec-2022 18:27:39.407 general: info: reloading zones succeeded
08-Dec-2022 18:27:39.416 general: error: dns_rdata_fromtext: /usr/local/etc/namedb/master/0.x.x.x.x.x.x.x.x.x.x.x.x.x.x.2.ip6.arpa.db:2: near 'LapStart.localdomain..': empty label
08-Dec-2022 18:27:39.416 zoneload: error: zone 0.x.x.x.x.x.x.x.x.x.x.x.x.x.x.2.ip6.arpa/IN: loading from master file /usr/local/etc/namedb/master/0.x.x.x.x.x.x.x.x.x.x.x.x.x.x.2.ip6.arpa.db failed: empty label
08-Dec-2022 18:27:39.416 zoneload: error: zone 0.x.x.x.x.x.x.x.x.x.x.x.x.x.x.2.ip6.arpa/IN: not loaded due to errors.
08-Dec-2022 18:27:39.417 general: error: dns_rdata_fromtext: /usr/local/etc/namedb/master/1.168.192.in-addr.arpa.db:2: near 'LapStart.localdomain..': empty label
08-Dec-2022 18:27:39.417 zoneload: error: zone 1.168.192.in-addr.arpa/IN: loading from master file /usr/local/etc/namedb/master/1.168.192.in-addr.arpa.db failed: empty label
08-Dec-2022 18:27:39.417 zoneload: error: zone 1.168.192.in-addr.arpa/IN: not loaded due to errors.
08-Dec-2022 18:27:39.417 general: notice: all zones loaded
08-Dec-2022 18:27:39.417 general: notice: running
08-Dec-2022 18:27:39.460 dnssec: info: managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer complete)
==================
# rndc reload and output from first session:
08-Dec-2022 18:30:25.961 general: info: reloading configuration succeeded
08-Dec-2022 18:30:25.962 general: info: reloading zones succeeded
08-Dec-2022 18:30:25.969 general: error: dns_rdata_fromtext: /usr/local/etc/namedb/master/1.168.192.in-addr.arpa.db:2: near 'LapStart.localdomain..': empty label
08-Dec-2022 18:30:25.969 zoneload: error: zone 1.168.192.in-addr.arpa/IN: loading from master file /usr/local/etc/namedb/master/1.168.192.in-addr.arpa.db failed: empty label
08-Dec-2022 18:30:25.969 zoneload: error: zone 1.168.192.in-addr.arpa/IN: not loaded due to errors.
08-Dec-2022 18:30:25.969 general: error: dns_rdata_fromtext: /usr/local/etc/namedb/master/0.x.x.x.x.x.x.x.x.x.x.x.x.x.x.2.ip6.arpa.db:2: near 'LapStart.localdomain..': empty label
08-Dec-2022 18:30:25.969 zoneload: error: zone 0.x.x.x.x.x.x.x.x.x.x.x.x.x.x.2.ip6.arpa/IN: loading from master file /usr/local/etc/namedb/master/0.x.x.x.x.x.x.x.x.x.x.x.x.x.x.2.ip6.arpa.db failed: empty label
08-Dec-2022 18:30:25.969 zoneload: error: zone 0.x.x.x.x.x.x.x.x.x.x.x.x.x.x.2.ip6.arpa/IN: not loaded due to errors.
08-Dec-2022 18:30:25.969 general: notice: all zones loaded
08-Dec-2022 18:30:25.969 general: notice: running
08-Dec-2022 18:30:26.010 dnssec: info: managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer complete)
-
You have syntactically invalid records in your reverse zones.
-
when I edit Master Zone [1.168.192.in-addr.arpa] field dns from LapStart.localdomain. to 127.0.0.1
i get
# tail -f /var/log/named/named.log
08-Dec-2022 19:44:42.985 zoneload: info: zone 127.in-addr.arpa/IN: loaded serial 42
08-Dec-2022 19:44:42.987 zoneload: info: zone localhost/IN: loaded serial 42
08-Dec-2022 19:44:42.987 notify: info: zone 0.x.x.x.x.x.x.x.x.x.x.x.x.x.x.2.ip6.arpa/IN: sending notifies (serial 2212081944)
08-Dec-2022 19:44:42.988 zoneload: info: zone 1.168.192.in-addr.arpa/IN: loaded serial 2212081944
08-Dec-2022 19:44:42.988 notify: info: zone 1.168.192.in-addr.arpa/IN: sending notifies (serial 2212081944)
08-Dec-2022 19:44:42.989 zoneload: info: zone 0.ip6.arpa/IN: loaded serial 42
08-Dec-2022 19:44:42.989 general: notice: all zones loaded
08-Dec-2022 19:44:42.989 general: notice: running
08-Dec-2022 19:44:43.280 dnssec: info: managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer complete)
08-Dec-2022 19:44:43.293 resolver: info: resolver priming query complete
08-Dec-2022 19:45:02.496 general: info: received control channel command 'reload'
08-Dec-2022 19:45:02.496 general: info: loading configuration from '/usr/local/etc/namedb/named.conf'
08-Dec-2022 19:45:02.497 general: info: reading built-in trust anchors from file '/usr/local/etc/namedb/bind.keys'
08-Dec-2022 19:45:02.498 general: info: using default UDP/IPv4 port range: [49152, 65535]
08-Dec-2022 19:45:02.498 general: info: using default UDP/IPv6 port range: [49152, 65535]
08-Dec-2022 19:45:02.499 general: info: sizing zone task pool based on 6 zones
08-Dec-2022 19:45:02.501 config: info: /usr/local/etc/namedb/named.conf:19: 'max-cache-size 80%' - setting to 26120MB (out of 32650MB)
08-Dec-2022 19:45:02.504 security: info: obtaining root key for view _default from '/usr/local/etc/namedb/bind.keys'
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 10.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 16.172.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 17.172.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 18.172.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 19.172.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 20.172.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 21.172.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 22.172.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 23.172.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 24.172.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 25.172.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 26.172.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 27.172.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 28.172.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 29.172.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 30.172.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 31.172.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 168.192.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 64.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 65.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 66.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 67.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 68.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 69.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 70.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 71.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 72.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 73.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 74.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 75.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 76.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 77.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 78.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 79.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 80.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 81.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 82.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 83.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 84.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 85.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 86.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 87.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 88.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 89.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 90.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 91.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 92.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 93.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 94.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 95.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.504 zoneload: info: automatic empty zone: 96.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 97.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 98.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 99.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 100.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 101.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 102.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 103.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 104.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 105.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 106.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 107.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 108.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 109.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 110.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 111.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 112.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 113.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 114.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 115.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 116.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 117.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 118.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 119.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 120.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 121.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 122.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 123.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 124.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 125.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 126.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 127.100.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 0.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 254.169.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 2.0.192.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 100.51.198.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 113.0.203.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 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.0.IP6.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty 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
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: D.F.IP6.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 8.E.F.IP6.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 9.E.F.IP6.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: A.E.F.IP6.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: B.E.F.IP6.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: EMPTY.AS112.ARPA
08-Dec-2022 19:45:02.505 zoneload: info: automatic empty zone: HOME.ARPA
08-Dec-2022 19:45:02.509 general: info: reloading configuration succeeded
08-Dec-2022 19:45:02.509 general: info: reloading zones succeeded
08-Dec-2022 19:45:02.515 general: notice: all zones loaded
08-Dec-2022 19:45:02.515 general: notice: running
08-Dec-2022 19:45:02.612 dnssec: info: managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer complete)
so the previous error is gone. but still
# drill -x -p 5353 @127.0.0.1 2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 61779
;; 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.2.ip6.arpa. 3600 IN PTR 2001-xxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxx.cable.dynamic.v6.ziggo.nl.
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 2154 msec
;; SERVER: 127.0.0.1
;; WHEN: Thu Dec 8 19:49:43 2022
;; MSG SIZE rcvd: 169
===============
maybe it is easier to copy and tweak from a good working screen capture? E.g. a zone and record screen capture from lan i could see and tweak back to my config? Or does the above show what the next step for me would be?
-
Sorry, I give up. I don't have a precise idea what is broken but each time you change something you seem to make it worse or work at unrelated issues.
You cannot put an IP address in an NS record. It's mandatory to have a hostname in there.
If you put "LapStart.localdomain." in there, you also need a zone named "localdomain" with an NS record reaading "LapStart.localdomain." and an A record reading "LapsStart" and an IP address.
I really do not want to be condescending or snarky but what do you know about DNS?
if you want to use BIND you have to construct all the information manually according to the standards and the intended outcome. Trailing dot or no trailing dot - do you know what that means?
A single typo and the entire zone won't load.
This is just impossible to debug over a forum. Pay someone to do it or switch back to Unbound, please.
I never recommended anyone use BIND. I wrote "I prefer BIND", because that is what I am running for 30 years. It's what holds the global DNS system together.
The manual is this:
https://www.oreilly.com/library/view/dns-and-bind/0596100574/
And yes, you need to understand most of what is in there to manage this piece of software.
Sorry.
Patrick
-
Thanks Patrick for your patience and guidance, I really appreciate it and what you do here being hyper active on the forum! I mostly try to follow an example and understand it from that. Learning while doing.
That is mostly how i got to learn opnsense, now in my second year.
With Bind I could hardly find any guidance. And when I do it is all written in a format totally different from the gui fields in opnsense, hence i asked for a screen capture from a working bind - LAN zone - and -records- in opsense with screen capture of the gui fields. That way I can manage to convert it into my opnsense config.
I really like the idea of being in control of dns like bind over unbound with automatically fields and dhcp etc. Like you pointed me into the direction of the option of not using upstreams/DoT/DoH but instead keep it at your own machine and the root servers.
But this Bind zone is the hardest part. So any guide for bind in opnsense and gui fields screen captures would be awesome to find on the net.
-
Part of my local forward and reverse zones for IPv4:
(https://forum.opnsense.org/index.php?action=dlattach;topic=31354.0;attach=24630;image)
(https://forum.opnsense.org/index.php?action=dlattach;topic=31354.0;attach=24632;image)
And I did mean that with the link to the book. This is the BIND manual. All of us administrators have a copy. And all of us have a shelf full of O'Reilly books from the times when there were no "howtos" and not even a world wide web - but there was Internet ;)
-
Thanks!
I think, if i see it correctly now, what the problem is. Have still to try it yet.
But I only have a reverse -1.168.192.in-addr.arpa zone configured and assumed the rest was already "known local".
But I think to see I have to make 2 (master) zones.
1. localdomain (e.g. your etlingen.hausen.com)
2. 1.168.192.in-addr.arpa (with reverence to the first)
what i'm curious about is what is in your master zone etlingen.hausen.com zone part gui -> [DNS Server] field. does it also say [ opnsense.etlingen.hausen.com. ] and the same in the 1.168.192.in-addr.arpa zone part gui -> [DNS Server] field?, thus the name of your opnsense box, and thus for me LapStart.localdomain.?
-
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.
-
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?
-
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?
-
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
-
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)
-
I'd take that topic to the AGH folks, now.
-
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!
-
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!