![]() ![]() ![]() |
|
Can you check you are definitely using Cloudflare DNS only (and not just adding manually specified Cloudflare resolvers into the round robin pool alongside DNS IPs acquired from the PPP session) - use something like whoami.akamai.net which returns the IP of the recursive resolver as A/AAAA record - do that a few times and note the owner of the IP using whois data. The issue of the Hamilton DNS IP not responding to some DNS queries can be worked around easily - that should at least solve your web page initial loading delay issue.
I'm assuming you're not making some joke and didn't realise that specific whoami doesn't work anymore 🤣
I did some dig'ging in command line, and all my requests seem to be routing through DNS correctly.
I did turn off use-peer-dns in dhcp-client in the router, so the only possible dns options are cloudfares (unless a device bypasses).
And then I found cloudfare's checker: https://1.1.1.1/help
yitz:
Can you check you are definitely using Cloudflare DNS only (and not just adding manually specified Cloudflare resolvers into the round robin pool alongside DNS IPs acquired from the PPP session) - use something like whoami.akamai.net which returns the IP of the recursive resolver as A/AAAA record - do that a few times and note the owner of the IP using whois data. The issue of the Hamilton DNS IP not responding to some DNS queries can be worked around easily - that should at least solve your web page initial loading delay issue.
kennedybaird:
I'm assuming you're not making some joke and didn't realise that specific whoami doesn't work anymore 🤣
Works for me. 🤷♂️ If Cloudflare has it's own checker then that will do too... other than Compass/Zeronet's Hamilton DNS IP quirk which I have bypassed I don't have an issue with them and don't have issues with intermittent delayed page loads or reliability in general. Only on 300/100 here so not going to bother with speed tests.
yitz:
Works for me. 🤷♂️ If Cloudflare has it's own checker then that will do too... other than Compass/Zeronet's Hamilton DNS IP quirk which I have bypassed I don't have an issue with them and don't have issues with intermittent delayed page loads or reliability in general. Only on 300/100 here so not going to bother with speed tests.
yitz:
Works for me. 🤷♂️ If Cloudflare has it's own checker then that will do too... other than Compass/Zeronet's Hamilton DNS IP quirk which I have bypassed I don't have an issue with them and don't have issues with intermittent delayed page loads or reliability in general. Only on 300/100 here so not going to bother with speed tests.
Just to note - whoami.akamai.net is a host name you can resolve (revealing the IPs of the DNS infrastructure used to perform recursive lookups) - it's not a web site you browse to in your internet brwoser or the name or IP of a DNS resolver so don't try and send DNS queries to it... it's also possible some privacy conscious applications will block it. Akamai is a content delivery network that in the past primarily used geographical load balancing based on recursive DNS.
Another thing to note if you send a lot of traffic through Cloudflare is that they don't have peering in Auckland with them and rely on upstream provider Voyager... usually ends in an Australian datacentre, so if you really must have single digit millisecond latency to their services then Zeronet may not be the ISP for you. In saying that they have made upgrades to the network recently so who knows - could be in the pipeline, you could ask them about it?
https://www.dnsleaktest.com/ will show which DNS servers are in use.
yitz:
Just to note - whoami.akamai.net is a host name you can resolve (revealing the IPs of the DNS infrastructure used to perform recursive lookups) - it's not a web site you browse to in your internet brwoser or the name or IP of a DNS resolver so don't try and send DNS queries to it... it's also possible some privacy conscious applications will block it. Akamai is a content delivery network that in the past primarily used geographical load balancing based on recursive DNS.
Another thing to note if you send a lot of traffic through Cloudflare is that they don't have peering in Auckland with them and rely on upstream provider Voyager... usually ends in an Australian datacentre, so if you really must have single digit millisecond latency to their services then Zeronet may not be the ISP for you. In saying that they have made upgrades to the network recently so who knows - could be in the pipeline, you could ask them about it?
To whom it may concern: https://www.bleepingcomputer.com/news/security/super-admin-elevation-bug-puts-900-000-mikrotik-devices-at-risk/
and
https://dnscheck.tools/ shows IP adresses, IPv6 DNS resolvers as well, DNSSEC and relevant signatures.
- NET: FTTH, OPNsense, 10G backbone, GWN APs, ipPBX
- SRV: 12 RU HA server cluster, 0.1 PB storage on premise
- IoT: thread, zigbee, tasmota, BidCoS, LoRa, WX suite, IR
- 3D: two 3D printers, 3D scanner, CNC router, laser cutter
For anyone who was curious, these were the final speedtest results up until I was moved over to Quic, added some summary stats at the top.
Tinkerisk:
To whom it may concern: https://www.bleepingcomputer.com/news/security/super-admin-elevation-bug-puts-900-000-mikrotik-devices-at-risk/
As a Mikrotik user this piqued my interest. CVE report is here: https://nvd.nist.gov/vuln/detail/CVE-2023-30799
"MikroTik RouterOS stable before 6.49.7 and long-term through 6.48.6 are vulnerable to a privilege escalation issue." so if you've already upgraded to 7.x I assume you're fine.
Also requires an existing admin account to execute the exploit. Its a concern because of the default Admin account being well known and the potential to brute force passwords. Mitigated by not allowing that account access to Winbox or the HTTP portal. I would say especially the portal (insert do not allow internet access to your http portal disclaimer here). Use difficult to guess passwords etc etc.
nzkc:
Tinkerisk:
To whom it may concern: https://www.bleepingcomputer.com/news/security/super-admin-elevation-bug-puts-900-000-mikrotik-devices-at-risk/
Also requires an existing admin account to execute the exploit. Its a concern because of the default Admin account being well known and the potential to brute force passwords. Mitigated by not allowing that account access to Winbox or the HTTP portal. I would say especially the portal (insert do not allow internet access to your http portal disclaimer here). Use difficult to guess passwords etc etc.
I am not using router from Mikrotik. I just came across it and thought someone might be interested.
- NET: FTTH, OPNsense, 10G backbone, GWN APs, ipPBX
- SRV: 12 RU HA server cluster, 0.1 PB storage on premise
- IoT: thread, zigbee, tasmota, BidCoS, LoRa, WX suite, IR
- 3D: two 3D printers, 3D scanner, CNC router, laser cutter
It's also been fixed for nearly a year, so no excuse for not updating to a more recent ROS version.
RunningMan:
It's also been fixed for nearly a year, so no excuse for not updating to a more recent ROS version.
Uh, no? The linked article is from 23 July 2023 and therefore the last fix for the LTS is 19 July 2023.
- NET: FTTH, OPNsense, 10G backbone, GWN APs, ipPBX
- SRV: 12 RU HA server cluster, 0.1 PB storage on premise
- IoT: thread, zigbee, tasmota, BidCoS, LoRa, WX suite, IR
- 3D: two 3D printers, 3D scanner, CNC router, laser cutter
|
![]() ![]() ![]() |