1 / 21

DNS: Domain Name System

People: many identifiers: SSN, name, Passport # Internet hosts, routers: IP address (32 bit) - used for addressing datagrams “name”, e.g., gaia.cs.umass.edu - used by humans Q: map between IP addresses and name ?. Domain Name System:

usoa
Download Presentation

DNS: Domain Name System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. People: many identifiers: SSN, name, Passport # Internet hosts, routers: IP address (32 bit) - used for addressing datagrams “name”, e.g., gaia.cs.umass.edu - used by humans Q: map between IP addresses and name ? Domain Name System: distributed database implemented in hierarchy of many name servers application-layer protocol host, routers, name servers to communicate to resolvenames (address/name translation) note: core Internet function implemented as application-layer protocol complexity at network’s “edge” DNS: Domain Name System

  2. no server has all name-to-IP address mappings local name servers: each ISP, company has local (default) name server host DNS query first goes to local name server authoritative name server: for a host: stores that host’s IP address, name can perform name/address translation for that host’s name Why not centralize DNS? single point of failure traffic volume distant centralized database Maintenance DoS attacks? doesn’t scale! DNS name servers

  3. contacted by local name server that can not resolve name root name server: contacts authoritative name server if name mapping not known gets mapping returns mapping to local name server ~ dozen root name servers worldwide 13 root DNS servers: replication for security and reliability Top-level DNS server: org, edu, com, jp,cn, fr, uk DNS: Root name servers

  4. host surf.eurecom.fr wants IP address of gaia.cs.umass.edu 1. Contacts its local DNS server, dns.eurecom.fr 2.dns.eurecom.fr contacts root name server, if necessary 3. root name server contacts authoritative name server, dns.umass.edu, if necessary local name server dns.eurecom.fr Simple DNS example root name server 2 4 3 5 authorititive name server dns.umass.edu 1 6 requesting host surf.eurecom.fr gaia.cs.umass.edu

  5. Root name server: may not know authoratiative name server may know intermediate name server: who to contact to find authoritative name server local name server dns.eurecom.fr intermediate name server dns.umass.edu DNS example root name server 6 2 3 7 5 4 1 8 authoritative name server dns.cs.umass.edu requesting host surf.eurecom.fr gaia.cs.umass.edu

  6. recursive query: puts burden of name resolution on contacted name server heavy load? iterated query: contacted server replies with name of server to contact “I don’t know this name, but ask this server” local name server dns.eurecom.fr intermediate name server dns.umass.edu DNS: iterated queries root name server iterated query 2 3 4 7 5 6 1 8 authoritative name server dns.cs.umass.edu requesting host surf.eurecom.fr gaia.cs.umass.edu

  7. once (any) name server learns mapping, it caches mapping cache entries timeout (disappear) after some time update/notify mechanisms under design by IETF RFC 2136 http://www.ietf.org/html.charters/dnsind-charter.html DNS: caching and updating records

  8. DNS: distributed db storing resource records (RR) Type=NS name is domain (e.g. foo.com) value is IP address of authoritative name server for this domain RR format: (name, value, type,ttl) DNS records • Type=CNAME • name is an alias name for some “cannonical” (the real) name • value is cannonical name • Type=A • name is hostname • value is IP address • Type=MX • value is hostname of mailserver associated with name

  9. DNS records For a particular hostname • If a DNS server is authoritative, it contains • a Type A record for the hostname • Otherwise • Maybe a Type A record for the hostname in cache • a Type NS record for the domain of the hostname • a Type A record for the DNS server for that domain • Host: gaia.cs.umass.edu • (umass.edu, dns.umass.edu, NS) • (dns.umass.edu, 128.119.40.111, A)

  10. DNS protocol :queryand repy messages, both with same message format DNS protocol, messages msg header • identification: 16 bit # for query, repy to query uses same # • flags: • query or reply • recursion desired • recursion available • reply is authoritative

  11. DNS protocol, messages Name, type fields for a query RRs in reponse to query records for authoritative servers additional “helpful” info that may be used Try nslookup?

  12. Mystery: How to set up your DNS server? • You setup a company: mynet.com • Step 1: register your domain name with a registrar • Provide name and IP address mapping • Primary authoritative DNS server: dns1.mynet.com, 212.212.212.1 • Optional: secondary DNS server: dns.mynet.com, 212.212.212.2 • Registrar will insert type NS and A records for you • (mynet.com, dns1.mynet.com, NS) • (dn1.mynet.com, 212.212.212.1, A) • Step 2: insert records into your DNS server • For web server (www.mynet.com, 212.212.212.3,A) • For mail sever (mail.mynet.com, 212.212.212.4, MX) • Then, others can access your web server and send emails

  13. a host-local, application-created/owned, OS-controlled interface (a “door”) into which application process can both send and receive messages to/from another (remote or local) application process socket Socket programming Goal: learn how to build client/server application that communicate using sockets Socket API • introduced in BSD4.1 UNIX, 1981 • explicitly created, used, released by apps • client/server paradigm • two types of transport service via socket API: • unreliable datagram • reliable, byte stream-oriented

  14. process process TCP with buffers, variables TCP with buffers, variables socket socket Socket-programming using TCP Socket: a door between application process and end-end-transport protocol (UCP or TCP) TCP service: reliable transfer of bytes from one process to another controlled by application developer controlled by application developer controlled by operating system controlled by operating system internet host or server host or server

  15. Client must contact server server process must first be running server must have created socket (door) that welcomes client’s contact Client contacts server by: creating client-local TCP socket specifying IP address, port number of server process When client creates socket: client TCP establishes connection to server TCP When contacted by client, server TCP creates new socket for server process to communicate with client allows server to talk with multiple clients TCP provides reliable, in-order transfer of bytes (“pipe”) between client and server application viewpoint Socket programming with TCP

  16. Example client-server app: client reads line from standard input, sends to server via socket server reads line from socket server converts line to uppercase, sends back to client client reads, prints modified line from socket Input stream: sequence of bytes into process Output stream: sequence of bytes out of process Socket programming with TCP outToServer iinFromServer inFromUser client socket

  17. create socket, connect to hostid, port=x create socket, port=x, for incoming request: int cli_socket = socket(..);connect(s,…); int s = socket(…); bind(s,…) listen(s,5); TCP connection setup wait for incoming connection request int cs = accept(s,….) send request using cli_socket read request from cs write reply to cs read reply from cli_socket close cs close cli_socket Client/server socket interaction: TCP Server (running on hostid) Client

  18. Multi-Clients Servers • Two main approaches to designing such servers. • Approach 1. • The first approach is using one process that awaits new connections, and one more process (or thread) for each Client already connected. This approach makes design quite easy, cause then the main process does not need to differ between servers, and the sub-processes are each a single-Client server process, hence, easier to implement. • However, this approach wastes too many system resources (if child processes are used), and complicates inter-Client communication: If one Client wants to send a message to another through the server, this will require communication between two processes on the server, or locking mechanisms, if using multiple threads. • See tutor for details!

  19. UDP: no “connection” between client and server no handshaking sender explicitly attaches IP address and port of destination server must extract IP address, port of sender from received datagram UDP: transmitted data may be received out of order, or lost UDP provides unreliable transfer of groups of bytes (“datagrams”) between client and server application viewpoint Socket programming with UDP

  20. application service requirements: reliability, bandwidth, delay client-server paradigm Internet transport service model connection-oriented, reliable: TCP unreliable, datagrams: UDP Our study of network apps now complete! Summary • specific protocols: • http • ftp • smtp, pop3 • dns • socket programming • client/server implementation • using tcp, udp sockets

  21. typical request/reply message exchange: client requests info or service server responds with data, status code message formats: headers: fields giving info about data data: info being communicated Most importantly: learned about protocols Summary • control vs. data msgs • in-based, out-of-band • centralized vs. decentralized • stateless vs. stateful • reliable vs. unreliable msg transfer • “complexity at network edge” • security: authentication

More Related