Information-Centric Networks Section # 3.3: DNS Issues Instructor: George Xylomenos Department: Informatics.

Slides:



Advertisements
Similar presentations
Information-Centric Networks05c-1 Week 5 / Paper 3 Democratizing content publication with Coral –Michael J. Freedman, Eric Freudenthal, David Mazières.
Advertisements

Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, Hari Balakrishnan MIT and Berkeley presented by Daniel Figueiredo Chord: A Scalable Peer-to-peer.
Sergei Komarov. DNS  Mechanism for IP hostname resolution  Globally distributed database  Hierarchical structure  Comprised of three components.
1 Server Selection & Content Distribution Networks (slides by Srini Seshan, CS CMU)
Domain Name System. DNS is a client/server protocol which provides Name to IP Address Resolution.
A Peer-to-Peer DNS Ilya Sukhar Venugopalan Ramasubramanian Emin Gün Sirer Cornell University.
Information-Centric Networks03c-1 Week 3 / Paper 3 The design and implementation of a next generation name service for the Internet –Venugopalan Ramasubramanian.
Beehive: Achieving O(1) Lookup Performance in P2P Overlays for Zipf-like Query Distributions Venugopalan Ramasubramanian (Rama) and Emin Gün Sirer Cornell.
Computer Networks: Domain Name System. The domain name system (DNS) is an application-layer protocol for mapping domain names to IP addresses Vacation.
Naming Computer Engineering Department Distributed Systems Course Asst. Prof. Dr. Ahmet Sayar Kocaeli University - Fall 2014.
Web Caching Schemes1 A Survey of Web Caching Schemes for the Internet Jia Wang.
Lecture 6 – Google File System (GFS) CSE 490h – Introduction to Distributed Computing, Winter 2008 Except as otherwise noted, the content of this presentation.
Vault: A Secure Binding Service Guor-Huar Lu, Changho Choi, Zhi-Li Zhang University of Minnesota.
P2P: Advanced Topics Filesystems over DHTs and P2P research Vyas Sekar.
Chord-over-Chord Overlay Sudhindra Rao Ph.D Qualifier Exam Department of ECECS.
Squirrel: A decentralized peer- to-peer web cache Paul Burstein 10/27/2003.
Wide-area cooperative storage with CFS
70-293: MCSE Guide to Planning a Microsoft Windows Server 2003 Network, Enhanced Chapter 7: Planning a DNS Strategy.
Or, Providing Scalable, Decentralized Location and Routing Network Services Tapestry: Fault-tolerant Wide-area Application Infrastructure Motivation and.
Information-Centric Networks05a-1 Week 5 / Paper 1 On the use and performance of content distribution networks –Balachander Krishnamurthy, Craig Wills,
Domain Name Services Oakton Community College CIS 238.
Hands-On Microsoft Windows Server 2008 Chapter 8 Managing Windows Server 2008 Network Services.
11.1 © 2004 Pearson Education, Inc. Exam Managing and Maintaining a Microsoft® Windows® Server 2003 Environment Lesson 11: Introducing WINS, DNS,
Storage management and caching in PAST PRESENTED BY BASKAR RETHINASABAPATHI 1.
1 Content Distribution Networks. 2 Replication Issues Request distribution: how to transparently distribute requests for content among replication servers.
Information-Centric Networks03a-1 Week 3 / Paper 1 What DNS is not –Paul Vixie –CACM, December 2009, vol. 52, no. 12 Main point –“DNS is many things to.
Chapter 16 – DNS. DNS Domain Name Service This service allows client machines to resolve computer names (domain names) to IP addresses DNS works at the.
The Design and Implementation of a Next Generation Name Service for the Internet Leo Bhebhe
Chord & CFS Presenter: Gang ZhouNov. 11th, University of Virginia.
October 8, 2015 University of Tulsa - Center for Information Security Microsoft Windows 2000 DNS October 8, 2015.
Information-Centric Networks07a-1 Week 7 / Paper 1 Internet Indirection Infrastructure –Ion Stoica, Daniel Adkins, Shelley Zhuang, Scott Shenker, Sonesh.
Chord: A Scalable Peer-to-peer Lookup Protocol for Internet Applications Xiaozhou Li COS 461: Computer Networks (precept 04/06/12) Princeton University.
Information-Centric Networks06a-1 Week 6 / Paper 1 Untangling the Web from DNS –Michael Walfish, Hari Balakrishnan and Scott Shenker –Networked Systems.
1 Distributed Hash Tables (DHTs) Lars Jørgen Lillehovde Jo Grimstad Bang Distributed Hash Tables (DHTs)
Peer-to-Peer Name Service (P2PNS) Ingmar Baumgart Institute of Telematics, Universität Karlsruhe IETF 70, Vancouver.
Perils of Transitive Trust in the Domain Name System Chen Xi Chen Xi.
Networking 2012 On inter-domain name resolution for information-centric networks K.V. Katsaros, N. Fotiou, X. Vasilakos, C.N. Ververidis, C. Tsilopoulos,
Paper Survey of DHT Distributed Hash Table. Usages Directory service  Very little amount of information, such as URI, metadata, … Storage  Data, such.
How to use DNS during the evolution of ICN? Zhiwei Yan.
Information-Centric Networks06c-1 Week 6 / Paper 3 Middleboxes No Longer Considered Harmful –Michael Walfish, Jeremy Stribling, Maxwell Krohn, Hari Balakrishnan,
DNS DNS overview DNS operation DNS zones. DNS Overview Name to IP address lookup service based on Domain Names Some DNS servers hold name and address.
Information-Centric Networks Section # 3.2: DNS Issues Instructor: George Xylomenos Department: Informatics.
Information-Centric Networks Section # 5.3: Content Distribution Instructor: George Xylomenos Department: Informatics.
Information-Centric Networks Section # 6.3: Evolved Naming & Resolution Instructor: George Xylomenos Department: Informatics.
Information-Centric Networks Section # 9.3: Clean Slate Instructor: George Xylomenos Department: Informatics.
Information-Centric Networks Section # 7.2: Evolved Addressing & Forwarding Instructor: George Xylomenos Department: Informatics.
Information-Centric Networks Section # 10.2: Publish/Subscribe Instructor: George Xylomenos Department: Informatics.
Peer to Peer Network Design Discovery and Routing algorithms
Information-Centric Networks Section # 3.1: DNS Issues Instructor: George Xylomenos Department: Informatics.
Information-Centric Networks Section # 6.2: Evolved Naming & Resolution Instructor: George Xylomenos Department: Informatics.
Information-Centric Networks Section # 7.1: Evolved Addressing & Forwarding Instructor: George Xylomenos Department: Informatics.
Information-Centric Networks Section # 1.1: Introduction Instructor: George Xylomenos Department: Informatics.
Information-Centric Networks Section # 4.3: Routing Issues Instructor: George Xylomenos Department: Informatics.
Information-Centric Networks Section # 6.1: Evolved Naming & Resolution Instructor: George Xylomenos Department: Informatics.
Information-Centric Networks Section # 7.3: Evolved Addressing & Forwarding Instructor: George Xylomenos Department: Informatics.
Information-Centric Networks Section # 10.3: Publish/Subscribe Instructor: George Xylomenos Department: Informatics.
Information-Centric Networks Section # 4.1: Routing Issues Instructor: George Xylomenos Department: Informatics.
CS 6401 Overlay Networks Outline Overlay networks overview Routing overlays Resilient Overlay Networks Content Distribution Networks.
Information-Centric Networks Section # 4.2: Routing Issues Instructor: George Xylomenos Department: Informatics.
Information-Centric Networks Section # 13.2: Alternatives Instructor: George Xylomenos Department: Informatics.
Information-Centric Networks Section # 2.3: Internet Evolution Instructor: George Xylomenos Department: Informatics.
LOOKING UP DATA IN P2P SYSTEMS Hari Balakrishnan M. Frans Kaashoek David Karger Robert Morris Ion Stoica MIT LCS.
Information-Centric Networks Section # 5.1: Content Distribution Instructor: George Xylomenos Department: Informatics.
Large Scale Sharing Marco F. Duarte COMP 520: Distributed Systems September 19, 2004.
The Design and Implementation of a Next Generation Name Service for the Internet V. Ramasubramanian, E. Gun Sirer Cornell Univ. SIGCOMM 2004 Ciprian Tutu.
TRUST Self-Organizing Systems Emin G ü n Sirer, Cornell University.
John S. Otto Mario A. Sánchez John P. Rula Fabián E. Bustamante Northwestern, EECS.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved DISTRIBUTED SYSTEMS.
Using Digital Signature with DNS. DNS structure Virtually every application uses the Domain Name System (DNS). DNS database maps: –Name to IP address.
Consistent Hashing and Distributed Hash Table
Presentation transcript:

Information-Centric Networks Section # 3.3: DNS Issues Instructor: George Xylomenos Department: Informatics

Funding These educational materials have been developed as part of the instructors educational tasks. The “Athens University of Economics and Business Open Courses” project only funded the reformatting of these educational materials. The project is being implemented as part of the Operational Program “Instruction and Lifelong Learning” and is co- financed by the European Union (European Social Fund) and national funds.

Licencing These educational materials are subject to a Creative Commons License.

Information-Centric Networks03c-4 Week 3 / Paper 3 The design and implementation of a next generation name service for the Internet –Venugopalan Ramasubramanian and Emin Gun Sirer –ACM SIGCOMM 2004 Main point –DNS is slow, vulnerable and not dynamic –CoDoNS is a DHT based alternative –It can work with or without DNS –PlanetLab tests show that it works very well

Information-Centric Networks03c-5 Introduction Susceptibility to DoS attacks –Limited server redundancy 80% of domains only have two authoritative servers 32% of the servers have a single connection to the Internet –The root servers are not that many –20% of DNS servers suffer from severe security flaws Name-address translation is slow –Up to 30% of web transactions require >1 sec for DNS –Caching does not work very well due to the skewed tree –CDNs require very small TTL values Caching prevents dynamic mapping –Changes to DNS may take a long time to propagate –Services cannot be relocated quickly

