VRF and DNS-Server

Hi,

i have the following configuration and my local dns-server is working perfectly as long I do the following:
Switch default route from just a main default to a inter vrf:

\# default into the vrf

add distance=20 dst-address=0.0.0.0/0 gateway=192.168.132.1@UP-VODA-vrf routing-table=main

\# backroute it’s not need i added just to avoid questions

add dst-address=192.168.128.0/20 gateway=192.168.128.3@main routing-table=UP-VODA-vrf

there is no nat involved but after that change the router it self can’t resolve any thing
and if i hit the dns-server it times out.

the dns cache show absolute no activty:

The connected networks have full connectivity only the dns resolver is not working.

Any Idea?

thx in advance

meno

I did see something about VRF & DNS in the features of the 7.21 beta software, maybe its functionality not there yet??

I will give it a try —
Just discovered that my WireGuard interfaces have the same problem. They seams to stop working after i moved the default route pointing in a VRF.

I updated to 7.21beta5, but the DNS in VRF is still not working.

1 Like

What would be the expected result? The vrf option controls where the dns server accepts requests.

In order for outgoing requests to be routed through a vrf, the @vrf notation should be used. As far as I can tell, adding it based on the dhcp client being in a vrf is still work in progress…

1 Like

The accepted result should be that the DNS and WireGuard should work. That’s too simple:

I have a main routing table, and the DNS and WireGuard are not specially configured, so I assume that they are running within the main routing table. And that works as expected as long as the default route looks like that:
DAd+ 0.0.0.0/0 192.168.132.1 main 1
But if I move the 192.168.132.0/24 net into a VRF and then change the route in the main to:
As 0.0.0.0/0 192.168.132.1@UP-VODA-vrf main 1
Then, all routing is working as expected, but the router itself, as well as the DNS server running on it, is unable to resolve anything. And in my case, also WireGuard stops working, which could be related to the fact that my peers are DNS-FQDN and not IPs.
In the not-working DNS state, I see request and response packets in exchange with the outside DNS servers. But the router gets no result, it’s timeouts from internal and also from an internal network hitting port 53.

I tested this with 7.20.4 and 7.21beta7

What you are describing is not new functionality, and should work.

I’d love to see a packet capture and a full route table.

Mostly, with these setups, the problem is that many configs use connection marks to route the response packets, but fail to mark the router’s own packets in the output chain. (Or forget to re-route the responses in prerouting, and using the appropriate rules.) Either that has to happen, or a correct route should be present in the vrf’s routing table for the return packets.

so if I switch on 7.20.4 from:

i stripped the routing tables they containing only a couple more vrf’s and and vlans local.

[admin@mam-hh-gwax3] /ip/vrf> /ip/route/print detail
Flags: D - dynamic; X - disabled, I - inactive, A - active; c - connect, s - static, r - rip, b - bgp, o - ospf, i - is-is, d - dhcp, v - vpn, m - modem, y - bgp-mpls-vpn;
H - hw-offloaded; + - ecmp
0 Xs dst-address=0.0.0.0/0 routing-table=main gateway=100.64.0.1@mam-hh-star-vrf distance=10

1 Is dst-address=0.0.0.0/0 routing-table=main gateway=192.168.132.1@UP-VODA-vrf immediate-gw="" distance=20 scope=30 target-scope=10

DAd dst-address=0.0.0.0/0 routing-table=main gateway=192.168.132.1 immediate-gw=192.168.132.1%vlan132-UP-VODA distance=10 scope=30 target-scope=10
vrf-interface=vlan132-UP-VODA

DAc dst-address=192.168.128.0/24 routing-table=main gateway=vlan128-MAM-HH immediate-gw=vlan128-MAM-HH distance=0 scope=10 target-scope=5
local-address=192.168.128.3%vlan128-MAM-HH

DAc + dst-address=192.168.129.0/24 routing-table=main gateway=vlan129-MAM-HH-DMZ immediate-gw=vlan129-MAM-HH-DMZ distance=0 scope=10 target-scope=5
local-address=192.168.129.3%vlan129-MAM-HH-DMZ

