NextDNS with device identification

[Jedis]

I have NextDNS working with Unbound DNS. However, all queries show up as "OPNsense", the name I configured in OPNsense's settings.

Is there a way for OPNsense to append the device hostname to DNS requests? So when it sees "AppleTV" send a DNS request, it will use the hostname "AppleTV-XXXXX.dns.nextdns.io" as the name it uses for the request?

> DNS-over-TLS/QUIC
Prepend the name to the provided domain (the name should only contain a-z, A-Z, 0-9 and -). Use -- for spaces.
For "John Router", you would use John--Router-XXXXX.dns.nextdns.io as your DNS-over-TLS endpoint.

[yegor]

There is a simpler way if you use this DNS daemon, it will relay client info from all your LAN devices and send it to NextDNS: https://github.com/Control-D-Inc/ctrld/wiki/NextDNS-Mode

It's fully compatible with OPNsense.

[securid]

For me the issue with replacing Unbound would be that it doesn't provide a gui for easy configuring of things like host aliases, overrides and fixed hostname registration. Its all done through CLI which requires login to opnSense every time a change is required. In my mind that does not make things easier. Also, if using opnSense API to register DNS or make changes to it, this won't work anymore.

There is however another way. Also not perfect.

You can run Unbound on a non-default port, say 5353. Select only a single interface (not all). Set NextDNS to listen to 53 instead.

Then in /usr/local/etc/nextdns.conf you can configure forwarders like so:
forwarder internal.yourlocaldomain.net.=127.0.0.1:5353

Do that for each subnet you're running.
Make a reverse forwarder like so:
forwarder 0.0.10.in-addr.arpa.=127.0.0.1:5353

I have never managed to make ipv6 forwarders work, I think they would like something like this:
forwarder 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.1.2.3.a.4.5.b.1.2.c.4.ip6.arpa.=127.0.0.1:5353

In your opnSense DHCP, you need to configure these options for DHCP clients:
gateway
domain
nameservers
ntp servers

Basically, any config your clients would get automatically when Unbound is running on 53, will no longer work so you need to manually set these. See this change for more info.
I made a request for NextDNS to support this, which got declined without further info.

Depending on your use you may run into other issues.

Personally, I have forgone the idea that I need client names to register. It seems handy at first but after a while you'll never look at it and when you actually need to troubleshoot a client, you'll find its not required at all.

I decided to use Unbound exclusively and setup DNS over TLS towards NextDNS. No hostnames but it works flawlessly with all the benefits that won't work with the other setups.

[tabsats]

I decided to use Unbound exclusively and setup DNS over TLS towards NextDNS. No hostnames but it works flawlessly with all the benefits that won't work with the other setups.

Could you please check with dnscheck.tools if you experience any dns leaks? Maybe also try it several times, sometimes I see only NextDNS server but most of the time I can also see cloudflare as well as opendns servers... I am not sure about if I have something misconfigured. I have created a post here in the forum but so far no one responded. Since you are using NextDNS exactly as I did I would be interested to see if this behaviour like me. Thanks!!

[yegor]

If you use the above linked software, you don't have to worry about any of the above concerns.

It will also automatically take care of local PTR/A resolution for all your LAN hostnames (through discovery via arp, mdns, ptr probes and DHCP leases file parsing), and you can delegate queries from subnets, MAC addresses or for custom TLDs to your local unbound instance if you want this.

Or do it the other way around and keep running unbound on UDP 53, and use ctrld as the upstream although you will lose the device identification data in this mode.

[tabsats]

Thanks for that tip, i will have a closer look at it. Since I want to have unbound managing my internal DNS and forwarders the only viable option is your ,,the other way around" suggestion. Will follow up as soon as I know more. Thanks!

[securid]

I decided to use Unbound exclusively and setup DNS over TLS towards NextDNS. No hostnames but it works flawlessly with all the benefits that won't work with the other setups.

Could you please check with dnscheck.tools if you experience any dns leaks? Maybe also try it several times, sometimes I see only NextDNS server but most of the time I can also see cloudflare as well as opendns servers... I am not sure about if I have something misconfigured. I have created a post here in the forum but so far no one responded. Since you are using NextDNS exactly as I did I would be interested to see if this behaviour like me. Thanks!!