Information-Centric Networks03c-6 Design goals A DNS replacement should have the following properties –Higher performance than DNS –Resilience to attacks –Fast (but secure) update propagation Cooperative Domain Name System (CoDoNS) –Uses a DHT for self-organization, scalability and resilience –Adds a proactive caching layer to replicate mappings –Wire-protocol compatible with DNS Clients simply direct their queries to CoDoNS servers Names not added to CoDoNS are translated by DNS –Decouples namespace management from physical delegation Name records are self-validating You can use many namespace operators for the same names

Information-Centric Networks03c-7 Problems with legacy DNS Study of DNS delegation chains –Based on two web directories and 500 most popular domains Failure resiliency – bottlenecks –Delegation bottlenecks How many servers need to be compromised to control a domain? –78.63% of domains rely on two servers –Over 90% rely on three or less nameservers –Physical bottlenecks How many gateways need to be compromised to control a domain? –33% of domains are bottlenecked at a single gateway –Redundant name servers are typically in the same area –Even Microsoft used to have all its servers on the same area

Information-Centric Networks03c-8 Problems with legacy DNS Failure resilience – implementation errors –2% of servers have the serious tsig bug Can be used to control the server –19% of servers have the negcache problem Can be used for DoS attacks Performance – latency –1-2 seconds are quite common –Largely due to the long tail of name popularity distribution Caching cannot help rarely accessed names –CDNs have made things worse The use of low TTLs reduces caching efficiency But it is required to perform server selection

Information-Centric Networks03c-9 Problems with legacy DNS Performance – misconfigurations –14% of domains return inconsistent responses –Due to delegation errors and timeouts Performance – load imbalance –The higher levels are necessarily loaded –The 16 root nameservers are became 60 –Performance and reliability issues Update propagation –The TTL has to balance caching and update propagation –Low TTL means limited caching –High TTL means slow update propagation –40% of domains use TTLs of one day or more

Information-Centric Networks03c-10 CoDoNS: Beehive Beehive is a proactive replication framework –Allows O(1) lookups on prefix matching DHTs Can be used on Pastry and Tapestry –These DHTs route objects by matching prefix digits –Normally this requires O(logN) steps –Beehive proactively caches objects on the path to a node Replication at level n means that an object is within n steps This means that it is cached at all nodes with n matching digits –The trick is to use popularity to decide on caching You need to know the popularity ranking of objects Then you set a goal for the average hops for a match A formula provides the level of replication for each object –Replication is predictable, unlike caching You can update replicas because you know where they are

