Domain name resolution fails

, ,

My YunoHost server

Hardware: OpenVZ VPS (vps-hdd-4) from http://dyjix.eu running debian 9
YunoHost version: 3.6.4.6
I have access to my server : Through SSH and through the webadmin
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : no

Description of my issue

Whenever the yunohost firewall is launched my server fails to resolve domain names.
Here is a quick example:

With the firewall on:
ping 1.1.1.1
Returns:

PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=6.80 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=6.83 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=6.78 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=56 time=6.77 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=56 time=6.78 ms

ping google.fr
Returns:

ping: google.fr: Temporary failure in name resolution
root@jaekr:~#

After yunohost firewall stop:
ping 1.1.1.1
Returns:

PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=6.84 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=6.79 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=6.78 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=56 time=6.78 ms

ping google.fr
Returns:

PING google.fr (216.58.206.227) 56(84) bytes of data.
64 bytes from par10s34-in-f3.1e100.net (216.58.206.227): icmp_seq=1 ttl=47 time=16.6 ms
64 bytes from par10s34-in-f3.1e100.net (216.58.206.227): icmp_seq=2 ttl=47 time=16.7 ms
64 bytes from par10s34-in-f3.1e100.net (216.58.206.227): icmp_seq=3 ttl=47 time=16.7 ms
64 bytes from par10s34-in-f3.1e100.net (216.58.206.227): icmp_seq=4 ttl=47 time=16.6 ms
64 bytes from par10s34-in-f3.1e100.net (216.58.206.227): icmp_seq=5 ttl=47 time=16.7 ms

I tried to disable and stop the yunohost-firewall service through systemD without success.
I also tried to set my DNS servers on 1.1.1.1 without success as well.

This problem gets really annoying especially when you need to install synapse or just update the system.

I hope someone has a fix.
Thank you in advance.

Hmmmokay, can you check what’s the content of /etc/resolv.conf using

cat /etc/resolv.conf

(should find 127.0.0.1 usually)

Do you happen to have a VPN configured or anything that might mess with the network ?

cat /etc/resolv.conf
Returns:

root@jaekr:~# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
root@jaekr:~#

I don’t have a VPN or anything.

Hmmokay and can you check dnsmasq is running using systemctl status dnsmasq ?

Here:

root@jaekr:~# systemctl status dnsmasq
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
   Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2019-10-01 14:36:49 CEST; 34min ago
 Main PID: 24079 (dnsmasq)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/dnsmasq.service
           └─24079 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --local-service --trust-anchor=.,20326,8,2,e06d44b80b8f1d39a95c0b0d7c65d08458e8804

Oct 01 14:36:49 jaekr.dev dnsmasq[24079]: using nameserver 80.67.188.188#53
Oct 01 14:36:49 jaekr.dev dnsmasq[24079]: using nameserver 85.214.20.141#53
Oct 01 14:36:49 jaekr.dev dnsmasq[24079]: using nameserver 91.239.100.100#53
Oct 01 14:36:49 jaekr.dev dnsmasq[24079]: using nameserver 2a0c:e300::101#53
Oct 01 14:36:49 jaekr.dev dnsmasq[24079]: using nameserver 2001:910:800::12#53
Oct 01 14:36:49 jaekr.dev dnsmasq[24079]: using nameserver 80.67.169.12#53
Oct 01 14:36:49 jaekr.dev dnsmasq[24079]: using nameserver 2001:67c:28a4::#53
Oct 01 14:36:49 jaekr.dev dnsmasq[24079]: using nameserver 89.234.141.66#53
Oct 01 14:36:49 jaekr.dev dnsmasq[24079]: read /etc/hosts - 5 addresses
Oct 01 14:36:49 jaekr.dev systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server.
root@jaekr:~#

Annnnd with firewall enabled/started, can you share the output of iptables-save ?

Here:

