>
> My name is Kevin and I'm working with the Argentina ccTLD team to upgrade
> our local NS systems and our goal is to load the .ar, .com.ar and
> subsequent zones using DLZ. Our other task was to deploy DNSSEC here and
> start signing our TLDs, but according to the e-mails I've read (dated
> 200
- "Hauke Lampe" wrote:
> On 14.09.2010 19:32, cybers...@comcast.net wrote:
>
> > Today I was given access to a Linux box on the Verizon network that
> is using their DNS server 71.252.0.12, which is affected by this
> problem.
>
> Your nameserver software is case-sensitive where it should
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14.09.2010 19:32, cybers...@comcast.net wrote:
> Today I was given access to a Linux box on the Verizon network that is using
> their DNS server 71.252.0.12, which is affected by this problem.
Your nameserver software is case-sensitive where it s
Sign them offline or out of band using a database trigger to initiate the
signing. Your schema might need to change a little though.
For a ccTLD, your private key should probably be secure and offline anyway.
Zone updates should be reasonably automatable using either the BIND dnssec
tools or any o
This is getting very involved - or I'm getting confused. Maybe
both :-)
I've tried to work out how this can work, but each solution
seems to uncover another question. I don't want to experiment
to get to "seems to work", only to find the next problem much later...
There doesn't seem to be muc
We have an average of around 11 QPS but we update zones daily (our servers
store NS delegations mostly and government sites) so it's a daily task to
approve new domains and update/reload zones.
We have a good DB infrastructure built in and the fact of having a MySQL server
that can replicate i
On Sep 14, 2010, at 12:15 PM, Kevin Mai wrote:
> My name is Kevin and I'm working with the Argentina ccTLD team to upgrade our
> local NS systems and our goal is to load the .ar, .com.ar and subsequent
> zones using DLZ. Our other task was to deploy DNSSEC here and start signing
> our TLDs, bu
Hi,
My name is Kevin and I'm working with the Argentina ccTLD team to upgrade our
local NS systems and our goal is to load the .ar, .com.ar and subsequent zones
using DLZ. Our other task was to deploy DNSSEC here and start signing our TLDs,
but according to the e-mails I've read (dated 2006 mo
- "Torsten" wrote:
> Am Tue, 14 Sep 2010 08:23:03 +0200
> schrieb Torsten :
>
> > Am Tue, 14 Sep 2010 05:15:16 + (UTC)
> > schrieb cybers...@comcast.net:
> >
> > >
> > >
> > >
> > > Hello List,
> > >
> > >
> > >
> > > I've run into an issue that has me stumped for the time being
So the cache servers are HA behind something (F5 LTM, Cisco local director,
something else). Are the authoritative servers? It would seem sensible to do
the same with them. That way a timeout only occurs if the whole HA cluster
is unavailable.
You can alleviate even that situation by seeding the ca
>From our AT&T based network it works but the individual server digs (dns1 &
>dns2) were significantly slower than the dig in which I didn't specify a
>server.
$ dig @dns2.mbc.irides.com www-mbclive.mbc.irides.com
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> @dns2.mbc.irides.com
www-mbcli
I have been working on building out a couple of large data centres and
have been struggling with how to set up the systems so that we get a high
resilience, highly responsive DNS service in the presence of failing
equipment.
The configuration we have adopted includes a layer of BIND 9.6.x servers
12 matches
Mail list logo
