CentOS VirtualBox 5 second latency on http request

I'm running centos 6.3 inside of VirtualBox 4.2.1 on my OSX 10.8.2 machine, and have encountered a latency issue I do not comprehend. Basically, every http request to anywhere has an additional 5000ms delay. Ping has no additional delay.

[vagrant@localhost ~]$ curl -o /dev/null https://google.com -w ""
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
110   220  110   220    0     0     42      0  0:00:05  0:00:05 --:--:--  7586
[vagrant@localhost ~]$ curl -o /dev/null https://google.com -w ""
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
110   220  110   220    0     0     42      0  0:00:05  0:00:05 --:--:--  7586
[vagrant@localhost ~]$ curl -o /dev/null https://google.com -w ""
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
110   220  110   220    0     0     42      0  0:00:05  0:00:05 --:--:--  7857
[vagrant@localhost ~]$ ping google.com
PING google.com (74.125.224.66) 56(84) bytes of data.
64 bytes from nuq04s07-in-f2.1e100.net (74.125.224.66): icmp_seq=1 ttl=63 time=7.64 ms
64 bytes from nuq04s07-in-f2.1e100.net (74.125.224.66): icmp_seq=2 ttl=63 time=6.26 ms
64 bytes from nuq04s07-in-f2.1e100.net (74.125.224.66): icmp_seq=3 ttl=63 time=8.69 ms
64 bytes from nuq04s07-in-f2.1e100.net (74.125.224.66): icmp_seq=4 ttl=63 time=7.89 ms
64 bytes from nuq04s07-in-f2.1e100.net (74.125.224.66): icmp_seq=5 ttl=63 time=5.99 ms
64 bytes from nuq04s07-in-f2.1e100.net (74.125.224.66): icmp_seq=6 ttl=63 time=8.64 ms

For the record, I have a ubuntu 12.04.1 virtual machine in the same VirtualBox/OSX environment, that does not experience the issue.

Ok, it turns out the issue was a DNS issue.

Basically the CentOS VirtualBox was configured to use a 10.0.2.3 DNS server that was internal to itself, but maybe conflicted with something on our network.

In any case, using a different DNS server resolved the issue.