DNS resolution errors within

Support
,
1

(This issue led me to the issue I found yesterday but I’m still having this issue while the other issue with nsswitch.conf seems to be fixed.)

I have a wordpress site with a plugin that runs a fetch request. It has worked without issue for a while, but it is not something I check often. I am getting a cURL error 6, which leads me to dns resolution. I then ssh in to my ApisCP and get this: (nslookup using local resolver fails, but dig works.)

[root@cpanel ~]# nslookup brickhouseofwashington.com
Server: 127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
*** Can’t find brickhouseofwashington.com: No answer

[root@cpanel ~]# dig @1.0.0.1 brickhouseofwashington.com

; <<>> DiG 9.11.36-RedHat-9.11.36-16.el8_10.4 <<>> @1.0.0.1 brickhouseofwashington.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54079
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;brickhouseofwashington.com. IN A

;; ANSWER SECTION:
brickhouseofwashington.com. 1799 IN A 108.224.190.154

;; Query time: 21 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Thu May 29 07:25:26 EDT 2025
;; MSG SIZE rcvd: 71

[root@cpanel ~]#

[root@cpanel ~]# nmcli connection show
NAME UUID TYPE DEVICE
ens18 eee5d605-0789-4d10-bc5b-3793d8d6ccb6 ethernet ens18
ens19 f294338d-9b9c-4821-b6bf-19b2455f2e5a ethernet –
[root@cpanel ~]# resolvectl status
Global
LLMNR setting: yes
MulticastDNS setting: yes
DNSOverTLS setting: no
DNSSEC setting: allow-downgrade
DNSSEC supported: yes
Current DNS Server: 1.0.0.1
DNS Servers: 1.0.0.1
1.1.1.1
Fallback DNS Servers: 9.9.9.9
DNS Domain: ~.
DNSSEC NTA: in-addr.arpa
ip6.arpa

Link 2 (ens18)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: allow-downgrade
DNSSEC supported: yes
Current DNS Server: 8.8.8.8
DNS Servers: 8.8.8.8
1.1.1.1
2600:1700:8461:b310::1
[root@cpanel ~]#

Any ideas on this one? TYIA!

2

lmaooooooo

3

Two considerations:

/etc/resolv.conf within the vfs is bad. Check /home/virtual/FILESYSTEMTEMPLATE/siteinfo/etc/resolv.conf. curl requests within an account use that information to check for DNS. It’s a special one-shot file, so it must first be unlinked, then recreated to copy data from /etc/resolv.conf on the server.

rm -f /home/virtual/FILESYSTEMTEMPLATE/siteinfo/etc/resolv.conf
upcp -sb apnscp/initialize-filesystem-template

Multihomed NIC, similar situation at this case.

That connection has a different DNS server configured: 8.8.8.8, 1.1.1.1, and 2600:1700:8461:b310::1.

For each IP, run the following command:

dig @IP +trace brickhouseofwashington.com

Depending how DNS is configured for the NIC, the offending resolver would be removed from /etc/sysconfig/network-scripts/ifcfg-DEV or /etc/NetworkManager/NetworkManager.conf. My money is on IPv6 resolver being invalid - either IPv6 missing from server or it’s an unrouteable address.

4

Anatoli: what did I miss?

Msaladna, thanks for the help. I’ll take a look when I’m back home.

5

Throwing things at a wall to see what sticks. I will say, I have been out of ApisCP since install and forgot a lot, so I appreacite the help.

1/ ens19 was an old artifact and wasnt being used. ip a show didnt display ens19. I used nmcli to remove 19.

2/ I didnt enable or disable IPv6, but it looks like it pulled a DHCP IPv6 from my provider.

nmcli connection modify ens18 ipv6.method “ignore”
ip -6 addr flush dev ens18

Fixed both the IPv6 IP and the DNS record

3/ Ran the command and checked the files you stated:

  • /etc/NetworkManager/NetworkManager.conf

Only thing not commented out caught my attention, but I’m not knowledgeable about nmcli to understand if this matters: I assume it is handled else where…?

[main]
dns = none

  1. /etc/hosts also had a ipv6 host to my domain, removed that

…and I’m still having issues

5/ I figured I’d try chatgpt and asked a few questions. I flushed the cache using ‘systemd-resolve --flush-caches’ and that worked. What the heck… crazy. Maybe it was a symptom of the ipv6 dns resolver…? I’ll never know. Thanks again for the help Matt.

6

I have / had the same…
I’m running rocky Linux and u?
Will post later my solution sorry for now

7

/etc/resolv.conf

``

Bewerk het bestand met:

sudo nano /etc/resolv.conf

``

``

bewerk de nameserver(s) naar

nameserver 1.0.0.1

nameserver 1.1.1.1

sla deze op

Controleer nu of je wel het juiste ip / adres terug krijt bij een command like:

8

So odd - Still having issues with the stub resolver. I would flush the cache, and it would work for 5-10 minutes, then nslookup would stop working on certain domains. Dig would find the A record on any public DNS, say 1.1.1.1 or 8.8.8.8, but dig on 127.0.0.53 would not show an A record. Primary and NIC DNS were set to 1.1.1.1 and 1.0.0.1 with a backup of 9.9.9.9.

I overwrote /etc/resolv.conf and made it read-only so no service can write over it with 1.1.1.1 and 1.0.0.1 as the name servers and no issues in >24 hours with nslookup…

But, the problem I am seeing is that the sites use the stub resolver and I’m still having some issues with my plugin trying to do a curl request.

Any thoughts on how to troubleshoot / fix?

9

DNS resolution occurs within vfs, so ensure that /etc/resolv.conf within /home/virtual/siteXX/fst is the same as the one located in /.

journalctl -n 500 -u systemd-resolved might report something pertaining to that DNS record. If you’d like to use upstream DNS directly instead of resolved:

Edit /etc/resolv.conf with your upstream resolvers (e.g. 1.1.1.1, 8.8.8.8), then run:

systemctl mask --now systemd-resolved
upcp -sbf common/update-config apnscp/initialize-filesystem-template apnscp/filesystem-checks