What's new

[Beta] Asuswrt-Merlin 384.11 Beta is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

But the method I use to bypass DOT, is by using the DNS Filter and setting those clients to a specific DNS. Or is dnsmasq only being used for DOT in this case?

Also on previous firmwares I always have been using DNS Filter to force clients to use the DNS that I specify. With the global option to for example q9 and Android clients to adguard.
You would want to tell those devices no filter so they use built.in dns.
 
Eric,

Thanks for the quick fix. Works perfectly now. Super stable.

I have a few questions though:
1) With DoT enabled, does this filter to the connected clients? Or is DNSFilter needed with "Router" setting on? If it's not, is it only for users who want clients to use a different DNS service/server vs another?
2) "Connect to DNS server automatically" -- DoT overrides this, correct? Does it matter if it's left on yes or custom input? Would it be possible to hide this field in later builds if DoT is enabled?
 
You can add an extra setting in dnsmasq.add to assist with Plex.
Code:
rebind-domain-ok=/plex.direct/
Thanks, I did find this solution also. For now I have rebind protection turned off. But the thing is that I never had this rebind issue and always have used the DNS Filter for all my clients, and now when I use DOT I get this error. If I use the DNS Filter without DOT, I don't get this error.

I tested this again if I force all clients with DNS filter to use quad9 I don't get this rebind error, if I force all client to use DOT then I do get this error. Shouldn't I get this error in both cases. Isn't this a bit strange?

I don't want to hijack this thread over this because Plex could also behaving differently in both cases. But it is just something I noticed.
 
When an VPN client is set to Exclusive with policy rule, like 192.168.1.0/24 and the client must restart after a reboot and DoT is set. Is DoT an extra layer of security when the VPN (before handshake) asks for connection through WAN?
 
Question regarding DNSSEC. As long as Cloudflare's servers aren't hijacked, will I effectively be protected using DNSSEC which their test page implies? Enabling it on the router protects against Cloudflare being compromised, correct?
 
Thanks, I did find this solution also. For now I have rebind protection turned off. But the thing is that I never had this rebind issue and always have used the DNS Filter for all my clients, and now when I use DOT I get this error. If I use the DNS Filter without DOT, I don't get this error.

I tested this again if I force all clients with DNS filter to use quad9 I don't get this rebind error, if I force all client to use DOT then I do get this error. Shouldn't I get this error in both cases. Isn't this a bit strange?

I don't want to hijack this thread over this because Plex could also behaving differently in both cases. But it is just something I noticed.
If you have used the DNSFilter to send to Quad, or anything other than 'router', you likely wouldn't have seen any issues as the dns resolving is done outside your network - and not with dnsmasq where the rebind issue is.
 
JIPG said:
I suppose that although the closed source parts (for RT-AC87U) belong to a previous release, they are still compatible 100%, aren´t they?

They should be, but only way to be 100% sure is by testing, since I have no way of knowing what was changed in the closed source parts.

JIPG said:
And, It does mean that the last problems solved in 384_45713 are not included for RT-AC87U as they are normally in closed source parts? (e.g Security issues with new CVE, network map related issues, VLAN bug form Movistar, etc).

It depends what was in the open sources parts, and what wasn't. Some of these are in the open sourced parts, others aren't.

Thank you for your answer.
I asked because I understood that you had some "hints" from ASUS about compatibility between binaries and GPLs, but OK, I am actually running a FW with these 384_45149 binary blobs, so no change in this aspect.
My other question was related to my internet connection, that is provided by Movistar, and I have to segregate the Voip phone from normal internet through VLAN configuration. One of the problems supposedly solved is "VLAN bug form Movistar", but if it is in the closed source part, no way. Anyway, if it only affects to the TV broadcasting part, I am not using now this service, so no problem.

Thank you again for all your efforts to keep alive this router with the new FW. :)
 
1) With DoT enabled, does this filter to the connected clients? Or is DNSFilter needed with "Router" setting on? If it's not, is it only for users who want clients to use a different DNS service/server vs another?
2) "Connect to DNS server automatically" -- DoT overrides this, correct? Does it matter if it's left on yes or custom input? Would it be possible to hide this field in later builds if DoT is enabled?
This is how I understand it, from the more experienced folks here—DNSFilter set to ‘Router’ ensures all your clients use DoT.

DNS Privacy overrides what you see in Network Map/Internet status. See pic attached. I have ‘Connect to DNS server automatically’ set to Yes and DNSFilter set to ‘Router’ and everything works great.
 

