Internet Protocols and Innovation. Starts by explaining interaction between MX and A records, and problems with early versions of Exchange and Outlook, taking up some remarks from Bellovin. Somewhat hard to understand over the webcast.
Discussion will overlap with what Steve said. New protocols and applications happen regularly. Some big hits, some not, some used locally. Some want to be nexts killer app, some don't want. Internet does not require anyone to go to central authority and ask for permission for adding new protocols. Gatekeeper for progress.
DNS why? ... Becomes part of critical infrastructure. When central infrastructure needs to be changed for new protocol, it becomes difficult to deploy new protocol. ... When developing new applications, infrastructure must behave in stable and predictable way. Can app depend on getting "no domain" if no registration? Yes for 250+ TLDs, no for few. Can you depend on specific behavior to odetect the situation? No.
Getting into a situation where applications have to interpret error responses based on what domain name information relates to. Search tables, by domain? Bad. Inhibit successful deployment of new TLDs. Experience.
(...)
Internationalization issues. Languages. IDNs, look-alike characters. Currently use the notion that many names must not be registered. Wildcards create illusion that all domain names are registered.
Talked to friend. "With all these problems ... it is amazing the thing works at all." Net designed to be robust against many types of abuse. Misconfigurations actually work. Other bad practices work for many -- don't dare break them. Expensive for economy at large.
Robustness principle. Be conservative about what is sent. Not explicitly stated with each one. That a behavior is defined does not make its use reasonable, appropriate, or even permitted. If you adopt rule that specifying a feature makes it legitimate to use it in whatever way, net will break down.
Discussion not about inhibiting innovation, but about continuing to enable it.
End of talk.
Q: Old software with SMTP bugs? A: Lots of old software around. Also exporting old hardware and OSs to developing countries. NT4 still around.
Crocker, devil's advocate: Tradeoff between innovation and not breaking old stuff? A: Always tradeoff.
...
More important to focus on future protocols, innovation, not on compatibility with old systems.
Can probably hammer out most issues with SMTP, HTTP. But the protocol we can't predict, the next killer application is much more serious problem.
...
Some argument about scale of problem. Can't things be fixed in applications? No. Tables.
Don't have standardized architecture that says "I'm not here" for all protocols. If that was here, Sitefinder rejection would be implementable.
Issues with non-email protocols that queue up data.
Bellovin: Timeout problems when sitefinder is unavailable, observed from AT&T.
...
Discussion on how to detect synthesized responses from name servers. But: Need to implement that everywhere. Cost for everyone on the net. Is it reasonable to deploy something that forces everybody else to deploy workarounds?
Alan Davidson: What to do about this? Architectural issue very compelling from user perspective. Innovation. Freedom. Define what's permitted?
...
Klensin on innovation, again: Innovation. Stable DNS that fulfills users' experiences is important. Changing that makes applications more difficult to write. Innovation difficult. ... Stability and policy problem: How much conversion and work-around effort may someone impose on the rest of the network by a unilateral change?
Crocker: We are in an area where some people say "stability issue." Others: business, governance, etc. Delicate issues about erring on side of taking up possible stability issues, or erring on the side of taking up certain stability issues. Answer: yes. Incumbent on SecSAC to address problem. ... Have to engage rest of community.
