200 likes | 496 Views
DNS. Domain name server a server to translate IP aliases to addresses As you know, IP (internet protocol) works by providing every Internet machine with a unique address as humans, we tend not to be able to remember lengthy strings of numbers so its easier for us to name our machines
E N D
DNS • Domain name server • a server to translate IP aliases to addresses • As you know, IP (internet protocol) works by providing every Internet machine with a unique address • as humans, we tend not to be able to remember lengthy strings of numbers so its easier for us to name our machines • DNS allows us to reference machines by name and still use IP • DNS servers exist across the Internet (globally) • however, within a given domain, you might have a DNS that breaks that domain into subdomains • for instance, NKU is a domain known by the global DNS’s but within NKU, we might have cs.nku.edu and it.nku.edu and library.nku.edu, etc • these subdomains are known by our DNS, which then can pass this information onto other DNS’s around the world • DNS requests use UDP (user datagram protocol) and typically communicate over port 53 to DNS servers • both request and response are usually single UDPs
How DNS Works • The structure of DNS’s is tree-like • when you want to translate an IP alias to address, you ask your local DNS to perform the lookup of the given domain • if that information is not available locally, the DNS asks its nearest neighbor DNS, which will be one level higher • if that DNS does not have the information, it asks its next nearest neighbor (again, one level higher) • ultimately, if no DNS has the information on the path up the tree, you get an error • the precise location of a domain name in this hierarchy is known as a fully qualified domain name (FQDN) or absolute domain name • If the alias has subdomains that are not known by the responding DNS, then it forwards the request to the domain’s DNS • A DNS can act as a server to translate IP aliases and/or a cache which can merely cache previous lookups and respond if available
Example • A fully qualified domain name might be • myhost.subnet1.example.com • here, the domain name is example.com • the subdomain or subnet name is subnet1 • and the host name is myhost • there will probably be a lot of DNS’s that have the IP address of example.com • if your local DNS does not, it just needs to go to the next higher level (and so on up the hierarchy) to find the entry • however, it is possible that the DNS that has the mapping for example.com does not know of the subnet1 subdomain, so the DNS requests more information from example.com’s DNS • it is likely that the subdomain information will be propagated to other DNS’s over time • what happens if example.com decides to alter their IP address structure so that subnet1 is given a new address?
The DNS Hierarchy image from wikipedia
DNS Zone • As shown on the previous slide, the DNS hierarchy is divided into zones • What is a zone? • it represents an area of the Internet that is in one administered space • that is, there is a unit whose job is to administer that zone • as an example, it.nku.edu is administered by IT while cs.nku.edu is administered by the computer science department, so these represent separate zones • it just so happens that IT administers the it.nku.edu and the nku.edu zones • these zones are not administered by other organizations on the Internet though so they are separate from say uk.edu and uc.edu
Types of Name Servers • An Authoritative name server is one that is configured from an original source • e.g., the system administrator for the given domain • Two forms of authoritative name servers • master – where the original records are stored • slave – obtains its information from masters but can still be authoritative as long as they are up to date • to register a domain name, the information must be stored on at least one primary name server (a master) and at least one secondary name server (usually a slave) • you register your domain with the ICANN • Aside from authoritative name servers, there are also • caching name servers – store recent DNS mapping results for more efficient access (these are configured with a “time-to-live” value to indicate how long entries are cached) • recursive name servers – see the next slide
Recursive Queries • The DNS resolver is responsible for resolving a DNS lookup • this runs on the client machine and its task is essentially to call the local DNS • the term “resolve” is used in linux to name the file, /etc/resolv.conf • What happens if the mapping is either not available or only partially available at the local DNS? • if the local DNS is set up to be a recursive query DNS then it will pass the request on to the next DNS, recursively up the hierarchy until the address is fully resolved
DNS Resource Records • The DNS stores its mapping information as resource records, which contain the following fields • name (the fully qualified name, may use * wildcards to represent all subdomains of a given domain) • type of record (IPv4 addresses, IPv6 addresses, type of database records, certificate records, DHCP identifier, key records or key types (for encryption), PTRs, email address of the domain’s administrator, and other information) • class (IN for Internet), CN (for Chaos), HS (for Hesiod) • time to live in seconds (that is, how long the record is accurate) • length of the data field • type-specific data • Example: *.X.Example. MX 10 A.X.Example. • all hosts in the domain X.Example use the mail exchanger (MX) of A.X.Example • this record has a time to live of 10 second
BIND • The Berkeley Internet Name Domain • this is the common tool used in Linux/Unix to implement a DNS • BIND uses daemon named, which is the program in Linux for resolving IP addresses • bind’s configuration file is typically stored in /etc/named.conf • we will primarily be editing and working with this file • the syntax of this file is peculiar (based on C code), you have to be careful to keep it syntactically correct or else bind won’t run! • other bind resources are usually found in the /var/named directory • If you choose to implement just a caching DNS then you would find the configuration file in /etc/named.caching-namserver.conf instead
named.conf • The file contains a list of statements in the form: • <statement> [“comment”] [<statement-class>] { <option>;<option>;…;<option>; }; • the comment and statement-class are optional • you can have as many options as desired (at least 1 or else there would be no need for the statement!) • Statements include • acl (access control statement) – dictate who can access the DNS – options are any, localhost, localnets, none, or a list of IP addresses or networks ending with ; (as in 10.2.3.0/24; or 10.2.0.0/16;) • include – to include other files with configuration information here to keep this file relatively short • since named.conf is readable by the world, to keep information secure you can move such information into include files • options – global server configuration settings (see next slide) • zone – to specify a zone within this domain
Options • allow-query, allow-recursion, blackhole • you provide previously defined acls here to indicate who can query or recurse with this DNS or who is disallowed access (blackhole) • directory • Specifies the working directory if different from the default /var/named/ • forwarders, forward • list of DNS’s that we should forward a request onto and how we should forward (first or only) • listen-on • specify a particular machine or subnet that we will only listen to, e.g., listen-on {10.2.3.0/24; }; would force us to only listen on the 10.2.3 subnet • defaults to listen to any incoming IP address • notify • used to specify whether and which slaves to notify for updates
Zones • The zone statement defines the characteristics of a given zone (subdomain) • you can define multiple zones here • The format of the zone statement is • zone <name> <class> { <option>; <option>;…; <option>; }; • class is optional • the zone name is extended to the domain name, so for instance if the domain name is example.com and the zone is sales. then we have the subdomain sales.example.com • zone options are largely the same as the previous options but also include • allow-transfer – which slaves can obtain info • allow-update – the masters which can update this DNS • masters – list of DNS’s that are masters – only used if the type of this DNS is slave • type – delegation-only, forward, hint, master, slave
Zone Files • Any zone statements in your main config file will also have an associated zone file • the zone file is stored in the named working directory (e.g., /var/named/) • Each zone file will (may) include directives about that zone and resource records • the directives to specialize that zone • resource records define parameters of the zone and assign identifiers to individual hosts within that zone (e.g., an email server, a web server) • zone file directives begin with a $ • the most common directives are • ORIGIN (to denote the name of this subdomain) • $INCLUDE • $TTL (time to live, or the default amount of time that a given resource record is valid)
Zone Resource Record Statements • These make up most of any zone file and consist of a number of record statements • The format is <name> <class> <type> <value> where class is the network class (usually IN for Internet) and type is the type of record • an address record to specify the IP address of a given host name • e.g., zappa IN A 10.2.3.31 • if the name is omitted, then the record is used for the zone’s name itself • a canonical name (CNAME) record maps one name onto another (for aliases) as in • ftp IN CNAME zappa ;; this makes zappa our ftp server • there are similar records to define a mail exchange (type is MX), name server (NS), pointer record (PTR) or start of authority (SOA) – see the next slide
SOA Format • The SOA is used to specify authoritative information for the slave DNSs for the given zone • the SOA must be located after any directives but before any other resource records • The format is: @ IN SOA <primary DNS> <hostmaster> (<serial-number>; <time-to-refresh>; <time-to-retry>; <time-to-expire>; <minimum-TTL>) • @ is replaced by $ORIGIN’s value, or the zone’s name if no $ORIGIN was provided • the <primary DNS> value is this zone’s authoritative DNS • <hostmaster> is the email of this zone’s administrator • <serial-number> is an initial numeric value used to indicate if this record has been modified and therefore needs to be sent to the slaves for updating • times default to be in seconds but can be modified using M (minute), H (hour), D (day) or W (week) • the values are the time before a slave should be refreshed, the time a slave should wait before requesting new information from the master if none is sent, the time before cached entries should expire and the default TTL if none is given
Example /etc/named.conf file options { directory "/var/named"; #tells DNS to use listed directory for other config files forward first; #check the "forwarders" before doing any resolution forwarders { # list of domain servers the check ("local" DNS) 10.150.22.7; #internal DNS server for company }; zone "." { #Settings for the ROOT ZONE type hint; #Specifies this as the ROOT ZONE type file "root.hints"; #File containing links to root servers (/var/named/root.hints) }; zone “3.2.10.in-addr.arpa" { #Used for reverse lookup #notice it is your network address backwards+"in-addr.arpa“ type master; #Specifies this as a MASTER ZONE file "pz/10.2.3"; #File that contains the details for zone (/var/named/pz/10.2.3) allow-update { none; }; };
The pz/10.2.3 File ;Defines the local zone. $ORIGIN cs.nku.edu. # defines our zone’s name $TTL 86400 # minimum TTL is 1 day @ IN SOA cs.nku.edu. Admin.cs.nku.edu. ( 1 ;Serial 8H ;Refresh 2H ;Retry 1W ;Expire 1D) ;Minimum TTL (not needed since we defined $TTL above) server1 IN A 10.2.3.2 # specifies a machine server1.cs.nku.edu www IN CNAME server1 # assigns an alias as www.cs.nku.edu dns IN A 10.2.3.3 # specifies authoritative DNS for this zone