Community discussions

MikroTik App
 
elmemis
just joined
Topic Author
Posts: 8
Joined: Sat Oct 01, 2016 6:49 am

[ERROR] Dual stack & NAT - DNS queries

Wed May 19, 2021 6:39 pm

Hi,

Some time ago (since "glibc 2.10"), in Linux the IPv4 & IPv6 parallel DNS lookup functionality was added. This functionality generates two requests in the same sockets, one for A query and the other for AAAA query. When our devices are behind Mikrotik with IPv6 and NAT IPv4 in the same "interface" and execute a query to an external DNS server, the router discards the second reply from the DNS server, and our devices still waiting for a second reply for 5 seconds.

The workaround in linux is add this options in resolv.conf, but not is a good solution or configure programs to only use IPv4 (example, curl -4).
options single-request-reopen

How to reproduce:
1- Add IPv4 and IPv6 in your router.
2- Configure local IPv4 and IPv6 (with o without advertise) in LAN interface.
3- Configure NAT for IPv4 with masquerade or src-nat.
4- Add server in LAN and configure external IPv4, IPv6 and external DNS (1.1.1.1, 8.8.8.8, or other).
5- Capture traffic in WAN interface for external DNS server and port 53.
6- Execute `curl -o /dev/null www.google.com -v`. 
7- In the traffic capture, you will see that you receive both responses, but only the first one reaches the LAN device.

curl freezes (waiting) for 5 seconds to get the second reply from the DNS server because Mikrotik discards the reply and after 5 seconds curl generates a new socket and executes the second (AAAA) query again.

Oficial info about options in resolv.conf for mitigate this issue (https://man7.org/linux/man-pages/man5/r ... onf.5.html).
single-request (since glibc 2.10)
Sets RES_SNGLKUP in _res.options. By default,
glibc performs IPv4 and IPv6 lookups in parallel
since version 2.9. Some appliance DNS servers
cannot handle these queries properly and make the
requests time out. This option disables the
behavior and makes glibc perform the IPv6 and IPv4
requests sequentially (at the cost of some slowdown
of the resolving process).

single-request-reopen (since glibc 2.9)
Sets RES_SNGLKUPREOP in _res.options. The resolver
uses the same socket for the A and AAAA requests.
Some hardware mistakenly sends back only one reply.
When that happens the client system will sit and
wait for the second reply. Turning this option on
changes this behavior so that if two requests from
the same port are not handled correctly it will
close the socket and open a new one before sending
the second request.
This issue only present when using NAT for IPv4, if you use public IPv4 behind in devices behind Mikrotik, the issue is not present.

Why Mikrotik discard second reply from external DNS server?

Who is online

Users browsing this forum: adrianmartin16, almdandi, marekm, pants6000 and 61 guests