PTR4 Record says Not Set

[joseph]

@skeats said in PTR4 Record says Not Set:

host -t PTR <IP address> 127.0.0.1 and it failed with:

host -t PTR <IP address> 127.0.0.150 is the correct way to test after Cloudron 8. Unbound has moved to 127.0.0.150 and there is nothing at 127.0.0.1 anymore

[skeats]

I did the check with 127.0.0.150 and got the following error:
Using domain server:
Name: 127.0.0.150
Address: 127.0.0.150#53
Aliases:
Host <IP Address>.in-addr.arpa not found: 2(SERVFAIL)

[skeats]

@james I know about that document for PTR Records, but I called my ISP, since my server is self hosted, and they confirmed that the record is set and is showing correctly. They said since on MXtoolbox, that it shows properly, the issue is with Cloudron. This is why I put in the ticket. What is going on with Unbound to not recognize the PTR record from my ISP.

[skeats]

@joseph I also noticed that the unbound is stuck in restarting status and will not fully start. Here are the logs for the last 2 minutes:

May 22 13:52:29 cloudron systemd[1]: unbound.service: Deactivated successfully.
May 22 13:52:29 cloudron systemd[1]: Stopped unbound.service - Unbound DNS Resolver.
May 22 13:52:29 cloudron systemd[1]: unbound.service: Consumed 4.835s CPU time, 9.9M memory peak, 0B memory swap peak.
May 22 13:52:29 cloudron systemd[1]: Starting unbound.service - Unbound DNS Resolver...
May 22 13:52:29 cloudron unbound[569109]: [569109:0] notice: init module 0: subnetcache
May 22 13:52:29 cloudron unbound[569109]: [569109:0] notice: init module 1: validator
May 22 13:52:29 cloudron unbound[569109]: [569109:0] notice: init module 2: iterator
May 22 13:52:29 cloudron unbound[569109]: [569109:0] info: start of service (unbound 1.19.2).
May 22 13:52:29 cloudron systemd[1]: Started unbound.service - Unbound DNS Resolver.
May 22 13:52:29 29+00:00 cloudron unbound[569109]: [569109:0] info: service stopped (unbound 1.19.2).
May 22 13:52:29 cloudron systemd[1]: Stopping unbound.service - Unbound DNS Resolver...
May 22 13:52:29 cloudron unbound[569109]: [569109:0] info: server stats for thread 0: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting
May 22 13:52:29 cloudron unbound[569109]: [569109:0] info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0
May 22 13:52:29 cloudron systemd[1]: unbound.service: Deactivated successfully.
May 22 13:52:29 cloudron systemd[1]: Stopped unbound.service - Unbound DNS Resolver.
May 22 13:52:29 cloudron systemd[1]: Starting unbound.service - Unbound DNS Resolver...
May 22 13:52:29 cloudron unbound[569124]: [569124:0] notice: init module 0: subnetcache
May 22 13:52:29 cloudron unbound[569124]: [569124:0] notice: init module 1: validator
May 22 13:52:29 cloudron unbound[569124]: [569124:0] notice: init module 2: iterator
May 22 13:52:30 cloudron systemd[1]: Started unbound.service - Unbound DNS Resolver.
May 22 13:52:30 cloudron unbound[569124]: [569124:0] info: start of service (unbound 1.19.2).
May 22 13:52:30 cloudron unbound[569124]: [569124:0] info: service stopped (unbound 1.19.2).
May 22 13:52:30 cloudron systemd[1]: Stopping unbound.service - Unbound DNS Resolver...
May 22 13:52:30 cloudron unbound[569124]: [569124:0] info: server stats for thread 0: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting
May 22 13:52:30 cloudron unbound[569124]: [569124:0] info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0
May 22 13:52:30 cloudron systemd[1]: unbound.service: Deactivated successfully.
May 22 13:52:30 cloudron systemd[1]: Stopped unbound.service - Unbound DNS Resolver.
May 22 13:52:30 cloudron systemd[1]: Starting unbound.service - Unbound DNS Resolver...
May 22 13:52:30 cloudron unbound[569147]: [569147:0] notice: init module 0: subnetcache
May 22 13:52:30 cloudron unbound[569147]: [569147:0] notice: init module 1: validator
May 22 13:52:30 cloudron unbound[569147]: [569147:0] notice: init module 2: iterator
May 22 13:52:30 cloudron unbound[569147]: [569147:0] info: start of service (unbound 1.19.2).
May 22 13:52:30 cloudron systemd[1]: Started unbound.service - Unbound DNS Resolver.
May 22 13:52:30 cloudron unbound[569147]: [569147:0] info: service stopped (unbound 1.19.2).
May 22 13:52:30 cloudron systemd[1]: Stopping unbound.service - Unbound DNS Resolver...
May 22 13:52:30 cloudron unbound[569147]: [569147:0] info: server stats for thread 0: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting
May 22 13:52:30 cloudron unbound[569147]: [569147:0] info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0
May 22 13:52:30 cloudron systemd[1]: unbound.service: Deactivated successfully.
May 22 13:52:30 cloudron systemd[1]: Stopped unbound.service - Unbound DNS Resolver.
May 22 13:52:30 cloudron systemd[1]: Starting unbound.service - Unbound DNS Resolver...
May 22 13:52:30 cloudron unbound[569164]: [569164:0] notice: init module 0: subnetcache
May 22 13:52:30 cloudron unbound[569164]: [569164:0] notice: init module 1: validator
May 22 13:52:30 cloudron unbound[569164]: [569164:0] notice: init module 2: iterator
May 22 13:52:30 cloudron unbound[569164]: [569164:0] info: start of service (unbound 1.19.2).
May 22 13:52:30 cloudron systemd[1]: Started unbound.service - Unbound DNS Resolver.

