GUI Features

[TheLyppardMan]

I notice that these settings are disabled by default. Can anyone explain what they do and when one should enable any of them?

 

[L&LD]

Pretty self-explanatory. If further help is needed, google is a copy/paste away.

 

[TheLyppardMan]

Pretty self-explanatory. If further help is needed, google is a copy/paste away.

If it were (self explanatory), I wouldn't have asked the question.

 

[L&LD]

I'll let others help you here.

 

[Tech9]

I notice that these settings are disabled by default.

Why you're always playing with your router's settings? Keep them all disabled.

 

[RMerlin]

I notice that these settings are disabled by default. Can anyone explain what they do and when one should enable any of them?

Click on the setting description to see the explanation.

 

[heysoundude]

Click on the setting description to see the explanation.

This Is The Way
And it will lead to the Asus support site and further web searching. And hopefully, understanding and knowledge.

 

[RMerlin]

And it will lead to the Asus support site

Highly unlikely since I wrote those help popups.

 

[DJones]

I notice that these settings are disabled by default. Can anyone explain what they do and when one should enable any of them?
View attachment 42713

DNSSEC was designed to protect applications using DNS from accepting forged or manipulated DNS data, such as that created by DNS cache poisoning.

DNS rebinding is a method of manipulating resolution of domain names that is commonly used as a form of computer attack.

DoH prevent stops browsers like Firefox from using DoH instead of the routers DoT.
(DoH is dns over secure encrypted https using TLS on port 443)

DoT is Dns over TLS on port 853 using a DNS provider that supports encryption. Basically the same thing as DoH except different port. DoH camouflages itself within https traffic because https is also port 443. DoT is router based and protects the whole network where as DoH is browser based and only protects the browser traffic usually and requires the browser supports DoH.

As to why it is disabled by default compatibility and choice I suppose.

Side note some devices are hardcoded to prefer a static dns over the routers dns provided server which may circumvent DoT, googles 8.8.8.8 being a popular choice of dns by device manufacturer. Setting dns filter to router should fix this however you can also firewall 8.8.8.8/8.8.8.4 or any dns ip you want to block and that should do the trick as well.

[Google copy pasted.. for the most part]

 

[RMerlin]

Thread cleaned up.

 

[TheLyppardMan]

Why you're always playing with your router's settings? Keep them all disabled.

I'm not always playing with my router settings. I was merely curious to know what these settings were for, so I could make an informed decision as to whether it would be better to have them on or off. You say "keep them all disabled", but you haven't provided any reason for your answer, so that doesn't help me at all.

 

[Tech9]

Your post contains 5 different questions with individual answers. The answers to those questions are easy to find, but only if you want to. If you don’t want to, keep the fail safe default settings. This forum does offer great help about Asus routers, but it’s not Google search assistance forum. You have to do at least minimal efforts to find some information yourself.

 

[eibgrad]

As far as the first three Yes/No options, I agree that most are self explanatory. But I will add a few comments anyway.

Resolving queries within your own domain may be managed either on the router itself, or upstream. The assumption for the router's domain is the former (DNSMasq) (No), otherwise some other upstream DNS server (Yes).

To the extent anyone believes DNS rebind attacks are still a threat, this should be set to Yes. In fact, most other third-party firmware in my experience does in fact enable it by default (e.g., DD-WRT and FreshTomato). And if you do find yourself experiencing rebind warnings in the syslog, but you know it to be a legitimate resolution (e.g., when configuring DNS for site-to-site w/ OpenVPN), you can disable it on a per-domain basis w/ the following DNSMasq directive.

rebind-domain-ok=/<domain-name-1>/<domain-name-2>/...

But what caught my attention was the description, which I find to be ambiguous (or at least a bit misleading). It's obvious to more experienced users this issue of being non routable (e.g., 192.168.1.1) is only wrt the internet. But you may very well be resolving domain names to local IPs via a local upstream DNS server, which is perfectly routable.

This option is meant to prevent probing of your internal, private IP network via DNS (with the assumption it may eventually be used to access that device locally, e.g., Javascript within the browser). Any attempt to access a local IP across the internet would never work regardless how you obtained it, DNS or otherwise. In short, this option protects you against the former (i.e., resolution to a private IP leading to *local* access), NOT the latter (i.e., resolution to a private IP leading to *remote* access). The latter is a function of how the internet's BGP routers are configured; they ignore anything in the private IP space.

