Please find below a copy of a formal complaint I have made to ICANN today regarding Verisign's wildcard change of yesterday, which may be of interest to members of this list. The text is also available at:- http://www.itconsult.co.uk/misc/icann17sep2003.htm Best wishes, Matthew ==================== From: Matthew Richardson To: Tina Dam Subject: {18876} Formal Complaint - .com & .net wildcards cause Internet destabilisation Date: Wed, 17 Sep 2003 20:46:54 +0100 Organization: I. T. Consultancy Limited, Jersey -----BEGIN PGP SIGNED MESSAGE----- {ref: 18876} To: The Internet Corporation for Assigned Names and Numbers (ICANN) For the attention of: Tina Dam I refer to our telephone conversation of yesterday morning relating to the very recent addition of "wildcard" records to the .com & .net GTLDs by Verisign. My purpose in writing, as we discussed, is to make a formal complaint to ICANN regarding Verisign's actions, and furthermore to formally request ICANN to instruct Verisign to remove these wildcard records with immediate effect, subject only to their possible reinstatement following an appropriate period of consultation. This complaint is being made in the public interest. Specifically it is that the CHANGE in behaviour within two of the largest Internet TLDs is likely to cause serious difficulties in a number of areas. The inevitable consequence of these CHANGES is that many businesses and users involved with .com & .net domains (quite a sizeable proportion of the Internet) will be involved in varying degrees of unforeseen inconvenience, failure and expenditure. Such unexpected disruption and expense seems, at the very least, somewhat inequitable to those on the receiving end, all the more so in the absence of any notice from Verisign. This is clearly a destabilising effect on a very significant portion of the Internet as a whole, which seems to be at some variance with ICANN's ongoing responsibilities as described in your announcement of today http://www.icann.org/announcements/announcement-17sep03.htm, which states "The MoU highlights ICANN's responsibility to ensure the stability of the Internet". There may be many additional (and perhaps compelling) reasons why others might suggest that change is not good, predominantly from a privacy and data protection perspective. However this complaint deals solely with the issues of the failures caused by the unexpected change and the cost of correcting them. The change appears to have been announced by Verisign yesterday and I have seen references by them in public to the documents:- http://www.verisign.com/resources/gd/sitefinder/implementation.pdf http://www.verisign.com/resources/gd/sitefinder/bestpractices.pdf The former, dated 27 August 2003, describes their wildcard implementation, citing its conformance with their latter document, which is dated 09 September 2003. Whilst the lay reader might assume that this latter document represents some form of approved Internet standard, nothing could be further from the truth. The following are merely a few very examples of the sorts of issues which will cause failures and which will cost money to fix:- (a) Unsolicited commercial email (colloquially known as "spam"), is a serious (and increasingly serious) problem. Many email servers incorporate anti-spam protections. One commonly used method is to perform a DNS check on the sender domain prior to continuing to accept the message. If it does not exist, the email is not accepted being either delayed or permanently rejected. At a low level, this is done by issuing a DNS query for the sender domain and checking for the presence of MX or A records. Verisign's changes will cause this mechanism to fail for all non-existent .com or .net domains. (b) Verisign have installed software which answers on SMTP port 25 on the IP address returned as the A record. This software, which purports to be an email server, is not even remotely compliant with rfc2821, the current standard for SMTP email. It is clearly designed to receive email connections and reject the messages, although it remains unclear what difficulties its gross non-compliance will cause. As an aside, its ability to capture sender addresses (and should it wish in the future whole email messages) which is most likely to cause significant concern to those of a privacy protection persuasion. (c) There are likely to be many applications and services around the Internet, which utilise the results of DNS lookups to test the existence of domains under .com & .net, a method which has worked correctly since the creation of these TLDs long long ago. Many of these applications will belong to those involved in the domain registration business. The addition of wildcard records will cause all such applications to fail. This appears to be understood by clearly Verisign who state in the latter document referred to above "It is important to note that this response, though generated as the result of a wildcard, does not differ from a non-wildcard-related response. The recipient cannot determine the presence of a wildcard entry in a zone from a single response generated as a result of that wildcard". (d) Blacklists known generically as "DNSBL" have evolved from the original MAPS RBL as a means of specifying IP addresses from which email can be blocked. The addition of the wildcard record may make certain retired DNSBL spring back into life listing all addresses resulting in the incorrect rejection of incoming emails. In conclusion a change of this magnitude to the operation of two of the most major TLDs on the Internet should not have been undertaken without significant consultation and notice. I therefore urge ICANN to act promptly and decisively to remove these records in furtherance of its ongoing obligations to ensure stability of the Internet. Regards, Matthew Richardson I T Consultancy Limited Jersey Channel Islands -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAgUBP2i5aQKwLwcHEv69AQFytQQAsC/XgAdvbK/tBsIFyaiemYJneDTR9d/O FGNTvmMtUbht6RCPgpPYAv/M2I4eBIXRSVYFEQQGEok24McKjEl78n4mTi/N0pLp EUcO/UnLhwaa5Vt6SAokdqsFUFQvkl2jfDiHJ8C72JCYPaOG/KGvG9z/idotZKGh BXhaA1973gY= =JRfV -----END PGP SIGNATURE-----