nslookup on Mikrotik

bakiri123 · Thu Aug 23, 2012 12:26 pm

Is there a Mikrotik command equivalent to the Windows nslookup command?

Thu Aug 23, 2012 12:30 pm

to find out the IP address of some domain, just ping it. or you can use the ":resolve" command, if you need it in scripts:

ros code

[admin@MikroTik] > put [:resolve mt.lv]
159.148.147.196

bakiri123 · Thu Aug 23, 2012 1:38 pm

Thanks. The command also works fine without the colon, i.e. put [resolve mt.lv]

marria · Thu Jul 23, 2015 5:09 am

to find out the IP address of some domain, just ping it. or you can use the ":resolve" command, if you need it in scripts:

ros code
[admin@MikroTik] > put [:resolve mt.lv]
159.148.147.196

This is true, but does not tell which dns server is resolving, which can be helpful...

olkba · Wed Oct 21, 2015 12:41 pm

you can specify target dns server to query easily:

put [resolve google.com server 8.8.8.8]

yottabit · Wed Feb 24, 2016 2:14 am

I have a static IP mapping for a host to resolve to an internal IP. However, in my script I want to resolve the public IP by using an external DNS server. Seems simple enough with the ":resolve <host> [server=1.2.3.4]" script command, but it's not working for me. It seems the :resolve command is always using local router DNS and ignoring the server=1.2.3.4 argument. Here's the example:

[admin@rb1.magrathea] > put [:resolve host.fqdn server=8.8.4.4]
172.16.42.25

But it's wrong, for example:

[root@nas1] ~# nslookup host.fqdn 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   host.fqdn
Address: 216.58.218.206

I have no redirect rules on the router, as evidenced by the above host using nslookup on the LAN through that same router.

Ideas?

Edit: version is:
# feb/23/2016 18:17:54 by RouterOS 6.35rc12

yottabit · Sat Feb 27, 2016 5:58 pm

Friendly bump to see if anyone has tips for forcing the :resolve command to use an external server?

Jotne · Sun May 07, 2017 1:16 pm

Old thread.

Just confirm that this works fine for me on 6.39

[user@GV-FV155] > put [resolve remote.my-server.com]
10.10.10.32
[user@GV-FV155] > put [resolve remote.my-serve.com server 8.8.8.8]
92.xxx.xxx.134
[user@GV-FV155] >

stardm · Wed Nov 01, 2017 9:01 pm

Hello, all

you can specify target dns server to query easily:
Code: Select all
put [resolve google.com server 8.8.8.8]

NO! How can I discover DNServer? Which server return address? (Yeah, I have a very long list DNS and I am use every server.)

(FREEBSD 9.3 nonroot command line)
$ nslookup g.cn
Server: 8.8.8.8 // WHO tell about adress?
Address: 8.8.8.8#53 // allright, about g.cn google DNS well known. Und das ist fantastisch, I can see NS port number! Mikrotik can it?
Non-authoritative answer:
Name: g.cn
Address: 173.194.73.94

Or is it difficult to implement and understand?
Danke schoen.

arashams · Mon Jan 01, 2018 10:04 am

when you use nslookup it will give you the DNS name of site (and also resolver IP and name)
what is the nslookup like command in mikrotik
Windows example:

nslookup 8.8.8.8
Server:  *******
Address:  10.5.50.177

Name:    google-public-dns-a.google.com
Address:  8.8.8.8

Linux example

nslookup microsoft.com

...and you would receive a response like this:

Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
Name:    microsoft.com
Address: 134.170.185.46
Name:    microsoft.com
Address: 134.170.188.221

nichky · Mon Jan 01, 2018 10:30 am

nice one, i thought MT didn't support that one

Deantwo · Wed Oct 02, 2019 12:48 pm

Yes, you have to assume that the DNS server that replied is the DNS server that you (or the router) specified.
The [:resolve "microsoft.com"] is a script command, it is not really a troubleshooting tool. I have a number of scripts that relay on [:resolve "microsoft.com"] returning just a single IP-address, any change to it would break scripts for a lot of people.

It would be nice with a real "NSLOOKUP"-style troubleshooting tool though.

In RouterOS version 6.36 and newer, you can also use address lists to get a list of IP-addresses that the DNS name resolve as.