Something more like the following would be less ambiguous imo.

Enabling this will protect your LAN against rebind attacks by refusing to return any IP in the private IP space (e.g., 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8) as the result of name resolution from upstream DNS servers.

I find this better because it allows the user to infer the consequences (of which there might be many) of enabling/disabling the option. Obviously this would NOT be desirable for a local, upstream DNS server resolving your own domain, nor for that OpenVPN site-to-site configuration I mentioned previously. Any concern regarding the routability of a private IP to the internet takes care of itself due to those BGP routers (or a local router serving as a gateway may decide to be preemptive and enforce it itself, but regardless, it has NOTHING to do w/ this setting).

DNSSEC is disabled by default simply because NOT every DNS server supports it. And even when it does, reliability is often an issue.

So personally, I think you could make an argument that DNS rebind protection should be enabled by default. The other two being disabled by default makes sense.

 

[TheLyppardMan]

As far as the first three Yes/No options, I agree that most are self explanatory. But I will add a few comments anyway.

Resolving queries within your own domain may be managed either on the router itself, or upstream. The assumption for the router's domain is the former (DNSMasq) (No), otherwise some other upstream DNS server (Yes).

To the extent anyone believes DNS rebind attacks are still a threat, this should be set to Yes. In fact, most other third-party firmware in my experience does in fact enable it by default (e.g., DD-WRT and FreshTomato). And if you do find yourself experiencing rebind warnings in the syslog, but you know it to be a legitimate resolution (e.g., when configuring DNS for site-to-site w/ OpenVPN), you can disable it on a per-domain basis w/ the following DNSMasq directive.

rebind-domain-ok=/<domain-name-1>/<domain-name-2>/...

But what caught my attention was the description, which I find to be ambiguous (or at least a bit misleading). It's obvious to more experienced users this issue of being non routable (e.g., 192.168.1.1) is only wrt the internet. But you may very well be resolving domain names to local IPs via a local upstream DNS server, which is perfectly routable.

This option is meant to prevent probing of your internal, private IP network via DNS (with the assumption it may eventually be used to access that device locally, e.g., Javascript within the browser). Any attempt to access a local IP across the internet would never work regardless how you obtained it, DNS or otherwise. In short, this option protects you against the former (i.e., resolution to a private IP leading to *local* access), NOT the latter (i.e., resolution to a private IP leading to *remote* access). The latter is a function of how the internet's BGP routers are configured; they ignore anything in the private IP space.

Something more like the following would be less ambiguous imo.

Enabling this will protect your LAN against rebind attacks by refusing to return any IP in the private IP space (e.g., 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8) as the result of name resolution from upstream DNS servers.

I find this better because it allows the user to infer the consequences (of which there might be many) of enabling/disabling the option. Obviously this would NOT be desirable for a local, upstream DNS server resolving your own domain, nor for that OpenVPN site-to-site configuration I mentioned previously. Any concern regarding the routability of a private IP to the internet takes care of itself due to those BGP routers (or a local router serving as a gateway may decide to be preemptive and enforce it itself, but regardless, it has NOTHING to do w/ this setting).

DNSSEC is disabled by default simply because NOT every DNS server supports it. And even when it does, reliability is often an issue.

So personally, I think you could make an argument that DNS rebind protection should be enabled by default. The other two being disabled by default makes sense.

Thank you for the detailed reply. I'm not sure I understand all of it, but I'll take you advice and try enabling the DNS rebind protection. I can always switch it off again if it causes any problems.

 

[TheLyppardMan]

DNSSEC was designed to protect applications using DNS from accepting forged or manipulated DNS data, such as that created by DNS cache poisoning.

DNS rebinding is a method of manipulating resolution of domain names that is commonly used as a form of computer attack.

DoH prevent stops browsers like Firefox from using DoH instead of the routers DoT.
(DoH is dns over secure encrypted https using TLS on port 443)

DoT is Dns over TLS on port 853 using a DNS provider that supports encryption. Basically the same thing as DoH except different port. DoH camouflages itself within https traffic because https is also port 443. DoT is router based and protects the whole network where as DoH is browser based and only protects the browser traffic usually and requires the browser supports DoH.

