1. 1 Computer Networks Application layer

2. 2 Application Layer So far –Socket programming, Network API Today –Application layer functions –Specific applications DNS FTP

3. 3 Application layer functions Applications –Implement desired functionality within application protocols when no underlying network service provides support –Functionality that is common rolled into libraries and “middleware” Functions –Security (S/MIME, PGP) –Delivery semantics (multicast overlays, anycast) –Reliable data transfer (reliable multicast, reliable UDP) –Quality of service (QoS overlays, scheduling) –Congestion control (Non-TCP applications) –Flow control (Non-TCP applications) –Naming (DNS) –Routing (overlays)

4. 4 AL: Specific application protocols DNS –Background –Nutshell description –DNS server design –DNS client lookups –DNS protocol messages FTP HTTP SMTP

5. 5 AL: Domain Name System (DNS) Internet hosts, routers like to use fixed length addresses (numbers) –IP address (32 bit) - used for addressing datagrams Humans like to use names –www.cse.ogi.eduwww.cse.ogi.edu –keywords DNS, keywords, naming protocols –Map from IP addresses to names –Map from names to IP addresses

6. 6 AL: Original Name to Address Mapping Flat namespace –/etc/hosts –SRI kept main copy –Downloaded regularly Problems –Count of hosts was increasing: machine per domain  machine per user Many more downloads Many more updates

7. 7 AL: Goals for a new naming system Implement a wide area distributed database –Scalability –Decentralized maintenance –Robustness, fault-tolerance –Global scope Names mean the same thing everywhere –Don’t need Atomicity Strong consistency

8. 8 AL: Goals for a new naming system Why not centralize DNS? Single server with all name-to-IP address mappings –single point of failure –traffic volume –distant centralized database (performance) –maintenance –doesn’t scale!

9. 9 AL: DNS (Domain Name System) http://www.rfc-editor.org/rfc/rfc1034.txt http://www.rfc-editor.org/rfc/rfc1035.txt distributed database implemented in hierarchy of many name servers decentralized control and management of data application-layer protocol used by hosts, routers, and name servers –communicate to resolve names (address/name translation) –core Internet function implemented as application-layer protocol complexity at network’s “edge” compare to phone network naming

10. 10 AL: DNS nutshell solution Hierarchical canonical name space –www.cse.ogi.edu root edu net org ukcom ca gwu ucb ogi bu mit cse ece www

11. 11 AL: DNS nutshell solution Distributed database stores names hierarchically Authoritative name servers store parts of the database –Names assigned to authoritative name servers For a host, authority stores that host’s IP address, name Responds to queries for host’s IP address Perform name/address translation for that host’s name –Hierarchy organizes authoritative name servers DNS hierarchy –Each host has a pointer to a local name server for which to query for unknown names –Each local name server knows root of hierarchy –Root points to sub-levels, sub-levels point to deeper sub-levels, …, deeper sub-levels point to leaf name server representing authority for unknown name

12. 12 AL: DNS nutshell figure Root name servers: may not know authoratiative name server may know intermediate name server: who to contact to find authoritative name server multiple root name servers for fault-tolerance requesting host surf.eurecom.fr gaia.cs.umass.edu root name server local name server dns.eurecom.fr 1 2 3 4 5 6 authoritative name server dns.cs.umass.edu intermediate name server dns.umass.edu 7 8

13. 13 AL: DNS server database DB contains tuples called resource records (RRs) –RR contains type, class and application data Before types added, only one record type (A) –Classes = Internet (IN), Chaosnet (CH), etc. –Each class defines types, e.g. for IN: A = address, NS = name server, CNAME = canonical name (for aliasing), HINFO = CPU/OS info, MX = mail exchange, PTR = pointer for reverse mapping of address to name

14. 14 AL: DNS record types Resource records (RR) and their types 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) Type=A –name is hostname –value is IP address Type=CNAME –name is an alias name for some “cannonical” (the real) name –value is cannonical name Type=MX –value is hostname of mailserver associated with name

15. 15 AL: DNS MX record type MX records point to mail exchanger for a name –E.g. mail.acm.org is MX for acm.org Addition of MX record type proved to be a challenge –How to get mail programs to lookup MX record for mail delivery rather than A record? –Needed critical mass of such mailers nslookup example

16. 16 AL: DNS server database distribution Administrative hierarchy –“.” as separator –Zone = contiguous section of name space Zones are created by convincing owner node to create/delegate a subzone –Each zone contains multiple redundant servers –Primary (master) name server updated manually –Secondary (redundant) servers updated by zone transfer of name space –Provides fault-tolerance within zone Host name to address section –Top-level domains  edu, gov, ca, us, etc. –Sub-domains = subtrees –Human readable name = leaf  root path

17. 17 AL: DNS client lookups Each host has a resolver –Typically a library that applications can link gethostbyname() –Local name servers hand-configured (e.g. /etc/resolv.conf) or automatically configured (DHCP) –Host queries local name server for unknown names Name servers –Configured with well-known root servers Currently {a-m}.root-servers.net –Local servers Typically do a recursive lookup of distant host names for local hosts Typically answer queries about local zone

18. 18 AL: Lookup Methods Recursive queries –Server goes out and searches for more info on behalf of the client (recursive) –Only returns final answer or “not found” –Puts burden of name resolution on contacted name server –Heavy load? Root server implosion Iterative –Server responds with as much as it knows (i.e. name of server to contact next) –“I don’t know this name, but ask this server” – Client iteratively queries additional servers

19. 19 AL: Typical Resolution Client does recursive request to local name server Local name server does iterative requests to find name Local name server has knowledge of root of name space Steps for resolving www.ogi.edu –Application calls gethostbyname() –Resolver contacts local name server (S 1 ) –S 1 queries root server (S 2 ) for (www.ogi.edu)www.ogi.edu –S 2 returns NS record for ogi.edu (S 3 ) –S 1 queries S 3 for www.ogi.eduwww.ogi.edu –S 3 returns A record for www.ogi.eduwww.ogi.edu Can return multiple addresses  what does this mean?

20. 20 AL: DNS Caching DNS responses are cached –Quick response for repeated translations –Other queries may reuse some parts of lookup NS records for domains DNS negative queries are also cached –Don’t have to repeat past mistakes –E.g. misspellings Cached data periodically times out –Soft state –Lifetime (TTL) of data controlled by owner of data –TTL passed with every record –TTL affects DNS-based load balancing techniques update/notify mechanisms under design by IETF –RFC 2136 –http://www.ietf.org/html.charters/dnsind-charter.html

21. 21 AL: A word about iterated queries and caching Why not do iterative queries from host? –Currently Host issues recursive query to local server Local server issues iterative queries subsequently –Win2k client Does iterative queries from host –Caching implications?

22. 22 AL: DNS Lookup Example Client Local DNS server root & edu DNS server ogi.edu DNS server www.cse.ogi.edu NS ogi.edu www.cse.ogi.edu NS cs.ogi.edu www=IPaddr cse.ogi.edu DNS server

23. 23 AL: Subsequent Lookup Example Client Local DNS server root & edu DNS server ogi.edu DNS server cse.ogi.edu DNS server ftp.cse.ogi.edu ftp=IPaddr ftp.cse.ogi.edu cse.ogi.edu entry cached

24. 24 AL: All recursive DNS example 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 requesting host surf.eurecom.fr gaia.cs.umass.edu root name server authorititive name server dns.umass.edu local name server dns.eurecom.fr 1 2 3 4 5 6

25. 25 AL: DNS root name servers 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 nslookup, named example –set iterative –lookup bogus name

26. 26 AL: DNS/nslookup example Real example using nslookup and named –Shows iterative –Shows root name servers –Shows recursive –Shows negative caching nslookup –Set iterative –Lookup bogus name –Get list of root servers –Set recursive –Lookup same bogus name –Get negative response –Set iterative –Lookup bogus name –Get negative response

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

28. 28 AL: 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

29. 29 AL: DNS issues Poor static configuration (root server list) Lack of exponential backoff No centralized caching per site –Each machine runs on caching local server UDP used for queries –Need reliability  Why not TCP?

30. 30 AL: ftp: the file transfer protocol transfer file to/from remote host client/server model –client: side that initiates transfer (either to/from remote) –server: remote host ftp: RFC 959 ftp server: port 21 file transfer FTP server FTP user interface FTP client local file system remote file system user at host

31. 31 AL: ftp: separate control, data connections ftp client contacts ftp server at port 21, specifying TCP as transport protocol two parallel TCP connections opened: –control: exchange commands, responses between client, server. “out of band control” –data: file data to/from server ftp server maintains “state”: current directory, earlier authentication Allows one ftp client to initiate a transfer between two ftp servers FTP client FTP server TCP control connection port 21 TCP data connection port 20

32. 32 AL: ftp commands, responses Sample commands: sent as ASCII text over control channel USER username PASS password LIST return list of file in current directory RETR filename retrieves (gets) file STOR filename stores (puts) file onto remote host Sample return codes status code and phrase (as in http) 331 Username OK, password required 125 data connection already open; transfer starting 425 Can’t open data connection 452 Error writing file

33. 33 AL: ftp, NAT and the PORT command Normal FTP mode –Server has port 20, 21 reserved –Client initiates control connection by connecting to port 21 on server –Client allocates port X for data connection –Client passes the data connection port (X) and its IP address in a PORT command to server –Server parses PORT command and initiates connection from its own port 20 to the client on port Y –What if client is behind a NAT device? NAT must capture outgoing connections destined for port 21 What if NAT doesn’t parse PORT command correctly? What if ftp server is running on a different port than 21? http://www.practicallynetworked.com/support/linksys_ftp_port. htmhttp://www.practicallynetworked.com/support/linksys_ftp_port. htm

34. 34 AL: ftp, NAT, and the PORT command Passive (PASV) mode –Client initiates control connection by connecting to port 21 on server –Client enables “Passive” mode –Server responds with PORT command giving client the IP address and port to use for subsequent data connection (usually port 20, but can be bypassed) –Client initiates data connection by connecting to specified port on server –Most web browsers do PASV-mode ftp –What if server is behind a NAT device? See client issues