DNS: Domain Name System
-
Upload
cairo-michael -
Category
Documents
-
view
29 -
download
0
description
Transcript of DNS: Domain Name System
1
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: distributed database
implemented in hierarchy of many name servers
application-layer protocol host, routers, name servers to communicate to resolve names (address/name translation) note: core Internet
function implemented as application-layer protocol
complexity at network’s “edge”
2
DNS name servers
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!
3
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 13 root DNS servers:
replication for security and reliability
Top-level DNS server: org, edu, com, jp,cn, fr, uk
4
Simple 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 hostsurf.eurecom.fr
gaia.cs.umass.edu
root name server
authorititive name serverdns.umass.edu
local name serverdns.eurecom.fr
1
23
4
5
6
5
DNS example
Root name server: may not know
authoratiative name server
may know intermediate name server: who to contact to find authoritative name server
requesting hostsurf.eurecom.fr
gaia.cs.umass.edu
root name server
local name serverdns.eurecom.fr
1
23
4 5
6
authoritative name serverdns.cs.umass.edu
intermediate name serverdns.umass.edu
7
8
6
DNS: iterated queries
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”
requesting hostsurf.eurecom.fr
gaia.cs.umass.edu
root name server
local name serverdns.eurecom.fr
1
23
4
5 6
authoritative name serverdns.cs.umass.edu
intermediate name serverdns.umass.edu
7
8
iterated query
7
DNS: caching and updating records 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
8
DNS records
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)
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
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, messagesDNS 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
11
DNS protocol, messages
Name, type fields for a query
RRs in reponseto query
records forauthoritative 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
Socket programming
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
a host-local, application-created/own
ed, OS-controlled interface (a “door”) into which
application process can both send and
receive messages to/from another (remote
or local) application
process
socket
Goal: learn how to build client/server application that communicate using sockets
14
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
process
TCP withbuffers,
variables
socket
controlled byapplicationdeveloper
controlled byoperating
system
host orserver
process
TCP withbuffers,
variables
socket
controlled byapplicationdeveloper
controlled byoperatingsystem
host orserver
internet
15
Socket programming with TCP
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
16
Socket programming with TCP
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
client socket
inFromUser outToServer
iinFromServer
17
Client/server socket interaction: TCP
wait for incomingconnection requestint cs =accept(s,….)
create socket,port=x, forincoming request:
int s = socket(…); bind(s,…) listen(s,5);
create socket,connect to hostid, port=x
int cli_socket = socket(..);connect(s,…);
closecs
read reply fromcli_socket
closecli_socket
Server (running on hostid) Client
send request usingcli_socketread request from
cs
write reply tocs
TCP connection setup
18
Example: C++ client (TCP)#include <stdio.h> /* Basic I/O routines */#include <sys/types.h> /* standard system types */#include <netinet/in.h> /* Internet address structures */#include <sys/socket.h> /* socket interface functions */#include <netdb.h> /* host to IP resolution */
int main(int argc, char *argv[]) { /* Address resolution stage */ struct hostent* hen = gethostbyname(argv[1]); if (!hen) { perror("couldn't resolve host name"); } struct sockaddr_in sa; memset(&sa, 0, sizeof(sa); sa.sin_family = AF_INET; sa.sin_port = htons(PORT); //server port number memcpy(&sa.sin_addr.s_addr, hen->h_addr_list[0], hen->h_length);
int cli_socket = socket(AF_INET, SOCK_STREAM, 0); assert(cli_socket >= 0); //I am just lazy here!! connect(s, (struct sockaddr *)&sa, sizeof(sa)); write(s, argv[2], strlen(argv[2])); //send it to server char buf[BUFLEN]; int rc; memset(buf, 0, BUFLEN); char* pc = buf; while(rc = read(cli_socket, pc, BUFLEN – (pc - buf))) pc += rc; write(1, buf, strlen(buf)); close(cli_socket);}
Create client socket,
connect to server
19
Example: C++ server (TCP)//include header files #define PORT 6789int main(int argc, char* argv[]) { struct sockaddr_in sa, csa; memset(&sa, 0, sizeof(sa); sa.sin_family = AF_INET; sa.sin_port = htons(PORT); sa.sin_addr.s_addr = INADDR_ANY; //any IP addr. Is accepted int s = socket(AF_INET,SOCK_STREAM, 0); assert( s>=0); int rc = bind(s, (struct sockaddr *)& sa, sizeof(sa)); //hook s with port rc = listen(s, 5); int cs_socket = accept(s, (struct sockaddr*)&csa, sizeof(csa)); char buf[BUFLEN]; memset(buf, 0, BUFLEN); char* pc = buf; while(rc = read(cs_socket, pc, BUFLEN – (pc - buf))) pc += rc; upper_case(buf); // covert it into upper case write(cs_socket, buf, strlen(buf)); close(cs_socket); close(s);}
20
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!
21
Socket programming with UDP
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
application viewpoint
UDP provides unreliable transfer of groups of bytes (“datagrams”)
between client and server
22
Summary
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!
specific protocols: http ftp smtp, pop3 dns
socket programming client/server
implementation using tcp, udp sockets
23
Summary
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
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