RT-AX88U distributes itself as a DNS when set up otherwise

[gil80]

Hi all.
I'm new here.

I'm running Pi-Hole adblocker alongside my router.
The Pi-Hole IP address is 192.168.1.2.
In the Asus router under LAN DHCP settings, I set the DNS to the Pi's IP address 192.168.1.2.
Under WAN, I set the Obtain DNS automatically to NO and left it empty but also experimented with setting it manually to 192.168.1.2.
In both cases, after flushing the DNS on my PC, I ran: netsh interface ipv4 show dnsservers
And for my PC's ethernet port, it seems that the router is refusing to let 192.168.1.2 be the DNS. It distributes itself as a DNS alongside Pi-hole, despite having only defined Pi-hole as a DNS via the router's DHCP settings.

Is there a way to overcome this to make sure my clients are using 192.168.1.2 as the DNS and the router won't distribute 192.168.1.1 as the DNS?

 

[SomeWhereOverTheRainBow]

Hi all.
I'm new here.

I'm running Pi-Hole adblocker alongside my router.
The Pi-Hole IP address is 192.168.1.2.
In the Asus router under LAN DHCP settings, I set the DNS to the Pi's IP address 192.168.1.2.
Under WAN, I set the Obtain DNS automatically to NO and left it empty but also experimented with setting it manually to 192.168.1.2.
In both cases, after flushing the DNS on my PC, I ran: netsh interface ipv4 show dnsservers
And for my PC's ethernet port, it seems that the router is refusing to let 192.168.1.2 be the DNS. It distributes itself as a DNS alongside Pi-hole, despite having only defined Pi-hole as a DNS via the router's DHCP settings.

Is there a way to overcome this to make sure my clients are using 192.168.1.2 as the DNS and the router won't distribute 192.168.1.1 as the DNS?

simple solution is to use Rmerlins version of the 88U firmware that gives you an option to disable advertisement of the routers IP under lan DNS.
heres an example of what that looks like.

I have a setup with the RT-AX88U running pihole at one of my family members houses using merlins latest firmware.

Here is a link to where you can download the latest firmware.

Download | Asuswrt-Merlin

www.asuswrt-merlin.net

At this time merlins firmware is pretty even with the lastest firmware release.

 

[gil80]

simple solution is to use Rmerlins version of the 88U firmware that gives you an option to disable advertisement of the routers IP under lan DNS.
heres an example of what that looks like.


I have a setup with the RT-AX88U running pihole at one of my family members houses using merlins latest firmware.

Here is a link to where you can download the latest firmware.

Download | Asuswrt-Merlin

www.asuswrt-merlin.net

At this time merlins firmware is pretty even with the lastest firmware release.

Thanks for the suggestion. It doesn't seem a simple solution at all. I guess Merlin has its own bugs which I'm not keen on discovering.
I don't have much time to mess around with new firmware so unfortunately, this is not a viable solution for my case.

I can use the Pi-hole's DHCP server, a much more simple solution than replacing the router's firmware. I'll go this route if it's 100% not possible to get this router to stop publish its own DNS.

What a stupid thing to do. You'd think that such a capable router would behave as expected.
Isn't there some way to SSH to the router and run a command to disable it, without using Merlin?

 

[SomeWhereOverTheRainBow]

Thanks for the suggestion. It doesn't seem a simple solution at all. I guess Merlin has its own bugs which I'm not keen on discovering.
I don't have much time to mess around with new firmware so unfortunately, this is not a viable solution for my case.

I can use the Pi-hole's DHCP server, a much more simple solution than replacing the router's firmware. I'll go this route if it's 100% not possible to get this router to stop publish its own DNS.

What a stupid thing to do. You'd think that such a capable router would behave as expected.
Isn't there some way to SSH to the router and run a command to disable it, without using Merlin?

unfortunately, not that I can think of. It is not always as simple as an NVRAM variable, but maybe someone else will catch this thread that might know something. As for Merlin firmware, I have been running it stable with PiHole and with AiMesh several nodes for over a year now and no issues to report. The only major issues I have seen reported seem to be configuration/topography issues not really on part of the firmware itself which is identical to asuswrt firmware just with enhancements and unlocked functionality.

 

[bbunge]

You can turn off DHCP in the router and use the Pi-hole to do DHCP and DNS. I tested this setup for a couple of days and it worked well for me. I wanted DNS redundancy so I have the router and the Pi-hole set to Cloudflare Family both using DNSSEC.

