[Release] Asuswrt-Merlin 384.11 is available

[Xentrk]

I found this while searching for the SPKI fingerprint

https://gist.github.com/alanbuxey/8713073e232adfd56198e8cd8ee1258b
anyone used these for cloudflare??

This is from a ticket I logged with the Stubby team when I developed the Stubby installer script last fall.

I would recommend NOT using SPKI pins for Cloudflare because they do not guarantee that they will not change and if they do change then this configuration will break.

https://github.com/getdnsapi/stubby/issues/136

 

[bbunge]

I use Quad9 primary and quad1 as DoT servers together with DNSSEC and it has been running fine for 3 days now. I do however use ipv4 aswell as the ipv6 servers.

got me wondering, how exactly does stubby select which DNS server to use? Does it use the first entry as primary or does it randomly select configured servers?

Stubby in 384.11 uses what is called round robin. This uses each resolver entry in turn then back to the first. So it cycles through all entries. This is supposed to improve response and in earlier Stubby versions was recommended to prevent errors due to a bug.

Sent from my SM-T380 using Tapatalk

 

[snixel]

Stubby in 384.11 uses what is called round robin. This uses each resolver entry in turn then back to the first. So it cycles through all entries. This is supposed to improve response and in earlier Stubby versions was recommended to prevent errors due to a bug.

Sent from my SM-T380 using Tapatalk

Thx for the info! I guess I havn't had any issues with quad9 + dot + dnssec then or I would have noticed it by now. And I haven't changed the idle timeout either as instructed by @EmeraldDeer in previous post. I only did a standard config through the GUI

 

[CriticJay]

OpenDNS has speedy servers, wish they had DoT, as you say. I used to use them and they were great.

true, they used to be fast - but after cloudflare came out with 1.1.1.1 last year, they became the new "speed kings" and have yet to be dethroned.

 

[CriticJay]

@RMerlin on the 384.11 Release:

Enable DNSSEC Support = NO , still results in my PCs "passing" the various DNSSEC tests on the web.

So far tested it using:
https://www.cloudflare.com/ssl/encrypted-sni/
https://dnssec.vs.uni-due.de/
http://en.conn.internet.nl/connection/

Thoughts?

 

[Swistheater]

@RMerlin on the 384.11 Release:

Enable DNSSEC Support = NO , still results in my PCs "passing" the various DNSSEC tests on the web.

So far tested it using:
https://www.cloudflare.com/ssl/encrypted-sni/
https://dnssec.vs.uni-due.de/
http://en.conn.internet.nl/connection/

Thoughts?

it is because that test is only testing weather the sever (like cloudflare) you are using validates dnssec and not if your built in resolver does.

 

[Swistheater]

@RMerlin on the 384.11 Release:

Enable DNSSEC Support = NO , still results in my PCs "passing" the various DNSSEC tests on the web.

So far tested it using:
https://www.cloudflare.com/ssl/encrypted-sni/
https://dnssec.vs.uni-due.de/
http://en.conn.internet.nl/connection/

Thoughts?

@RMerlin on the 384.11 Release:

Enable DNSSEC Support = NO , still results in my PCs "passing" the various DNSSEC tests on the web.

So far tested it using:
https://www.cloudflare.com/ssl/encrypted-sni/
https://dnssec.vs.uni-due.de/
http://en.conn.internet.nl/connection/

Thoughts?

i recommend trying this test
https://rootcanary.org/test.html

and you should see the difference of what it looks like from the server (dnssec turned off) vs what it looks like with dnssec turned on.

I have done test with no dnssec,
and test with dnssec via dnsmasq,
and test with dnssec via stubby,
and I have determined which works best for my servers,
#note Dnsmasq dnssec will sometimes do server fails if your resolver does not validate a certain combination of signatures, this is due to it's stricter nature of validation.

 

[Swistheater]

as of right now with my current setup this is what my test looks like

 

[mbze430]

I don't know what's going on with my setup with DoT. I have since disabled my DNSCrypt-Proxy and try to use the "built-in" Stubby on the ASUS Merlin. That setup works VERY well.

I run a LAN MS DNS/DHCP. DHCP gives only my MS DNS nameserver as the lookup. my MS DNS forwarder is set-up to go back to my ASUS router running Diversion. But looking at all my tcpdump on 853 and 53 most of the DNS replies are still @ 53. There are some traffic on 853 but rare

I couldn't figure out if Diversion listens on 53 on the local loop or does it listen on 53 on the LAN iface. I do know the built-in Stubby listens on 127.0.1.1.

Anyone else can chime in on modifying the configuration to make this more seamless?

 

[Swistheater]

I don't know what's going on with my setup with DoT. I have since disabled my DNSCrypt-Proxy and try to use the "built-in" Stubby on the ASUS Merlin. That setup works VERY well.

I run a LAN MS DNS/DHCP. DHCP gives only my MS DNS nameserver as the lookup. my MS DNS forwarder is set-up to go back to my ASUS router running Diversion. But looking at all my tcpdump on 853 and 53 most of the DNS replies are still @ 53. There are some traffic on 853 but rare

I couldn't figure out if Diversion listens on 53 on the local loop or does it listen on 53 on the LAN iface. I do know the built-in Stubby listens on 127.0.1.1.

Anyone else can chime in on modifying the configuration to make this more seamless?

* i may be wrong*

but you could try turning on DNSFilter with the global mode set to "ROUTER" and that is it.

it sounds like a lot of the devices you are using have built in specific dns they use. with this feature turned on it will force them to use DoT. you seem to be currently leaking traffic through port 53

 

[JemTheWire]

When I run that test, this is my result:

I haven’t a clue what it all means but I don’t like the red crosses!

I have DoT enabled and it does pass the other tests I use.

 

[Swistheater]

When I run that test, this is my result:

View attachment 17652

I haven’t a clue what it all means but I don’t like the red crosses!

I have DoT enabled and it does pass the other tests I use.

It seems you may be running into some collisions with DNSMASQ DNSSEC, you could try running the test several times to see if your results get better- otherwise you have dns abnomal behavior going on. which could be caused by whatever server you are using.

 

[mbze430]

* i may be wrong*

but you could try turning on DNSFilter with the global mode set to "ROUTER" and that is it.

I'll test that method... but I still feel like the listening port might be in play here.

it sounds like a lot of the devices you are using have built in specific dns they use. with this feature turned on it will force them to use DoT. you seem to be currently leaking traffic through port 53

Obviously all my Google Home/Chromecast Ultra....etc... AND devices as such that can't be modified will continue to use 8.8.8.8 as it is hardcoded in their firmware.

However, ALL my VMs, servers, workstations and laptops, and mobile devices use my MS DNS as a local lookup. Anything that is outside of my domain will forward name lookup out to the ASUS Merlin router, I even have root lookup disabled.

Prior to changing over to built-in Stubby, my DNSCrypt-Proxy was working great because I was able to assign a listening port other than 53 (it used 5300). The DNS chain flowed perfectly.

 

[Paliv]

When I run that test, this is my result:

View attachment 17652

I haven’t a clue what it all means but I don’t like the red crosses!

I have DoT enabled and it does pass the other tests I use.

Mine is identical to yours when I run it with DoT with DNSSEC and DNSFilter (Router) turned on.

 

[Swistheater]

I'll test that method... but I still feel like the listening port might be in play here.



Obviously all my Google Home/Chromecast Ultra....etc... AND devices as such that can't be modified will continue to use 8.8.8.8 as it is hardcoded in their firmware.

However, ALL my VMs, servers, workstations and laptops, and mobile devices use my MS DNS as a local lookup. Anything that is outside of my domain will forward name lookup out to the ASUS Merlin router, I even have root lookup disabled.

Prior to changing over to built-in Stubby, my DNSCrypt-Proxy was working great because I was able to assign a listening port other than 53 (it used 5300). The DNS chain flowed perfectly.

I hear ya. let us know what kind of results. you may have other configurations that need to be done, but hard to say. if it works, you could set the global mode to "No Filter" and try listing each device that you want to use "Router" via the client list, so that way anything you have that is hard coded doesn't get included if that is what you like.

 

[InkyRag]

This is what I get with nothing enabled on the router but using Pi-Hole for DNS which is using Quad9 servers and with DNSSEC enabled.

 

[mbze430]

* i may be wrong*

but you could try turning on DNSFilter with the global mode set to "ROUTER" and that is it.

Setting the DNSFilter to ROUTER... everything is filtering through my OpenVPN connection to my PIA VPN Account that I setup in the Merlin firmware.

 

[Swistheater]

This is what I get with nothing enabled on the router but using Pi-Hole for DNS which is using Quad9 servers and with DNSSEC enabled.

The reds are because of the strictness of builtin dnssec of your setup v.s. your server not being able to validate the signature. it isn't a bad thing though just means that it will not load those signatures.

 

[Swistheater]

Setting the DNSFilter to ROUTER... everything is filtering through my OpenVPN connection to my PIA VPN Account that I setup in the Merlin firmware.

so that sounds like it isn't the option for you then. what are the settings on your wan dns look like? and your lan dhcp server?

 

[Swistheater]

This is what I get with nothing enabled on the router but using Pi-Hole for DNS which is using Quad9 servers and with DNSSEC enabled.

if you are curious more about this issue i suggest read
https://labs.ripe.net/Members/rolan...the-coalmine-for-the-dnssec-root-key-rollover

Test your resolver
As part of this project, we have developed an online DNSSEC validation checking tool. This tool performs an extensive test of the DNS resolver(s) configured on your system to see which DNSSEC algorithms it supports. This is useful in two ways. First, it confirms if your DNSSEC validating DNS resolver works correctly. Second, it can show you if your validating DNS resolver supports modern DNSSEC algorithms, such as those based on Elliptic Curve Cryptography. The picture below shows an example of the output of this tool for a resolver that supports most modern DNSSEC algorithms.