DNS resolution broken after Starlink firmware update — MikroTik behind Starlink router
Hello,
Setup: Starlink Gen 2 router → MikroTik C52iG-5HaxD2HaxD, RouterOS 7.18.2 (ether1 WAN) → internal LAN (192.168.88.x). Ran completely stable for many months. No manual changes on MikroTik.
Since a Starlink firmware update two days ago: DNS resolution completely broken.
What works:
Ping to any IP (8.8.8.8, 1.1.1.1) — works
HTTP fetch to IP addresses — works
HotSpot through the same MikroTik — works
nslookup directly on Starlink router via LAN cable — works perfectly
What does not work:
Any DNS resolution through MikroTik
Current state:
Bypass mode is active (was reset by Starlink update)
ether1 has 100.111.x.x/10, gateway 100.64.0.1
use-peer-dns=no on DHCP client
DNS servers set to 1.1.1.1
allow-remote-requests=yes
dynamic-server: empty
IPv6 globally disabled
Firewall (defconf):
input: accept established/related/untracked, drop invalid, accept ICMP, accept loopback, drop all not from LAN (in-interface-list=!LAN)
forward: accept ipsec, fasttrack established/related, accept established/related/untracked, drop invalid, drop all from WAN not DSTNATed (connection-nat-state=!dstnat connection-state=new in-interface-list=WAN)
NAT: masquerade on out-interface-list=WAN
What we found:
UDP connection tracking shows DNS queries reach 1.1.1.1 and 1 reply packet is received
Adding explicit input chain rule: accept udp src-port=53 in-interface=ether1 — rule counts packets but /resolve still fails
/resolve google.com server=1.1.1.1 → no result or "DNS server failure"
Before the Starlink update, Bypass was off and ether1 had 192.168.1.x — everything worked
Question: What in this defconf firewall setup blocks DNS resolution from working in Bypass mode with 100.x.x.x addressing? And why does the explicit input accept rule not help?
I appreciate any help.
PS: Testing is rather complicated as I am on a boat and mid ocean
My recommendation is to so save your config using :export file=boat-router.rsc and download the file from WinBox to your laptop first. And go to Files > Backup and create a new backup file, then download that one from Files (along the boat-router.rsc file).
One choice is do a "System" > "Reset Configuration" to just get back the default firewall, since it seems your main change is DNS (which you can do later). If you do, use "Keep Users" and DO NOT check "No Default" (since you want the default firewall, so uncheck No Default). As long as the starlink app is set for Bypass & it's plugged into ether1, this should work. Now this will put all clients on 192.168.88.x address from the router on Wi-Fi/ethernet... so if you have equipment that expects a certain range, you can edit the range in QuickSet where you can configure a new subnet for the LAN after the reset-configuration (now things can go wrong on the QuickSet if you're not careful, so leave the default without changing QuickSet likely best). Also, you can get the same reset by unplugging router from power, hit Reset button for ~7-9 seconds AFTER plugging back in (so reset is pressed before power is re-applied) - this will also get you the default configuration if you ever lose access (although WinBox with MAC address also works to get into a misconfigured router).
Otherwise, you can post you configuration using same export above... since it hard to guess what's wrong since in theory changing to bypass should only be helpful not break things.
I have a different setup with starlink. Forcing the dhcp to use 1.1.1.1/8.8.8.8 instead of the provided DNS (as I host my own DNS Server).
Also, I do not use the Starlink provided router at all. I have a PoE power supply (100W) and plug my RB5009 directly to the Antenna. This way I'm sure the router cannot interfere.
Note, I have to explicitly open the router firewall for DNS, as only some specific systems are allowed to use public DNS servers. All others have RPZ to protect from unwanted advertising crap.
It's that your firewall may not be right that's the issue, not using another DNS server. Starlink works fine with alternative DNS servers, so that's not problem... your config likely is.
You really should post your config and a better description of the problem. The "summary" of your firewall/config implies it's the "default", but clearly it's not if 1.1.1.1 DNS is not working.
I have updated to the latest stable version.
My problem is solved: the clients can resolve the servers now. It turns out, that in Winbox /resolve google.com or /resolve google.com server =1.1.1.1 still shows nothing.
This issue is :resolve (or /resolve is same) is a function, not really a command. So you need to output the return value to see it. Normally resolve is used in scripts.
The : (or /) is used to specify that this is a main router command...
Without the : (or /), both give an error ONLY when invoked on a non-root "path".
I don't understand this superfluous argument about the : (or /).
It's like forgetting to open or close a parenthesis. What does that have to do with the rest?
modest comment from a newbie: "It has always been like this" appears to be not very helpful for new users, who still struggle with the whole OS. Not one internet search gave me a hint.
It comes down to the question: For whom arew these forums? Discussions between expert or to help newcomers?
I have to say that the "AI Overview" is quite thorough... Lots of examples and considerations, just read on...
Then there's the MANUAL... just read it...
also with.. resolve... and comlpete examples... just read it...
So I doubt you actually searched for information about how the "resolve" command works...
And by "searched," I mean "searched," not simply a query made to some unknown Artificial Deficiency.
Every global command should start with the ":" token, otherwise, it will be treated as a variable.
There, I fixed it:
Global commands
Every global command should be prefixed with either the ":" or "/" character, otherwise it will work the same from root or throw an error from any other path.
Please note how a number of commands will normally NOT print output on terminal, these commands need to be used as an argument to :put (inside square brackets [ ... ]) to show output (see examples).
I don't think that any of your options is the correct one.
The most probable is:
4) The documentation is written by someone who does not know how to write documentation.
Whether they know or not the scripting language and commands is secondary to the lack of rigorous wording and frequent use of Mikrotikish (as opposed to English).