root@jaekr:~# iptables-save
# Generated by iptables-save v1.6.0 on Tue Oct  1 15:15:12 2019
*filter
:INPUT ACCEPT [74074:55877807]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [71659:41130520]
COMMIT
# Completed on Tue Oct  1 15:15:12 2019
# Generated by iptables-save v1.6.0 on Tue Oct  1 15:15:12 2019
*mangle
:PREROUTING ACCEPT [325910:802891089]
:INPUT ACCEPT [325910:802891089]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [308795:138549910]
:POSTROUTING ACCEPT [308795:138549910]
COMMIT
# Completed on Tue Oct  1 15:15:12 2019
# Generated by iptables-save v1.6.0 on Tue Oct  1 15:15:12 2019
*raw
:PREROUTING ACCEPT [325910:802891089]
:OUTPUT ACCEPT [308795:138549910]
COMMIT
# Completed on Tue Oct  1 15:15:12 2019
root@jaekr:~#

Here is the log 10 minutes later and a yunohost firewall reload:

# Generated by iptables-save v1.6.0 on Tue Oct  1 15:26:36 2019
*filter
:INPUT DROP [423:71234]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2031:736641]
:f2b-bitwarden - [0:0]
:f2b-dovecot - [0:0]
:f2b-nginx-http-auth - [0:0]
:f2b-pam-generic - [0:0]
:f2b-postfix - [0:0]
:f2b-postfix-sasl - [0:0]
:f2b-recidive - [0:0]
:f2b-sshd - [0:0]
:f2b-sshd-ddos - [0:0]
:f2b-yunohost - [0:0]
-A INPUT -p tcp -j f2b-pam-generic
-A INPUT -p tcp -m multiport --dports 80,443 -j f2b-yunohost
-A INPUT -p tcp -m multiport --dports 80,443 -j f2b-bitwarden
-A INPUT -p tcp -j f2b-recidive
-A INPUT -p tcp -m multiport --dports 25,587,143,993,110,995 -j f2b-postfix-sasl
-A INPUT -p tcp -m multiport --dports 110,995,143,993,587,4190 -j f2b-dovecot
-A INPUT -p tcp -m multiport --dports 25,587 -j f2b-postfix
-A INPUT -p tcp -m multiport --dports 80,443 -j f2b-nginx-http-auth
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd-ddos
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 587 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 993 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5222 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5269 -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -p udp -m udp --dport 5353 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A f2b-bitwarden -j RETURN
-A f2b-dovecot -j RETURN
-A f2b-nginx-http-auth -j RETURN
-A f2b-pam-generic -s 222.186.180.19/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-pam-generic -j RETURN
-A f2b-postfix -j RETURN
-A f2b-postfix-sasl -j RETURN
-A f2b-recidive -s 52.80.96.153/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-recidive -s 222.98.37.25/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-recidive -s 217.182.253.230/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-recidive -s 200.199.6.204/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-recidive -s 185.127.27.46/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-recidive -s 183.88.219.84/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-recidive -s 142.93.241.93/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-recidive -s 139.155.1.18/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-recidive -s 132.232.39.15/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-recidive -s 123.207.16.33/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-recidive -s 106.13.189.240/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-recidive -s 106.12.148.155/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-recidive -j RETURN
-A f2b-sshd -s 222.186.180.19/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 222.186.173.201/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 217.182.253.230/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 183.88.219.84/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 172.94.53.142/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 139.155.1.18/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -s 136.34.218.11/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -j RETURN
-A f2b-sshd-ddos -j RETURN
-A f2b-yunohost -j RETURN
COMMIT
# Completed on Tue Oct  1 15:26:36 2019
# Generated by iptables-save v1.6.0 on Tue Oct  1 15:26:36 2019
*mangle
:PREROUTING ACCEPT [340747:814380592]
:INPUT ACCEPT [340747:814380592]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [322691:153133324]
:POSTROUTING ACCEPT [322691:153133324]
COMMIT
# Completed on Tue Oct  1 15:26:36 2019
# Generated by iptables-save v1.6.0 on Tue Oct  1 15:26:36 2019
*raw
:PREROUTING ACCEPT [340747:814380592]
:OUTPUT ACCEPT [322691:153133324]
COMMIT
# Completed on Tue Oct  1 15:26:36 2019

Hmmm okay, again moar test (sorry) :

with the regular DNS resolution broken (as you did earlier when ping google.fr doesn’t work but ping 8.8.8.8 does work) are you able to

dig +short google.fr @8.8.8.8

and

dig +short google.fr @89.234.141.66

(so using explicit DNS resolvers)

