On 2011-03-01 21:00, Torinthiel wrote:
On 03/01/11 20:17, fakessh @ wrote:
And about OVH - I don't know if it's related, but I've asked Polish OVH
how about providing DNSSEC, as .pl is planned to be signed mid-year, and
they've answered me they will probably be ready. This might, or might
not
One other thing: on the filesystem in which reside directories that
house the zone files, set the mount option noatime. This will
improve the performance of re-reading the zone files because it will
take out the necessity of updating a time-stamp for each read.
-DTK
On Mon, Feb 28, 2011 at
Running off SSDs has also proved to help startup/reload times in our usage.
Dan Durrer
No-IP
On Mar 2, 2011, at 5:32 AM, david klein r...@nachtmaus.us wrote:
One other thing: on the filesystem in which reside directories that
house the zone files, set the mount option noatime. This will
On 3/1/2011 5:27 PM, Kevin Darcy wrote:
See my other post. This is designed-in behavior for Cisco GSSes, since
there is no service unavailable, try again later RCODE.
- Kevin
When the question is what is the ip address of 'foo' an answer of the
web server is down in nonsensical.
--
Dave
On Mar 1, 2011, at 5:27 PM, Kevin Darcy wrote:
See my other post. This is designed-in behavior for Cisco GSSes,
since there is no service unavailable, try again later RCODE.
Yes[0].
W
[0]: there is no service unavailable, try again later RCODE.
On 3/2/2011 10:34 AM, David Sparro wrote:
On 3/1/2011 5:27 PM, Kevin Darcy wrote:
See my other post. This is designed-in behavior for Cisco GSSes, since
there is no service unavailable, try again later RCODE.
When the question is what is the ip address of 'foo' an answer of
the web server
What's really strange is that when we attempt a query, be it DIG or an
attempt to browse tools.cisco.com, they send some sort of query back to us
from/to UDP 53. We drop it at the firewall due to some sort of sanity
check so I can't see the contents. This is in addition to the SERVFAIL
message.
On 3/2/2011 1:20 PM, Kevin Darcy wrote:
I'm not saying I agree with this perspective, only that I've dealt with
load-balancer vendors enough (Cisco in particular) to understand that
this is where they're coming from.
Besides, what alternative is there? If the load-balancer returns an
address
On Mar 2, 2011, at 1:20 PM, Kevin Darcy wrote:
On 3/2/2011 10:34 AM, David Sparro wrote:
On 3/1/2011 5:27 PM, Kevin Darcy wrote:
See my other post. This is designed-in behavior for Cisco GSSes,
since
there is no service unavailable, try again later RCODE.
When the question is what is
On 3/1/2011 6:30 PM, Mark Andrews wrote:
In message4d6d7268.1080...@chrysler.com, Kevin Darcy writes:
I got a trouble ticket on this too.
From the looks of things, Cisco is using GSSes to load-balance this
site. GSSes return SERVFAIL if all of the resources behind the
load-balancer are down
A few options:
1: once the LB knows that all back-ends are down, it can continue to answer
with the correct A, but drop the TTL to be much shorter -- this allows
things to recover faster.
This would work well because the actually web site wasn't down, at least not
yesterday. If I substituted the
On Mar 2, 2011, at 1:21 PM, Mike Bernhardt wrote:
What's really strange is that when we attempt a query, be it DIG or an
attempt to browse tools.cisco.com, they send some sort of query back
to us
from/to UDP 53
Many GSLB solutions attempt to figure out what the best location to
serve
On Mar 2, 2011, at 8:49 PM, ShanyiWan wrote:
bind-dlz (BDB as backend)
[root@flyinweb ~]# dig @ns1.dnssafe.cn www.djytest.com
; DiG 9.7.0-P2 @ns1.dnssafe.cnwww.djytest.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status:
In addition to my pvt email Evan
The dev link page still shows 9.7.3 as current production, no 9.8.0, but
going to all downloads shows 9.8.0 as current production, and as things
happen in three's ...
bind-9.8.0.tar.gz clicking on this yields a file called
bind-980targzno periods,
14 matches
Mail list logo
