• Wildcarding name resolution breaks standards track RFCs.
  
  
  • Specifically, the result of a DNS look-up should always be relied upon to be assertive. A look-up failure should be every bit as meaningful as a success (RFC2308). Such a failure is more than just the absence of something - it can and often does imply the presence of something else. For example, try looking up your own MTA's IP in the MAPS RBL. Assuming it is not actually listed in MAPS, you will see a look-up failure.
    
    This is a positive assertion - "host x.x.x.x is not listed in the MAPS RBL".
    
    Now suppose an MTA is using a long defunct DNSBL in the .com TLD - let us call it zone.deaddnsbl.com - look-ups would take the form 2.0.0.127.zone.deadDNSBL.com and would fail (host is not listed by this DNSBL). Wildcarding .com NS look-ups means that 2.0.0.127.zone.deaddnsbl.com does now resolve (for any IP). So suddenly an MTA that has been working flawlessly for years starts to block all email.
    
    OK, you might argue that the administrator of this MTA should have managed it better - but the point remains. Look-up failures mean something.
    
    
  • And what about the domain whois information? RFC954 requires that "all hosts who can connect to 'the DoD Internet' and are capable of passing traffic should be listed in the whois server (accessible via a standard TCP port, 43), complete with contact information including network e-mail address."
    
    But while a host named www.gsahjgkdjgjkagasjhgdhjgahg.com does now resolve to an IP and that IP does respond on a number of ports (25, 80 and perhaps others), whois -h whois.crsnic.net gsahjgkdjgjkagasjhgdhjgahg.com fails. So we appear to have a named host in a domain with no whois info - a clear violation of another standards track RFC.
  
  
• There is more to the Internet than just www... A basic assumption in wildcarding .com and .net name resolution is that most look-ups of non-existent names are caused by people with fat fingers using web browsers, but the stats do not support this.
  
  Let us go through our logs here and see what we find.
  
  Every inbound email here causes a DNS look-up, looking for a DNS A or MX record for the domain part of the sender envelope. This happens 1,000 to 1,200 times per day, every day and c. 0.5% of these look-ups fail because the sender domain is bogus. That is 5-6 failures per day (almost always spam, but occasionally a user with a broken MUA).
  
  Looking through our proxy server logs for HTTP access to sitefinder.verisign.com since the wildcarded .com and .net name resolution was introduced, I find precisely 11 hits and all but two of those were me testing it.
  
  Two web hits in three days. Six email hits every day.
  
  
• Sending email to user@typographical_error.com will cause a bounce, but not before an "MTA" at typograhical_error.com has accepted a connection from the sending MTA and logged both the sender and recipient envelopes. In the UK, these are personal data within the meaning of the Data Protection Act and are protected. But we have no way of knowing what has happened to them.
  
  
• The correct place to implement a helper for users with fat fingers is at the application layer (i.e. in the browser). Both Microsoft and Netscape have features which do this and these can be turned on or off at the request of the user. Wildcarding .com and .net name resolution breaks these features in every browser and is not user configurable.
  
  It also destroys competition, because now users are forced to use one service where previously they had a choice of several, or none.

I wonder how the good folks at Microsoft, Netscape and possibly even Google feel about having searches redirected in this way?

Category: T'Internet
Technorati: T'Internet

Unable to post a comment? Please read this for a possible explanation...