Impossible because I "catch & redirect" DNS through a NAT rule back to OPNsense. Unless some client (like mobile devices) connects through "secure DNS", basically DNS over TLS or HTTPS. I'm not sure if I could catch those but my own devices don't do that so its only guest devices and I don't care enough.

[securid]

If you use the above linked software, you don't have to worry about any of the above concerns.

It will also automatically take care of local PTR/A resolution for all your LAN hostnames (through discovery via arp, mdns, ptr probes and DHCP leases file parsing), and you can delegate queries from subnets, MAC addresses or for custom TLDs to your local unbound instance if you want this.

Or do it the other way around and keep running unbound on UDP 53, and use ctrld as the upstream although you will lose the device identification data in this mode.

It does all the automatic DHCP registering with PTR as well? I didn't read that in the documentation, that is neat!

But still it requires manual CLI configuration for host overrides, aliases and other manual config, right?

[tabsats]

I decided to use Unbound exclusively and setup DNS over TLS towards NextDNS. No hostnames but it works flawlessly with all the benefits that won't work with the other setups.

Could you please check with dnscheck.tools if you experience any dns leaks? Maybe also try it several times, sometimes I see only NextDNS server but most of the time I can also see cloudflare as well as opendns servers... I am not sure about if I have something misconfigured. I have created a post here in the forum but so far no one responded. Since you are using NextDNS exactly as I did I would be interested to see if this behaviour like me. Thanks!!

Impossible because I "catch & redirect" DNS through a NAT rule back to OPNsense. Unless some client (like mobile devices) connects through "secure DNS", basically DNS over TLS or HTTPS. I'm not sure if I could catch those but my own devices don't do that so its only guest devices and I don't care enough.

Yes, its the same on my setup, catch and redirect DNS through a NAT rule. I didn't understand what's impossible? To check if you have any leaks or that leaks should be impossible?

[securid]

Yes, its the same on my setup, catch and redirect DNS through a NAT rule. I didn't understand what's impossible? To check if you have any leaks or that leaks should be impossible?

I meant the leaks. If the NAT rule is setup correctly, it should be impossible to get leaks to cloudflare or Opendns, or any other DNS server.

I think what might be happening is that the client sends a query to some random DNS server, the query gets redirected and a reply is sent back. The client thinks it was answered by some random DNS server while in reality, it was your opnsense replying.

I remember I looked into this in the past and was puzzled as well. I did some tcpdumps and analysis from opnsense, but never saw any traffic going out on 53. The only thing I did see was root server queries from Unbound itself which IIRC is by design. This was before I was using NextDNS and I assume its the same now.

[doktornotor]

These days, redirecting 53 is definitely not enough to force your DNS server. You need to block 853 out. And block DoH via (of course incomplete and ever growing) DNS blocklists. And then people use other non-standard ports for DNS.

[securid]

These days, redirecting 53 is definitely not enough to force your DNS server. You need to block 853 out. And block DoH via (of course incomplete and ever growing) DNS blocklists. And then people use other non-standard ports for DNS.

Only when you allow all out which I think is bad practise. I block all destination ports except what I deem necessary. If a client requires a non-standard port, I open that through a separate rule for that client.

[doktornotor]

I block all destination ports except what I deem necessary. If a client requires a non-standard port, I open that through a separate rule for that client.

Yeah, that's an effective way to get divorced at home, and go mad at work extremely fast.  ;D

[yegor]

If you use the above linked software, you don't have to worry about any of the above concerns.

It will also automatically take care of local PTR/A resolution for all your LAN hostnames (through discovery via arp, mdns, ptr probes and DHCP leases file parsing), and you can delegate queries from subnets, MAC addresses or for custom TLDs to your local unbound instance if you want this.

Or do it the other way around and keep running unbound on UDP 53, and use ctrld as the upstream although you will lose the device identification data in this mode.

It does all the automatic DHCP registering with PTR as well? I didn't read that in the documentation, that is neat!

But still it requires manual CLI configuration for host overrides, aliases and other manual config, right?

Manual host override support (reading of the mappings you have in place) is coming in the next version.