DAc + dst-address=192.168.129.0/24 routing-table=main gateway=vrrp129-MAM-HH-DMZ immediate-gw=vrrp129-MAM-HH-DMZ distance=0 scope=10 target-scope=5
local-address=192.168.129.1%vrrp129-MAM-HH-DMZ

D b dst-address=192.168.129.0/24 routing-table=main gateway=192.168.128.2 immediate-gw=192.168.128.2%vlan128-MAM-HH distance=200 scope=40 target-scope=30

D b dst-address=192.168.132.0/24 routing-table=main gateway=192.168.128.2 immediate-gw=192.168.128.2%vlan128-MAM-HH distance=200 scope=40 target-scope=30

DAc + dst-address=192.168.132.0/24 routing-table=main gateway=vlan132-UP-VODA immediate-gw=vlan132-UP-VODA distance=0 scope=10 target-scope=5
local-address=192.168.132.90%vlan132-UP-VODA

DAc + dst-address=192.168.132.0/24 routing-table=main gateway=vlan132-UP-VODA immediate-gw=vlan132-UP-VODA distance=0 scope=10 target-scope=5
local-address=192.168.132.34%vlan132-UP-VODA

all good then I enable
/ip vrf
0 name="UP-VODA-vrf" interfaces=vlan132-UP-VODA,vrrp132-UP-VODA

then the connectivity is still there and dns stops

[admin@mam-hh-gwax3] /ip/vrf> /ip/route/print detail
Flags: D - dynamic; X - disabled, I - inactive, A - active; c - connect, s - static, r - rip, b - bgp, o - ospf, i - is-is, d - dhcp, v - vpn, m - modem, y - bgp-mpls-vpn;
H - hw-offloaded; + - ecmp
0 Xs dst-address=0.0.0.0/0 routing-table=main gateway=100.64.0.1@mam-hh-star-vrf distance=10

1 As dst-address=0.0.0.0/0 routing-table=main gateway=192.168.132.1@UP-VODA-vrf immediate-gw=192.168.132.1%vlan132-UP-VODA distance=20 scope=30 target-scope=10

DAc dst-address=192.168.128.0/24 routing-table=main gateway=vlan128-MAM-HH immediate-gw=vlan128-MAM-HH distance=0 scope=10 target-scope=5
local-address=192.168.128.3%vlan128-MAM-HH

D b dst-address=192.168.128.0/24 routing-table=main gateway=192.168.128.2 immediate-gw=192.168.128.2%vlan128-MAM-HH distance=200 scope=40 target-scope=30

DAc + dst-address=192.168.129.0/24 routing-table=main gateway=vlan129-MAM-HH-DMZ immediate-gw=vlan129-MAM-HH-DMZ distance=0 scope=10 target-scope=5
local-address=192.168.129.3%vlan129-MAM-HH-DMZ

DAc + dst-address=192.168.129.0/24 routing-table=main gateway=vrrp129-MAM-HH-DMZ immediate-gw=vrrp129-MAM-HH-DMZ distance=0 scope=10 target-scope=5
local-address=192.168.129.1%vrrp129-MAM-HH-DMZ

D b dst-address=192.168.129.0/24 routing-table=main gateway=192.168.128.2 immediate-gw=192.168.128.2%vlan128-MAM-HH distance=200 scope=40 target-scope=30

DAb dst-address=192.168.132.0/24 routing-table=main gateway=192.168.128.2 immediate-gw=192.168.128.2%vlan128-MAM-HH distance=200 scope=40 target-scope=30

DAd dst-address=0.0.0.0/0 routing-table=UP-VODA-vrf gateway=192.168.132.1@UP-VODA-vrf immediate-gw=192.168.132.1%vlan132-UP-VODA distance=10 scope=30 target-scope=10
vrf-interface=vlan132-UP-VODA

DAc + dst-address=192.168.132.0/24 routing-table=UP-VODA-vrf gateway=vlan132-UP-VODA@UP-VODA-vrf immediate-gw=vlan132-UP-VODA distance=0 scope=10 target-scope=5
local-address=192.168.132.90%vlan132-UP-VODA@UP-VODA-vrf