As to why it is disabled by default compatibility and choice I suppose.

Side note some devices are hardcoded to prefer a static dns over the routers dns provided server which may circumvent DoT, googles 8.8.8.8 being a popular choice of dns by device manufacturer. Setting dns filter to router should fix this however you can also firewall 8.8.8.8/8.8.8.4 or any dns ip you want to block and that should do the trick as well.

[Google copy pasted.. for the most part]

Thanks for that. I already have my dns filter set to "router" as the default setting. I did try to use AdGuard for my mobile phone to see if it blocked adverts on that, but it didn't and yet I thought it had worked on the 386.7 build, but I've had to downgrade from that as like others have reported, my Wi-Fi became unreliable.

 

[DJones]

Thanks for that. I already have my dns filter set to "router" as the default setting. I did try to use AdGuard for my mobile phone to see if it blocked adverts on that, but it didn't and yet I thought it had worked on the 386.7 build, but I've had to downgrade from that as like others have reported, my Wi-Fi became unreliable.

Use Diversion from ssh’s amtm for ad blocking it works wonders, but enable type 65 blocking if you have a iOS device because apple circumvents it’s ads using type 65 https if I understand correctly. I believe it might require standard diversion but I’m unsure.

“

• Adds option to block type 65 queries in tb using iptables.

iOS 14 and newer, as well as a growing number of apps or devices use the type 65 query.

Dnsmasq currently has no option to suppress or specifically handle these types of queries and therefore circumvent Diversion ad-blocking.”

 

[RMerlin]

Something more like the following would be less ambiguous imo.

Enabling this will protect your LAN against rebind attacks by refusing to return any IP in the private IP space (e.g., 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8) as the result of name resolution from upstream DNS servers.

Sounds good to me, I will update it.

To the extent anyone believes DNS rebind attacks are still a threat, this should be set to Yes. In fact, most other third-party firmware in my experience does in fact enable it by default

I don't because it prevents something that may be totally legitimate from working properly. For example myself, I have a customer with dozens of servers that are manageable over VPN. Rather than having a table of all IP addresses, I created a sub-domain that contains DNS entries for all the private IPs for these servers (i.e. webserver1.lan.domain.com).

So technically, there is nothing wrong with a DNS entry pointing at a private IP address. I just don't want the default setting to be one that can create hard-to-troubleshoot issues.

Rebind protection is just a workaround to protect against a certain form of attack, it does not fix anything wrong at a technical level.

 

[jj22038]

Rebind protection is just a workaround to protect against a certain form of attack, it does not fix anything wrong at a technical level.

Rebind protection messes up Plex server. Plex is using DNS rebinding in a "clever" way.

 

[RMerlin]

Rebind protection messes up Plex server. Plex is using DNS rebinding in a "clever" way.

Yep, I know Plex is one of those that are affected by it.

 

[eibgrad]

Rebind protection messes up Plex server. Plex is using DNS rebinding in a "clever" way.

Obviously, like any mitigation against known threats, there may be tradeoffs. Users simply have to decide what is and isn't worth it.

In the case of DD-WRT, they have a mitigation (ON by default) for the OpenVPN server and CVE-2019-14899. The solution? To deny *all* LAN access, limiting the server to acting as an internet gateway. Needless to say, NOT a very appealing mitigation. But users just have to decide what's more important; LAN access or mitigating the threat. There is no right or wrong, it's just a judgment call (fwiw, if I was the developer, I would default to OFF).

You can (as I explained previously) disable rebind protection for specific domains using the rebind-domain-ok directive in DNSMasq. And according to the following Plex documentation ...

How to Use Secure Server Connections

What’s the Deal With Secure Connections? Why Is It Important? When browsing the internet or making other connections these days,...

support.plex.tv

... you need to specify the following ...

rebind-domain-ok=/plex.direct/

Perhaps the option might be more useful and easier to manage if the user was able to define exceptions on the same page. Even better, provide pre-defined exceptions for Plex and other known exceptions.

That same documentation seems to suggest you can alternatively workaround the problem using NAT loopback (they don't use that terminology specifically, but that's the way it reads to me). However, it may have other undesirable side-effects.