Don’t worry.

root@jaekr:~# dig +short google.fr @8.8.8.8
;; connection timed out; no servers could be reached
root@jaekr:~#
root@jaekr:~# dig +short google.fr @89.234.141.66
;; connection timed out; no servers could be reached
root@jaekr:~#

Watching this one! I had a similar issue after a postinstall on Hetzner VPS and tracked it down to the “enable upnp” code in the post install. After some chat on IRC, it doesn’t appear to be related but my firewall was also doing the same thing as here.

Do anyone knows how to just remove the firewall?
It will (I think) fix my problem.

On which kernel are you ?

uname -a

What’s the content of /etc/resolv.dnsmasq.conf ?

cat /etc/resolv.dnsmasq.conf

You should check the ip of your DNS resolver are not listed in the iptables fail2ban rules.

YunoHost restarts the firewall on some operations , so you can’t disable it i think (unless by creating a post hook on it). But if you disable your firewall you will be under a lot of attacks, i am not sure it’s really reasonable, if you choose to do that you should check all admin and user password are very good (like passphrase instead of password)!

I think you should find the iptables rules that create the issue, and fix it by creating a specific hook. We can help you to do that.

An other way very hackish to stop the firewall or manage it manually could be to modify /etc/init.d/yunohost-firewall to replace call of yunohost firewall reload by /bin/true …

The current version is:

Linux jaekr.dev 4.9.0 #1 SMP Wed May 15 09:45:34 MSK 2019 x86_64 GNU/Linux

And the DNSMasQ config is:

nameserver 2a0c:e300::100
nameserver 2001:1608:10:25::9249:d69b
nameserver 2a00:5884:8218::1
nameserver 2a00:5881:8100:1000::3
nameserver 80.67.169.12
nameserver 2001:910:800::12
nameserver 84.200.69.80
nameserver 195.160.173.53
nameserver 85.214.20.141
nameserver 80.67.169.40
nameserver 2001:67c:28a4::
nameserver 2a01:3a0:53:53::
nameserver 194.150.168.168
nameserver 2001:910:800::40
nameserver 84.200.70.40
nameserver 185.233.100.101
nameserver 2a0c:e300::101
nameserver 2001:1608:10:25::1c04:b12f
nameserver 185.233.100.100
nameserver 89.234.141.66
nameserver 80.67.188.188
nameserver 2001:913::8
nameserver 80.67.190.200
nameserver 91.239.100.100
nameserver 89.233.43.71
nameserver 2001:4ce8::53

Yes, it does it when I try to install synapse but because of this, synapse can’t be installed.

Histoire d’éliminer toutes les règles fail2ban essaie d’activer le parefeu et de désactiver fail2ban et de voir si ça résout les noms de domaine.

Fail2Ban ok; Firewall off:

PING ftp.debian.org (130.89.148.12) 56(84) bytes of data.
64 bytes from klecker-ftp.debian.org (130.89.148.12): icmp_seq=1 ttl=50 time=21.4 ms
64 bytes from klecker-ftp.debian.org (130.89.148.12): icmp_seq=2 ttl=50 time=21.3 ms
64 bytes from klecker-ftp.debian.org (130.89.148.12): icmp_seq=3 ttl=50 time=21.3 ms

Fail2ban ok; Firewall ok:

ping: ftp.debian.org: Temporary failure in name resolution

Fail2ban off; Firewall ok:

ping: ftp.debian.org: Temporary failure in name resolution

All the ping requests were done to ftp.debian.org and fail2ban has been stopped with systemctl stop fail2ban and confirmed stopped with systemctl status fail2ban:

● fail2ban.service - Fail2Ban Service
   Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Thu 2019-10-03 17:23:42 CEST; 1min 58s ago
     Docs: man:fail2ban(1)
  Process: 8777 ExecStop=/usr/bin/fail2ban-client stop (code=exited, status=0/SUCCESS)
  Process: 5277 ExecReload=/usr/bin/fail2ban-client reload (code=exited, status=0/SUCCESS)
 Main PID: 10105 (code=killed, signal=TERM)

