Module 0123 DNS and BIND by jianghongl

VIEWS: 6 PAGES: 4

									                                  Module 0123: DNS and BIND
                                              Tak Auyeung, Ph.D.
                                                  April 19, 2007


1     About this module
    ˆ Prerequisites:

    ˆ Objectives: This module discusses DNS as a protocol and how to use BIND as a DNS server.


2     Why do we need DNS?
DNS (domain name system) is a protocol and mechanism that acts as “411” of computers.
    Like the telephone system, each interface on a TCP/IP network has a unique IP address associated with it. This
IP address is numerical. In fact, it is just a 32-bit pattern (32 binary digits). This is the bottom line. If you want
to locate an interface in a network, you need to use the IP address.
    IP addresses, however, suffer from two major problems. One, people cannot remember IP addresses very well.
This is why we have lettering on the telephone keypad/dial to begin with! The second limitation of IP addresses is
that we only have a mechanism to identify a physical interface, but not a logical entity.
    The second point requires a little more explanation. Let us consider yahoo.com. Yahoo.com is a logical organiza-
tion, it can have many network interfaces for redundancy and efficiency. It is a hassle if every user has to remember
the IP addresses of all the interfaces used by yahoo.com. It is even worse when a user needs to determine which
interface is faster.
    To solve these two problems, we have domain names. A domain name is a symbolic name that we can use to
identify “domains”. Here is an example:

    ˆ yahoo.com is a domain name.

    ˆ 66.94.234.13 and 216.109.112.135 are the IP addresses associated with this domain name.

    Would you rather remember the domain name, or the IP addresses corresponding to the domain name?


3     How does DNS work?
3.1    The general idea
Somewhat similar to the 411 service of you phone company, DNS is localized. However, DNS is also hierarchical.
Let us simulate a particular DNS query.

    ˆ You want to visit the website funky.town.org. The browser (an HTTP client) issues an HTTP request directed
      to funky.town.org.
    ˆ Your workstation needs to resolve the domain name to an IP address. it looks up a local cache for an entry.

    ˆ If an entry is found locally, you’re done. If not, your workstation determines what is your primary DNS server
      (name server). This is usually set by DHCP when your computer first connect to the network. Let’s say
      66.218.71.63 is the IP address of the primary name server.
    ˆ Your workstation sends a DNS request to 66.218.71.63 and ask “what is the IP address of the domain name
      funky.town.org?”



                                                          1
   ˆ 66.218.71.63 receives your request. It looks up its local cache (to see if someone else has already made the
     same request). If the answer is found in the cache, it replies and the process is done.
     Otherwise, it sends the same request to the root name server.
   ˆ The root name server cannot track all domain names on the internet. It looks at the domain name funky.town.org,
     replies to the name server your ISP, and says “so-and-so knows more about .org domain names, ask it instead.”

   ˆ The name server of your ISP then makes another DNS request to this name server that specializes in .org
     domain names. The .org specialist name server looks at the domain name, and determines that yet another
     server specializes in domain names ending with town.org. It replies to the DNS server of your ISP with the
     IP address of this name server that specializes in town.org domain names.

   ˆ The name server that specializes in town.org looks at the domain name, and finds the corresponding IP
     address. It replies to the DNS server of your ISP.
   ˆ The DNS server of your ISP adds this entry to its local cache, and reply to the request that originated from
     your workstation. Your workstation also caches this entry. Then it knows where to send the original HTTP
     request.

3.2    Specific terms
To facilitate more meaningful discussions regarding name resolution, it is important to understand some of the basic
terms used in name resolution literature.

   ˆ domain name: this is a dot-separated identifier, such as power.arc.losrios.edu, www.yahoo.com and etc.

   ˆ host name: a host name is a domain name that resolves to a specific IP address.

   ˆ subdomain: a domain name is a subdomain of another domain if the former consists of a symbolic name
     inserted in front of the latter. For example, arc.losrios.edu is a subdomain of losrios.edu.
   ˆ top-level domain: a top level domain is the symbolic name at the rightmost portion of a domain name. For
     example, the top-level domain of power.arc.losrios.edu is edu, the top-level domain of maps.google.com
     is com, and so on.

3.3    Who is in charge? How do I get my own domain name?
We all want to get our very own domain names for free, so who is stopping us from doing so?
    Let’s say you have broadband service at home, and you also have a static IP (which is not required for a domain
name, but it does make things easier). Let’s also say that you want to use the domain name coolstuff.net, with
subdomains (and hostnames) jacks.coolstuff.net and marys.coolstuff.net.
    In order for other computers to resolve jacks.coolstuff.net to its IP address, the root DNS server defers to
the .net specialist DNS server. The .net specialized DNS server then needs to know which other DNS server is
responsible for the domain name coolstuff.net.
    Ah, ha, this is why you need to pay. Not everyone can just go ahead and add a new entry to the database
maintained by the .net specialized DNS server. Only certain organizations can take the money (domain name
registration) and update the DNS databases of important DNS servers!
    Whichever company takes your domain name registration fees is also responsible to set up a DNS entry for your
