RouterOS problem with StarLink Update

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.

  1. The (very) default firewal do not block at all DNS
  2. (etehr1=WAN?) The added rule accept all packets that try to use your machine as DNS proxy for DDoS & other.
  3. Plug directly one device with DHCP to starlink and see what DNSs are provided. Use that DNSs.

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.

:put [:resolve server=1.1.1.1 google.com]

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.

[admin@CHR] > resolve google.com
[admin@CHR] > :put [resolve google.com]
142.251.214.110

@Amm0
Thanks for the explanation.
I believe this has bitten everyone (surely myself):

Still, I don't §@çking care if it is a function or whatever, it should throw an error, not a newline.

No...

Se io voglio semplicemente vedere se me lo risolve nella cache...

(no newline, just the prompt is showed again)

Should this also be an error?

[rex@tended] > (1+1)
[rex@tended] >

No.
Why should it? Useful or not, it's not wrong.

Or this:

[rex@tended] > $myfunction mypar="abc"
[rex@tended] >

If there is no ":put" inside the function, why would it throw an error?


This is how all RouterOS scripting works.

[rex@tended] > :tonum "666"
[rex@tended] >

It has always been there. So it shouldn't be changed.


:resolve or :tonum
are different (as I see it) from
resolve or tonum

The former ones should not throw an error, the second ones should.

"resolve is not recognized as internal or external command ..."

And the prompt is shown again on a new line, so the effect is the same of a newline or pressing [ENTER].

[rex@tended] > :resolve "gogole.com"
[rex@tended] > /resolve "gogole.com"
[rex@tended] > resolve "gogole.com"
[rex@tended] > :tonum "666"
[rex@tended] > /tonum "666"
[rex@tended] > tonum "666"
[rex@tended] > ip
[rex@tended] /ip> :resolve "gogole.com"
[rex@tended] /ip> /resolve "gogole.com"
[rex@tended] /ip> resolve "gogole.com"
bad command name resolve (line 1 column 1)
[rex@tended] /ip> :tonum "666"
[rex@tended] /ip> /tonum "666"
[rex@tended] /ip> tonum "666"
bad command name tonum (line 1 column 1)

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?

(in a perfect world) that error would be:

[rex@tended] /ip> resolve "gogole.com"
bad command name resolve is not available under /ip (line 1 column 1)

I was only trying to find a way to make command line friendler to the newcomer.

Then maybe a new command :astonished_face: showresolve would be useful.

That message is misleading: "is not available under %path"

  1. Where is it available then? But if OS already know where it available, launch it... /system script settings autoroot=yes

  2. So where? What if it doesn't exist at all? "bad command name fixconfig is not available at all (line 1 column 1)"

  3. AI loves 3)...

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?

Let's start, perhaps, if we quote, by using the exact words.

"like this" is not the same as "there"


It's always been illegal to drive against traffic,
so why shouldn't the rule change for new drivers?


Searching for what? How does the "resolve" command work?

https://www.google.com/search?q=routeros+resolve+command

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.

Global commands

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).

The documentation is certainly poorly done, incomplete. [e su questo... non si discute...]

resolve:
return [not print] the IP address of the given DNS name

All examples use :put

:put [:resolve "www.mikrotik.com"];

:put [:resolve domain-name="www.mikrotik.com"];

:put [:resolve domain-name="www.mikrotik.com" server=192.168.88.1 port=53];

:put [:resolve domain-name="www.mikrotik.com" type=ipv6];

and nowhere is "/resolve" indicated

Yep, also it is explicitly said that without the ":" it will be treated as a variable[1].

[1] And of course no example of such an use is given, AND we have just seen that it works just fine (from root) or throws an error (from non-root)

There are two things, choose:

  1. The documentation is written by someone who knows how to use scripts
    so they take a lot of things for granted.

  2. The documentation is written by someone who doesn't know how to use scripts
    so they haven't learned a lot of things.

  3. And this is the third option for Artificial Deficiency.

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).