On 9/19/2010 6:57 AM, kalpesh varyani wrote:
I would just like to know, how BIND takes care of the 2038 problem.
Since now DNSSEC has a lot to do with timings, there could be issues if
someone would set the signature expiry time to a large value (possibly
after Y2K38). This can create
On Mon, 20 Sep 2010, Alan Clegg wrote:
All signature expire times are in MMDDHHMMSS format in the zone data
and are handled correctly as far as BIND deals with it.
If your OS deals with the 2038 issue correctly, then BIND will as well.
RFC 4034 says that the signature validity times are
Date: Mon, 20 Sep 2010 11:03:31 +0200
From: Kalman Feher kalman.fe...@melbourneit.com.au
Sender: bind-users-bounces+oberman=es@lists.isc.org
Apologies in advance for the longer than intended reply.
I've spent a lot of time reviewing documents regarding timing values and
they vary
On 20/09/10 6:09 PM, Kevin Oberman ober...@es.net wrote:
Date: Mon, 20 Sep 2010 11:03:31 +0200
From: Kalman Feher kalman.fe...@melbourneit.com.au
Sender: bind-users-bounces+oberman=es@lists.isc.org
Apologies in advance for the longer than intended reply.
I've spent a lot of time
I'm trying to get named and my management tool cooperating
with named on DNSSEC key management.
I'm seeing behavior with auto-signing that doesn't strictly
match the ARM and would like to know what's correct. I'm
also not clear on what named expects for some cases.
4 questions after a little
[I apologize in advance if this is a double post. I'm not sure if my
original went through]
I was implementing ISC Bind 9.5 at a client site last month and had a single
zone that accepted DDNS updates only from the ISC DHCP service.
The environment consisted of a Master BIND server and almost
It probably has something to do with the packet size. You can't easily fit 25
NS records into a 512 byte UDP packet.
You really don't want to have more than 8 published NS records for most
purposes.
Chris Buxton
BlueCat Networks
On Sep 20, 2010, at 2:30 PM, Christopher Cain wrote:
[I
7 matches
Mail list logo