domain. This company does not need to be your ISP (internet service provider) or your hosting company (if you have
a standalone web host). This registration requires that you specify which DNS server(s) are responsible to resolve
the registered domain name.
    Normally, if you do not have subdomains, then the paid DNS entry can refer to any DNS servers that you choose
to use to resolve your domain names. There are plenty of free DNS services. Let’s say you choose to use dnsexit.com
to act as your domain name server. Then, you put in the name servers of dnsexit.com when you register your domain
name.
    In this particular case, it gets a little more complicated. Because you plan to have many subdomains under
coolstuff.net, you need to find a DNS service that allows subdomains. You can pay to have this set up, or you can
set up your own DNS server(s). Let’s say the IP address of your DNS server is 66.205.123.20. Then the domain
name registrar will put an entry in that says “inquire 66.205.123.20 for everything that ends with coolstuff.net
”.


                                                         2
    Setting up your own DNS server has advantages and disadvantages. It is next to free, assuming your do have a
free machine, and it is very flexible. However, if your DNS server stops functioning, then no one can find the hosts
in the domain, even if all those hosts are well and alive.

3.4   Reverse DNS lookup
Yes, it sounds counter intuitive. “Reverse DNS” (RDNS) is exactly what the name implies: given an IP address,
what is its domain name?
    Why do we need this?
    This is mostly used by email servers for authenticating the origin of email messages. SMTP is somewhat of an
old protocol, invented before security became a big issue. As such, SMTP itself has no built-in mechanism for a
client to authenticate itself to a server. There is also no way to check the true origin of a message.
    For example, let’s say I want to stir up some trouble in the organization called peace-r-us.com. I know cer-
tain email addresses of some individual of that organization from their websites or publicity literatures. And,
as a bad person, I want to pretend to be love@peace-r-us.com and send a really inappropriate message to
respect@peace-r-us.com. Also, assume that I cannot gain any access to any workstations/hosts in the domain
peace-r-us.com.
    It doesn’t matter. I can easily create an email message and forge the from: field to say love@peace-r-us.com!
Then I send this message via SMTP through the SMTP relay of my ISP, and just wait and watch peace-r-us.com
appear on the news.
    But, a good system administrator at peace-r-us.com can easily foil my attempt. Almost all SMTP servers
(postfix, sendmail and etc.) can set up to use RDNS for basic authentication. This is how it works.

   ˆ the SMTP relay of my isp, say 66.205.45.123 sends the forged message to the SMTP server of peace-r-us.com.
     The SMTP server of peace-r-us.com knows which IP originates the message (66.205.45.123).

   ˆ The SMTP server of peace-r-us.com analyzes the message (which is in plain text), and sees that the from:
     field is love@peace-r-us.com.
   ˆ The SMTP server of peace-r-us.com queries its DNS server and ask “what is the domain name corresponding
     to the IP address of 66.205.45.123?”

   ˆ The DNS server replies mail.myisp.com (which is the domain name of the SMTP server of my ISP). This does
     not match the domain name of the from: field of the message!
   ˆ The SMTP server decides that this message is questionable, and either block it, mark it as suspicious, or bounce
     it.

    Note that if you want to handle your own email with your email server, you probably need to have an RDNS
entry to talk to most SMTP servers. Without an RDNS entry, the SMTP server simply cannot get the domain name
corresponding to an IP address, and many SMTP servers will discard messages coming from SMTP servers/relays
with no RDNS entries.
    Also, note that whoever sets up your DNS entries may not be able to set up RDNS entries. Typically, it is up
to a hosting company that set up RDNS for you, and not all hosting companies offer this service. Obviously, not
everyone can set up an RDNS entry due to the security sensitivity.
    Some hosting companies/ISPs will set up default RDNS entries based on the IP address. Surewest, for example,
sets up the RDNS entry of 66.205.135.41 as 040.135-205-66.ftth.swbr.surewest.net. This is sufficient for
some SMTP servers (that there is an RDNS entry). However, some SMTP servers wants to match the RDNS name
to the name of the from: field, which makes the default RDNS entries insufficient.
    If your hosting company cannot set up an RDNS entry for your SMTP server or domain, you can subscribe to
paid services to relay email. This kind of service is usually offered by companies that offer DNS services (which may
or may not be the same as the domain name registrar!). This is the way it works.

   ˆ You tell the service your domain name, and the IP address of your SMTP server.

   ˆ The service registers an RDNS entry, but with the IP address of the service itself.

   ˆ You configure your SMTP server (software) to use IP relay to send out messages. Incoming messages are not
     affected.



                                                         3
ˆ When your SMTP server needs to send a message, it is first sent to the IP relay.

ˆ The IP relay sends the message to its destination SMTP server.

ˆ The destination SMTP server looks up the RDNS entry of the IP address of the IP relay. It should match
  because the IP relay service provider registered the address of the IP relay to map to your domain name.




                                                    4

								
To top