[james]

@skeats the not fully starting unbound service is the biggest culprit here.
The config for unbound is located in /etc/unbound/unbound.conf.d/cloudron-network.conf

# Unbound is used primarily for RBL queries (host 2.0.0.127.zen.spamhaus.org)
# We cannot use dnsmasq because it is not a recursive resolver and defaults to the value in the interfaces file (which is Google DNS!)

server:
        port: 53
        interface: 127.0.0.150
        interface: 172.18.0.1
        ip-freebind: yes
        do-ip6: yes
        access-control: 127.0.0.1 allow
        access-control: 172.18.0.1/16 allow
        cache-max-negative-ttl: 30
        cache-max-ttl: 300
        # enable below for logging to journalctl -u unbound
        # verbosity: 5
        # log-queries: yes

# https://github.com/NLnetLabs/unbound/issues/806
remote-control:
    control-enable: no

@skeats can you please check if port 53 is already in use?

Start with netstat - output from one of my systems:

netstat -tulpn | grep -i -E '.*:53\s+.*$'
tcp        0      0 127.0.0.150:53          0.0.0.0:*               LISTEN      835/unbound
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      656/systemd-resolve
tcp        0      0 127.0.0.54:53           0.0.0.0:*               LISTEN      656/systemd-resolve
tcp        0      0 172.18.0.1:53           0.0.0.0:*               LISTEN      835/unbound
tcp        0      0 188.245.165.100:53      0.0.0.0:*               LISTEN      1070/dockerd
udp        0      0 188.245.165.100:53      0.0.0.0:*                           1070/dockerd
udp        0      0 172.18.0.1:53           0.0.0.0:*                           835/unbound
udp        0      0 127.0.0.150:53          0.0.0.0:*                           835/unbound
udp        0      0 127.0.0.54:53           0.0.0.0:*                           656/systemd-resolve
udp        0      0 127.0.0.53:53           0.0.0.0:*                           656/systemd-resolve

Does yours look different? Is something else using port 53?

Also the lsof -i :53 command can give some insight:

lsof -i :53
COMMAND    PID            USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
systemd-r  656 systemd-resolve   14u  IPv4   8685      0t0  UDP _localdnsstub:domain
systemd-r  656 systemd-resolve   15u  IPv4   8686      0t0  TCP _localdnsstub:domain (LISTEN)
systemd-r  656 systemd-resolve   16u  IPv4   8687      0t0  UDP _localdnsproxy:domain
systemd-r  656 systemd-resolve   17u  IPv4   8688      0t0  TCP _localdnsproxy:domain (LISTEN)
unbound    835         unbound    3u  IPv4   9391      0t0  UDP localhost:domain
unbound    835         unbound    4u  IPv4   9392      0t0  TCP localhost:domain (LISTEN)
unbound    835         unbound    5u  IPv4   9393      0t0  UDP my-DOMAIN-TLD:domain
unbound    835         unbound    6u  IPv4   9394      0t0  TCP my-DOMAIN-TLD:domain (LISTEN)
dockerd   1070            root   36u  IPv4  10659      0t0  TCP mail.DOMAIN.TLD:domain (LISTEN)
dockerd   1070            root   41u  IPv4  10660      0t0  UDP mail.DOMAIN.TLD:domain

Please check that and report back. Thanks.

[skeats]

sudo netstat -tulpn | grep -i -E '.:53\s+.$'
tcp 0 0 127.0.0.54:53 0.0.0.0:* LISTEN 767/systemd-resolve
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 767/systemd-resolve
tcp 0 0 127.0.0.150:53 0.0.0.0:* LISTEN 1120/unbound
tcp 0 0 172.18.0.1:53 0.0.0.0:* LISTEN 1120/unbound
udp 0 0 172.18.0.1:53 0.0.0.0:* 1120/unbound
udp 0 0 127.0.0.150:53 0.0.0.0:* 1120/unbound
udp 0 0 127.0.0.54:53 0.0.0.0:* 767/systemd-resolve
udp 0 0 127.0.0.53:53 0.0.0.0:* 767/systemd-resolve

[skeats]

I can confirm that the cloudron-network.config file is identical to the one you provided.

sudo lsof -i :53
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
systemd-r 767 systemd-resolve 14u IPv4 12307 0t0 UDP _localdnsstub:domain
systemd-r 767 systemd-resolve 15u IPv4 12308 0t0 TCP _localdnsstub:domain (LISTEN)
systemd-r 767 systemd-resolve 16u IPv4 12309 0t0 UDP _localdnsproxy:domain
systemd-r 767 systemd-resolve 17u IPv4 12310 0t0 TCP _localdnsproxy:domain (LISTEN)
unbound 1120 unbound 3u IPv4 10993 0t0 UDP localhost:domain
unbound 1120 unbound 4u IPv4 10994 0t0 TCP localhost:domain (LISTEN)
unbound 1120 unbound 5u IPv4 10995 0t0 UDP cloudron:domain
unbound 1120 unbound 6u IPv4 10996 0t0 TCP cloudron:domain (LISTEN)

[james]

That is very abnormal.
Please send a mail to support@cloudron.io and link this topic in your ticket.

[james]

Hello @skeats
Did this issue resolve itself, or do you still need further assistance?

[LoudLemur]

I don't know if this is closely related, but ptr records not set is a recurring and seemingly unsolvable problem for me on my instances.

. Cloudron notifies that email is "not configured properly". (Ptris null but should point to...) We (yet again) inform the VPS provider. They check and say that it is all looking good to them. The notification is dismissed. Some while later it returns again.

[james]

Hello @LoudLemur
If this happens again, could you please pinpoint the time and save the box.log or even better the output of cloudron-support --send-diagnostics so I can look further into it.