DAc + dst-address=192.168.132.0/24 routing-table=UP-VODA-vrf gateway=vlan132-UP-VODA@UP-VODA-vrf immediate-gw=vlan132-UP-VODA distance=0 scope=10 target-scope=5
local-address=192.168.132.34%vlan132-UP-VODA@UP-VODA-vrf

there are no filter rules no nat, no filter, no mangle…..

this is the package trace

[admin@mam-hh-gwax3] /ip/vrf> /tool/sniffer/quick interface=vlan132-UP-VODA port 53
Columns: INTERFACE, TIME, NUM, DIR, SRC-MAC, DST-MAC, SRC-ADDRESS, DST-ADDRESS, PROTOCOL, SIZE, CPU
INTERFACE TIME NUM DIR SRC-MAC DST-MAC SRC-ADDRESS DST-ADDRESS PROTOCOL SIZE CPU
vlan132-UP-VODA 5.597 1 -> 04:F4:1C:1D:33:17 DC:15:C8:2C:FD:95 192.168.129.88:51574 1.1.1.1:53 (dns) ip:udp 179 0
vlan132-UP-VODA 6.908 2 -> 04:F4:1C:1D:33:17 DC:15:C8:2C:FD:95 192.168.129.88:52145 1.1.1.1:53 (dns) ip:udp 85 1
vlan132-UP-VODA 15.302 3 -> 04:F4:1C:1D:33:17 DC:15:C8:2C:FD:95 192.168.129.88:51359 8.8.8.8:53 (dns) ip:udp 179 0
vlan132-UP-VODA 18.24 4 -> 04:F4:1C:1D:33:17 DC:15:C8:2C:FD:95 192.168.129.88:60403 1.1.1.1:53 (dns) ip:udp 84 2

I’m not totally certain without immersing myself in your setup fully, but the source address seems wrong. You can investigate this by looking at the /routing part of your config. Maybe you will have to set pref-src manually.

(This can also be solved with outgoing srcnat, but that’s not the totally correct solution.)

about the source address – that’s my fault — here is the hopefully right trace:

/resolve www.google.com,
times out, and this is the network trace

[admin@mam-hh-gwax3] > /tool/sniffer/quick interface=vlan132-UP-VODA port 53
Columns: INTERFACE, TIME, NUM, DIR, SRC-MAC, DST-MAC, SRC-ADDRESS, DST-ADDRESS, PROTOCOL, SIZE, CPU
INTERFACE TIME NUM DIR SRC-MAC DST-MAC SRC-ADDRESS DST-ADDRESS PROTOCOL SIZE CPU
vlan132-UP-VODA 8.537 71 <- DC:15:C8:2C:FD:95 04:F4:1C:1D:33:17 8.8.4.4:53 (dns) 192.168.132.90:58480 ip:udp 90 1
vlan132-UP-VODA 9.232 72 -> 04:F4:1C:1D:33:17 DC:15:C8:2C:FD:95 192.168.132.90:45160 8.8.4.4:53 (dns) ip:udp 92 1
vlan132-UP-VODA 9.259 73 <- DC:15:C8:2C:FD:95 04:F4:1C:1D:33:17 8.8.4.4:53 (dns) 192.168.132.90:45160 ip:udp 108 0
vlan132-UP-VODA 9.442 74 -> 04:F4:1C:1D:33:17 DC:15:C8:2C:FD:95 192.168.132.90:60513 8.8.4.4:53 (dns) ip:udp 92 1
vlan132-UP-VODA 9.459 75 <- DC:15:C8:2C:FD:95 04:F4:1C:1D:33:17 8.8.4.4:53 (dns) 192.168.132.90:60513 ip:udp 120 2
vlan132-UP-VODA 9.519 76 -> 04:F4:1C:1D:33:17 DC:15:C8:2C:FD:95 192.168.132.90:38058 8.8.4.4:53 (dns) ip:udp 92 1
vlan132-UP-VODA 9.535 77 <- DC:15:C8:2C:FD:95 04:F4:1C:1D:33:17 8.8.4.4:53 (dns) 192.168.132.90:38058 ip:udp 120 0
vlan132-UP-VODA 9.8 78 -> 04:F4:1C:1D:33:17 DC:15:C8:2C:FD:95 192.168.132.90:45954 8.8.4.4:53 (dns) ip:udp 92 1

