Re: 2038 problem and BIND.

[Alan Clegg]

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 problems, if care is not taken in BIND
 code. Or does BIND code is designed so that it relies on the OS to deal
 with this problem?

Note that signature expiration times are used to protect from replay
attacks.  If you are signing zones with expiration dates 28 years in the
future, you may want to consider if this is a good idea or not.

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.

I do also assume that there will be a few BIND releases between now and
then and that you will be upgrading accordingly.

AlanC



signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: 2038 problem and BIND.

[Tony Finch]

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 unsigned 32 bit
whereas time_t is typically signed. The error that kalpesh varyani pointed
out looked to me like bind was treating the expiry time as signed 32 bit.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users