I have a site-to-site connection between two routers over wireguard.
Site A: router.lacinet address 192.168.14.254/24
Site B: router.kavicsnet address 192.168.18.254/24
Split-DNS is not working. Example:
[gandalf@router.lacinet] > /ping 192.168.18.254
SEQ HOST SIZE TTL TIME STATUS
0 192.168.18.254 56 64 39ms412us
1 192.168.18.254 56 64 41ms493us
2 192.168.18.254 56 64 38ms510us
sent=3 received=3 packet-loss=0% min-rtt=38ms510us avg-rtt=39ms805us max-rtt=41ms493us
[gandalf@router.lacinet] > /ping borika-pc.kavicsnet
invalid value for argument address:
invalid value of mac-address, mac address required
invalid value for argument ipv6-address
while resolving ip-address: name does not exist
[gandalf@router.lacinet] > :put [/resolve borika-pc.kavicsnet]
failure: dns name does not exist
[gandalf@router.lacinet] > :put [/resolve borika-pc.kavicsnet server=192.168.18.254]
192.168.18.199
[gandalf@router.lacinet] >
So router.lacinet can see router.kavicsnet. DNS works when I specify the server directly. But it does not work when I do not specify the server.
But with this particular network, it does not want to work. Since the direct request to the remote DNS server works, I think we can rule out any firewall or connection problem.
IMO the problem is that MT’s DNS server doesn’t perform recursive lookups. In your case it would have to because of FWD record. Any other DNS client seeing this record would know to contact next hop DNS server, but MT doesn’t.
In short, DNS server in ROS is very limited in functionality and if trivial functions are not enough, you should install proper DNS server (e.g. pihole running on a raspberry pi) in your network.
Error message mentioning MAC address makes me think problem might actually involve routing config … an obscure one for sure. But without knowing all the config (pissibly of both routers) and exact network layout it’s a guessing game.
It cannot be a routing problem, because a direct DNS request succeeds. It also precludes any firewall config error.
[gandalf@router.lacinet] > :put [/resolve borika-pc.kavicsnet server=192.168.18.254]
192.168.18.199
[gandalf@router.lacinet] > :put [/resolve borika-pc.kavicsnet]
failure: dns name does not exist
There are many similar sites connected, and only this one is not working as it should
The MAC address message comes from ping, and not resolve.
[gandalf@router.lacinet] /ip/dns/static> /ping borika-pc.kavicsnet
invalid value for argument address:
invalid value of mac-address, mac address required
invalid value for argument ipv6-address
while resolving ip-address: name does not exist
[gandalf@router.lacinet] /ip/dns/static> :put [/resolve borika-pc.kavicsnet]
failure: dns name does not exist
[gandalf@router.lacinet] /ip/dns/static>
Does resolving of borika-pc.kavicsnet work for clients, connected to problematic router’s LAN segment? With router set as DNS server? If yes, what does wireshark trace show, who does recursive queries, client or ROS DNS server?
Is it possible that local router received negative answer from forwarding server for this particular host name and is using cached negative answer which didn’t expire yet (could be it’s using forwarder record TTL for that).
I think it is not possible, because the 192.168.18.254 router has borika-pc.kavicsnet added as a static DNS entry. Just to make sure, I have changed the ttl of all FWD records to 1 minute, but it has no effect.
I think when I switched from ros6 to ros7, the forward DNS didn’t work for me.
Try edit FWD regex appeding “.?$” for matching ending dot in the query, looks like
regexp=“.*.visznet.?$” type=FWD forward-to=192.168.5.254 ttl=1d
I get “dns name does not exist” logged when there’s already cached negative answer. So it could be that there was query for that before you added FWD record, that got cached, and you need to either wait until it times out of flush cache.
For me, it seems to be working with or without an ending dot. This was always that way, even though the regexp does not match names with an ending dot:
If that was the real problem, then there is a conclusion for me - I’ll never leave the default ttl for FWD records, because it makes DNS fragile. An intermittent connection error to the forwarder might make a whole subdomain unavailable. It is not probable, but it is possible and can cause lots of problems.
If you’re using your DNS system only for a few (tens?) devices, then amount of DNS requests won’t be huge and you can safely use TTLs with length in order of a few minutes. Number of DNS queries still won’t DDoS your DNS servers.
AFAIK the ending dot is local thing, it doesn’t go into DNS packets. If you want to make sure that regexp matches only TLD and not something in the middle of hostname, end it with $.
And I don’t think that FWD record’s TTL should affect anything. It’s not real record, only instruction for resolver what server to use. It has TTL probably only because they added it as fake record and all other real records have TTL.
Thanks for Nagyizs and Sob resolving my error in trailing dot problem.
The FWD record TTL is equal the successfully resolved DNS cached name TTL and begin counting down.
You can overwrite this with Cache Max TTL when the value lower than FWD record TTL.
DNS resolve request not forwarded until name record is cached, servicing is performed from the cache until the record expires.
I thought the same. However, the problems went away only after setting ttl=1m on the FWD records, and then waiting one day. I suspect that when a forwarder fails, then the failure is cached with the ttl of the forwarder. E.g. if the FWD record has ttl=1d and the forwarder is not available at the moment, then the NXDOMAIN is cached for a whole day. It is not documented anywhere (or at least I could not find it), but it seems to be working that way.
If the forwarder resolves the name, then it returns the address and its own TTL. E.g. it should not be equal to the TTL of the FWD record, because it has its own TTL. If the forwarder is not available, then NXDOMAIN is cached, and its TTL will be equal to the ttl of the FWD record. This is my experience - I cannot check this, because NXDOMAIN cache entries are not listed under /ip/dns/cache. Can somebody please confirm this?
If the forwarder resolves the name, then it returns the address and its own TTL. E.g. it should not be equal to the TTL of the FWD record, because it has its own TTL.
Its correct, not the FWD TTL but also response TTL will be equal the cached value. I think the mikrotik DNS server sends the response along with the name record TTL.
When i stopped the bind9 and resolve a domain name in terminal, get the error message:
failure: dns server failure
and mikrotik dns cache not changed.
When dns is working (bind9 is runnig) and probe resolve an FQDN which is not exist in domain, bind9 send NXDOMAIN and negative cache TTL i.e. 5 minutes.
This is cached by mikrotik dns cache.
To list NXDOMAIN type entries try in terminal:
/ip/dns/cache/all print where negative
Sometimes help is one:
/ip/dns/cache/ flush
Sob written:
And I don’t think that FWD record’s TTL should affect anything. It’s not real record, only instruction for resolver what server to use. It has TTL probably only because they added it as fake record and all other real records have TTL.
Today it went wrong again, but with a different hostname.
I followed your advice and I found the host in the negative cache:
[gandalf@router.lacinet] /ip/dns> /ip/dns/cache/all print where negative
Flags: N - NEGATIVE
Columns: NAME, TTL
# NAME TTL
0 N _LDAP._TCP 8h8m17s
1 N channel.status.request.url 10h44m51s
2 N local 11h39m53s
3 N mw40.home 21h33m30s
4 N stun.ideasip.com 11m8s
5 N PENZTAR-PC.VISZNET 23h16m39s
6 N wpad.lacinet 23h59m11s
7 N stands-app.lacinet 23h59m11s
The problematic one is penztar-pc.visznet.
I don’t understand, why it is having 23h16m ttl? That record has ttl=1m on the authoritative server:
[gandalf@viszfuvar.visznet] /ip/dns/static> print detail where name~"penztar.*"
Flags: D - dynamic; X - disabled
23 ;;; #DHCP
name="penztar-pc.visznet." address=192.168.5.176 ttl=1m
And the FWD record also has 1m ttl:
[gandalf@router.lacinet] /ip/dns/static> print detail where regexp~".visznet"
Flags: D - dynamic; X - disabled
4 regexp=".*\.visznet" type=FWD forward-to=192.168.5.254 ttl=1m
Where is this 23h coming from??? (I guess its initial value was 1d, because I first experienced the problem about an hour ago.)