[yonatan]

maybe the DNS server finished its monthly bandwidth and it's limited to 10Mbps?

[freshwire]

A local caching nameserver is faster than forwarding your DNS queries to
another server and waiting for it to do your work. There's already a big thread
about that somewhere here on the forum.

As long as your server doesn't sit still 99.9% of the time

[ictdude]

Jeff66 wrote:
> | Domain | Google | EasyDNS | OpenDNS | OVH |

Do the same with a caching bind on 127.0.0.1 to wee what I'm talking about :-)
--
Felix
OVH Team

Yeah cached queries are always faster because its on the local server.
But before it is cached it first need to contact a DNS server. Well any way some response here. So at least i know am not the only one. And for now everybody already found a workaround or more a solution to use other DNS servers. And of course you can use those other DNS servers to locally cache those queries on your local server. But for now i can see whats the case here. Thanx already for all reply guys.

[Myatu]

No.
213.186.33.99 is not "one" DNS server, it's "many DNS servers". To know which
one might be bugged, I need to know the IP you're accessing it from.

I've had lots of problems resolving external websites (ie., google.com, ubuntu mirror [non-OVH]) from all the mC Cloud servers I've created at one point or another (one you could try is 188.165.52.112, but you'll have to change the nameserver to 213.186.33.99 first as it goes to my internal server currently - you have my permission to change it for testing purposes). There's been some threads about this on the cloud-list as well.

> I've noticed this a while ago, and with new systems you will notice it
> has both 127.0.0.1 and OVH's 213.something nameserver; and they've
> conveniently installed Bind9 for you (for the 127.0.0.1).

That has always been like this (with only very few exceptions)

I hadn't noticed it on my Proxmox distro, but I could be mistaken as I generally change the nameserver as one of the first things I do with a new install.

> I generally dump Bind9 right away, in favor for the PowerDNS recursor

A local caching nameserver is faster than forwarding your DNS queries to
another server and waiting for it to do your work. There's already a big thread
about that somewhere here on the forum.
--
Felix
OVH Team

Definitely. PowerDNS is DNS and a recursor daemon (separate packages) like Bind9; I may have confused some, by mentioning OpenDNS in the same sentence - OpenDNS is not software. Though, OpenDNS can serve as a good pre-cache instead of your own recursor - it still improves speeds in general, IMO.

[yonatan]

yonatan wrote:
> I am facing this issue also, seems to be only for machines in RBX-3
> RBX-3:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51101
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58947
>
> RBX-2
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16266
>
> P-19
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53064
>
> RBX:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18253

What issue?
--
Felix
OVH Team

Hi Felix,
look at the Query time.

;; Query time: 3540 msec
;; SERVER: 213.186.33.99#53(213.186.33.99)
;; WHEN: Wed Jul 7 17:09:21 2010
;; MSG SIZE rcvd: 329

;; Query time: 3335 msec
;; SERVER: 213.186.33.99#53(213.186.33.99)
;; WHEN: Wed Jul 7 17:01:23 2010
;; MSG SIZE rcvd: 260

I am not sure the time wait comes from akamai or google.


i test now to Microsoft also same issue:

dig microsoft.com @213.186.33.99

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> microsoft.com @213.186.33.99
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49989
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 5

;; QUESTION SECTION:
;microsoft.com.                 IN      A

;; ANSWER SECTION:
microsoft.com.          1155    IN      A       207.46.197.32
microsoft.com.          1155    IN      A       207.46.232.182

;; AUTHORITY SECTION:
microsoft.com.          66481   IN      NS      ns3.msft.net.
microsoft.com.          66481   IN      NS      ns4.msft.net.
microsoft.com.          66481   IN      NS      ns5.msft.net.
microsoft.com.          66481   IN      NS      ns1.msft.net.
microsoft.com.          66481   IN      NS      ns2.msft.net.

;; ADDITIONAL SECTION:
ns1.msft.net.           3355    IN      A       65.55.37.62
ns2.msft.net.           2219    IN      A       64.4.59.173
ns3.msft.net.           1871    IN      A       213.199.161.77
ns4.msft.net.           1599    IN      A       207.46.75.254
ns5.msft.net.           2219    IN      A       65.55.226.140

;; Query time: 4186 msec
;; SERVER: 213.186.33.99#53(213.186.33.99)
;; WHEN: Wed Jul  7 19:46:33 2010
;; MSG SIZE  rcvd: 241

do you need the server name?

the location is:
Datacentre : rbx3
Rack : 41C16

I consider under 300ms as OK to work with, but this is a very high value, so must be looked at , considering the great internal connection and servers in rbx1/2/p19.

[kro]

yonatan wrote:
> I am facing this issue also, seems to be only for machines in RBX-3
> RBX-3:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51101
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58947
>
> RBX-2
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16266
>
> P-19
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53064
>
> RBX:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18253

What issue?
--
Felix
OVH Team

[kro]

Jeff66 wrote:
> | Domain | Google | EasyDNS | OpenDNS | OVH |

Do the same with a caching bind on 127.0.0.1 to wee what I'm talking about :-)
--
Felix
OVH Team

[yonatan]

I am facing this issue also, seems to be only for machines in RBX-3

RBX-3:

dig www.nasa.gov @213.186.33.99

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> www.nasa.gov @213.186.33.99
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51101
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 9, ADDITIONAL: 0

;; QUESTION SECTION:
;www.nasa.gov.                  IN      A

;; ANSWER SECTION:
www.nasa.gov.           300     IN      CNAME   www.nasa.gov.speedera.net.
www.nasa.gov.speedera.net. 120  IN      CNAME   www.nasa.gov.edgesuite.net.
www.nasa.gov.edgesuite.net. 3322 IN     CNAME   a1718.x.akamai.net.
a1718.x.akamai.net.     20      IN      A       213.155.154.88
a1718.x.akamai.net.     20      IN      A       213.155.154.96

;; AUTHORITY SECTION:
x.akamai.net.           1153    IN      NS      n5x.akamai.net.
x.akamai.net.           1153    IN      NS      n6x.akamai.net.
x.akamai.net.           1153    IN      NS      n7x.akamai.net.
x.akamai.net.           1153    IN      NS      n8x.akamai.net.
x.akamai.net.           1153    IN      NS      n0x.akamai.net.
x.akamai.net.           1153    IN      NS      n1x.akamai.net.
x.akamai.net.           1153    IN      NS      n2x.akamai.net.
x.akamai.net.           1153    IN      NS      n3x.akamai.net.
x.akamai.net.           1153    IN      NS      n4x.akamai.net.

;; Query time: 3540 msec
;; SERVER: 213.186.33.99#53(213.186.33.99)
;; WHEN: Wed Jul  7 17:09:21 2010
;; MSG SIZE  rcvd: 329


dig google.com @213.186.33.99

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> google.com @213.186.33.99
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58947
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             281     IN      A       209.85.227.106
google.com.             281     IN      A       209.85.227.147
google.com.             281     IN      A       209.85.227.99
google.com.             281     IN      A       209.85.227.103
google.com.             281     IN      A       209.85.227.104
google.com.             281     IN      A       209.85.227.105

;; AUTHORITY SECTION:
google.com.             268217  IN      NS      ns3.google.com.
google.com.             268217  IN      NS      ns4.google.com.
google.com.             268217  IN      NS      ns1.google.com.
google.com.             268217  IN      NS      ns2.google.com.

;; ADDITIONAL SECTION:
ns1.google.com.         267622  IN      A       216.239.32.10
ns2.google.com.         267622  IN      A       216.239.34.10
ns3.google.com.         267622  IN      A       216.239.36.10
ns4.google.com.         267622  IN      A       216.239.38.10

;; Query time: 3335 msec
;; SERVER: 213.186.33.99#53(213.186.33.99)
;; WHEN: Wed Jul  7 17:01:23 2010
;; MSG SIZE  rcvd: 260

RBX-2

 dig facebook.com @213.186.33.99

; <<>> DiG 9.3.4-P1 <<>> facebook.com @213.186.33.99
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16266
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 5, ADDITIONAL: 5

;; QUESTION SECTION:
;facebook.com.                  IN      A

;; ANSWER SECTION:
facebook.com.           3600    IN      A       69.63.181.11
facebook.com.           3600    IN      A       69.63.181.12
facebook.com.           3600    IN      A       69.63.189.11
facebook.com.           3600    IN      A       69.63.189.16

;; AUTHORITY SECTION:
facebook.com.           123339  IN      NS      ns3.facebook.com.
facebook.com.           123339  IN      NS      ns4.facebook.com.
facebook.com.           123339  IN      NS      ns5.facebook.com.
facebook.com.           123339  IN      NS      ns1.facebook.com.
facebook.com.           123339  IN      NS      ns2.facebook.com.

;; ADDITIONAL SECTION:
ns1.facebook.com.       1194    IN      A       204.74.66.132
ns2.facebook.com.       1194    IN      A       204.74.67.132
ns3.facebook.com.       1194    IN      A       69.63.178.21
ns4.facebook.com.       1196    IN      A       69.63.186.49
ns5.facebook.com.       1196    IN      A       69.63.176.200

;; Query time: 9 msec
;; SERVER: 213.186.33.99#53(213.186.33.99)
;; WHEN: Wed Jul  7 17:02:02 2010
;; MSG SIZE  rcvd: 264

P-19

 dig cnn.com @213.186.33.99

; <<>> DiG 9.6.1-P1 <<>> cnn.com @213.186.33.99
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53064
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;cnn.com.                       IN      A

;; ANSWER SECTION:
cnn.com.                300     IN      A       157.166.224.25
cnn.com.                300     IN      A       157.166.224.26
cnn.com.                300     IN      A       157.166.226.25
cnn.com.                300     IN      A       157.166.226.26
cnn.com.                300     IN      A       157.166.255.18
cnn.com.                300     IN      A       157.166.255.19

;; AUTHORITY SECTION:
cnn.com.                29653   IN      NS      ns3.timewarner.net.
cnn.com.                29653   IN      NS      ns5.timewarner.net.
cnn.com.                29653   IN      NS      ns1.timewarner.net.

;; ADDITIONAL SECTION:
ns1.timewarner.net.     3600    IN      A       204.74.108.238
ns3.timewarner.net.     3600    IN      A       199.7.68.238
ns5.timewarner.net.     3600    IN      A       204.74.109.238

;; Query time: 58 msec
;; SERVER: 213.186.33.99#53(213.186.33.99)
;; WHEN: Wed Jul  7 15:02:02 2010
;; MSG SIZE  rcvd: 237

RBX:

dig paypal.com @213.186.33.99

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> paypal.com @213.186.33.99
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18253
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;paypal.com.                    IN      A

;; ANSWER SECTION:
paypal.com.             3600    IN      A       64.4.241.45
paypal.com.             3600    IN      A       64.4.241.61
paypal.com.             3600    IN      A       66.211.169.66

;; AUTHORITY SECTION:
paypal.com.             3600    IN      NS      ppns1.den.paypal.com.
paypal.com.             3600    IN      NS      ppns1.phx.paypal.com.
paypal.com.             3600    IN      NS      ppns2.den.paypal.com.
paypal.com.             3600    IN      NS      ppns2.phx.paypal.com.

;; Query time: 140 msec
;; SERVER: 213.186.33.99#53(213.186.33.99)
;; WHEN: Wed Jul  7 17:05:44 2010
;; MSG SIZE  rcvd: 164

* note to ovh staff:

reboot the server into rescue run the hardware test ,
then send a ticket =P

[Jeff66]

I've just tested the speed of various DNS servers for some popular domains to see how they compare.
As you can see OVH's is extremely slow and often times out, with OpenDNS being the quickest. This is from my server at 188.165.193.94

+-------------------------+------------+------------+------------+------------+
| Domain                  | Google     | EasyDNS    | OpenDNS    | OVH        |
+-------------------------+------------+------------+------------+------------+
| twitter.com             |    11 msec |   100 msec |     5 msec |  5031 msec |
+-------------------------+------------+------------+------------+------------+
| facebook.com            |    11 msec |   100 msec |     5 msec |  4706 msec |
+-------------------------+------------+------------+------------+------------+
| wordpress.org           |    11 msec |    99 msec |     6 msec |  5218 msec |
+-------------------------+------------+------------+------------+------------+
| ovh.net                 |    11 msec |    99 msec |     6 msec |            |
+-------------------------+------------+------------+------------+------------+
| google.co.uk            |    53 msec |   147 msec |     6 msec |            |
+-------------------------+------------+------------+------------+------------+
| bbc.co.uk               |    11 msec |   209 msec |     5 msec |  5902 msec |
+-------------------------+------------+------------+------------+------------+

[kro]

Myatu wrote:
> I think OVH changed it to only resolve local (read: OVH) addresses, and

No.
213.186.33.99 is not "one" DNS server, it's "many DNS servers". To know which
one might be bugged, I need to know the IP you're accessing it from.

> I've noticed this a while ago, and with new systems you will notice it
> has both 127.0.0.1 and OVH's 213.something nameserver; and they've
> conveniently installed Bind9 for you (for the 127.0.0.1).

That has always been like this (with only very few exceptions)

> I generally dump Bind9 right away, in favor for the PowerDNS recursor

A local caching nameserver is faster than forwarding your DNS queries to
another server and waiting for it to do your work. There's already a big thread
about that somewhere here on the forum.
--
Felix
OVH Team

[freshwire]

I have always switched over to using djbdns dnscache. I don't like to depend on OVH to resolve things for me... it will just cause problems if it's unavailable... or the above happens

[ictdude]

I just assumed it OVH's DNS server was down, as it's always worked OK for me, until yesterday.

I think what Myatu is telling us is more logic. A company with 70 or
80.000 servers will have will have more dns servers running. With loadbalancing. So they will not be down they need it to install new servers, The scripts will use dns to resolve. Well you can do a little test and ping one of the servers in the OVH network. Set your server to the DNS IP of OVH network. Then login with ssh or so and try to ping one of the internal servers. And ping a site like google or so. If the internal ping is ok and other not then Myatu is right.

[Jeff66]

Would be nice if OVH let us know about this. I always thought OVH DNS could be used. guess not...

I just assumed it OVH's DNS server was down, as it's always worked OK for me, until yesterday.

[ictdude]

I had the same problem yesterday on my dedicated server, nothing was resolving using OVH's DNS.

I switched to Google's public DNS servers.
I didn't want to use OpenDNS because they return an IP address even if there's no record, and I thought that might cause problems.

Would be nice if OVH let us know about this. I always thought OVH DNS could be used. guess not...

[Jeff66]

I had the same problem yesterday on my dedicated server, nothing was resolving using OVH's DNS.

I switched to Google's public DNS servers.
I didn't want to use OpenDNS because they return an IP address even if there's no record, and I thought that might cause problems.

[Myatu]

OpenDNS is anycast to your nearest server; so even if it's a US IP, you might end up requesting from a server in, say, Germany.

I did a performance test a while ago, when I was having issues with slow responses using OVH as the resolver.



OVH is that orange line, way at the bottom. The black and brown lines are my local DNS servers, both of which (at that time - not anymore) used OpenDNS as the recursor (Yellow). The advantage was that things were already pre-cached by OpenDNS before it entered my local cache. See http://www.myatus.co.uk/2009/12/14/d...arking-update/ for the whole thing...

I currently have PowerDNS as the recursor instead of OpenDNS though, because I found the domain-hijacking a bit tedious at times (it *really* messed up Proxmox for some reason and had to build at cron/script to fix it nightly). But I could have gone for Google's Public DNS or BT (which were also blistering fast and don't hijack).