Attachments

  • EAF0BC2F-C3C0-45FE-B714-94A620BEBAA4.jpeg
    EAF0BC2F-C3C0-45FE-B714-94A620BEBAA4.jpeg
    53.7 KB · Views: 439
Last edited:
This is how I understand it, from the more experienced folks here—DNSFilter set to ‘Router’ ensures all your clients use DoT.

DNS Privacy overrides what you see in Network Map/Internet status. See pic attached. I have ‘Connect to DNS server automatically’ set to Yes and DNSFilter set to ‘Router’ and everything works great.
If you have no clients to filter, there is no need to use DNSFilter to force evryone to use DOT as long as you enabled DOT in the WAN settings then all pass through that.
 
Send me your boot log.

I reviewed the code chain, and nothing looks wrong there. The WAN code only starts the OpenVPN instances after WAN comes up. Both the VPN client and server check for ntp_ready to be set, and if it's not set, they wait for up to 5 minutes for it to be set (retrying after increasing wait times). I'm also unable to reproduce the problem here, everything happens in the proper order, and within a normal period of time.

So, either your ISP is taking forever to bring the WAN online, or something else in your configuration is interfering with the boot process.
What is the best way to send my un-sanitized logs?
 
Send me your boot log.

I reviewed the code chain, and nothing looks wrong there. The WAN code only starts the OpenVPN instances after WAN comes up. Both the VPN client and server check for ntp_ready to be set, and if it's not set, they wait for up to 5 minutes for it to be set (retrying after increasing wait times). I'm also unable to reproduce the problem here, everything happens in the proper order, and within a normal period of time.

So, either your ISP is taking forever to bring the WAN online, or something else in your configuration is interfering with the boot process.
I'll send you a PM with the link to pastebin. Thanks @RMerlin
 
Unless a client has overridden their DNS servers locally. Depends on your objective for privacy, though.
That's why I said, "If you have no clients to filter". DNSFilter is redundant with WAN DOT if your purpose is to force clients to use DOT. DNSFilter is used for exceptions and override hardcoded DNS's.
 
If you have no clients to filter, there is no need to use DNSFilter to force evryone to use DOT as long as you enabled DOT in the WAN settings then all pass through that.
Unless a client has overridden their DNS servers locally. Depends on your objective for privacy, though.

Perfect, that's what I was looking for. For some reason, I was thinking that it was necessary to set DNSFilter to on. It sounded like it needed to be set globally for router and that it didn't filter to clients normally unless explicitly to On/Router.
 
Perfect, that's what I was looking for. For some reason, I was thinking that it was necessary to set DNSFilter to on. It sounded like it needed to be set globally for router and that it didn't filter to clients normally unless explicitly to On/Router.
I think of it this way:
  • Without DNSFilter, DoT is offered to clients as the default DNS path, but can be circumvented by any client on the LAN.
  • With DNSFilter set to Router, DoT is enforced as the only DNS path, and cannot be circumvented by any client on the LAN (except with a DNS-over-HTTPS browser or CloudFlare app).
 
I think of it this way:
  • Without DNSFilter, DoT is offered to clients as the default DNS path, but can be circumvented by any client on the LAN.
  • With DNSFilter set to Router, DoT is enforced as the only DNS path, and cannot be circumvented by any client on the LAN (except with a DNS-over-HTTPS browser or CloudFlare app).
This is exactly what I want. Thanks, Dave!
 
2) "Connect to DNS server automatically" -- DoT overrides this, correct? Does it matter if it's left on yes or custom input? Would it be possible to hide this field in later builds if DoT is enabled?
  • Yes, DoT overrides "Connect to DNS Server automatically" regardless of Yes or No
  • When does the override happen? When DoT starts
  • What DNS settings are used before DoT starts? "Connect to DNS Server automatically" Yes is the non-DoT DNS servers your ISP set in WAN DHCP, No is whatever non-DoT DNS servers you type in
  • Will "Connect to DNS Server automatically" be hidden in later builds? No
 
Dirty upgrade from 384.10_2 all fine.
 
But the method I use to bypass DOT, is by using the DNS Filter and setting those clients to a specific DNS. Or is dnsmasq only being used for DOT in this case?

DSNFilter will bypass dnsmasq (unless you set DNSFilter to "Router").

DoT works within the dnsmasq chain - the queries are sent to dnsmasq, which relays them through Stubby instead of your WAN DNS. So DoT benefits both from dnsmasq caching, DNSSEC validation, and rebind protection.
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top