Question about cache reload

[Lawrence K. Chen, P.Eng.]

----- Original Message -----

> Firstly you should not use NSEC3 unless you NEED to use NSEC3, NSEC
> is more than sufficient for most zones.  NSEC3 is more expensive
> for both servers and clients.  99.999% of zones (forward and reverse)
> DO NOT need to use NSEC3.  They derive NO benefit from NSEC3 compared
> to using NSEC.  In most case NSEC3 is actually a negative as not
> only is is more computationally expensive it is harder to debug.
> 
> NSEC3 is pointless for IP6.ARPA, IN-ADDR.ARPA and any other similarly
> structured zones.  The structure defeats any attempt to prevent zone
> walking.
> 
> For most forward zones preventing zone walking does NOTHING except
> give warm fuzzy feelings.  It does NOT make your machines any safer.
> Yes I know that this is against all the advice you have received
> in the past but really it doesn't appreciably help and you are
> deluding yourself if you think it does.
> 
> Mark

I remember when I first started working on DNSSEC...on whether NSEC3 should be done or not.  signing the zone was taking either forever or forever-plus.....  Moving my master server from a V240 to a T2000 helped....

But, we then got some outside secondaries.  And, initially they didn't support NSEC3.  That would have to wait until they upgraded their server hardware/OS before they would build bind with that support?  So, I thought that answered whether we would do NSEC3 or not.  But, then our IT Security group weighed in....so we're doing NSEC3.  We'll just hold off on having outside secondaries.

Though since then, we've only had one major interruption of our connectivity...and its was due the packet inspection appliance that IT Security runs.  The log volume in it had filled up, so it stopped passing traffic.  It did expose some problems with in local DNS resolution, that someday I should do something about.

T2000 was still taking what was considered to be too long....people around here expect that when I make complete their dns change request, that they can immediately look up host and see the new IP.  Ignoring that they queried all the caching servers on campus before the request was done, so the old info will be there for up to 1 day.  Some people will request that the TTL be lowered in advance of the change, though they don't necessarily allow a day between the two.

Later I had the choice of moving to a T5120 or an X4100, where I found that the X4100 was faster than the T5120.  My master server is currently an X4170.  And, later our automation includes flushing our zones from the caching servers....  Also have a script to flush other zones when needed, but that process can't tell what zones were updated...so it can't tell what zone to flush. (one is see if files associated with our signed zones changed, do signing, call rndc reload and then over time flush caching servers in some order...the other is if any file has changed, do rndc reload....)

Wonder what I'll have when we scrap some 400+ Solaris servers ... by year end?

-- 
Who: Lawrence K. Chen, P.Eng. - W0LKC - Senior Unix Systems Administrator
For: Enterprise Server Technologies (EST) -- & SafeZone Ally
Snail: Computing and Telecommunications Services (CTS)
Kansas State University, 109 East Stadium, Manhattan, KS 66506-3102
Phone: (785) 532-4916 - Fax: (785) 532-3515 - Email: lkchen at ksu.edu
Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library