After Steve Crocker has finished his introductory remarks, Verisign's Scott Hollenbeck delivers his presentation on Sitefinder.
What is Sitefinder? Implementation. Technical Questions Raised. DNS Wildcard Guidelines. Questions?
Notes below. Most of what Hollenbeck says is (almost verbatim) what's in Verisign's response to the IAB, though.
DNS perspective: Sitefinder is wildcard A records in .com, .net that points to service site. For non-HTTP protocols, protocol-defined response. SMTP bouncer. TCP/UDP. Pre-Sitefinder: NXDOMAIN for non-existing domain names. Sitefinder: A record that points to Verisign site. Analysis of requests. Details of implementation described in whitepaper. Extensive testing prior to launching service. Post-launch, formed technical review panel. Ongoing monitoring program; feed-back, stay on top of issues as they arrive.
FAQ: What kind of traffic are you seeing? 85% of connection attempts HTTP or SMTP. Other TCP protocols: RST. UDP: ICMP port unreachable. List of about 20 protocols accouonts for 97% of traffic. About 1000 protocols account for remaining percents. (Slide was not visible.)
Question raised -- Verisign is listening. Technical FAQ. Released technical response to IAB and SecSAC. Will speak to some issues, not enough time to address everything.
Besides HTTP, SMTP was object of questions. Deployed bounce server. Prevent messages from queuing. Consider wildcard MX record to get name error instead of sitefinder address. Restore pre-Sitefinder behaviour for E-Mail; might drop bouncer.
Spam detection: Dorkslayers? Impact was minor, resolved on 16 September. Point was raised, addressed quickly and easily. False domain names: Spammers have given up because easy to detect. Empirics: Only 3% of spam.
Effect on mis-configured software. Misconfigured MX records, SMTP servers, etc. Analysis of MX records in .com, .net: Less than 0.1% of domain names concerned. Small problem. Privacy: Verisign is not collecting or retaining any data. Single point of failure: Track record of providing highly reliable services.
Guildelines: Have looked at what's out there. .museum, .biz, .us, ccTLDs. Drafted guidelines with Matt Larson.
(Missing part of the Q&A.)
Chuck Gomes: How to work through technical issues without giving up information to competitors that you don't want to give to them. Crocker: Obviously no competitors in this case. Gomes: Over 200 competitors. Not just registry space, but also -- with regard to sitefinder -- other businesses that do similar things. Competing for search business. Crocker: Appreciate.
Q: What's percentage of people clicking through? Hollenbeck hands over to someone else. Security, Stability, or other questions? Crocker: Fair point. Larger question with regard to security and stability? Question passed on. Look at statistics in break. Q: What issues did you deal with while sitefinder up? See IAB response.
Q: Number of things that were previously handled closer to the user from protocol perspective now further away from user. Accounts for unexpected effects. Q: How many things are there of that nature that we haven't seen yet? Changes to infrastructure service might lead to strange effects. Look at these? A: Technical Review Panel. NANOG. Slashdot. Q: Additional feedback from Verisign on things of that nature? How make better assessment in future? How determine breadth of impact close to user end in the future? A: Yes. Q: Plan assessment? A: Right. Output of Technical Review Panel with address this.
Q via e-mail: Even benign changes might be destabilizing. How address that in moving forward? A: Not sure Hollenbeck understands question. Crocker: Everything you do has impact. Lots of moving parts. How to move forward without destablizing things? A: Steps taken -- guidelines document, have set up external mailing list, fact-based, rational comments will be taken seriously.
Q from audience: How do you tell review committee what to look at and what not? Scott Hollenbeck: Operational impact? Applicable standards? Gomes: Technical research, standards compliance, rigorous process. Deal with specific technical issues. Please tell!
Q: How much testing of desktop applications other than web browsers was performed? Ex: E-Mail server configured wrongly in Outlook now turned into "wrong address" error. A: QA evaluation prior to launch. Testing with partners. With respect to outlook, would be solved by wildcard MX record.
Discussion of advance notice of future service changes?
(Missing final part of the webcast.)