[admin@MikroTestRouter] > /ip firewall address-list add address="microsoft.com" list="list1"
[admin@MikroTestRouter] > /ip firewall address-list print where list="list1"
Flags: X - disabled, D - dynamic 
 #   LIST                  ADDRESS                                    CREATION-TIME        TIMEOUT
 0   list1                 microsoft.com                              oct/02/2019 11:38:55
 1 D ;;; microsoft.com
     list1                 40.112.72.205                              oct/02/2019 11:38:55
 2 D ;;; microsoft.com
     list1                 40.113.200.201                             oct/02/2019 11:38:55
 3 D ;;; microsoft.com
     list1                 104.215.148.63                             oct/02/2019 11:38:55
 4 D ;;; microsoft.com
     list1                 13.77.161.179                              oct/02/2019 11:38:55
 5 D ;;; microsoft.com
     list1                 40.76.4.15                                 oct/02/2019 11:38:55
[admin@MikroTestRouter] > /ip firewall address-list remove [find list="list1" !dynamic]

tannexdadole · Fri May 08, 2020 4:32 pm

you can specify target dns server to query easily:
Code: Select all
put [resolve google.com server 8.8.8.8]

is there a way to get this output as a variable?

this code runs only in terminal.. how do I translate this so it can run on script?

:do {
:put [:resolve www.example.com];
} on-error={ :put "resolver failed"};
:put "lala"

output:

resolver failed
lala

Cha0s · Fri May 08, 2020 4:40 pm

:global dns [:resolve "www.google.com"]     
:put $dns
216.58.212.4

msatter · Fri May 08, 2020 4:43 pm

:set $result [:resolve mt.lv]; :put $result

tannexdadole · Fri May 08, 2020 6:24 pm

:set $result [:resolve mt.lv]; :put $result

thanks mate...

msatter · Fri May 08, 2020 7:16 pm

If you want to use the result in a other script then you should use :global, as ChaOs suggested.

Jotne · Fri May 08, 2020 9:23 pm

When you use set of a variable, it should be declared fist (but works without), so either this;

:local result
:set $result [:resolve mt.lv]
:put $result

Or set it directly when declare the variable like this:

:local result [:resolve mt.lv]
:put $result

One line

local result [:resolve mt.lv]; :put $result

JAza · Fri Dec 24, 2021 2:22 am

to find out the IP address of some domain, just ping it. or you can use the ":resolve" command, if you need it in scripts:

ros code
[admin@MikroTik] > put [:resolve mt.lv]
159.148.147.196

The problem with this tact is that it only allows to resolve the first A record. NSLOOKUP allows record type lookups like MX, SOA, etc.

How to accomplish this on Mikrotik?? Need an NSLOOKUP type tool.

Deantwo · Fri Dec 24, 2021 4:39 pm

to find out the IP address of some domain, just ping it. or you can use the ":resolve" command, if you need it in scripts:

ros code
[admin@MikroTik] > put [:resolve mt.lv]
159.148.147.196
The problem with this tact is that it only allows to resolve the first A record. NSLOOKUP allows record type lookups like MX, SOA, etc.

How to accomplish this on Mikrotik?? Need an NSLOOKUP type tool.

What I wrote in #12 is the only other way I think we have right now.
Other than that, use an actual Windows mashie.

Why do you even need all that information on the router itself?

JAza · Fri Dec 24, 2021 10:03 pm

The problem with this tact is that it only allows to resolve the first A record. NSLOOKUP allows record type lookups like MX, SOA, etc.

How to accomplish this on Mikrotik?? Need an NSLOOKUP type tool.
What I wrote in #12 is the only other way I think we have right now.
Other than that, use an actual Windows mashie.

Why do you even need all that information on the router itself?

First, try to ping fqdn of an MX record (or any non A record) and all above methods will fail and no IP will be returned.

Second, as a troubleshooting tool, if there is a problem inside the network that appears to be affecting all machines (as the reason I was googling and what brought me here) then we check first outside the network to verify if it's external DNS or problem is elsewhere.
If it works outside, then where is next logical step if not to check if problem exists at the edge/gateway? (and in some cases said gateway is the DHCP and even DNS server (or caching relay)...)

If I cannot verify it works at the edge properly then I can't eliminate that variable from testing, can I? Suddenly the Mikrotik is NOT the swiss army knife problem-solver router I chose to deploy everywhere; suddenly, it becomes an anchor.

If NSLOOKUP saves my ass even once in 20 or cuts my resolution time on a problem even once in a hundred, it's a useful tool and we should have it.
The 'tik is based on the 2.6 Linux kernel iirc. No reason it can't have these tools and no reason it should be overly difficult to port them in (if porting is even needed at all.) Not asking for bespoke development here just make an existing, basic staple, *nix tool available on our *nix networking devices.
It's a no brainer to me.

Deantwo · Sat Dec 25, 2021 3:13 am

First, try to ping fqdn of an MX record (or any non A record) and all above methods will fail and no IP will be returned.

And this is something you need to do from your router? When exactly?
I am not saying it wouldn't be nice if the ":resolve" got some more options, for example to lookup MX records or whatever, but it at least isn't possible right now. So the question was why you needed it at all, to try and help you find an alternative. I however guess it is impossible for you to lookup an MX record on the router currently, unless someone has a fancy trick.

I mean, maybe there is a DNS server out there that you can ask specifically for MX records and have it return them as if they were A records. You can't possibly be the first person in the world that need the IP-address of an MX record returned as an A record result. At worst you might have to make this custom DNS server yourself if one doesn't exist, maybe others would find it useful too.

Second, as a troubleshooting tool, if there is a problem inside the network that appears to be affecting all machines (as the reason I was googling and what brought me here) then we check first outside the network to verify if it's external DNS or problem is elsewhere.
If it works outside, then where is next logical step if not to check if problem exists at the edge/gateway? (and in some cases said gateway is the DHCP and even DNS server (or caching relay)...)

What is the difference between doing the NSLOOKUP command on your network edge/gateway, and using it on any machine on the network? Does your network block and/or reroute all DNS queries leaving your network?

If you simply specify the DNS server in the NSLOOKUP command, you will ask any DNS server. If your machine can't make DNS queries or doesn't have internet access, you have found out that the issue is in your network.

C:\Users\admin>NSLOOKUP google.com 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    google.com
Addresses:  2a00:1450:400f:801::200e
          142.250.74.142

Again, yes it would be nice with something similar to the NSLOOKUP command on the router, but I really don't see why it important.

SergeyUshakov · Fri Jan 07, 2022 6:53 pm

The approach in #12 by Deantwo with firewall lists is handy, but unfortunately it does not seem to have a facility for resolving the host via specific server.

Still in case a host resolves into several addresses, and a specific DNS server is required to be used, my observation suggests that subsequent calls like `:put [:resolve www.google.com server 8.8.8.8]` return different addresses, and they may be eventually collected in full. This feature is probably not documented, and still it looks like working.

The proof of concept looks like this:

# resolveAllHostAddresses : a function to return an array of IP addresses for a host, resolved using a specific DNS server
# arguments:
# - host : host name to be resolved
# - server (default: local DNS server) : DNS server to be used
# - confirmations (default: 2) : number of confirmations for every address to be obtained in a series of DNS queries, for the result to be considered as complete
# return value: array of IP addresses for the host
:global resolveAllHostAddresses do={
  # actual repetition count value to be used for every address
  :local sufficientCount;
  if ([:type $confirmations]!="nothing") do={
    :set sufficientCount $confirmations;
  } else={
    :set sufficientCount 2;
  }
  # array of addresses to be returned, initialized as empty
  :local addressesToReturn [:toarray ""];
  # array of remaining confirmation counts, initialized as empty
  :local counts [:toarray ""];
  # variable to be used as loop exit flag
  :local done true;
  # safeguard against infinite looping
  :local attempts 100;
  # perform resolving in a loop until every address is received more than once
  :do {
    # decrement the safeguard count
    :set attempts ($attempts - 1);
    # get a new DNS query result
    :local address;
    if ([:type $server]!="nothing") do={
      :set address [:resolve $host server $server];
    } else={
      :set address [:resolve $host];
    }
    # check if the obtained address is known already
    :local idx [:find $addressesToReturn $address];
    :if ([:type $idx]="nil") do={
      # new address: add it to the array to be returned as-is
      :set addressesToReturn ($addressesToReturn, $address);
      # add one more remaining count value to the counts array
      :set counts ($counts, $sufficientCount);
    } else={
      # known address: decrement confirmation count in the counts array with zero as limit
      :local count ($counts->$idx);
      :local newCount ($count - 1);
      :if ($newCount>=0) do={
        # set decreased value
        :set ($counts->"$idx") $newCount;
      }
    }
    # check the counts array to see if all the addresses were received required number of times
    :set done true;
    :foreach count in=$counts do={
      :if ($count>0) do={
        :set done false;
      }
    }
  } while=((!done)&&($attempts>0));
  :return $addressesToReturn;
};

Amazingly, the default `confirmations` value as 2 seems to yield sufficient degree of completeness.

