Presentation on theme: "Untangling the Web from DNS Michael Walfish Hari Balakrishnan Massachusetts Institute of Technology Scott Shenker UC Berkeley/ICSI IRIS Project 30 March."— Presentation transcript:
Untangling the Web from DNS Michael Walfish Hari Balakrishnan Massachusetts Institute of Technology Scott Shenker UC Berkeley/ICSI IRIS Project 30 March 2004
Introduction The Web depends on linking; links contain references Properties of DNS-based references encode administrative domain human-friendly click here These properties are problems!
Goal #2: Supporting Object Replication Host replication relatively easy today But per-object replication requires: separate DNS name for each object virtual hosting so replica servers recognize names configuring DNS to refer to replica servers isp.com /docs/foo.ps mit.edu ~joe/foo.ps HTTP GET / host: object26.org HTTP GET / host: object26.org
What Should References Encode? Observe: if the object is allowed to change administrative domains, then the reference cant encode an administrative domain What can the reference encode? Nothing about the object that might change! Especially not the objects whereabouts! What kind of namespace should we use?
Goal #3: Automate Namespace Management Automated management implies no fighting over references DNS-based URLs do not satisfy this...
DNS is a Locus of Contention Used as a branding mechanism tremendous legal combat name squatting, typo squatting, reverse hijacking,... ICANN and WIPO politics technical coordinator inventing naming rights set-asides for misspelled trademarks Humans will always fight over names...
Separate References and User-level Handles So arent you just moving the problem? Yes. But. Let people fight over handles, not references Object Location Human- unfriendly References User Handles (AOL Keywords, New Services, etc.) tussle space [Clark et al., 2002]
Two Principles for References 1.References should not embed object or location semantics 2.References should be human-unfriendly Flat tags Minimal interface Natural choice:
Outline I.Argue for flat tags instead of DNS-based URLs II.Resolution service for flat tags: SFR Object Location Flat Tag User Handle (AOL Keyword, New Handle, etc.)
(Doesnt address massive replication) Flexible Object Replication (IP1, port1, path1), (IP2, port2, path2), (IP3, port3, path3),... 0xf SFR o-record Grass-roots Replication People replicate each others content Does not require control over Web servers
Reference Management Requirements No collisions, even under network partition References must be human-unfriendly Only authorized updates to o-records Approach: randomness and self-certification tag = hash(pubkey, salt) o-record has pubkey, salt, signature anyone can check if tag and o-record match
Latency Problem: Lookups should be fast Solution: lots of TTL-based caching Clients and DHT nodes cache o-records DHT nodes cache each others locations In Chord, aggressive location caching 2 or 3 hops per lookup Could also use one-hop or Beehive
Outline I.Argue for flat tags instead of DNS-based URLs II.Resolution service for flat tags: SFR III.Related Work / Summary / Conclusion
Related Work URN (Universal Resource Name) DOI: an existing URN implementation PURL (Permanent URL) Globe Open Network Handles DNS over Chord
Summary Should we build flat references for the Web? Yes! Can we build flat references for the Web? Yes! (Our implementation is usable.) Lots of future work...
Conclusion DNS-based URLs certainly convenient! But flat tags better for linking Future: type DNS names, link with flat tags?
Implementation HTTP SFR Web Proxy SFR Client SFR Portal Chord DHash SFR Server Web Client Proxy allows: End-users to experience SFR latency Dynamic population of SFR infrastructure with o-records orec = get(tag) put(orec,tag) HTTP SFR Portal GetRequest GetResponse PlanetLab
Evaluation SFR data eight day trace 390 virtual hosts; 130 nodes in Chord ring on PlanetLab latency seen by SFR portal most queries are two hops informal feedback: generally indistinguishable from DNS Comparison meant to be suggestive not conclusive DNS data collected at MIT CSAIL, Feb. 2004
Alternate SFR Design: SFR-- SFR stores only pointers to organizations Analogous to NS records in DNS GET(0xf012120) org ptr: x User SFR Infrastructure x GET(0xf012120) meta-data (IP addr, etc.) Organization