Opened 9 years ago
Closed 9 years ago
#14736 closed defect (fixed)
DNS server stops responding after number of gpg requests => Fixed in SVN
Reported by: | x-yuri | Owned by: | |
---|---|---|---|
Component: | network/NAT | Version: | VirtualBox 5.0.4 |
Keywords: | Cc: | ||
Guest type: | Linux | Host type: | Linux |
Description
Hi,
Steps to reproduce the issue:
$ mkdir vm1 $ cd $_ $ vagrant init ubuntu/trusty64 $ vagrant up $ vagrant ssh $ cat /etc/resolv.conf | grep nameserver nameserver 10.0.2.3 $ i=0; while true; do echo "--- $i"; gpg --delete-key --batch --yes D39DC0E3; gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 || { echo -e $? '\a'; break; }; sleep 5; : $(( i++ )); done --- 0 gpg: key "D39DC0E3" not found: eof gpg: D39DC0E3: delete key failed: eof gpg: requesting key D39DC0E3 from hkp server keys.gnupg.net gpg: key D39DC0E3: public key "Michal Papis (RVM signing)<mpapis@gmail.com>" imported gpg: no ultimately trusted keys found gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) --- 1 gpg: requesting key D39DC0E3 from hkp server keys.gnupg.net gpg: key D39DC0E3: public key "Michal Papis (RVM signing) <mpapis@gmail.com>" imported gpg: no ultimately trusted keys found gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) ... --- 11 gpg: requesting key D39DC0E3 from hkp server keys.gnupg.net gpgkeys: HTTP fetch error 6: Could not resolve host: keys.gnupg.net gpg: no valid OpenPGP data found. gpg: Total number processed: 0
After this you can't resolve this particular domain, until you relog in. Meanwhile, getaddrinfo
returns EAI_AGAIN
(Temporary failure in name resolution
). You can check this by compiling and running the following program:
#include <stdio.h> #include <sys/types.h> #include <sys/socket.h> #include <netdb.h> #include <string.h> int main(void) { int r; struct addrinfo hints, *res; memset(&hints, 0, sizeof (hints)); hints.ai_socktype = SOCK_STREAM; r = getaddrinfo("keys.gnupg.net", "11371", &hints, &res); // r = getaddrinfo("pool.sks-keyservers.net", "11371", &hints, &res); if (r) { printf("r: %hhi\n", r); // EAI_AGAIN printf("r: %s\n", gai_strerror(r)); } return 0; }
You can most likely reproduce it without vagrant
. Just start up some VM, make sure it has 10.0.2.3
as its resolver and run the last command. It doesn't always happen on 11th try however, so be patient and leave it for a while. It'll call you back soon :)
The host OS is Arch Linux, if anything.
More info can be found here: https://sourceware.org/ml/libc-help/2015-10/msg00012.html https://lists.gnupg.org/pipermail/gnupg-users/2015-October/054532.html https://github.com/protobox/protobox/issues/159 https://github.com/rvm/rvm/issues/3110#issuecomment-95161168
Regards, Yuri
Change History (6)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
I've just figured out, what's the difference between vagrant VMs and the ones created manually: https://forums.virtualbox.org/viewtopic.php?f=3&t=74243&p=343586 Vagrant VMs use dns proxy (--natdnsproxy1 on). And now I can reproduce it on non-vagrant VMs as well, after I do VBoxManage modifyvm NAME --natdnsproxy1 on
. So, to answer your question, yes, I use dns proxy.
comment:3 by , 9 years ago
Ok, I can reproduce it. The problem is that resolver library tries to contact nameserver via TCP instead of UDP. Unfortunately, DNS proxy doesn't currently support TCP.
What triggers the switch from UDP to TCP is the size of the answer. Some nameservers will supply Authority RRs in their answers and that makes replies too large.
Incidentally I happen to be currently on a network with the nameserver that doesn't do TCP either. So your program hangs for me on the host too. But if I change host's nameserver to google's 8.8.8.8
then the program works and does not use TCP. This is because my local nameserver supplies Authority RRs (which triggers switch to TCP), but google's nameserver doesn't supply Authority RRs, so its replies are small enough to stay in UDP.
comment:4 by , 9 years ago
A simpler way to reproduce this would be e.g.
$ nslookup -q=any pool.sks-keyservers.net. ;; Truncated, retrying in TCP mode. ...
comment:5 by , 9 years ago
Summary: | DNS server stops responding after number of gpg requests → DNS server stops responding after number of gpg requests => Fixed in SVN |
---|
This will be addressed in the next dot-dot releases of 5.0 and 4.3. For now only single server is used; if TCP connection to it fails, we won't try other servers - that would require much more extensive changes internally.
Do you use dns proxy or host resolver?