North American Network Operators Group

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

Re: data request on Sitefinder

  • From: Bruce Campbell
  • Date: Tue Oct 21 11:00:56 2003

On Mon, 20 Oct 2003 [email protected] wrote:

> On Mon, 20 Oct 2003 16:31:45 EDT, "Steven M. Bellovin" <[email protected]>  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.