Re: [sitefinder-tech-discuss] Pseudo code please

[Kee Hinckley <nazgul@somewhere.com>]

At 5:29 PM +0200 10/21/03, Bruce Campbell wrote:
> directory-did-you-mean thing).  Kee has raised a technical issue, which I
> feel has not been addressed by Verisign in any fashion apart from 'here is
> a solution which does not address all of your points'.
>
> Could we have a reply on that issue, or a least an acknowledgment that the
> issue has been raised?

I'd given up.  That line about not knowing why you'd want to resolve 
a host was such a good ending point :-).  But what the heck, let's 
try and explain the issue again.  Here's an example problem.

Verisign has stated that people who put non-existent hosts in their 
MX records (thus potentially bouncing their mail off of SiteFinder) 
should be more careful.

As I see it, that's a UI issue.  The interface for adding a mail host 
to DNS (and for that matter, for adding a pop server to a mail 
program, or an smtp server, or configuring an ftp server, or a 
vpn...) should check the user's input and make sure it exists.  In 
fact, in the web interfaces I've built, I do exactly that.  I check 
the user's data and make sure the provided host name returns an A 
record.  Yes, you should also check whether the service exists on the 
host, but that is a separate issue, with separate errors and lots of 
other issues.  The *first* step is to make sure the name they gave 
you was valid.

So.  Verisign has decided that for .com and .net, while they are the 
contractor in charge, that's not going to work.  If there is a typo 
in the domain name, we won't realize it.  So far we've had vague 
statements about how programs should "take into account" the fact 
that wildcard's are allowed at the root level.  That's very nice. 
But take into account how?  There are multiple technical problems 
here.

First, there's the simple one.  How exactly do I deal with finding 
out if the host exists given Verisign's current plans?  Is it real? 
Or is it Memorex?

Then life gets more interesting.  How do I generalize that code to 
work with all domains and all services?  After all, one can certainly 
imagine a TLD which wildcards MX for legitimate reasons.  Maybe the 
.space domain needs to route all email through a gateway that queues 
messages up by priority for interplanetary transmission.  So 
obviously I can't assume that just because there's a wildcard MX 
record that I *shouldn't* treat it as a legitimate mail server.  If 
you think that is far-fetched, consider that the .name registry does 
in fact do something similar.  But here's another scenario.  Suppose 
your web browser currently looks up the user entered address to see 
if it's valid, and if it isn't, it displays a page offering help to 
the user.  And then a particular domain offers a wildcard that goes 
to a web server that offers better help.  Clearly for *that* domain, 
the browser shouldn't change it's behavior to treat the address as 
invalid.  Shouldn't it?  But what if another registrar sets up a 
wildcard A record that simply returns a 404 error.  Now what?

In fact, if you think about it, you'll realize that if web browsers 
had, as Verisign suggests, taken into account the ability of a 
registry to have root wildcards, SiteFinder would not be possible!

So, yes, we have a real technical problem.  However I fail to see any 
way that it can be resolved in a general way without knowing the 
policies and services and intention of the registry responsible for 
the wildcard.  And that means that EVERY piece of code that does a 
lookup to validate user information has to be reexamined, and 
possibly changed, whenever ANY registry changes it's policies.

But go ahead.  Prove me wrong.  Show me the correct algorithm that 
always does the right thing for all registries.

--
Kee Hinckley
http://www.messagefire.com/         Next Generation Spam Defense
http://commons.somewhere.com/buzz/  Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.elistx.com/unsubscribe>