North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
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, [email protected] wrote:
On Mon, 20 Oct 2003 16:31:45 EDT, "Steven M. Bellovin"
<[email protected]> said:
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.
OK, since you asked....
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?
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'.
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