[yonatan]

I think OVH changed it to only resolve local (read: OVH) addresses, and for anything else you're responsible to provide your own or a 3rd party nameserver.

I've noticed this a while ago, and with new systems you will notice it has both 127.0.0.1 and OVH's 213.something nameserver; and they've conveniently installed Bind9 for you (for the 127.0.0.1).

I generally dump Bind9 right away, in favor for the PowerDNS recursor and/or OpenDNS (208.67.222.222 and 208.67.220.220).

Hey Myatu ,
don't you think a local resolver is better?
i use local resolvers ( also use an EG server as second DNS for my proxmox ).

what is the benefit of using these US DNS servers? won't it be slower to resolve?

[Myatu]

I think OVH changed it to only resolve local (read: OVH) addresses, and for anything else you're responsible to provide your own or a 3rd party nameserver.

I've noticed this a while ago, and with new systems you will notice it has both 127.0.0.1 and OVH's 213.something nameserver; and they've conveniently installed Bind9 for you (for the 127.0.0.1).

I generally dump Bind9 right away, in favor for the PowerDNS recursor and/or OpenDNS (208.67.222.222 and 208.67.220.220).

[ictdude]

Strange incident. Noticed this a month a go on 2 of my VM's in Proxmox.
The DNS server of OVH dont resolve dns names any more. So i just
edit the network and use a dns server other then OVH and this worked.
Now a other VM's same issue. Same solution work around. Did use a other dns server for name resolution. Is OVH blocking queries from dns clients ?

I did notice this because i had a mail queue mail could not get out.
Did change to other dns server and all ok. Had this a year ago also.

Do somebody or OVH know whats wrong here ? Its not my system other dns servers resolve no problems. OVH dns just stop resolving names to IP.