[GH-ISSUE #163] nslookup works but not ping

kerem commented

2026-02-26 04:33:56 +03:00

Owner

Originally created by @kundeng on GitHub (Oct 5, 2019).
Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/163

On a linux (mint) system, I tried it.
nslookup works, but ping doesn't. Any idea why?

ping dns-proxy-server
ping: dns-proxy-server: Name or service not known

nslookup dns-proxy-server
Server: 172.17.0.2
Address: 172.17.0.2#53

Non-authoritative answer:
*** Can't find dns-proxy-server.localdomain: No answer

I read somewhere I need to remove mdns4. Do I have to?

Originally created by @kundeng on GitHub (Oct 5, 2019). Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/163 On a linux (mint) system, I tried it. nslookup works, but ping doesn't. Any idea why? ping dns-proxy-server ping: dns-proxy-server: Name or service not known nslookup dns-proxy-server Server: 172.17.0.2 Address: 172.17.0.2#53 Non-authoritative answer: *** Can't find dns-proxy-server.localdomain: No answer I read somewhere I need to remove mdns4. Do I have to?

kerem

2026-02-26 04:33:56 +03:00

closed this issue
added the
discussion
label

kerem commented

2026-02-26 04:33:56 +03:00

Author

Owner

@mageddo commented on GitHub (Nov 3, 2019):

Please describe the steps to reproduce the issue including the steps to start DPS.
Provide which DPS version you're using

@mageddo commented on GitHub (Nov 3, 2019): * Please describe the steps to reproduce the issue including the steps to start DPS. * Provide which DPS version you're using

kerem commented

2026-02-26 04:33:56 +03:00

Author

Owner

@adigourdi commented on GitHub (Nov 14, 2019):

Encountered the same issue when my hostnames ended with .local
(eg: alpine.local, postgres.local)

Changed it to .test and now it works correctly

No idea why though

PS: using :latest docker images

@adigourdi commented on GitHub (Nov 14, 2019): Encountered the same issue when my hostnames ended with `.local` (eg: `alpine.local`, `postgres.local`) Changed it to `.test` and now it works correctly No idea why though _PS: using :latest docker images_

kerem commented

2026-02-26 04:33:56 +03:00

Author

Owner

@thomasleveil commented on GitHub (Dec 31, 2019):

domains ending with .local are resolved using mDNS on Linux Mint OS. It's kind of a pain to disable it. The best option is to never use domains ending with ".local" unless you want to actually use mdns.

@thomasleveil commented on GitHub (Dec 31, 2019): domains ending with `.local` are resolved using [mDNS](https://en.wikipedia.org/wiki/Bonjour_(software)) on Linux Mint OS. It's kind of a pain to disable it. The best option is to never use domains ending with ".local" unless you want to actually use mdns.

kerem commented

2026-02-26 04:33:56 +03:00

Author

Owner

@mageddo commented on GitHub (Jan 8, 2020):

I confirm it, by some reason .local domains are not pingable, not sure if I have mDNS running, @thomasleveil how can I check that?

linux: Ubuntu 19.04

@mageddo commented on GitHub (Jan 8, 2020): I confirm it, by some reason `.local` domains are not pingable, not sure if I have `mDNS` running, @thomasleveil how can I check that? linux: Ubuntu 19.04

kerem commented

2026-02-26 04:33:56 +03:00

Author

Owner

@mageddo commented on GitHub (Jan 8, 2020):

While using ping DPS couldn't solve .local DNS names. It is not founding the hostname locally, then proxying to the internet.

2020/01/08 12:02:36.998074 INFO f=remote.go:64 pkg=github.com/mageddo/dns-proxy-server/proxy.remoteDnsSolver m=Solve uuid=510c06d8f3 status=bad-code, name=local., rcode=3, err=status=invalid-answer-name, name=local., rcode=3
2020/01/08 12:02:36.998119 INFO f=remote.go:64 pkg=github.com/mageddo/dns-proxy-server/proxy.remoteDnsSolver m=Solve uuid=510c06d8f3 status=complete, name=local., res=3

@mageddo commented on GitHub (Jan 8, 2020): While using ping DPS couldn't solve `.local` DNS names. It is not founding the hostname locally, then proxying to the internet. ``` 2020/01/08 12:02:36.998074 INFO f=remote.go:64 pkg=github.com/mageddo/dns-proxy-server/proxy.remoteDnsSolver m=Solve uuid=510c06d8f3 status=bad-code, name=local., rcode=3, err=status=invalid-answer-name, name=local., rcode=3 2020/01/08 12:02:36.998119 INFO f=remote.go:64 pkg=github.com/mageddo/dns-proxy-server/proxy.remoteDnsSolver m=Solve uuid=510c06d8f3 status=complete, name=local., res=3 ```

kerem commented

2026-02-26 04:33:56 +03:00

Author

Owner

@mageddo commented on GitHub (Jan 8, 2020):

I'll have to make deeper find, looks like DPS it's only receiving the domain, not the full hostname

status=complete, name=local., res=3

@mageddo commented on GitHub (Jan 8, 2020): I'll have to make deeper find, looks like DPS it's only receiving the domain, not the full hostname `status=complete, name=local., res=3`

kerem commented

2026-02-26 04:33:56 +03:00

Author

Owner

@thomasleveil commented on GitHub (Jan 8, 2020):

@mageddo : execute grep hosts: /etc/nsswitch.conf and see if mdns appears

@thomasleveil commented on GitHub (Jan 8, 2020): @mageddo : execute `grep hosts: /etc/nsswitch.conf` and see if `mdns` appears

kerem commented

2026-02-26 04:33:56 +03:00

Author

Owner

@mageddo commented on GitHub (Jan 8, 2020):

@mageddo : execute grep hosts: /etc/nsswitch.conf and see if mdns appears

Yes, it appears

hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname

@mageddo commented on GitHub (Jan 8, 2020): > @mageddo : execute `grep hosts: /etc/nsswitch.conf` and see if `mdns` appears Yes, it appears ```hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname```

kerem commented

2026-02-26 04:33:56 +03:00

Author

Owner

@mageddo commented on GitHub (Jan 15, 2020):

When hostnames are terminated by .local ping decides to make a SOA request to .local domain first, it's proxied to remote dns server, obviously it's not a valid domain then the remote answers NXDOMAIN (not found), then ping receives the answer as an error (and it is) and abort the process, Name or service not known is printed by ping

@mageddo commented on GitHub (Jan 15, 2020): When hostnames are terminated by `.local` ping decides to make a [SOA][1] request to `.local` domain first, it's proxied to **remote** dns server, obviously it's not a valid domain then the **remote** answers **NXDOMAIN** (not found), then **ping** receives the answer as an error (and it is) and abort the process, `Name or service not known` is printed by **ping** [1]: https://en.wikipedia.org/wiki/SOA_record

kerem commented

2026-02-26 04:33:56 +03:00

Author

Owner

@mageddo commented on GitHub (Jan 15, 2020):

I imagine the SOA request is made to check if DPS can solve the hostname after mdns fails. Not sure if this check is made by ping or mdns though.

@mageddo commented on GitHub (Jan 15, 2020): I imagine the **SOA** request is made to check if DPS can solve the hostname after **mdns** fails. Not sure if this check is made by **ping** or **mdns** though.

kerem commented

2026-02-26 04:33:57 +03:00

Author

Owner

@mageddo commented on GitHub (Jan 15, 2020):

I suppose this issue will be fixed by implementing SOA record queries on DPS, actually DPS doesn't fully support it.

@mageddo commented on GitHub (Jan 15, 2020): I suppose this issue will be fixed by implementing **SOA** record queries on DPS, actually DPS doesn't fully support it.

kerem commented

2026-02-26 04:33:57 +03:00

Author

Owner

@lucassardois commented on GitHub (Sep 3, 2021):

I have the same issue except I'm not using .local.
I started dps with the following:

docker run --rm --hostname dns.mageddo \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /etc/resolv.conf:/etc/resolv.conf \
defreitas/dns-proxy-server

And as the documentation show, I except to be able to ping dns.mageddo, ping returns:

ping: dns.mageddo: Name or service not known

When I do nslookup dns.magddo I get:

Server:         172.17.0.2
Address:        172.17.0.2#53

** server can't find dns.magddo: NXDOMAIN

When I directly ping the ip address, it works:

➜  ~ ping 172.17.0.2
PING 172.17.0.2 (172.17.0.2) 56(84) bytes of data.
64 bytes from 172.17.0.2: icmp_seq=1 ttl=64 time=0.114 ms
64 bytes from 172.17.0.2: icmp_seq=2 ttl=64 time=0.091 ms
64 bytes from 172.17.0.2: icmp_seq=3 ttl=64 time=0.101 ms

I'm on a Fedora 34 (Workstation) system. When I check the /etc/resolvconf while dps is running I can see the following:

# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

# nameserver 127.0.0.53 # dps-comment
options edns0 trust-ad
search .
nameserver 172.17.0.2 # dps-entry

This looks OK to me?

Here is the result of resolvectl status as explained in the previous file comments, in case you need it:

Global
         Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 8.8.8.8
       DNS Servers: 8.8.8.8 8.8.4.4 80.80.80.80

Link 2 (enp0s31f6)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 3 (wlp3s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: fd0f:ee:b0::1
       DNS Servers: 192.168.1.254 fd0f:ee:b0::1

Link 4 (virbr0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 5 (docker0)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 6 (br-d1c080aa5d4a)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 7 (br-d32bfd4019c2)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 8 (br-7dbacfc74479)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 14 (veth42c3216)
Current Scopes: LLMNR/IPv6
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Where wlp3s0 is my wifi interface currently used.

Also, here is the result of things running on port 53:

➜  ~ sudo netstat -anp | grep ":53"
tcp        0      0 0.0.0.0:5355            0.0.0.0:*               LISTEN      760/systemd-resolve 
tcp        0      0 192.168.122.1:53        0.0.0.0:*               LISTEN      1201/dnsmasq        
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      760/systemd-resolve 
tcp6       0      0 :::5355                 :::*                    LISTEN      760/systemd-resolve 
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           783/avahi-daemon: r 
udp        0      0 0.0.0.0:5355            0.0.0.0:*                           760/systemd-resolve 
udp        0      0 192.168.122.1:53        0.0.0.0:*                           1201/dnsmasq        
udp        0      0 127.0.0.53:53           0.0.0.0:*                           760/systemd-resolve 
udp6       0      0 :::5353                 :::*                                783/avahi-daemon: r 
udp6       0      0 :::5355                 :::*                                760/systemd-resolve

Any idea on how to fix this issue?

@lucassardois commented on GitHub (Sep 3, 2021): I have the same issue except I'm not using `.local`. I started dps with the following: ```bash docker run --rm --hostname dns.mageddo \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /etc/resolv.conf:/etc/resolv.conf \ defreitas/dns-proxy-server ``` And as the documentation show, I except to be able to ping `dns.mageddo`, ping returns: ```bash ping: dns.mageddo: Name or service not known ``` When I do `nslookup dns.magddo` I get: ```bash Server: 172.17.0.2 Address: 172.17.0.2#53 ** server can't find dns.magddo: NXDOMAIN ``` When I directly ping the ip address, it works: ```bash ➜ ~ ping 172.17.0.2 PING 172.17.0.2 (172.17.0.2) 56(84) bytes of data. 64 bytes from 172.17.0.2: icmp_seq=1 ttl=64 time=0.114 ms 64 bytes from 172.17.0.2: icmp_seq=2 ttl=64 time=0.091 ms 64 bytes from 172.17.0.2: icmp_seq=3 ttl=64 time=0.101 ms ``` I'm on a Fedora 34 (Workstation) system. When I check the `/etc/resolvconf` while dps is running I can see the following: ```bash # This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8). # Do not edit. # # This file might be symlinked as /etc/resolv.conf. If you're looking at # /etc/resolv.conf and seeing this text, you have followed the symlink. # # This is a dynamic resolv.conf file for connecting local clients to the # internal DNS stub resolver of systemd-resolved. This file lists all # configured search domains. # # Run "resolvectl status" to see details about the uplink DNS servers # currently in use. # # Third party programs should typically not access this file directly, but only # through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a # different way, replace this symlink by a static file or a different symlink. # # See man:systemd-resolved.service(8) for details about the supported modes of # operation for /etc/resolv.conf. # nameserver 127.0.0.53 # dps-comment options edns0 trust-ad search . nameserver 172.17.0.2 # dps-entry ``` This looks OK to me? Here is the result of `resolvectl status` as explained in the previous file comments, in case you need it: ```bash Global Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub Current DNS Server: 8.8.8.8 DNS Servers: 8.8.8.8 8.8.4.4 80.80.80.80 Link 2 (enp0s31f6) Current Scopes: none Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Link 3 (wlp3s0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: fd0f:ee:b0::1 DNS Servers: 192.168.1.254 fd0f:ee:b0::1 Link 4 (virbr0) Current Scopes: none Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Link 5 (docker0) Current Scopes: LLMNR/IPv4 LLMNR/IPv6 Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Link 6 (br-d1c080aa5d4a) Current Scopes: none Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Link 7 (br-d32bfd4019c2) Current Scopes: none Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Link 8 (br-7dbacfc74479) Current Scopes: none Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Link 14 (veth42c3216) Current Scopes: LLMNR/IPv6 Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported ``` Where `wlp3s0` is my wifi interface currently used. Also, here is the result of things running on port 53: ``` ➜ ~ sudo netstat -anp | grep ":53" tcp 0 0 0.0.0.0:5355 0.0.0.0:* LISTEN 760/systemd-resolve tcp 0 0 192.168.122.1:53 0.0.0.0:* LISTEN 1201/dnsmasq tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 760/systemd-resolve tcp6 0 0 :::5355 :::* LISTEN 760/systemd-resolve udp 0 0 0.0.0.0:5353 0.0.0.0:* 783/avahi-daemon: r udp 0 0 0.0.0.0:5355 0.0.0.0:* 760/systemd-resolve udp 0 0 192.168.122.1:53 0.0.0.0:* 1201/dnsmasq udp 0 0 127.0.0.53:53 0.0.0.0:* 760/systemd-resolve udp6 0 0 :::5353 :::* 783/avahi-daemon: r udp6 0 0 :::5355 :::* 760/systemd-resolve ``` Any idea on how to fix this issue?

kerem commented

2026-02-26 04:33:57 +03:00

Author

Owner

@mageddo commented on GitHub (Mar 4, 2023):

So, just to give an conclusion to this issue, there is no much to do about .local entries, they are entries for a reserved domain, just don't use that if you want to not have issues, because Linux won't forward .local hostname queries to the configured DNS, if you query using nslookup or whatever client specifying DPS server then it will work.

$ docker run --rm -it --hostname dns-proxy-server.local alpine sh
$ docker run --rm -it --hostname dns-proxy-server.dev alpine sh

# Querying letting the system decide whether use DNS server or not won't work.
$ nslookup dns-proxy-server.local
Server:		127.0.0.53
Address:	127.0.0.53#53

** server can't find dns-proxy-server.local: SERVFAIL

# .dev domain works normally
$ nslookup dns-proxy-server.dev
Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
Name:	dns-proxy-server.dev
Address: 172.17.0.5

# Query .local domain specifying DPS server will work though
$ nslookup -po=8053 dns-proxy-server.local 127.0.0.1
Server:		127.0.0.1
Address:	127.0.0.1#8053

Non-authoritative answer:
Name:	dns-proxy-server.local
Address: 172.17.0.4
Name:	dns-proxy-server.local
Address: 172.17.0.4

@mageddo commented on GitHub (Mar 4, 2023): So, just to give an conclusion to this issue, there is no much to do about `.local` entries, they are entries for a [reserved domain](https://en.wikipedia.org/wiki/.local), just don't use that if you want to not have issues, because Linux won't forward .local hostname queries to the configured DNS, if you query using nslookup or whatever client specifying DPS server then it will work. ```bash $ docker run --rm -it --hostname dns-proxy-server.local alpine sh $ docker run --rm -it --hostname dns-proxy-server.dev alpine sh ``` ```bash # Querying letting the system decide whether use DNS server or not won't work. $ nslookup dns-proxy-server.local Server: 127.0.0.53 Address: 127.0.0.53#53 ** server can't find dns-proxy-server.local: SERVFAIL # .dev domain works normally $ nslookup dns-proxy-server.dev Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: Name: dns-proxy-server.dev Address: 172.17.0.5 # Query .local domain specifying DPS server will work though $ nslookup -po=8053 dns-proxy-server.local 127.0.0.1 Server: 127.0.0.1 Address: 127.0.0.1#8053 Non-authoritative answer: Name: dns-proxy-server.local Address: 172.17.0.4 Name: dns-proxy-server.local Address: 172.17.0.4 ```

kerem commented

2026-02-26 04:33:57 +03:00

Author

Owner

@mageddo commented on GitHub (Mar 4, 2023):

@lucassardois I think your issue has a different cause, maybe it's related wit this entry search . you could try remove it, maybe it's related to system-resolved in that case you can see this thread #244, if neither don't solve your issues then you can open a new issue , please.

@mageddo commented on GitHub (Mar 4, 2023): @lucassardois I think your issue has a different cause, maybe it's related wit this entry `search .` you could try remove it, maybe it's related to system-resolved in that case you can see [this thread](https://github.com/mageddo/dns-proxy-server/issues/244) #244, if neither don't solve your issues then you can open a new issue , please.

kerem referenced this issue

2026-02-26 04:34:37 +03:00

[PR #64] [MERGED] Update service.go #249

Rows
Columns

[GH-ISSUE #163] nslookup works but not ping #64