Paul Vixie presents. Observed workarounds.
Background, DNS responses. Three types of responses that server can issue. Could tell you "here's address." Could send referral -- don't know address, but know where to possibly get it. Could tell that name does not exist. Difference rather important to understanding community's response. Negative answers started to come back as normal answers.
Personal background: Supplier of some of workaround software. Publish BIND, run name server, etc. Budget, salary etc. depends on relevance to community. Negative community response to sitefinder; had to do something. Has personal views, but ISC is just about supporting customers.
Early patch: Look for specific answer returned for wildcard. Weakness: Address can change for natural causes. Hard-coding address into software or config file is bad idea. Scalability. One patch had all synthetic data coming from any TLD listed.
First workaround from ISC: Require referrals from some TLDs. "delegation-only" for specified domains. Does not depend on specific address returned by server. Not default behaviour; turn on explicitly.
Then learned of long list of other TLDs with synthetic data. Reverse sense of configuration directive -- explicitly permit synthetic data. Not default, not in example config.
Other name servers out there that can selectively forward. ISC runs bind9 with delegation-only. ISC runs such a server. Traffic light.
15,000 users downloaded bind patch, including integrators and linux distributors.
Some ISPs have put up ad servers at sitefinder's IP address for their users. Slippery slope with respect to stability, as all workarounds. But this is one of the worse. Experience depends on what ISP you are using. If Verisign tries again, solves some problems, people inside ISPs won't solve that. Hopes not to see this widespread. Complete autonomy of ISPs.
Large ISPs has been observed to replace both sitefinder and RCODE 3 by pointer to their own server.
Slide with a list of software for which patches have been published.
Protocol Violations? If protocol is violated, then responses will be rejected. In strict definitional sense, neither Verisign, nor workarounds violate protocol. Not protocol violation, but system expectation violation.
Points to Zittrain and Edelman paper, reports some results.
Q: Address hijacking? A: Could become a huge mess.
Q: ISPs, operators extending wildcard-like services to TLDs that have elected not to have wildcards (.org). A: Not directly. But one workaround involved rewriting RCODE3. Q: User perspective -- difference to IE redirect to MSN? A: Depends on definition of "user." Crocker: Ordinary users whose client software does same thing. A: If you don't like MSN service, you can turn off IE feature. If provider changes DNS responses, you can't do anything to browser configuration.
Chuck Gomes (?): Option for exceptions in switch? How determine what exceptions are appropriate? User-configurable, patch? A: Patch gives ability to list own exceptions. No standardized list. Q: Own exceptions for each user? A: That's right. Name server operators make choice on their own.