My typical test result looks like this:

> :global resolveAllHostAddresses; :put [$resolveAllHostAddresses host=www.google.com server=8.8.8.8]
64.233.161.104;74.125.205.147;74.125.131.147;64.233.164.147;64.233.161.105

> :global resolveAllHostAddresses; :put [$resolveAllHostAddresses host=www.google.com server=1.1.1.1]
173.194.222.104;209.85.233.106;74.125.131.106;173.194.222.99;74.125.131.105;209.85.233.105;173.194.222.147;74.125.131.103;74.125.131.104;209.85.233.147;173.194.222.105;74.125.131.99;74.125.131.147;209.85.233.103;173.194.222.103;173.194.222.106;209.85.233.99;209.85.233.104

JAza · Fri Feb 18, 2022 12:49 am

First, try to ping fqdn of an MX record (or any non A record) and all above methods will fail and no IP will be returned.
And this is something you need to do from your router? When exactly?
I am not saying it wouldn't be nice if the ":resolve" got some more options, for example to lookup MX records or whatever, but it at least isn't possible right now. So the question was why you needed it at all, to try and help you find an alternative. I however guess it is impossible for you to lookup an MX record on the router currently, unless someone has a fancy trick.

I mean, maybe there is a DNS server out there that you can ask specifically for MX records and have it return them as if they were A records. You can't possibly be the first person in the world that need the IP-address of an MX record returned as an A record result. At worst you might have to make this custom DNS server yourself if one doesn't exist, maybe others would find it useful too.

Second, as a troubleshooting tool, if there is a problem inside the network that appears to be affecting all machines (as the reason I was googling and what brought me here) then we check first outside the network to verify if it's external DNS or problem is elsewhere.
If it works outside, then where is next logical step if not to check if problem exists at the edge/gateway? (and in some cases said gateway is the DHCP and even DNS server (or caching relay)...)
What is the difference between doing the NSLOOKUP command on your network edge/gateway, and using it on any machine on the network? Does your network block and/or reroute all DNS queries leaving your network?

If you simply specify the DNS server in the NSLOOKUP command, you will ask any DNS server. If your machine can't make DNS queries or doesn't have internet access, you have found out that the issue is in your network.
Code: Select all
C:\Users\admin>NSLOOKUP google.com 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    google.com
Addresses:  2a00:1450:400f:801::200e
          142.250.74.142
Again, yes it would be nice with something similar to the NSLOOKUP command on the router, but I really don't see why it important.

Sorry for late response must have missed the notif.

To answer your questions, first yes, it IS a "nice to have" but there are times (edge cases maybe but still, times) that this would be very helpful. Not every tool in ROS is a daily essential, there are LOTS of "nice to have"s.

Torch is a "nice to have". I can use the router fine without it and many routers are sold every day that don't have such a tool.
Address Lists are "nice to have" We got along fine without them for many years
Cloud and in-built DDNS is a "nice to have" I still have my scripts for doing ddns resolution and updating.
I could go on...

