Re: DNS security and spoofing (Re: [cobalt-security] Anyone else get this error?)

["E.B. Dreger" <eddy+public+spam@xxxxxxxxxxxxxxxxx>]

EC> Date: 30 Dec 2002 21:39:46 +0300
EC> From: Eugene Crosser


EC> > Likewise, one could have a centrally-distributed copy of
EC> > the hints file.
EC>
EC> The difference is that the public key does not change [as
EC> often as the hints file may].  You may need to download and
EC> verify the public key only once in the lifetime of your
EC> server.  And then check the hints file several times a year.

Definitely true.

A quick recap for those following this thread:

	1) Obtain public key
	2) Verify out-of-band

	3) Periodically download public key and hints on one
	   server
	4) Alert admin if either has changed
	5) Verify out-of-band
	6) Redistribute to other servers via secure network and
	   protocol

Downloading and checking the key technically isn't needed.  If
the key truly has changed, the hints' signature will raise a
flag.  If/when this happens, one should know to check for a key
change, and verify it OOB.

I'd also like to point out that what Eugene has been posting is
_absolutely critical_ if one's resolvers are on a shared ethernet
segment.  Verifying the authenticity of the hints file allows one
to detect any sort of bogus records.

It's only 99.999% critical if one's resolvers aren't on a shared
segment; can one truly trust one's path to the roots?  Routes
_do_ get roguecasted now and then... I'd hope no provider would
be dumb enough to announce a root-containing netblock, but I'd
bet against that possibility.

Thanks for your many good ideas and pointing out that signed
records now are available.  That certainly is very useful.


Eddy
--
Brotsman & Dreger, Inc. - EverQuick Internet Division
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 (785) 865-5885 Lawrence and [inter]national
Phone: +1 (316) 794-8922 Wichita

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist@xxxxxxxxx>
To: blacklist@xxxxxxxxx
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <blacklist@xxxxxxxxx>, or you are likely to
be blocked.