nanog mailing list archives

Re: data request on Sitefinder


From: Bruce Campbell <bc-nanog () vicious dropbear id au>
Date: Tue, 21 Oct 2003 16:58:26 +0200 (CEST)


On Mon, 20 Oct 2003 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).

Its not just wildcards.  Although the IAB rejected VeriSign's previous
request to do specific response synthesis for IDN, it is conceivable that
someone else will do 'interesting' response synthesis, which applications
will be _unable_ to detect by querying for a wildcard.

( A similar problem to Randy's 'how do I tell which nameserver gave me
  this response, without requerying?' )

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.

Yes, which implies that many applications would need to change
'gethostbyname()' calls to 'getrealhostbyname()' (or whatever).

Whilst many _popular_ applications can be patched in a relatively quick
timeframe, the more subtle implications of large scale synthesis
deployment will probably take much longer to be understood, let alone
patches being deployed, particular with less popular applications.

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'.

draft-bcampbell-non-wildcard-00 was submitted last Tuesday to the rfc
editor and should appear in time to be discussed during dnsext in Minnie.

Even if its approved instantly (very unlikely, as I've suggested using the
last reserved header bit), and relevant authoritative nameservers are
upgraded in short order, there is a huge implied change to applications
and libraries, which extends the deployment timeline tremendously.

To answer Steve's question, it would be at least 3 months to patch my
employer's applications to work around a possible .com or .net wildcard,
and at least 6 months to do it in a fashion which does not break
established standards.

--==--
Bruce.


Current thread: