David Schairer (VP Software Engineering, XO Communications) speaks on consequences of sitefinder.
Impact on web browsing; language issues; specialized error handling with some devices. Network cost (cell phones etc.). Redirect 100 x size of DNS response.
Stability risks. Resolution of non-domain requests moves from multi-address distributed infrastructure (TLD servers) to single-address centralized one (sitefinder.verisign.com). Response time. System likely to be attacked. DoS, null-routing, ... Prestige target. Likely to get hacked, understand risks when that happens.
SMTP interactions. Initial server was badly non-compliant. Replaced soon after launch. New server speaks valid SMTP, but issues remain. Initial negotiation limits message size to 10MB. "Message too large" response instead of "bad domain name." Client timeout on new wildcard SMTP server is 10 seconds. RFC: timeout SHOULD be 5 minutes. Can impact slow senders on slow connections. Will cause e-mail to be queued.
Not prepared to talk to wildcard MX proposal. Some issues will be changed, others remain, others new. Stale MX records -- small percentage, 15,000 domains.
Non-existent A record available in private address space, MX points to that, sitefinder leads to bounces. Seen in the wild. Domain an MX points to expires, wildcard kicks in. Sitefinder increases traffic and server cost.
Spam filtering -- non-existing sender domain rule alone blocks 10%+ of inbound mail.
Effect on spammers, mailing list operators: Cleansing list from bad addresses.
Effect on other protocols: Packet count or session count? Statistics may compare apples and oranges. May be able to implement rejectors for some more protocols, may not be able to do it for some, may encounter private protocols. Many applications affected by this might be implemented in firmware; not easily updated. Client configuration UIs that check for valid DNS on input.
For technical users, annoyance, not life-threatening. For non-technical users, confusion caused by wrong error diagnostics. Increased support cost.
Conclusion: Not a single, large, pan-network failure. Instead, large number of chronic problems. Some fixable by more careful deployment. Many intrinsic to concept, unavoidable. SSL handling! Some problems have been cleaned up by software patches and fixes. More fixes necessary should wildcard be deployed. Similar to Y2K patching. Ongoing "tax" on Internet use.
Larger level: Shows how sensitive core infrastructure is. Complexity, connectedness. DNS most centralized part of infrastructure. Everything touches DNS. Effects of wildcard in com, net larger than in other TLDs. RFC compliance cornerstone, but not sufficient to judge impact of change that happens. RFCs are statutory law. There's also a Common Law here. Best Current Practice.
Q: Anything that's more than annoyance to a small number of people? A: Spam filtering. Cost increases. Service providers. Q: Security and stability related issues, not usability issues unless they create security and stability issues. 10% increase of spam security/stability problem? A: 10% of incoming e-mail means more than 10% increase of spam. Definition of stability and security? Stability concerns when users' ability to use net is impacted? Q: Talking about misconfigurations frequently. Services wouldn't ever be reached. A: Argument that "any error message is ok" is not correct. Think about dropping packets. Purpose of different error codes?
Q: How determine if change will have broad-reaching impact to user level? How evolve infrastructure and not run into problems.
...
Miriam Sapiro: Q. about patches. Widespread concern that deployment of patches to counter sitefinder could add further instability. Battle of patches? Crocker: Topic of next speaker. Quick response. A: Any time patches are rushed, you get problems. Defer to Vixie.
Cuck Gomes: Setting the record straight, facts.
Matt Larson at microphone. Responses on the flight. Echo remark that this is valuable input. Specific, quantifiable examples would be helpful. Need specific examples.
Terminology: Root servers -- root name servers. Belowo that, Top Level Domain Name servers. Important; terminology was confounded. Several TLDs had wildcards before. Not accurate to claim that this is all of a sudden something new. Discussion of HEAD HTTP command. Crocker suggests to move this to the end. Some exchange in between. Larson tries to continue. SMTP reject server does respond with 550 response to RCPT TO. Didn't understand point about message size. Schairer explains. Larson: Will have to look. Wildcard MX to nonexisting target would solve. Spam. Frustrating for them as well. Corner case, blown out of proportion. Commercial providers don't even bother with this check any more. Crocker: These are issues for next step. Apologize, but have requirement to get rest of the material that has been prepared out. Cut off.
Comments (2)
Posted by Mueller | October 8, 2003 5:26 AM
Posted on October 8, 2003 05:26
Posted by Thomas Roessler | October 8, 2003 8:29 AM
Posted on October 8, 2003 08:29