You are not logged in.
I'm using my home router (my gateway) as a nameserver and from some reason I can't connect to several domains. I've tried to change the `nameserver` in my `/etc/resolv.conf` to `8.8.8.8` and some other opennic DNS servers IP addresses and I still can't connect to the same specific domains:
savannah.gnu.org
octave.org
I'm trying to clone the unstable version of GNU octave with mercurial:
$ hg clone https://www.octave.org/hg/octave
abort: error: Name or service not known
I have no idea how to fix this, I've tried running `dig` for these domains and I get the following responses:
$ dig octave.org
; <<>> DiG 9.13.5 <<>> octave.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36842
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ee326cef7fd395aac0a89b535c41de63430093bee0e5488b (good)
;; QUESTION SECTION:
;octave.org. IN A
;; ANSWER SECTION:
octave.org. 14400 IN A 173.236.224.198
;; Query time: 352 msec
;; SERVER: 192.168.14.1#53(192.168.14.1)
;; WHEN: Fri Jan 18 16:10:42 IST 2019
;; MSG SIZE rcvd: 83
$ dig savannah.gnu.org
; <<>> DiG 9.13.5 <<>> savannah.gnu.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51230
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 127796805f526f22fd8b06465c41de80a2f7c0065f3b6236 (good)
;; QUESTION SECTION:
;savannah.gnu.org. IN A
;; ANSWER SECTION:
savannah.gnu.org. 300 IN A 209.51.188.79
;; Query time: 152 msec
;; SERVER: 192.168.14.1#53(192.168.14.1)
;; WHEN: Fri Jan 18 16:11:11 IST 2019
;; MSG SIZE rcvd: 89
Putting octave.org in the browser redirects you to https://www.gnu.org/software/octave/ but savannha.gnu.org is not accessible even from the browser (any browser).
I'm sure this is a computer specific problem and not a router issue since I can access savannah.gnu.org from the browser of my phone and other clients on the same network.
Last edited by Doron.Behar (2019-01-18 18:12:01)
Offline
Hello there,
Out of curiosity, what's in your /etc/resolv.conf and /etc/hosts?
EDIT: It's quite normal to have temporary nameserver failed lookups With dig, try with dig +trace, that can show a clearer picture.
Regards
Last edited by bugsmanagement (2019-01-18 14:47:28)
Offline
My `/etc/resolve.conf` has only 1 line (besides comments)
nameserver 192.168.14.1
This is the IP of my gateway. My `/etc/hosts` has:
127.0.0.1 nuc.doronbehar.com NUC
::1 nuc.doronbehar.com NUC
Adding `+trace` to `dig` doesn't much useful information I could spot:
; <<>> DiG 9.13.5 <<>> +trace savannah.gnu.org
;; global options: +cmd
. 269968 IN NS k.root-servers.net.
. 269968 IN NS j.root-servers.net.
. 269968 IN NS h.root-servers.net.
. 269968 IN NS l.root-servers.net.
. 269968 IN NS m.root-servers.net.
. 269968 IN NS f.root-servers.net.
. 269968 IN NS i.root-servers.net.
. 269968 IN NS b.root-servers.net.
. 269968 IN NS d.root-servers.net.
. 269968 IN NS c.root-servers.net.
. 269968 IN NS e.root-servers.net.
. 269968 IN NS g.root-servers.net.
. 269968 IN NS a.root-servers.net.
. 485984 IN RRSIG NS 8 0 518400 20190131050000 20190118040000 16749 . bLvLzE/fwgVM+/y6R5hXzbobPia0NWwvLDpksqPNJQlIiiC3JcjE115d zFgZCoDDD3rWU62YdjIfdKEekocrgCykuEjXSFodcdBnMKLrslF2CrtA uknyxOvKjt06i0rhoWcSpumIVoZYH/aFuPB/rFwi/gkxXY/CJ7TxEKNa P391Iiq9zfQMKhmbZ32AYQh+hb+W4xZFL7tn7NuoH7xN4qTP58AiDLvp fU9ISRiElzIlvcivRuljSzkw2KUGqFazSG+s7YwkDGVu36VpP+jZOJU3 +AS7PY2ZDcciI4i2XOIEPqOMQj0tzqd4OaKkAUSpMmsQ6BHDMUI2P+9c R4sc1Q==
;; Received 565 bytes from 192.168.14.1#53(192.168.14.1) in 11 ms
org. 172800 IN NS a0.org.afilias-nst.info.
org. 172800 IN NS a2.org.afilias-nst.info.
org. 172800 IN NS b0.org.afilias-nst.org.
org. 172800 IN NS b2.org.afilias-nst.org.
org. 172800 IN NS c0.org.afilias-nst.info.
org. 172800 IN NS d0.org.afilias-nst.org.
org. 86400 IN DS 9795 7 1 364DFAB3DAF254CAB477B5675B10766DDAA24982
org. 86400 IN DS 9795 7 2 3922B31B6F3A4EA92B19EB7B52120F031FD8E05FF0B03BAFCF9F891B FE7FF8E5
org. 86400 IN RRSIG DS 8 1 86400 20190131050000 20190118040000 16749 . qmK8uIhtbn5BvZ19tBaVZHmOBjzGDfywDkeqG7u09oFSePkwYO705aOC 6kZc4AssnC1zyavZy2F9P0w9JMr+735Qt6cQwIXfVCHZ9oCEqmgiiwS1 PVQ4rBpATxDfaCDpC6NzDkVT9PUl3UeB2etbd5Zf7R0Ll7IGZ8TVN4Zx EoNMkV6tFxDCm3PqEwDsKFsUaS3ak0CpdwaIW+j5hVd461TuqqMmCnRQ RsO6DUMZgQ82WMYcCoIborxHCIwXy0jJAxJk+IdNH9a69eVWx8M9znJd f7x/e4inh67XGsYBT6S60xYJfLYx0/3V+F4FAvj85ynVT0LOfBQXTMYr OWXbHg==
;; Received 818 bytes from 193.0.14.129#53(k.root-servers.net) in 62 ms
gnu.org. 86400 IN NS ns3.gnu.org.
gnu.org. 86400 IN NS ns1.gnu.org.
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 86400 IN NSEC3 1 1 1 D399EAAB H9PARR669T6U8O1GSG9E1LMITK4DEM0T NS SOA RRSIG DNSKEY NSEC3PARAM
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 86400 IN RRSIG NSEC3 7 2 86400 20190208150010 20190118140010 45404 org. VOEYTvEFnbTl3TrO/vwMfEPtXEXn4YF21emwdDBntGNcj1dBkvn4Rv6+ u4YpJ0riS148ZeB8DrqTFotQfdoRBPFZW7s55oXQJqCt/9AmDrg6yeBe m+fWJp7VFxtIDFhEDHZrhv0fn3AYlIxNkiNvmvgQv+rTrkzDi48uNPgb 0HU=
i04qlmh02e8hnk82gro1maq4cv271tkq.org. 86400 IN NSEC3 1 1 1 D399EAAB I05KPF6BVAE0SS9ON3EDEH1M2I7V2NLL A RRSIG
i04qlmh02e8hnk82gro1maq4cv271tkq.org. 86400 IN RRSIG NSEC3 7 2 86400 20190207152537 20190117142537 45404 org. KaZPy0uhTBK4sC0jGRjFDuQmHU1dda3AmnEBns7xZfcdgDQrRojoG5OF LKHKQxOs2HYCZsIyR2gYemV5U6xEXFl+L5fdmcSRnkmRPbrV1il9kuyQ CcEbmqI4l9fXnCjJuBVh9HbSqxFT0K4Amr2NAKN2JCsBYa7LT8u6C+Ed QPA=
;; Received 662 bytes from 199.19.54.1#53(b0.org.afilias-nst.org) in 81 ms
savannah.gnu.org. 300 IN A 209.51.188.79
savannah.gnu.org. 300 IN NS ns1.gnu.org.
savannah.gnu.org. 300 IN NS ns2.gnu.org.
savannah.gnu.org. 300 IN NS ns3.gnu.org.
;; Received 2017 bytes from 209.51.188.164#53(ns1.gnu.org) in 150 ms
EDIT: It's quite normal to have temporary nameserver failed lookups With dig, try with dig +trace, that can show a clearer picture.
This problem has been going on for a long time, I've only now found the time to ask for help in fixing it.
Offline
Adding `+trace` to `dig` doesn't much useful information I could spot:
This means, bypass what it says in /etc/resolv.conf and contact the DNS root servers directly.
This problem has been going on for a long time, I've only now found the time to ask for help in fixing it.
The problem is that DNS uses UDP as transport, there is no guarantee that your packet will be delivered. If you don't have any 'iptables -S' rules in place and it's intermittent, then the problem lies at the network layer. Or if it's reproducible 100% of the times, which rarely happens to me, it could be a problem with the application. I've seen 'Name not found' errors before, because it's 'generic', it would require a lot of debugging to find the culprit.
Offline
Thanks for trying to help me, this issue is 100% reproducible, without a doubt and all applications experience this issue - `wget`, `ping`, `curl`.. all of them can't resolve host savannah.gnu.org. Could you please give me a pointer for how to debug this? Do you know if `dig` uses `gethostbyname(3)` or if it reads `/etc/resolv.conf`?
Offline
first things first:
- openresolv or systemd-resolved: "ps aux | grep resolve"
- contents of /etc/nsswitch.conf
- "nslookup octave.org" ?
Offline
First of all, I'm using `connman` as the network manager. I don't use `openresolv`. I have `systemd-resolved` service running but currently I've chosen to symlink `/var/run/connman/resolv.conf` to `/etc/resolv.conf` and not `/var/run/systemd/resolve/resolv.conf`.
Contents of `/etc/nsswitch.conf`:
# Name Service Switch configuration file.
# See nsswitch.conf(5) for details.
passwd: files mymachines systemd
group: files mymachines systemd
shadow: files
publickey: files
hosts: files mymachines myhostname resolve [!UNAVAIL=return] dns
networks: files
protocols: files
services: files
ethers: files
rpc: files
netgroup: files
`nslookup savannah.gnu.org` (The real domain which is unreachable) gives:
Server: 192.168.14.1
Address: 192.168.14.1#53
Non-authoritative answer:
Name: savannah.gnu.org
Address: 209.51.188.79
EDIT: Additional information
I have `nscd.service` running as well and I do see improvement in name resolving speed of other domains thanks to it.
Last edited by Doron.Behar (2019-01-18 17:14:01)
Offline
Please stop the systemd-resolved service and see what happens.
Offline
Boy, that worked! Thanks a lot, I noticed that when I disabled it, it also removed a service called `dbus-org.freedesktop.resolve1.service`. Could it be that has to do anything with the problem?
Offline
Yes, the resolve entry in nsswitch.conf will draw in resolved and that requires some extra attention (sigh)
I don't know about the connman specific support (seems to be there) but if you do not intend to use systemd-resolved at all, just don't run the service.
Offline
That's great but I'm am just as puzzled.
I have `systemd-resolved` service running but currently I've chosen to symlink `/var/run/connman/resolv.conf` to `/etc/resolv.conf` and not `/var/run/systemd/resolve/resolv.conf`.
`nslookup savannah.gnu.org` (The real domain which is unreachable) gives:
Server: 192.168.14.1 Address: 192.168.14.1#53 Non-authoritative answer: Name: savannah.gnu.org Address: 209.51.188.79
By any chance, did the 'symlink' did not stick because 'systemd-resolved' was running? I've never come across a situation where 'systemd-resolved' was running, 'chattr +i /etc/resolv.conf', would lead to 'Name not found' for 'one domain'.
Yes, the resolve entry in nsswitch.conf will draw in resolved and that requires some extra attention (sigh)
Gotcha.
And you referring to this:
hosts: files mymachines myhostname resolve [!UNAVAIL=return] dns
Last edited by bugsmanagement (2019-01-18 17:50:57)
Offline
By any chance, did the 'symlink' did not stick because 'systemd-resolved' was running? I've never come across a situation where 'systemd-resolved' was running, 'chattr +i /etc/resolv.conf', would lead to 'Name not found' for 'one domain'.
What do you mean by saying the symlink did not stick?
I don't know about the connman specific support (seems to be there)
Connman can and has an option to enable or disable internal caching of DNS but I chose not to use it and just stick to the nameserver it suggests through it's `/run/connman/resolv.conf` and just use `nscd.service` instead.
BTW: interestingly, even when I symlinked /var/run/systemd/resolve/resolv.conf` to `/etc/resolv.conf` I had the same problem. My suspicion is that sytemd-resolved.service doesn't play well with other network managers other then systemd-networkd.
Last edited by Doron.Behar (2019-01-18 17:54:24)
Offline
I meant the connman specific support for systemd-resolved and mean people (not me ;-) would say that systemd-resolved doesn't even play nice with systemd-networkd
If you look around in the forum, you'll find it to be a constant source for DNS issues (that's why I asked itfp)
Offline
That's good to know.. I've had issues in the past where systemd-resolved.service had to be running otherwise name resolving wouldn't work at all, I wonder why was that.. Thanks a lot for the help BTW, I'll mark this as solved.
Offline