Issues with pinging websites by DNS name

There is something wrong with “ping”. Instead of previous interval of 1 second between every ping sent, it now defaults to 5 seconds and ignores the the flag -i and still sends every 4-5 seconds. Even if I set it to minimum allowed -i 0.2 it still sends them every 4-5 seconds.

This only happens if you ping website by dns name. If you ping by IP, it seems to work perfectly. Which is very odd. Almost like it would make a new DNS query for each next ping. Also the name resolution for ping is and has been always horribly slow. It does not seem to use system DNS server (which responds instantly) but takes about 4-5 seconds always. It has not really bothered me before, since it did it just once at the start, but now it’s just bad.

That is odd, I just tried ping to www.google.com and a few others and am not experiencing the same issue (my pings are coming every second by default and the name resolution is occurring fairly instant. You may want to create a new thread and give more information about your system (which edition of manjaro you are running (desktop environment) along with the information mentioned here:

https://forum.manjaro.org/t/how-to-provide-good-information

You will want to also include what network interface you are using and also what you are using for dns resolution.

I’m not able to replicate, default ping time for me is 1 s, -i flag works as expected.

What is your guys hosts: value in /etc/nsswitch.conf file? I got it “fixed”, buy removing a lot of stuff from it:

#old (was my Manjaro default) -- ping interval is VERY SLOW (not the actual ping result)
# hosts: files mymachines mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns mdns4 myhostname
#new -- works like a charm now.
hosts: files dns

Original one, here it is:

passwd: files mymachines systemd

group: files mymachines systemd

shadow: files

publickey: files

hosts: files mymachines mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns mdns4 myhostname

networks: files

protocols: files

services: files

ethers: files

rpc: files

netgroup: files
1 Like

Hmm, Mine is using the manjaro default and contains the items you removed. That probably points to the problem being in one of this items you removed.

hosts: files mymachines mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns mdns4 myhostname

Your workaround may break other things now or in the future. I don’t know if any of the items you removed are needed, or what the purpose of those items are. (I’m out of my depth as to the reason why those items are in the default configuration). You may want to create a new thread if you want to figure out what is wrong with having the default configuration in place.

I tracked down the problem to mdns4 in this line. After removing it everything started working fine and the line looks now this:
hosts: files mymachines mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname

By fine I mean:

  1. ping www.ee, www.lt and all the other websites does it in 1s interval by default and respects -i for even shorter interval, instead of previous buggy 5s.
  2. I still can ping my local other devices by name (without DNS), like Zen.local, nas542.local, U745.local etc. (when I removed also the mdns4_minimal parts, this stopped working)

it’s almost as for me somehow or for some reason this 13 year old Ubuntu issue with nss-mdns and/or avahi-daemon surfaced in Manjaro. Go figure.

1 Like

Interesting, so I take it that you are using a home router as your dns resolver. That’s probably why I am not experiencing the issue because I always use real DNS servers since most home routers have very poor dns implementations.

You are the exception though, everybody™ uses their ISP’s router as their caching DNS server.

1 Like

well I am using dnsmasq with dnscrypt :wink:

Well. first of all DNS and mDNS (Multicast DNS) are 2 totally different animals – using different protocols, different ports and everything. Can’t blame router for “bad DNS implementation” if we have problem with mDNS (which should work “routerless” in local network) :smile_cat:
(for the record, I do not own an ISP router, which I replaced with my own rather beefy mikrotik RB4011, that does a lot for me – including decent performance VPN (main reason I replaced ISP router; which didn’t offer any VPN option at all); dns over https proxy to cloudflare; actual IPV4 and IPV6 firewall instead of regular NAT only; and most importantly, I am the master in this system, whereas in ISP provided router I was mere “user” where they were the admins. However now googling “mikrotik mdns” – there might be some issue there indeed. Will explore further. Then again, bad mdns implementation in Manjaro/nss-mdns/avahi-daemon – can’t handle correctly incoming (incorrect?) replies or just hangs on no results – isn’t exactly OK also.)

There isn’t anything wrong with the implementation in Manjaro. It is done correctly. That is the whole reason the issue was never “fixed”. The problem only occurs if your internal network is configured incorrectly (by incorrectly that means you are using the TLD .local as your DNS domain name which is a reserved TLD name used by mDNS).

Basically you want to make sure you internal network isn’t using a .local domain as that is where the problem comes into play and where DNS and mDNS can bump into each other. So if you setup your router to use the domain mydomain.local or anythingreally.local then you are going to have the issue with mdns. The thread you posted is a very interesting read but it also shows that they since it is following all of the correct “rules” they don’t see it as a problem and have no intention of fixing it to work with incorrectly configured local networks since .local is now a reserved TLD and shouldn’t be used. One of the reasons the use of .local is frequently out there is that dating back to the early 2000’s Microsoft used to recommend using the .local domain for internal networks when setting up AD and it was recommended as part of their “Best Practices”. At the time they made that recommendation .local wasn’t used officially for anything. That later changed in February 20th 2013 when the IETF ratified RFC6762 which now reserves the TLD .local for use with mdns. Anyway from that thread the most useful workaround info is as follows:

Original, delayed lookup on improperly configured internal networks:
#hosts: files mdns4_minimal [NOTFOUND=return] dns

Use this if you’re not on a local network with Microsoft services or if you don’t need on them:
hosts: files dns

Delays looking up hosts on your internal network, but you will get the best of both worlds;
multicast DNS resolution and resolution of your incorrectly-named internal network:
hosts: files mdns4_minimal dns

So based on manjaro default of the following:

hosts: files mymachines mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns mdns4 myhostname

You could try this config if you want to use mdns (a lot of “internet of things” devices like network speakers, thermostats, video streaming server devices, etc… use mdns) and have your local network incorrectly configured to use the reserved .local domain and have no way of changing it the following should let you use mdns and not cause a really long delay.

hosts: files mymachines mdns4_minimal resolve [!UNAVAIL=return] dns mdns4 myhostname

That being said the ideal solution would be to fix the incorrectly configured internal network to not use the .local TLD.

1 Like

Are there any reserved tlds I could use for the lan? Like .lan? I’m looking for something reserved, since Google registering .dev as a global tld already caused enough headaches.

1 Like

Okay, answering my own question now that I am back at something with a usably big screen and a keyboard :wink:

As far as I can determine RFC2606 lists the four (4!) only reserved non-routable TLDs:

.test
.example
.invalid
.localhost

So yes, this is rather limiting… and there have been drafts like 2606bis that propose to add a couple of reserved TLDs like .localdomain, .domain, .lan, .home, .host, .corp, but Appendix G of RFC6762 duly notes:

We do not recommend use of unregistered top-level domains at all, but should network operators decide to do this, the following top-level domains have been used on private internal networks without the problems caused by trying to reuse “.local.” for this purpose:
.intranet.
.internal.
.private.
.corp.
.home.
.lan

The main advice I see is that if you do have a FQDN, you should use something like internal.yourdomainname.tld for your local intranet.

You assume it is. But it isn’t. My router just doesn’t answer itself to mdns query at all. And by default (and currently still is) its configured name and TLD is router.lan. Also for DHCP it doesn’t give any dns-suffix type of thing at all (I assume, you assumed, that here for some reason I had .local, but I don’t).

EDIT: Now this is weird. When I have this mdns4 in nssconf and I tested the ping interval delay thing, I always used ping www.ee for it’s shortness… and it’s SLOW delay like I described in the first issue. ping www.google.com doesn’t suffer from this problem. Nor does ping www.de. But ping www.lt does have the same delay problem… wtf is going on? it’s like it’s (and by it, I mean Manjaro) trying to on some cases resolve the name with .local suffix and sometimes not? And then there comes this delay in?
I mean like if you try to ping dsfiuhdsiufhsdiuf you get instant “Name or service not known” but if you try to ping dsfiuhdsiufhsdiuf.local then there is this delay … before you get the same “Name or service not known”. And for some domains for some reason it does try to always do this automatic .local addition???
Do you have this ping interval delay for ping www.ee ?

This is weird! I see the exact same delay!

[edit] Seeing the delay with www.ee and www.lt, also not seeing the delay with google or www.de
[edit] Local network is using tld .lan
[edit] Not seeing the delay when pinging local hosts like hostname.lan
[edit] Just booted Ubuntu 20.04 from USB: no problems with pinging local network or the www.ee and www.lt hosts

1 Like

Glad I am not the only one then :smiley:

1 Like

I have same issue.

1 Like