in routing is only:
/routing bgp instance
add as=4200000003 disabled=no name=mam-hh-bb router-id=192.168.128.3 routing-table=main vrf=main
/routing bgp connection
add afi=ip,ipv6 as=4200000003 disabled=no instance=mam-hh-bb local.role=ibgp-rr name=mam-hh-test output.filter-chain=bgp-out .redistribute=connected
remote.address=192.168.135.9 routing-table=main vrf=main
add afi=ip,ipv6 as=4200000003 disabled=no instance=mam-hh-bb local.role=ibgp-rr name=mam-hh-gwx86 output.filter-chain=bgp-out .redistribute=connected
remote.address=192.168.128.2 routing-table=main vrf=main
add afi=ip,ipv6 as=4200000003 disabled=no instance=mam-hh-bb local.role=ibgp-rr name=gw-to-earth-ng output.filter-chain=bgp-out .redistribute=connected
remote.address=192.168.129.88 routing-table=main vrf=main
/routing filter rule
add chain=bgp-out rule=accept
add chain=bgp-in rule=accept

But I switched it off and that makes not difference

here switch results:
[admin@mam-hh-gwax3] /ip/vrf> enable 0
[admin@mam-hh-gwax3] /ip/vrf> /ping 1.1.1.1
SEQ HOST SIZE TTL TIME STATUS
0 1.1.1.1 56 56 21ms690us
sent=1 received=1 packet-loss=0% min-rtt=21ms690us avg-rtt=21ms690us max-rtt=21ms690us

[admin@mam-hh-gwax3] /ip/vrf> disable 0
[admin@mam-hh-gwax3] /ip/vrf> enable 0
[admin@mam-hh-gwax3] /ip/vrf> /ping 1.1.1.1
SEQ HOST SIZE TTL TIME STATUS
0 1.1.1.1 56 56 21ms185us
sent=1 received=1 packet-loss=0% min-rtt=21ms185us avg-rtt=21ms185us max-rtt=21ms185us

[admin@mam-hh-gwax3] /ip/vrf> /ping www.google.com
invalid value for argument address:
invalid value of mac-address, mac address required
invalid value for argument ipv6-address
interrupted
[admin@mam-hh-gwax3] /ip/vrf[dis]> disable 0
[admin@mam-hh-gwax3] /ip/vrf> /ping www.google.com
SEQ HOST SIZE TTL TIME STATUS
0 172.217.16.68 56 117 18ms368us
sent=1 received=1 packet-loss=0% min-rtt=18ms368us avg-rtt=18ms368us max-rtt=18ms368us

VRF keeps changing they are up to beta7 now (not yet released)
https://mikrotik.com/download/changelogs

*) dns - added VRF support for ":resolve" command;
*) dns - added VRF support for DNS servers;

Hi,

to test if it’s works, I need to put a production router on test —
Do you think it’s worth the hassle?

thx

There now is a new bug: when you don’t have any VRF, the IP→DNS window in some cases shows “VRF: unknown” and you cannot save it, but there is no valid selection (like “main”) either… another beta required. I have one CHR which has this issue, while another one does not. The CHR with the issue has probably had VRF but it has been removed, I am not sure.

But in fact the config should allow multiple IP→DNS instances, for each VRF.

About your idea for having different DNS instances per VRF, I want that too.
In my case, I have three VRFs that are used to change my location, such as one that is VPN’ed to the US. Currently, I need to set up an outside DNS server via DHCP so I don’t have any DNS caching.
That's why I would be cool to have for each VRF also a bound DNS instance.

1 Like

As deeper i dive into the dhcp on mikrotik as more in complete it gets just found that:

MikroTik's /tool dns-update is hardcoded to use port 53 only and doesn't support custom ports.

After giving up on Mikrotik, DNS, DHCP, and VRFs, I built that as a K8s helm thingy, which switches via VLANs into the right networks and provides DNS/DHCP. It currently misses the DHCP IPv6, but that’s will come sometime -:slight_smile:
might be interesting for you: