en.internet.nl
Cloudflare Browser Check
Secure DNS Transport using DoH (DNS over HTTPS) or DoT (DNS over TLS) and SNI with ECHwww.cloudflare.com
Test for modern Internet Standards like IPv6, DNSSEC, HTTPS, DMARC, STARTTLS and DANE.
Test for modern Internet Standards IPv6, DNSSEC, HTTPS, HSTS, DMARC, DKIM, SPF, STARTTLS, DANE, RPKI and security.txt
DNSSEC Tools - ICANN
www.icann.org
and the one you already have just for sake of having all for reference:
I see the same with 3.19 and 3.20. Is anyone able to see Rootcanary working as before or is this non-functional for everyone?
; <<>> DiG 9.16.6 <<>> txt com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28368
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;com. IN TXT
;; AUTHORITY SECTION:
com. 900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1601604595 1800 900 604800 86400
;; Query time: 19 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Thu Oct 01 22:10:23 EDT 2020
;; MSG SIZE rcvd: 105
; <<>> DiG 9.16.6 <<>> com. @127.0.0.1 -p 53
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50881
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;com. IN A
;; AUTHORITY SECTION:
com. 1200 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1601604610 1800 900 604800 86400
;; Query time: 39 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct 01 22:10:23 EDT 2020
;; MSG SIZE rcvd: 105
Rootcanary test definitely broken - have nudged developer to fix.
The changes to the config terminology still maintain backwards compatibility - this will be important. I don't want to take the discussion in this direction, but I think it's important they didn't break everyone's (especially unbound_manager's) configurations overnight.However - this is accounting for the smaller buffer size needed for ipv6 and if you exclusively use ipv4, this number is perhaps too conservative.
I don't have IPv6 available from my ISP and apparently neither does @Linux_Chemist? , but I have posted beta 'unbound_manager v3.21b' on the Github 'dev' branch
e = Exit Script [?]
A:Option ==> uf dev
unbound_manager.sh downloaded successfully Github 'dev/development' branch
unbound Manager UPDATE Complete! 843c8cb62ae6a4a1a2b7591d9c45efece = Exit Script [?]
A:Option ==> vb
Active 'unbound.conf' backed up to '/opt/share/unbound/configs/yyyymmdd-hhmmss_unbound.conf'e = Exit Script [?]
A:Option ==> i dev
Retrieving Custom unbound configuration
unbound.conf downloaded successfully Github 'dev/development' branch
<snip>e = Exit Script [?]
A:Option ==> oq edns-buffer-size
unbound-control 'edns-buffer-size' '1232'# v1.11 Martineau - Add 'private-address: ::/0' Enhance 'do-ip6: no' i.e. explicitly drop ALL IPv6 responses
# - Add IPv6 Private Address 'fd00::/8' and 'fe80::/10'
these numbers (the 1472, particularly) share a possibly striking similarity to ~1500 MTU (and MRU) numbers that are germane if you are a user of (Cake-)QoS...and 4096 hits me as the "larger" frame size on the way up to Jumbo (9000bits?). If I'm on any way near a right track with this, I would tend to think that if unbound is caching but recursively queries authoritative servers, wouldn't it be best to align with whatever THEY use on our networks? (I like these types of math-logic problems)With unbound 1.12.0 soon, I thought I'd highlight the changes for discussion.
There are many nice memory leak fixes.
What I wanted to highlight was:
The default config for unbound_manager sets edns-buffer-size to 1472, but the new default under the recommendation of DNS flag day (https://dnsflagday.net/2020/) for this setting is being reduced to 1232 and I wonder if this is a bit too far, but I'd like to see some data on udp vs tcp dns performance.
It wasn't long ago that this was defaulted to 4096 in unbound and this had a performance boosting potential. (Particularly for DNSSEC - an important thing to use but having DNSSEC enabled makes the messages bigger). By default, or at least before this upcoming release, Unbound tries 4096 and if it fails, tries again at 1232 for IPv6 and 1472 for IPv4.
The balancing act is picking a number that avoids fragmentation while also minimising having to fallback to TCP.
The exact number to use for this setting has been debated, but there was a inkling it should go a little lower. If DNS can't manage sending what it needs on UDP, it can fallback to TCP which is a bit slower (I will say that in practice I only see it happen on scientific journal sites etc).
However - this is accounting for the smaller buffer size needed for ipv6 and if you exclusively use ipv4, this number is perhaps too conservative.
Is it throwing away performance for the sake of conforming? Some set it all the way down to 512 to guarantee fragmentation won't happen (all but forcing slower TCP).
See older notes for the setting:
In short, I'll be interested to see whether you think unbound_manager sticks to 1472, but changes like this (on servers in general) are likely to mean a shift, however marginal, in DNS resolvers switching to TCP more often. I will continue to push my luck with 4096 but will probably relent to 1472 in the end on my ipv4-exclusive setup. Perhaps the script could set 1232 if do-ip6: yes?
True that. Talk talk UK is my ISP and they've just put it off for years and years and respond to the question with 'they're doing everything they can to make their ipv4 systems good'.
End result: no ipv6 to speak of unless you feel like setting up v4-to-v6 tunnelling (I don't lol) Unbound slapping a lower number as the default just seems a bit heavy handed a change when ipv4 was perfectly happy with 1472.They do share a similarity - I think it's something like "you can accept 4096 since it's udp but if you're falling back to tcp, then you're confined to a sensible mtu value like ethernet's 1500 minus the usual packet restrictions". If the receiving end can't handle the size you've chosen, it fails, the resend creates the timeout, then it tries again with a lower value (and tcp guarantees the old handshake that it got the message).
They do share a similarity - I think it's something like "you can accept 4096 since it's udp but if you're falling back to tcp, then you're confined to a sensible mtu value like ethernet's 1500 minus the usual packet restrictions". If the receiving end can't handle the size you've chosen, it fails, the resend creates the timeout, then it tries again with a lower value (and tcp guarantees the old handshake that it got the message).
Ultimately, it's all about picking a standard and it seems that standard is now 1472 for ipv4 and 1232 for ipv6, with the lower number for a mixed network. Will performance suffer? potentially but it has to be consensus driven and the dns overlords have spoken lol I will abide. Long may they reign.
EDIT: Using tcp instead of udp can cut throughput for DNS requests to 1/3 (https://dnsprivacy.org/wiki/pages/viewpage.action?pageId=17629326) - using tcp will be better congestion control but does the small number of dns requests on a home network really make a difference to congestion?
There's a graph showing that using tcp with powerdns (dnsdist) rather than unbound actually had improved performance vs udp - will definitely be looking into that later for what's going on there.
I'm beginning to think I should put these wordier thoughts around unbound/dns into separate posts
I wouldn't mess with MTU though - the lower number of you to your router vs router to your isp etc etc will end up being the bottleneck and if it's too big, it'll cause fragmentation and a lot of icmp type 3 packets in response after it to say 'woahhh boy, get that mtu down!' Maybe a little ryzen with at least 8 threads? Powerdns may be better at working asynchronously than Unbound, or it does its lookups in some different funky way, but it's very interesting that that testing I linked got better throughput on it for tcp than udp somehow. If that wasn't just an anomaly, there might be some crucial takeaway from it for Unbound if we're all migrating into a more 'dns over tcp' future.). My total.tcpusage is at 0.
github.com
"512" => "512: IPv4 Minimum",
"1220" => "1220: NSD IPv6 EDNS Minimum",
"1232" => "1232: IPv6 Minimum",
"1432" => "1432: 1500 Byte MTU",
^
|
v
"1480" => "1480: NSD IPv4 EDNS Minimum",
"4096" => "4096: (Old) Unbound Default"I can update to 3.21b successfully, but once I try to install 'unbound.conf v1.11' using
Retrieving Custom unbound configuration
unbound.conf downloaded successfully Github 'dev/development' branch
doc/example.conf.in downloaded successfully
Checking IPv6.....
Customising unbound IPv6 configuration.....
Customising unbound configuration Options:
Do you want to ENABLE unbound logging? (NO recommended)
Reply 'y' or press ENTER to skip
y
unbound Logging enabled - 'verbosity: 1'
/opt/var/lib/unbound/unbound.conf:153: error: cannot open include file '/opt/var/lib/unbound/adblock/adservers': No such file or directory
/opt/var/lib/unbound/unbound.conf:212: error: cannot open include file '/opt/share/unbound/configs/unbound.conf.addgui': No such file or directory
/opt/var/lib/unbound/unbound.conf:215: error: cannot open include file '/opt/share/unbound/configs/unbound.conf.localhosts': No such file or directory
/opt/var/lib/unbound/unbound.conf:221: error: cannot open include file '/opt/share/unbound/configs/unbound.conf.add': No such file or directory
read /opt/var/lib/unbound/unbound.conf failed: 4 errors in configuration file
Restarting dnsmasq.....
Done.
***ERROR FATAL...ABORTing!
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!
