Matt - I'm interested in finding out Verisign's plans for DNSSEC support for the *.com and *.net wildcards. Are there obvious semantics for securing them? What does it mean to say that "64.94.110.11" is or is not certified by .com as the address for bad-example-12345.com , or that something else is? Is it really the same as a wild-card that points to real sites? Your Best Practices says that it's not incompatible with DNSSEC, but doesn't say anything about whether you're using it or suggesting others do. (For other readers, "64.94.110.11" is the IP address I got from running "dig a '*.com'" to look at the wildcard DNS response.) By the way, http://64.94.110.11 returns a nice friendly web page telling me that there's no web server at 64.94.110.11 :-) Has there been any security analysis of the effects of putting a large chunk of Javascript in the response page? I didn't see Mozilla listed in the collection of browsers the Javascript was looking for; perhaps I'm under the radar or perhaps it's handling it as Netscape (or I missed it in the non-human-readable formatting.) What are the security implications of the wildcard servers getting compromised or DDOSed? In the past, if my browser or email tried to go to nonexistent-example.com, it'd get a reject from my system's DNS resolver and fail; now it starts up a TCP connection to your machines, so I have to worry about what your machines will say, and what happens if I can't reach your Internap connection for some reason. Is it appropriate to have the address be Verisign's? Or should you be using some special address from IANA? (I suppose it only takes 15 minutes to change if you change your mind...) Thanks; Bill Stewart bill.stewart@pobox.com
Official notice from verisign.
Today VeriSign is adding a wildcard A record to the .com and .net zones. The wildcard record in the .net zone was activated from 10:45AM EDT to 13:30PM EDT. The wildcard record in the .com zone is being added now. We have prepared a white paper describing VeriSign's wildcard implementation, which is available here:
http://www.verisign.com/resources/gd/sitefinder/implementation.pdf
By way of background, over the course of last year, VeriSign has been engaged in various aspects of web navigation work and study. These activities were prompted by analysis of the IAB's recommendations regarding IDN navigation and discussions within the Council of European National Top-Level Domain Registries (CENTR) prompted by DNS wildcard testing in the .biz and .us top-level domains. Understanding that some registries have already implemented wildcards and that others may in the future, we believe that it would be helpful to have a set of guidelines for registries and would like to make them publicly available for that purpose. Accordingly, we drafted a white paper describing guidelines for the use of DNS wildcards in top-level domain zones. This document, which may be of interest to the NANOG community, is available here:
http://www.verisign.com/resources/gd/sitefinder/bestpractices.pdf
Matt -- Matt Larson <mlarson@verisign.com> VeriSign Naming and Directory Services