VirtualBox

Ticket #14736 (closed defect: fixed)

Opened 2 years ago

Last modified 2 years ago

DNS server stops responding after number of gpg requests => Fixed in SVN

Reported by: x-yuri Owned by:
Priority: minor 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

comment:1 Changed 2 years ago by vushakov

Do you use dns proxy or host resolver?

comment:2 Changed 2 years ago by x-yuri

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 Changed 2 years ago by vushakov

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 Changed 2 years ago by vushakov

A simpler way to reproduce this would be e.g.

$ nslookup -q=any pool.sks-keyservers.net.
;; Truncated, retrying in TCP mode.
...

comment:5 Changed 2 years ago by vushakov

  • Summary changed from DNS server stops responding after number of gpg requests to 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.

comment:6 Changed 2 years ago by frank

  • Status changed from new to closed
  • Resolution set to fixed

Fix is part of VBox 5.0.10.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use