Edit:
You need to have the router/WAN DNS Server 1 and 2 set to a remote resolver, not the Pi-Hole. This is, basically, to insure the router gets the proper time when it starts.

To use the Pi-Hole for DHCP, on the router LAN/DHCP Server /Enable the DHCP server - No. On the Pi-Hole, Settings/DHCP/DHCP server enabled - checked. AS you have the Pi-Hole set to a static IP address, 192.168.1.2, make sure the Range of IP addresses to hand out starts at 192.168.1.3 or higher. Also a good idea to connect the Pi-Hole to the router with a good Ethernet cable.

* Should add that yesterday my wife got an email from a friend with a link to a picture on a web site. She told me that the web browser could not find the picture. In fact the email was not from her friend (hacked email account) and the Pi-Hole had blocked the malicious web site! Hurrah!!!

 

[gil80]

You can turn off DHCP in the router and use the Pi-hole to do DHCP and DNS. I tested this setup for a couple of days and it worked well for me. I wanted DNS redundancy so I have the router and the Pi-hole set to Cloudflare Family both using DNSSEC.

Ok, so just to make sure I understood correctly:
1. Router > WAN > DNS > set to 1.1.1.1 and 1.0.0.1?
2. Router LAN - DHCP > Disable.
3. Pi Hole > DHCP > Enable

Additional:
1. /etc/dhcpcd.conf is set to use 192.168.1.2 so RPi will always get that address
2. Currently, the router IP pool is set from 192.168.1.11 to .249 because I want the first 10 address to allocate manually for the Pi, my PC and other devices which I remote to.
3. My Pi-hole is already set up to use DNS over HTTPS using Cloudflared. (see screenshot)

https://i.ibb.co/92zZzHH/DNS-Pi.png

Is that correct?

 

[bbunge]

Ok, so just to make sure I understood correctly:
1. Router > WAN > DNS > set to 1.1.1.1 and 1.0.0.1?
2. Router LAN - DHCP > Disable.
3. Pi Hole > DHCP > Enable

Additional:
1. /etc/dhcpcd.conf is set to use 192.168.1.2 so RPi will always get that address
2. Currently, the router IP pool is set from 192.168.1.11 to .249 because I want the first 10 address to allocate manually for the Pi, my PC and other devices which I remote to.
3. My Pi-hole is already set up to use DNS over HTTPS using Cloudflared. (see screenshot)

https://i.ibb.co/92zZzHH/DNS-Pi.png

Is that correct?

Almost.
I RECOMMEND YOU USE 1.1.1.2 AND 1.0.0.2 (BLOCKS MALWARE)
192.168.1.11 to .249 is OK
In the pi-hole Custom DNS Server 1 use 1.1.1.2 Server 2 use 1.0.0.2 and enable DNSSEC. I recommend not using Cloudflared DoH. DoH while claiming it is secure still depends on normal DNS over port 53 to locate the DoH server so is not, in my opinion, secure. If you want secure DNS use Stubby DoT. See: https://discourse.pi-hole.net/t/implementing-dns-over-tls/27538/8
Note: Cloudflare currently supports DoT at 1.1.1.1 and 1.0.0.1

 

[gil80]

Almost.
I RECOMMEND YOU USE 1.1.1.2 AND 1.0.0.2 (BLOCKS MALWARE)
192.168.1.11 to .249 is OK
In the pi-hole Custom DNS Server 1 use 1.1.1.2 Server 2 use 1.0.0.2 and enable DNSSEC. I recommend not using Cloudflared DoH. DoH while claiming it is secure still depends on normal DNS over port 53 to locate the DoH server so is not, in my opinion, secure. If you want secure DNS use Stubby DoT. See: https://discourse.pi-hole.net/t/implementing-dns-over-tls/27538/8
Note: Cloudflare currently supports DoT at 1.1.1.1 and 1.0.0.1

So for this section:
upstream_recursive_servers:
- address_data: 9.9.9.9
tls_auth_name: "dns.quad9.net"
- address_data: 149.112.112.112
tls_auth_name: "dns.quad9.net"

And since you are using quad9, is there any benefit over cloudflare?

Using cloudflare from the stubby.yml or even quad9, I get the following:

, "Generic error"
Error parsing config file "/etc/stubby/stubby.yml": Generic error
WARNING: No Stubby config file found... using minimal default config (Opportunis
tic Usage)
error: Could not bind on given addresses: Permission denied

I tried to revert back to DoH with Cloudflared and now I get this:

status cloudflaredpi@raspberry:/ $ sudo systemctl status cloudflared
● cloudflared.service - Argo Tunnel
   Loaded: loaded (/etc/systemd/system/cloudflared.service; enabled; vendor pres
et: enabled)
   Active: active (running) since Sat 2020-10-10 01:21:06 AEDT; 1 day 18h ago
 Main PID: 462 (cloudflared)
    Tasks: 12 (limit: 2065)
   CGroup: /system.slice/cloudflared.service
           └─462 /usr/local/bin/cloudflared --config /etc/cloudflared/config.yml
 --origincert /etc/cloudflared/cert.pem --no-autoupdate

Oct 11 01:05:33 raspberry cloudflared[462]: ERROR[2020-10-11T01:05:33+11:00] fai
led to connect to an HTTPS backend "https://1.1.1.1/dns-query": failed to perfor
m an HTTPS request: Post "https://1.1.1.1/dns-query": net/http: request cancele
Oct 11 01:05:33 raspberry cloudflared[462]: ERROR[2020-10-11T01:05:33+11:00] fai
led to connect to an HTTPS backend "https://1.1.1.1/dns-query": failed to perfor
m an HTTPS request: Post "https://1.1.1.1/dns-query": net/http: request cancele
Oct 11 01:05:33 raspberry cloudflared[462]: ERROR[2020-10-11T01:05:33+11:00] fai
led to connect to an HTTPS backend "https://1.1.1.1/dns-query": failed to perfor
m an HTTPS request: Post "https://1.1.1.1/dns-query": net/http: request cancele
Oct 11 01:05:33 raspberry cloudflared[462]: ERROR[2020-10-11T01:05:33+11:00] fai
led to connect to an HTTPS backend "https://1.1.1.1/dns-query": failed to perfor
m an HTTPS request: Post "https://1.1.1.1/dns-query": net/http: request cancele
Oct 11 01:05:33 raspberry cloudflared[462]: ERROR[2020-10-11T01:05:33+11:00] fai
led to connect to an HTTPS backend "https://1.1.1.1/dns-query": failed to perfor
m an HTTPS request: Post "https://1.1.1.1/dns-query": net/http: request cancele
Oct 11 01:05:33 raspberry cloudflared[462]: ERROR[2020-10-11T01:05:33+11:00] fai
led to connect to an HTTPS backend "https://1.1.1.1/dns-query": failed to perfor
m an HTTPS request: Post "https://1.1.1.1/dns-query": net/http: request cancele
Oct 11 18:54:11 raspberry cloudflared[462]: ERROR[2020-10-11T18:54:11+11:00] fai
led to connect to an HTTPS backend "https://1.1.1.1/dns-query": failed to perfor
m an HTTPS request: Post "https://1.1.1.1/dns-query": net/http: request cancele
Oct 11 18:54:13 raspberry cloudflared[462]: ERROR[2020-10-11T18:54:13+11:00] fai
led to connect to an HTTPS backend "https://1.1.1.1/dns-query": failed to perfor
m an HTTPS request: Post "https://1.1.1.1/dns-query": context deadline exceeded
Oct 11 18:54:16 raspberry cloudflared[462]: ERROR[2020-10-11T18:54:16+11:00] fai
led to connect to an HTTPS backend "https://1.0.0.1/dns-query": failed to perfor
m an HTTPS request: Post "https://1.0.0.1/dns-query": net/http: request cancele
Oct 11 19:04:32 raspberry systemd[1]: cloudflared.service: Current command vanis
hed from the unit file, execution of the command list won't be resumed.

So I'm worse from where I started.

 

[bbunge]

The stubby.yml is fussy with layout. You have an error somewhere.
I am currently using 1.1.1.2 and 1.0.0.2 with DNSSEC and not using DoT or DoH.

 

[bbunge]

Here is the stubby.yml contents:

resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 128
edns_client_subnet_private : 1
round_robin_upstreams: 1
idle_timeout: 10000
tls_connection_retries: 5
tls_ca_path: "/etc/ssl/certs/"
listen_addresses:
  - 127.0.0.1@5453
  - ::1@5453
