Re: [sitefinder-tech-discuss] A technical question

[Kee Hinckley <nazgul@somewhere.com>]

At 9:45 PM -0400 10/7/03, Andrew Newton wrote:
> One method for conducting this check would be to compare the result 
> of a query for the wildcard (e.g. *.com) to the result of your 
> domain lookup.  With caching, this should be efficient.

Yes, I started to write that code.  But it raises some interesting issues too.

First of all, in this particular case my primary concern is whether 
or not the domain in question can conceivably receive email (insofar 
as one can tell short of trying to connect to a mail server).

Previously the query would be pretty straightforward.
1. If NXDOMAIN, the answer is no, bail.
2. If A record exists, answer is yes, bail.
3. If MX record exists, answer is yes, bail.
4. No.

Now we have a more complex situation.
1. If any of the A records for this domain are different from any of 
the A records for *.tld, then the answer is yes, bail.
2. If any of the MX records for this domain are different from any of 
the MX records for *.tld, then the answer is yes, bail.
3. No.

Of course this code introduces an interesting ambiguity in the 
system.  It now becomes possible to have a domain that appears not to 
exist.  All that's necessary is to use the same DNS entries that 
Verisign is using.  That's not relevant to my particular application, 
but I do worry about the security consequences of that.

I think that is the most complete and safest test I can do (comments 
would be appreciated).  However it's not perfect.  In particular, it 
completely depends on one single statement that I found on the only 
technical document I could find on your site.  That page stated that 
the lookup for *.tld would be "deterministic".  I assume that means 
that you are promising that a lookup for *.tld will always return the 
same results as a lookup for notreallythere.tld.

I'm not really happy about shipping commercial code that depends on 
an arbitrary promise that the value of two different kinds of DNS 
lookups will always return the same value.  There's a very 
qualitative difference between that and a promise that a domain 
without DNS will always return NXDOMAIN.  This is especially a 
concern because I can think of lots of reasons *not* to make it 
deterministic.  DDoS attacks and load balancing needs come to mind 
immediately.  On top of that, Verisign's public statements about the 
usefulness of NXDOMAIN to anti-spam software have been extremely 
negative.  In other words--your company has publicly stated that they 
don't believe that this is important, but you are promising that you 
won't break it.

> The service may cause a problem for a small number of spam filters 
> that check to see if inbound e-mail is coming from a legitimate Web 
> address, said Matt Larson, principle engineer with VeriSign's Naming 
> and Directory Services. But the domain name check isn't used by most 
> popular spam filters, and it's just one of many checks a spam filter 
> vendor should use to check for spam, Larson said.

It's not used by many spam filters because it's a standard feature in 
all major mail servers.  Furthermore, it is on by default in 
Sendmail, CommuniGate and probably many others.  It's a first line of 
defense that (unlike almost all other anti-spam mechanisms) has no 
risk of false positives.

I'm afraid it's very hard to keep to a technical discussion here, 
because as soon as the technical footing becomes unstable, the final 
decision hinges on trust.  My experiences with Network Solutions 
(which are widely shared in the technical community) have greatly 
lowered my trust in Verisign as a whole.  The way this service was 
introduced has certainly not helped--you cost my company thousands of 
dollars in unexpected, and very rushed, development time.  The public 
statements from Verisign have, instead of attempting to address those 
issues, focused on belittling concerns and insulting those who have 
them.  Mr. McLaughlin has done more damage to your reputation in one 
article than years of Network Solutions gaffes.

There are technical issues here.  But right now Versign's biggest 
problems are process (following it) and trust (earning it).  Until 
those issues are addressed, it's not clear to me that it's even worth 
discussing the technical ones.

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