VirtualBox

Opened 8 years ago

Closed 8 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 Valery Ushakov, 8 years ago

Do you use dns proxy or host resolver?

comment:2 by x-yuri, 8 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 Valery Ushakov, 8 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 Valery Ushakov, 8 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 Valery Ushakov, 8 years ago

Summary: DNS server stops responding after number of gpg requestsDNS 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.

comment:6 by Frank Mehnert, 8 years ago

Resolution: fixed
Status: newclosed

Fix is part of VBox 5.0.10.

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use