DNS and NamingDomain Name System GoalsDNS ExperienceSlide 4Architectural BrittlenessNaming Can HelpInternet Naming is Host-CentricThe Trouble with Host-Centric NamesKey Architectural QuestionsName Services and Hosts SeparatelyThe Naming LayersSlide 12SIDs and EIDs should be Flat 0xf436f0ab527bac9e8b100afeff394300Flat Names Enable Flexible MigrationFlat Names are a Two-Edged SwordSlide 16DelegationDelegation Enables Architecturally-Sound IntermediariesDNS and NamingAditya Akella03/16/2007Supplemental slidesDomain Name System Goals•Basically building a wide area distributed database•Scalability•Decentralized maintenance•Robustness•Global scope –Names mean the same thing everywhere•Don’t need–Atomicity–Strong consistencyDNS Experience•23% of lookups with no answer–Retransmit aggressively  most packets in trace for unanswered lookups!–Correct answers tend to come back quickly/with few retries•10 - 42% negative answers  most = no name exists–Inverse lookups and bogus NS records•Worst 10% lookup latency got much worse–Median 8597, 90th percentile 4471176•Increasing share of low TTL records  what is happening to caching?DNS Experience•Hit rate for DNS = 80%  1-(#DNS/#connections)–Most Internet traffic is Web–What does a typical page look like?  average of 4-5 imbedded objects  needs 4-5 transfers  accounts for 80% hit rate!•70% hit rate for NS records  i.e. don’t go to root/gTLD servers–NS TTLs are much longer than A TTLs–NS record caching is much more important to scalability•Name distribution = Zipf-like = 1/xa•A records  TTLs = 10 minutes similar to TTLs = infinite•10 client hit rate = 1000+ client hit rateArchitectural Brittleness•Hosts are tied to IP addresses–Mobility and multi-homing pose problems•Services are tied to hosts–A service is more than just one host: replication, migration, composition•Packets might require processing at intermediaries before reaching destination–“Middleboxes” (NATs, firewalls, …)Naming Can Help•Thesis: proper naming can cure some ills–Layered naming provides layers of indirection and shielding•Many proposals advocate large-scale, overarching architectural change–Routers, end-hosts, services•Proposal:–Changes “only” hosts and name resolution–Synthesis of much previous workInternet Naming is Host-Centric•Two global namespaces: DNS and IP addresses•These namespaces are host-centric–IP addresses: network location of host–DNS names: domain of host–Both closely tied to an underlying structure–Motivated by host-centric applicationsThe Trouble with Host-Centric Names•Host-centric names are fragile–If a name is based on mutable properties of its referent, it is fragile–Example: If Joe’s Web page www.berkeley.edu/~hippie moves to www.wallstreetstiffs.com/~yuppie, Web links to his page break•Fragile names constrain movement–IP addresses are not stable host names–DNS URLs are not stable data namesKey Architectural Questions1. Which entities should be named?2. What should names look like?3. What should names resolve to?Name Services and Hosts Separately•Service identifiers (SIDs) are host-independent data names•End-point identifiers (EIDs) are location-independent host names•Protocols bind to names, and resolve them–Apps should use SIDs as data handles–Transport connections should bind to EIDsBinding principle: Names should bind protocols onlyto relevant aspects of underlying structure Binding principle: Names should bind protocols onlyto relevant aspects of underlying structureThe Naming LayersUser-level descriptors(e.g., search)App sessionApp-specific search/lookupreturns SIDTransportResolves SID to EIDOpens transport connsIPResolves EID to IPBind to EIDUse SID as handleIP hdr EID TCP SID …IPTransportApp sessionApplicationKey Architectural Questions1. Which entities should be named?2. What should names look like?3. What should names resolve to?SIDs and EIDs should be Flat0xf436f0ab527bac9e8b100afeff394300•Flat names impose no structure on entities–Structured names stable only if name structure matches natural structure of entities–Can be resolved scalably using, e.g., DHTs•Flat names can be used to name anything–Once you have a large flat namespace, you never need other global “handles”Stable-name principle: A stable name should not impose restrictions on the entity it namesStable-name principle: A stable name should not impose restrictions on the entity it namesResolutionServiceFlat Names Enable Flexible Migration<A HREF=http://f012012/pub.pdf>here is a paper</A><A HREF=http://f012012/pub.pdf>here is a paper</A>HTTP GET: /docs/pub.pdf10.1.2.3/docs/20.2.4.6HTTP GET: /~user/pubs/pub.pdf(10.1.2.3,80,/docs/)(20.2.4.6,80,/~user/pubs/)/~user/pubs/•SID abstracts all object reachability information•Objects: any granularity (files, directories)•Benefit: Links (referrers) don’t breakDomain HDomain YFlat Names are a Two-Edged Sword•Global resolution infrastructure needed–Perhaps as “managed DHT” infrastructure•Lack of local name control•Lack of locality•Not user-friendly–User-level descriptors are human-friendlyKey Architectural Questions1. Which entities should be named?2. What should names look like?3. What should names resolve to?Delegation•Names usually resolve to “location” of entity•Packets might require processing at intermediaries before reaching destination•Such processing today violates layering–Only element identified by packet’s IP destination should inspect higher layersDelegation principle: A network entity should be able to direct resolutions of its name not only to its ownlocation, but also to chosen delegatesDelegation principle: A network entity should be able to direct resolutions of its name not only to its ownlocation, but also to chosen delegates•Delegate can be anywhere in the network, not necessarily on the IP path to d (ipd)•SID/EID can resolve to sequence of delegatesipf EID d TCP hdrPacket structure (dests only)EID dIP ipdEID sFirewallEID fIP ipfipfffdMappingDest EIDResolution svcDelegation Enables Architecturally-Sound