North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: data request on Sitefinder
On Mon, 20 Oct 2003 Valdis.Kletnieks@vt.edu wrote: > On Mon, 20 Oct 2003 16:31:45 EDT, "Steven M. Bellovin" <firstname.lastname@example.org> 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.