North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: data request on Sitefinder

  • From: Howard C. Berkowitz
  • Date: Mon Oct 20 17:24:24 2003

At 5:09 PM -0400 10/20/03, Valdis.Kletnieks@vt.edu wrote:
On Mon, 20 Oct 2003 16:31:45 EDT, "Steven M. Bellovin" <smb@research.att.com> said:
 A number of people havce responded that they don't want to be forced to
 pay for a change that will benefit Verisign.  That's a policy issue I'm
 trying to avoid here.  I'm looking for pure technical answers -- how
 much lead time do you need to make such changes safely?
OK, since you asked....

At least from where I am, the answer will depend *heavily* on whether Verisign
deploys something that an end-user program can *reliably* detect if it's been
fed a wildcard it didn't expect. Note that making a second lookup for '*.foo'
and comparing the two answers is specifically *NOT* acceptable due to the added
lookup latency (and to some extent, the attendant race conditions and failure
modes as well).

Also note that it has to be done in a manner that can be tested by an
application - there will be a *REAL* need for things like Sendmail to be
able to test for wildcards *without the assistance* of a patched local DNS.

And yes, this means the minimum lead time to deploy is 'amount of time to write
a "Wildcard Reply Bit" I-D, advance through IETF to some reasonable point on
standards track, and then upgrade DNS, end host resolvers, and applications'.
You make an assumption here -- one with which I agree completely -- but that certainly wasn't followed during the Sitefinder debacle. The assumption is that the IETF provides a tested mechanism for disseminating information and making comments.

Verisign claims that they had tested their ideas with a Verisign-selected group of organizations, and made their commercial decisions based on the proprietary data it generated from those organizations.