Oct 03 10:03:08 jaekr.dev systemd[1]: Reloaded Fail2Ban Service.
Oct 03 10:05:55 jaekr.dev systemd[1]: Reloading Fail2Ban Service.
Oct 03 10:06:50 jaekr.dev systemd[1]: Reloaded Fail2Ban Service.
Oct 03 10:08:52 jaekr.dev systemd[1]: Reloading Fail2Ban Service.
Oct 03 10:09:25 jaekr.dev systemd[1]: Reloaded Fail2Ban Service.
Oct 03 17:21:11 jaekr.dev systemd[1]: Reloading Fail2Ban Service.
Oct 03 17:22:04 jaekr.dev systemd[1]: Reloaded Fail2Ban Service.
Oct 03 17:23:02 jaekr.dev systemd[1]: Stopping Fail2Ban Service...
Oct 03 17:23:42 jaekr.dev fail2ban-client[8777]: Shutdown successful
Oct 03 17:23:42 jaekr.dev systemd[1]: Stopped Fail2Ban Service.

P.S, I know how to speak french but I’ll keep this in english so someone with the same problem will be able to understand how to fix it (if we find a way).

Sorry it’s because i do a lot of things in the same time: some in french and others in english…

So may be try to disable your firewall and then:

tcpdump -i eth0 udp port 53 -vv -X

Don’t forget to change eth0 by your network interface (you can get it with /sbin/ifconfig command)

On an other console try to make some dns resolve operations:

dig A test.com

Did you see some UDP packet going though eth0 when you run the command dig ?
And if you rerun the firewall ?

For the moment i don’t understand which iptables rules could block your dns it’s really strange for me.

Other idea: Have you upnp enable on your firewall, if yes disable it.

Here is the TCPDump output:

tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
17:47:31.422518 IP (tos 0x0, ttl 64, id 33974, offset 0, flags [none], proto UDP (17), length 65)
    localhost.41840 > localhost.domain: [bad udp cksum 0xfe40 -> 0x761c!] 33772+ [1au] A? jaekr.me. ar: . OPT UDPsize=4096 (37)
        0x0000:  4500 0041 84b6 0000 4011 f7f3 7f00 0001  E..A....@.......
        0x0010:  7f00 0001 a370 0035 002d fe40 83ec 0120  .....p.5.-.@....
        0x0020:  0001 0000 0000 0001 056a 6165 6b72 026d  .........jaekr.m
        0x0030:  6500 0001 0001 0000 2910 0000 0000 0000  e.......).......
        0x0040:  00                                       .
17:47:36.422424 IP (tos 0x0, ttl 64, id 35974, offset 0, flags [none], proto UDP (17), length 65)
    localhost.41840 > localhost.domain: [bad udp cksum 0xfe40 -> 0x761c!] 33772+ [1au] A? jaekr.me. ar: . OPT UDPsize=4096 (37)
        0x0000:  4500 0041 8c86 0000 4011 f023 7f00 0001  E..A....@..#....
        0x0010:  7f00 0001 a370 0035 002d fe40 83ec 0120  .....p.5.-.@....
        0x0020:  0001 0000 0000 0001 056a 6165 6b72 026d  .........jaekr.m
        0x0030:  6500 0001 0001 0000 2910 0000 0000 0000  e.......).......
        0x0040:  00                                       .
17:47:41.422500 IP (tos 0x0, ttl 64, id 37224, offset 0, flags [none], proto UDP (17), length 65)
    localhost.41840 > localhost.domain: [bad udp cksum 0xfe40 -> 0x761c!] 33772+ [1au] A? jaekr.me. ar: . OPT UDPsize=4096 (37)
        0x0000:  4500 0041 9168 0000 4011 eb41 7f00 0001  E..A.h..@..A....
        0x0010:  7f00 0001 a370 0035 002d fe40 83ec 0120  .....p.5.-.@....
        0x0020:  0001 0000 0000 0001 056a 6165 6b72 026d  .........jaekr.m
        0x0030:  6500 0001 0001 0000 2910 0000 0000 0000  e.......).......
        0x0040:  00                                       .

Here is the dig output:

; <<>> DiG 9.10.3-P4-Debian <<>> A jaekr.me
;; global options: +cmd
;; connection timed out; no servers could be reached

How can I disable Upnp for sure? I think I disabled it in somewhere but I’m not sure.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.