dnssec: GETDNS_EXTENSION_TRUE
appdata_dir: "/var/cache/stubby"
upstream_recursive_servers:
### Anycast services ###
## Quad 9 'secure' service
  - address_data: 9.9.9.9
    tls_auth_name: "dns.quad9.net"
  - address_data: 149.112.112.112
    tls_auth_name: "dns.quad9.net"
## Cloudflare 1.1.1.1 and 1.0.0.1
#  - address_data: 1.1.1.1
#    tls_auth_name: "cloudflare-dns.com"
#  - address_data: 1.0.0.1
#    tls_auth_name: "cloudflare-dns.com"

To use Cloudflare remove the # and add # before the Quad9 entries.
Note: do the editing with Nano or another Linux test editor!

 

[gil80]

The stubby.yml is fussy with layout. You have an error somewhere.
I am currently using 1.1.1.2 and 1.0.0.2 with DNSSEC and not using DoT or DoH.

Two questions, please:
1. Is that more secure and private than DoT/DoH?
2. What's the benefit and downside of enabling DNSSEC? Because it is not enabled by default.

 

[dave14305]

Two questions, please:
1. Is that more secure and private than DoT/DoH?
2. What's the benefit and downside of enabling DNSSEC? Because it is not enabled by default.

DNSSEC ensures the integrity of the DNS response for domains that actually support DNSSEC. It doesn’t offer any privacy, however. It’s sent “in the clear” if not using DoT or DoH.

 

[gil80]

I am currently using 1.1.1.2 and 1.0.0.2 with DNSSEC and not using DoT or DoH.

Why? Is it a better security and privacy option over the use of DoT?
What about using Unbound?

DNSSEC ensures the integrity of the DNS response for domains that actually support DNSSEC. It doesn’t offer any privacy, however. It’s sent “in the clear” if not using DoT or DoH.

Is it ok to use DNSSEC with DoH enabled? Any ideas why DNSSEC is not enabled by default? surely there must be a reason.

Currently I'm still running DoH with Cloudflared and DNSSEC enabled.
But considering using Unbound in addition.

 

[gil80]

DNSSEC ensures the integrity of the DNS response for domains that actually support DNSSEC. It doesn’t offer any privacy, however. It’s sent “in the clear” if not using DoT or DoH.

would then having 1.1.1.2 + DNSSEC be a better solution with Pihole, over DoH with Pihole?

 

[gil80]

The stubby.yml is fussy with layout. You have an error somewhere.
I am currently using 1.1.1.2 and 1.0.0.2 with DNSSEC and not using DoT or DoH.

why did you change to this approach? is that better than DoT as you previously mentioned?

 

[dave14305]

would then having 1.1.1.2 + DNSSEC be a better solution with Pihole, over DoH with Pihole?

“Better” depends on your goal. Privacy would suggest DoT/DoH with a possible performance trade-off. I personally don’t like the performance penalty of using Stubby and the occasional hiccup, compared to standard DNS over UDP. But I’m not concerned with ISP/Government snooping, like some are.

 

[gil80]

“Better” depends on your goal. Privacy would suggest DoT/DoH with a possible performance trade-off. I personally don’t like the performance penalty of using Stubby and the occasional hiccup, compared to standard DNS over UDP. But I’m not concerned with ISP/Government snooping, like some are.

What about using Unbound?

 

[dave14305]

What about using Unbound?

I like Unbound, but you have to be clear on what you want to do with it. Decide if encrypted DNS is important or not, then decide which tool you want to use.

 

[gil80]

I like Unbound, but you have to be clear on what you want to do with it. Decide if encrypted DNS is important or not, then decide which tool you want to use.

I've just started to learn these things, so I'm like a kid in a toy shop, I want everything without a full grasp of reality.

So I'm after security and privacy with as little as possible on performance impact.
The pihole tool allows for the adblocking, which is great. Now, like add-ons, I'd like to extend the function of the Raspberry pi to do a bit more than just block ads, i.e., add a layer of privacy and security as best as this little piece of hardware can support.

 

[Yo_2T]

What about using Unbound?

Unbound is just switching the DNS resolution task from someone else (your ISP, Google, CloudFlare, etc.) to your own router. The requests are still sent in the clear, the meta data just aren't captured by a third party resolver (like Google DNS for example, if you use them, they have some info on you). That takes care of the privacy part, not the security part.