Untangling the Web from DNS

1
Untangling the Web from DNS

• Michael Walfish Hari Balakrishnan
• Massachusetts Institute of Technology

Scott Shenker UC Berkeley/ICSI
IRIS Project 30 March 2004
2
Introduction

• The Web depends on linking links contain
  references

• ltA HREFhttp//domain_name/path_namegtclick
  herelt/Agt

• Properties of DNS-based references
• encode administrative domain
• human-friendly

• These properties are problems!

3
Web Links Should Use Flat Identifiers
Proposed
Current
ltA HREF http//isp.com/dog.jpg gtmy friends
doglt/Agt
ltA HREF http//f0120123112/ gtmy friends doglt/Agt

• This talk
• That we should build this
• That we can build this

4
Outline

• Argue for flat tags instead of DNS-based URLs
• Resolution service for flat tags

5
Status Quo
Browser
Web Page
a.com
DNS
ltA HREF http//a.com/dog.jpggtSpotlt/Agt
http//
IP addr
Reference Resolution Service
HTTP GET /dog.jpg
Why not DNS?
6
Goal 1 Stable References
Stablereference is invariant when object moves

• In other words, links shouldnt break
• DNS-based URLs are not stable . . .

7
Object Movement Breaks Links
URLs hard-code a domain and a path
HTTP GET /dog.jpg
isp.com
ltA HREF http//isp.com/dog.jpg gtSpotlt/Agt
http//
dog.jpg
HTTP 404
Browser
isp-2.com
spot.jpg
8
Object Movement Breaks Links, Contd
HTTP GET /dog.jpg
isp.com
ltA HREF http//isp.com/dog.jpg gtSpotlt/Agt
http//
dog.jpg
HTTP 404
Browser

• Todays solutions not stable
• HTTP redirects
• need cooperation of original host
• Vanity domains, e.g. internetjoe.org
• now owner cant change

isp-2.com
spot.jpg
9
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
HTTP GET / host object26.org
/docs/foo.ps
http//object26.org
mit.edu
HTTP GET / host object26.org
joe/foo.ps
10
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?

11
Goal 3 Automate Namespace Management

• Automated management implies no fighting over
  references
• DNS-based URLs do not satisfy this . . .

12
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 . . .

13
Separate References and User-level Handles
Object Location
Human-unfriendly References
User Handles (AOL Keywords, New Services, etc.)
tussle space Clark et al., 2002

• So arent you just moving the problem?
• Yes.
• But.
• Let people fight over handles, not references

14
Two Principles for References

• References should not embed object or location
  semantics
• References should be human-unfriendly

Flat tags Minimal interface
Natural choice
15
Outline

• Argue for flat tags instead of DNS-based URLs
• Resolution service for flat tags SFR

Object Location
Flat Tag
User Handle (AOL Keyword, New Handle, etc.)
16
SFR in a Nutshell
GET(0xf012c1d)
ltA HREF http//f012c1d/ gtSpotlt/Agt
Managed DHT-based Infrastructure
o-record
(10.1.2.3, 80, /pics/dog.gif)
orec

• API
• orec get(tag)
• put(tag, orec)
• Anyone can put() or get()

HTTP GET /pics/dog.gif
10.1.2.3
/pics/dog.gif
Web Server
17
Resilient Linking

• tag abstracts all object reachability information
• objects any granularity (files, directories,
  hosts)

HTTP GET /docs/pub.pdf
10.1.2.3
ltA HREF http//f012012/pub.pdf gthere is a
paperlt/Agt
/docs/
HTTP GET /user/pubs/pub.pdf
20.2.4.6
(10.1.2.3,80, /docs/)
/user/pubs/
(20.2.4.6,80, /user/pubs/)
SFR
18
Flexible Object Replication
o-record
SFR
(IP1, port1, path1), (IP2, port2, path2), (IP3,
port3, path3), . . .
0xf012012

• Grass-roots Replication
• People replicate each others content
• Does not require control over Web servers

• (Doesnt address massive replication)

19
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

20
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
21
Outline

• Argue for flat tags instead of DNS-based URLs
• Resolution service for flat tags SFR
• Related Work / Summary / Conclusion

22
Related Work

• URN (Universal Resource Name)
• DOI an existing URN implementation
• PURL (Permanent URL)
• Globe
• Open Network Handles
• DNS over Chord

23
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 . . .

24
Conclusion

• DNS-based URLs certainly convenient!
• But flat tags better for linking
• Future type DNS names, link with flat tags?

25
Appendix Slides
26
Implementation
HTTP
http//
HTTP
SFR Web Proxy
SFR Portal
orec get(tag) put(orec,tag)
PlanetLab
SFR Portal
SFR Client
Web Client
GetRequest

• Proxy allows
• End-users to experience SFR latency
• Dynamic population of SFR infrastructure with
  o-records

GetResponse
SFR Server
DHash
Chord
27
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

• DNS data
• collected at MIT CSAIL, Feb. 2004

Comparison meant to be suggestive not conclusive
28
SFR Components
Portal
Relay
SFR Infrastructure
Org Store
Relay
Portal
Relay
SFR Client
Application

• Infrastructure stores (tag, o-record) pairs
• Caching throughout o-record has TTL field

29
Fate Sharing
Portal
Relay
SFR Infrastructure
put(tag,orec)
Org Store
Relay
Portal
get(tag)
Relay

• Fate sharing via write-locality
• Simple case . . .

30
Alternate SFR Design SFR--

• SFR stores only pointers to organizations
• Analogous to NS records in DNS

SFR Infrastructure
GET(0xf012120)
User
x
Organization
org ptr x
GET(0xf012120)
meta-data (IP addr, etc.)
31
When Files Separate From Directories
HTTP GET /doc/pub3.ps
10.1.2.3
ltA HREF http//f012012/pub3.ps gthere is a
paperlt/Agt
/doc/pub1.ps
/doc/pub2.ps
GET(0xf012012)
/doc/pub3.ps
x
(10.1.2.3,80, /doc/)
redirect ptr x
HTTP GET /abc/pub3.ps
20.2.4.6
SFR
/abc/pub3.ps