The recent case that brought me here was me remoting into a user's machine who's complaining of xyz (that smelled DNS related) and from that machine I tried to do a nslookup that failed.
Now, I KNOW internet works, I'm remoting into the machine FROM the internet.
I see that most things work in the browser (google,etc. Incl. some obscure url I know they would not ever have tried so it's not just cached) but SOME things won't work and again, the nslookup fails.
Tried two other machines on the network, same deal.
Eventually I realized that ALL nslookups were failing and on all the machines.

So that's a case where I ABSOLUTELY could have benefited from being able to do a lookup at the gateway. Just for a sanity check if nothing else.
In this case it turned out user was using a VPN software, restricted only to vpn some apps (whitelist). Whether it's a bad implementation or for whatever reason, this app borks all attempts to nslookup from the machines.

Did I figure this out other ways? Yes, eventually.
Did it cost me a couple hours it shouldn't have? Yes, pretty much.
Would nslookup on the gateway have saved me those couple hours? Yes, almost guaranteed.

If I'd been able to isolate quickly that the issue was endemic to the endpoints and not network wide (remember, multiple machines, same behavior. Because all the users used same vpn brand/software) I'd likely not have gone down a couple of rabbit holes that (obviously) were not the right answer.

I'm sure there have also been other times that nslookup would have been useful to me at the edge but this is the latest and freshest in my memory. I'm sure I'm not alone either.

And again, we're not asking here for bespoke development of some new fancy tool or functions library that doesn't exist yet. nslookup is a staple of most any/every *nix, has been since probably not long after the epoch (at least as long as mattered in MY lifetime) and I'm pretty sure it wouldn't be that hard to find one they can easily port (if not directly drop in) to ROS. And most if not all modern RBs should have the space. We're not dealing with 8MB of system storage anymore.

So all in it seems a fairly straightforward ask imho, and, since it's a decade old and we've seen multiple MAJOR version releases in that time I think a better question than "why do I want it" is "why DON'T we have it yet?"

J.

Deantwo · Sat Feb 19, 2022 9:53 am

The recent case that brought me here was me remoting into a user's machine who's complaining of xyz (that smelled DNS related) and from that machine I tried to do a nslookup that failed.
Now, I KNOW internet works, I'm remoting into the machine FROM the internet.
I see that most things work in the browser (google,etc. Incl. some obscure url I know they would not ever have tried so it's not just cached) but SOME things won't work and again, the nslookup fails.
Tried two other machines on the network, same deal.
Eventually I realized that ALL nslookups were failing and on all the machines.

So that's a case where I ABSOLUTELY could have benefited from being able to do a lookup at the gateway. Just for a sanity check if nothing else.
In this case it turned out user was using a VPN software, restricted only to vpn some apps (whitelist). Whether it's a bad implementation or for whatever reason, this app borks all attempts to nslookup from the machines.

If I'd been able to isolate quickly that the issue was endemic to the endpoints and not network wide (remember, multiple machines, same behavior. Because all the users used same vpn brand/software) I'd likely not have gone down a couple of rabbit holes that (obviously) were not the right answer.

I'm sure there have also been other times that nslookup would have been useful to me at the edge but this is the latest and freshest in my memory. I'm sure I'm not alone either.

If you just need to check if a DNS request would work from the gateway router, the [:resolve google.com server=8.8.8.8]
command seem like it would have been enough.

And I know it is easy for me to say this after the fact. But remember the golden IT supporter rule, turn it off and on again. If you had rebooted the users endpoint so you had it fresh with no programs started by the user, it would likely have worked again. At least I haven't seen a VPN program automatically connect on startup before, since they usually require some form of authentication. Then you know it is some software the user is normally running on the machine.

As for weird VPN programs causing weird network issues, yes it is confusing and annoying. However a simple IPCONFIG command should reveal that some form of other network interface exist on the machine, even if the VPN program is nowhere to be seen.

Anyway, I am sure you know how to do your job.

Aside from being able to get all IP-addresses on a DNS record, or getting MX records, I really don't see what special function the NSLOOKUP command does that [:resolve google.com server=8.8.8.8] doesn't.

jcrg · Wed Mar 08, 2023 10:34 pm

you can specify target dns server to query easily:
Code: Select all
put [resolve google.com server 8.8.8.8]

I have not found any reference in the official documentation to the parameters of the resolve command. Do you know any website where to find it?

Deantwo · Thu Mar 09, 2023 3:52 pm

you can specify target dns server to query easily:
Code: Select all
put [resolve google.com server 8.8.8.8]
I have not found any reference in the official documentation to the parameters of the resolve command. Do you know any website where to find it?

https://wiki.mikrotik.com/wiki/Manual:S ... g#Commands

Seem to be the only place it is mentioned. You could email support and ask them to expand on that command in the wiki.

Amm0 · Thu Mar 09, 2023 5:35 pm

Agree it should describe its operation/parameters in docs. But you can hit <tab> twice after any command to find out:

:resolve <tab><tab>
domain-name  server  server-port

But it's more a scripting function, than a dig/nslookup replacement. e.g. there is NO type= option to do NS, SOA, MX, PTR, etc records lookups.

Amm0 · Thu Mar 09, 2023 5:46 pm

BTW the quoted "server 8.8.8.8" here is wrong. There should be an equal = sign between params and param value:

:put [:resolve hostname.example.com server=1.1.1.1]

Maybe the server space syntax works in some versions, but asking for trouble.

Similar with the the colons if you are always at the root, it's fine.

[admin@Mikrotik] > put [resolve dishy.starlink.com server=8.8.8.8]
192.168.100.1

But if you navigate to down the config tree, you need them:

[admin@Mikrotik] /ip/address> put [resolve dishy.starlink.com server=8.8.8.8]
bad command name resolve (line 1 column 6)
[admin@Mikrotik] /ip/address> :put [:resolve dishy.starlink.com server=8.8.8.8]
192.168.100.1

Easier to always use a colon.