DNS Fundamentals PDF

gaia.cs.umass.edu ? You need to check out the.edu TLD gaia.cs.umass.edu ? You need to check out the dns.umass.edu gaia.cs.umass.edu ? gaia.cs.umass.edu ?...

gaia.cs.umass.edu ? You need to check out the.edu TLD gaia.cs.umass.edu ? You need to check out the dns.umass.edu gaia.cs.umass.edu ? gaia.cs.umass.edu ? Its X.X.X.X Its X.X.X.X  Recursive queries in DNS Recursive query: ▪ puts burden of name resolution on contacted name server ▪ heavy load at upper levels of hierarchy?  DNS: caching 2- 137  DNS caching is used  to improve performance (delay)  to reduce the number of DNS messages going around the Internet (save bandwidth)  once (any) name server learns mapping, it caches mapping in local memory  cache entries timeout (disappear) after some time (TTL)  TLD servers typically cached in local name servers  thus root name servers not often visited  DNS: caching 2- 138  cached entries may be out-of-date (best effort name-to- address translation!)  if name host changes IP address, may not be known Internet-wide until all TTLs expire (e.g. keep for 2 days)  update/notify mechanisms proposed IETF standard  RFC 2136  DNS: record  The DNS server stores different types of resource records (RR) used to resolve names. These records contain the name, address, and type of record.  Some of these record types are: RR Format: (Name, Value, Type, TTL) Type=A - an end device address ➔ Value is the IP address for the hostname. Type=NS - an authoritative name server ➔ Value is the hostname of an authoritative DNS server that knows how to get the IP addresses for hostname (e.g. foo.com) Type= CNAME ➔ Value is a canonical hostname (or Fully Qualified Domain Name) for the alias hostname Name. www.ibm.com is really servereast.backup2.ibm.com Type= MX ➔ Value is the canonical name of a mail server that has an alias hostname Name.  DNS protocol, messages 2- 142  There are query and reply messages ➔ both with same message form ❖ identification: 16 bit number for query, reply to query uses same number ❖ flags: ▪ query or reply ▪ recursion desired ▪ recursion available ▪ reply is authoritative Application Layer  DNS: A 16-bit number that Indicators: query/reply messages identifies the query. etc. RR – Resource Records Class activity: Using nslookup 144  Getting your info into the DNS Applicatio n Layer: 2-145 example: new startup “Network Utopia” ▪ register name networkuptopia.com at DNS registrar (e.g., Network Solutions) provide names, IP addresses of authoritative name server (primary and secondary) registrar inserts NS, A RRs into.com TLD server: (networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, 212.212.212.1, A) ▪ create authoritative server locally with IP address 212.212.212.1 type A record for www.networkuptopia.com type MX record for networkutopia.com  DNS security DDoS attacks Spoofing attacks ▪bombard root servers ▪ intercept DNS queries, with traffic returning bogus replies not successful to date ▪ DNS cache poisoning traffic filtering ▪ Send bogus replies to DNS server, which local DNS servers cache caches IPs of TLD servers, ▪ RFC 4033: DNSSEC allowing root server authentication services bypass ▪bombard TLD servers exploit DNS for DDoS ▪send queries with spoofed source address: potentially more target IP dangerous ▪requires amplification  Chapter 2: Outline  Principles of network  P2P applications applications  video streaming and  app architectures content distribution  app requirements networks  Web and HTTP  socket programming with  Electronic mail UDP and TCP  SMTP, POP3, IMAP  DNS P2P & CDN  Peer-to-peer (P2P) architecture ▪ no always-on server ▪ arbitrary end systems directly communicate mobile network national or global ISP ▪ peers request service from other peers, provide service in return to other peers self scalability – new peers bring local or regional new service capacity, and new ISP service demands home network content provider ▪ peers are intermittently network datacenter network connected and change IP addresses enterprise ▪ examples: P2P file sharing network (BitTorrent), streaming (KanKan), VoIP (Skype)  File distribution: client-server vs P2P Question: how much time to di: peer i download distribute file capacity us: server (size F) from upload one server to N capacity peers? network (with abundant peer bandwidth) upload/download capacity is limited resource ui: peer i upload capacity  File distribution: client-server vs P2P  TWO assumptions are us: server made upload capacity di: peer i download 1. the Internet core has capacity abundant bandwidth, implying that all of the bottlenecks are in access networks. network (with abundant bandwidth) 2. the server and clients are not participating in any ui: peer i other network upload capacity applications  us: server File distribution: client-server upload capacity  server transmission: must di: peer i sequentially send (upload) N file download capacity copies:  time to send one copy: F/us ui: peer i upload  time to send N copies: NF/us capacity ▪ client: each client must download file copy dmin = min client download rate min client download time: F/dmin time to distribute F to N clients using Dc-s > max{NF/us,,F/dmin} client-server approach increases linearly in N Dcs = the distribution time for the client-server architecture N = the number of peers that the server service (each needs a copy) NF = the total transmitted bits to all peers us = server’s upload rate dmin = the download rate of the peer with the lowest download rate F/dmin = the minimum distribution time the distribution time increases linearly with the number of peers N  us: server File distribution: P2P upload capacity  server transmission: must upload di: peer i at least one copy download capacity  time to send one copy: F/us ▪ client: each client must download ui: peer i upload file copy capacity min client download time: F/dmin ▪ clients: as aggregate must download NF bits max upload rate (limiting max download rate) is us + Sui time to distribute F to N clients using DP2P > max{F/us,,F/dmin,,NF/(us + Sui)} P2P approach  File distribution: P2P increases linearly in N time to distribute F to N clients using DP2P > max{F/us,,F/dmin,,NF/(us + Sui)} P2P approach Increases as each peer brings service capacity  the minimum distribution time F/us = the min distribution time for the client-server (at beginning) N = the number of peers that the server service (each needs a copy) NF = the total transmitted bits to all peers us = server’s upload rate dmin = the download rate of the peer with the lowest download rate F/dmin = the minimum distribution time Sui = total upload rates of each of the individual peers the total upload capacity of the system as a whole is equal to the upload rate of the server plus the upload rates of each of the individual peers. Distribution time for P2P and client-server architectures For the CS architecture: the distribution time increases linearly and without bound as the number of peers increases For the P2P architecture: the minimal distribution time is always less than the distribution time of the CS P2P file tracker: tracks peers participating in torrent torrent: group of peers distribution: exchanging chunks of a file BitTorrent o file divided into 256Kb chunks Alice arrives o peers in torrent send/receive file chunks → obtains list of peers from tracker → and begins exchanging file chunks with peers in torrent  P2P file distribution: BitTorrent  peer joining torrent:  has no chunks, but will accumulate them over time from other peers  registers with tracker to get list of peers, connects to subset of peers (“neighbors”) ❖ while downloading, peer uploads chunks to other peers ❖ peer may change peers with whom it exchanges chunks ❖ churn: peers may come and go ❖ once peer has entire file, it may (selfishly) leave or (altruistically) remain in torrent  BitTorrent: requesting, sending file chunks requesting chunks: sending chunks: tit-for-tat  at any given time, different ❖ Alice sends chunks to those peers have different subsets four peers currently sending her of file chunks chunks at highest rate ▪ other peers are choked by Alice (do  periodically, Alice asks each not receive chunks from her) peer for list of chunks that ▪ re-evaluate top 4 every10 secs they have ❖ every 30 secs: randomly select another peer, starts sending  Alice requests missing chunks chunks from peers, rarest ▪ “optimistically unchoke” this peer first ▪ newly chosen peer may join top 4 BitTorrent: tit-for-tat (1) Alice “optimistically unchokes” Bob (2) Alice becomes one of Bob’s top-four providers; Bob reciprocates (3) Bob becomes one of Alice’s top-four providers higher upload rate: find better trading partners, get file faster ! requests missing chunks from peers: rarest first  Chapter 2: outline 2- 168  2.1 principles of network  2.5 P2P applications applications  2.6 video streaming and  2.2 Web and HTTP content distribution  2.3 electronic mail networks (CDNs)  SMTP, POP3, IMAP  2.7 socket programming  2.4 DNS with UDP and TCP Video Streaming and CDNs: context ▪ stream video traffic: major consumer of Internet bandwidth Netflix, YouTube, Amazon Prime: account for 80% of residential ISP traffic (2020) Netflix, YouTube: 37%, 16% of downstream residential ISP traffic ~1B YouTube users, ~75M Netflix users ▪ challenge: scale - how to reach ~1B users? ▪ challenge: heterogeneity ▪different users have different capabilities (e.g., wired versus mobile; bandwidth rich versus bandwidth poor) ▪ solution: distributed, application-level infrastructure  spatial coding example: instead Multimedia: video of sending N values of same color (all purple), send only two values: color value (purple) and number of repeated values (N)  video: sequence of images displayed at constant rate …………………….. ……………….…….  e.g., 24 images/sec  digital image: array of pixels  each pixel represented by bits  coding: use redundancy frame i within and between images to decrease # bits used to encode image  spatial (within image) temporal coding example: instead of sending  temporal (from one image to complete frame at i+1, next) send only differences from frame i+1 frame i  Multimedia: video spatial coding example: instead of sending N values of same color (all purple), send only two ▪ CBR: (constant bit rate): values: color value (purple) and video encoding rate fixed number of repeated values (N) ▪ VBR: (variable bit rate): …………………….. ……………….……. video encoding rate changes as amount of spatial, temporal coding changes ▪ examples: MPEG 1 (CD-ROM) 1.5 frame i Mbps MPEG2 (DVD) 3-6 Mbps MPEG4 (often used in Internet, < 1 Mbps) temporal coding example: instead of sending complete frame at i+1, use compression to create multiple send only differences from versions of the same video, each at a frame i frame i+1 different quality level.  Streaming stored video: simple scenario: Internet video server client (stored video) Have a major shortcoming: All clients receive the same encoding of the video, despite the large variations in the amount of bandwidth available to a client ➔across different clients ➔over time for the same client.  Streaming multimedia: DASH  DASH: Dynamic, Adaptive Streaming over HTTP  server:  divides video file into multiple chunks  each chunk stored, encoded at different rates  manifest file: provides URLs for different chunks  client:  periodically measures server-to-client bandwidth  consulting manifest, requests one chunk at a time  chooses maximum coding rate sustainable given current bandwidth  can choose different coding rates at different points in time (depending on available bandwidth at time)  Streaming multimedia: DASH  DASH: Dynamic, Adaptive Streaming over HTTP  “intelligence” at client: client determines  when to request chunk (so that buffer starvation, or overflow does not occur)  what encoding rate to request (higher quality when more bandwidth available)  where to request chunk (can request from URL server that is “close” to client or has high available bandwidth) Streaming video = encoding + DASH + playout buffering  Streaming stored video: simple scenario: Internet video server client (stored video) With DASH: Dynamic, Adaptive Streaming over HTTP use compression to create multiple Users decide which version they want versions of the same video, each at a to depending on their current available different quality level. bandwidth. DASH allows the client to freely switch among different quality levels. Content distribution networks (CDNs) challenge: how to stream content (selected from millions of videos) to hundreds of thousands of simultaneous users? ▪ option 1: single, large “mega-server” single point of failure ….quite simply: this point of network congestion solution doesn't scale long (and possibly congested) path to distant clients multiple copies of video sent over outgoing link ▪ option 2: store/serve multiple copies of videos at multiple geographically distributed sites (CDN) CDN A CDN is a system of distributed servers (network) that deliver pages and other Web content to a user, based on the geographic locations of the user, the origin of the webpage and the content delivery server. It attempts to direct each user request to a CDN location that will provide the best user experience oA CDN’s job is to enhance your regular hosting by reducing bandwidth consumption minimizing latency providing the scalability needed to handle abnormal traffic loads. o Requires a robust network architecture **scrubbing server : for security (DDoS scrubbing)  CDN  Servers in multiple geographic locations  May be  private CDN (owned by content provider) - Google’s CDN distributes YouTube videos and other types of content  a 3-rd party CDN (pay someone else to do it) -Akamai, Limelight and Level-3 all operate third-party CDNs  CDN placements:  Enter Deep  Bring Home  CDN replicates content across clusters  Not all – just popular ones  Uses pull strategy  Clients request → cluster retrieve → cluster caches → cluster clears when cache is full  CDN placements  Enter Deep  Goal: get close to end users (into access networks) → improve user- perceived delay and throughput  Deploy server clusters in access ISP all over the world  Akamai has about 240,000 locations in >120 countries (2015)  Issue: maintain and manage these clusters  Bring Home  Goal: get close to ISPs→ lower maintenance and management overhead  Deploy server clusters in IXP (Internet Xchange Point)  Instead of getting inside the access ISPs, these CDNs typically place each cluster at a location that is simultaneously near the point of presence (POP) of many tier-1 ISPs.  Smaller number (10’s) of larger clusters – connected using private high-speed network  Issue: higher delay, lower throughput  Homework  CASE STUDY: GOOGLE’S NETWORK INFRASTRUCTURE  Read this in Textbook (pg. 179)  Video link ➔ http://video.netcinema.com/6Y7B23V Most CDNs take advantage of DNS to intercept and redirect requests User visits the web page at Assume NetCinema NetCinema pays the 3rd party CDN company, KingCDN, to IP for video link? distribute its videos IP for video link? to its customers. Ask KingCDN.com IP = X.X.X.X IP for video link? TCP connection established IP = X.X.X.X Issue HTTP GET If DASH is used - May have manifest file  Which CDN servers to refer to?  Cluster selection strategy is employed.  This is a mechanism for dynamically directing clients to a server cluster or a data center within the CDN  Approaches:  Geographically closest  Easiest, can cater many users (not all)  Tend to use the same CDN servers (do not consider variation in delay and available bandwidth)  Real-time measurements  Determine best cluster based on current traffic conditions  How: send probes periodically to measure  Issue: Many LDNS servers are configured to not respond to probes Netflix video streaming platform Netflix video distribution has two major components: 1. the Amazon cloud and AC services? 2. its own private CDN infrastructure. Netflix employs many of the techniques, including video distribution using a CDN (actually multiple CDNs) adaptive streaming over HTTP  Netflix: Amazon Cloud services  User side: User accounts, registration, payment, movie catalogue, search, recommendation  Content ingestion  Netflix get studio master versions of movies → uploads and processes them to hosts in the Amazon cloud  Content processing  create many different formats for each movie, suitable for a diverse array of client video players running on different end devices  A different version is created for each of these formats and at multiple bit rates, allowing for adaptive streaming over HTTP using DASH.  Uploading versions to its CDN  the hosts in the Amazon cloud upload these versions to its CDN servers  Case study: Netflix Amazon cloud upload copies of multiple versions of video to CDN servers CDN server Netflix registration, accounting servers Bob browses Netflix video CDN 2 Manifest file, server requested 1 3 returned for Bob manages specific video Netflix account CDN 4 server DASH server selected, contacted, streaming begins  Chapter 2: outline 2.1 principles of network  2.5 P2P applications applications  2.6 video streaming and 2.2 Web and HTTP content distribution 2.3 electronic mail networks (CDNs) SMTP, POP3, IMAP  2.7 socket programming 2.4 DNS with UDP and TCP  Socket programming goal: learn how to build client/server applications that communicate using sockets socket: door between application process and end-end- transport protocol  Socket programming Two socket types for two transport services:  UDP: unreliable datagram  TCP: reliable, byte stream-oriented Application Example: 1. client reads a line of characters (data) from its keyboard and sends data to server 2. server receives the data and converts characters to uppercase 3. server sends modified data to client 4. client receives modified data and displays line on its screen  Socket programming with UDP UDP: no “connection” between client & server  no handshaking before sending data  sender explicitly attaches IP destination address and port # to each packet  receiver extracts sender IP address and port# from received packet UDP: transmitted data may be lost or received out-of-order Application viewpoint:  UDP provides unreliable transfer of groups of bytes (“datagrams”) between client and server Client/server socket interaction: UDP server (running on serverIP) client create socket: create socket, port= x: clientSocket = serverSocket = socket(AF_INET,SOCK_DGRAM) socket(AF_INET,SOCK_DGRAM) Create datagram with server IP and port=x; send datagram via read datagram from clientSocket serverSocket write reply to serverSocket read datagram from specifying clientSocket client address, port number close clientSocket  Example app: UDP client Python UDPClient include Python’s socket library from socket import * ▪IP address (128.138.32.126) or the ▪hostname (abc.uniA.edu) of the server serverName = ‘hostname’ serverPort = 12000 ▪AF = Address family create UDP socket for clientSocket = socket(AF_INET, ▪AF_INET = IPv4 server SOCK_DGRAM) get user keyboard input message = raw_input(’Input lowercase sentence:’) Attach server name, port to clientSocket.sendto(message.encode(), message; send into socket (serverName, serverPort)) modifiedMessage, serverAddress = read reply characters from socket into string clientSocket.recvfrom(2048) print out received string print modifiedMessage.decode() and close socket clientSocket.close()  Example app: UDP server Python UDPServer from socket import * serverPort = 12000 create UDP socket serverSocket = socket(AF_INET, SOCK_DGRAM) bind socket to local port number 12000 serverSocket.bind(('', serverPort)) print (“The server is ready to receive”) loop forever while True: Read from UDP socket into message, clientAddress = serverSocket.recvfrom(2048) message, getting client’s address (client IP and port) modifiedMessage = message.decode().upper() send upper case string serverSocket.sendto(modifiedMessage.encode(), back to this client clientAddress)  Socket programming with TCP client must contact server  when contacted by client, server TCP creates new  server process must first be socket for server process to running communicate with that  server must have created particular client socket (door) that welcomes  allows server to talk with client’s contact multiple clients  source port numbers used client contacts server by: to distinguish clients  Creating TCP socket, (more in Chap 3) specifying IP address, port number of server process application viewpoint:  when client creates TCP provides reliable, in-order socket: client TCP byte-stream transfer (“pipe”) establishes connection to between client and server server TCP Client/server socket interaction:TCP server (running on hostid) client create socket, port=x, for incoming request: serverSocket = socket() wait for incoming create socket, connection request TCP connect to hostid, port=x connectionSocket = connection setup clientSocket = socket() serverSocket.accept() send request using read request from clientSocket connectionSocket write reply to connectionSocket read reply from clientSocket close connectionSocket close clientSocket  Example app: TCP client Python TCPClient from socket import * Create a serverName = ’servername’ client TCP socket serverPort = 12000 create TCP socket for clientSocket = socket(AF_INET, SOCK_STREAM) server, remote port 12000 clientSocket.connect((serverName,serverPort)) sentence = raw_input(‘Input lowercase sentence:’) sends the sentence clientSocket.send(sentence.encode()) through the client’s socket and into the modifiedSentence = clientSocket.recv(1024) TCP connection. No need to attach server print (‘From Server:’, modifiedSentence.decode()) name, port clientSocket.close()  Example app: TCP server Python TCPServer from socket import * create TCP welcoming serverPort = 12000 socket serverSocket = socket(AF_INET,SOCK_STREAM) serverSocket.bind((‘’,serverPort)) server begins listening for incoming TCP requests serverSocket.listen(1) print ‘The server is ready to receive’ loop forever while True: server waits on accept() for incoming requests, new connectionSocket, addr = serverSocket.accept() socket created on return sentence = connectionSocket.recv(1024).decode() read bytes from socket (but not address as in UDP) capitalizedSentence = sentence.upper() close connection to this connectionSocket.send(capitalizedSentence. client (but not welcoming socket) encode()) connectionSocket.close()  Chapter 2: summary  application architectures our study of network apps  client-server now complete!  P2P ❖ specific protocols:  application service ▪ HTTP requirements: ▪ FTP  reliability, bandwidth, ▪ SMTP, POP, IMAP delay ▪ DNS  Internet transport service ▪ P2P: BitTorrent model ▪ video streaming, CDNs ▪ socket programming:  connection-oriented, reliable: TCP TCP, UDP sockets  unreliable, datagrams: UDP  Chapter 2: summary most importantly: learned about protocols!  typical request/reply important themes: message exchange: ❖ control vs. data messages  client requests info or ▪ in-band, out-of-band service ❖ centralized vs. decentralized  server responds with data, ❖ stateless vs. stateful status code ❖ reliable vs. unreliable  message formats: message transfer  headers: fields giving info ❖ “complexity at network about data  data: info being edge” communicated