Information-Centric Networks03c-11 CoDoNS: Beehive How do you know how popular an object is? –Combination of local measurements and aggregation –Each node locally tracks object access frequencies –Periodically each node aggregates values from descendants Recursively, all data reach the home node of the object –The home node pushes the estimate to replicating nodes –Each node calculates the replication level for each object –A replication protocol is used to insert/update/remove replicas Each node only talks to nodes one level away from itself –Each node only needs to track nodes one hop away Response to flash crowds and attacks –The access frequencies change rapidly –The replication level is increased automatically

Information-Centric Networks03c-12 CoDoNS: architecture Namespace management <> name resolution –Each institution contributes some nodes to CoDoNS These nodes self-organize into a DHT –Nameowners purchase name certificates from operators Names are inserted into CoDoNS with these certificates –The home node for a name is calculated by hashing The home node holds a permanent record of the data It also manages the replication protocol Each object is replicated close to the home node for failover The namespace does not have to be hierarchical What happens with names outside CoDoNS? –Their “home node” fetches the data from DNS –It is also responsible to monitor the DNS for changes

Information-Centric Networks03c-13 CoDoNS: implementation CoDoNS is layered on top of Pastry and Beehive –Each query is routed via Pastry to the home node –Either a cache or the home node responds –Beehive proactively replicates popular objects –Data can also be entered in local CoDoNS servers This avoids asking for it from a faraway home node There is no other caching in CoDoNS! –Only replication and locally entered data –Replicated data does not time out It is only proactively modified –Each node knows with whom to replicate data CoDoNS can update data very quickly

Information-Centric Networks03c-14 Issues and implications CoDoNS is based on DNSSEC –DNS records are digitally signed by operators –Public keys and certificates are stored in DNS –Each node can verify the authenticity of signed records –CoDoNS also caches the certificates –Only signed data can be inserted into CoDoNS All servers check verify data signatures –CoDoNS uses certifying resolvers for DNS data Multiple resolvers are used to ensure authenticity CDNs are supported in a special way –CoDoNS cannot be used to do the “stupid DNS tricks” –Redirection records are used to select servers instead They are replicated like any other record

Information-Centric Networks03c-15 Evaluation Based on a PlanetLab deployment –75 nodes were used, getting data from DNS –Queries were issued after the Pastry DHT stabilized –Comparison with regular DNS Lookup performance –Initially CoDoNS is slower than DNS It needs to fetch data from DNS first –Eventually it is much faster than DNS Records are cached after being fetched from the DNS Flash-crowd effect –Modeled as a large scale change (reversal) of object popularity –During the switch CoDoNS slows down –A bit later is starts outperforming DNS again

Information-Centric Networks03c-16 Evaluation Load balance –Initially the home nodes of popular objects are overloaded –Eventually load is spread evenly due to proactive caching –Even with flash crowds, CoDoNS adapts quickly Update propagation –98% of replicas are updated within one second This allows DNS to handle dynamic objects How much does this cost? –Nodes need to store 10% of total records for this performance Roughly 13 MB per node –Low bandwidth usage for all network activities 12.2 KB/s on average

Information-Centric Networks03c-17 Counterpoint What about the comparative study of DNS with DHTs? –That paper (supplementary reading) does not endorse DHTs –It shows that DNS works better for some things –Plus, it can be modified to work as good as DHTs in others BUT, it does not compare DNS with CoDoNS –It uses a simple DHT (Chord) without proactive caching –DHTs without modifications do indeed have many problems They cannot compete with DNS for hierarchical namespaces –The core idea in CoDoNS is not the DHT but Beehive Proactive replication is heavily used Otherwise lookups are not particularly fast Replication improves the common case –It is important to understand what is compared in each case!

End of Section # 3.3 Course: Information-Centric Networks, Section # 3.3: DNS Issues Instructor: George Xylomenos, Department: Informatics