Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-) Softpanorama Search

DNS

Domain Name System (DNS) is an Internet-wide naming system for resolving host names to IP addresses and IP addresses to host names. DNS supports name resolution for both local and remote hosts, and uses the concept of domains to allow multiple hosts with identical name to coexist on the Internet.

It is originated from the needs of addressing electronic mail. While the invention is attributed to Paul Mockapetris (the original specifications are described in RFC 882 November, 1983);  the ideas were in the air for a long time: RFC 805 reflected the decision to introduce DNS-type names for mail addressing;  RFC 811 by K. Harrenstien, V. White and E. Feinler introduced the idea of the original centralized hostname lookup server (March,1982); and RFC 819 documented the tree structure ideas of DNS (Aug, 1982). 

Updated the DNS specification  were published in 1987 (RFC 1034 and RFC 1035). Altogether there is more then a dozen  RFCs published that propose various extensions to the core protocol. Historically DNS can be considered the first directory service implemented on Internet. 

The collection of networked systems that use DNS is referred to as the DNS namespace. The DNS namespace is divided into a hierarchy of domains. A DNS domain is a group of systems. Each domain is usually supported by two or more name servers, a master name server, and one or more secondary (slave) DNS servers. In Unix server implements DNS by running special daemon, the in.named daemon in case of bind. On the client’s side, DNS is implemented through the kernel’s resolver. The resolver library resolves users’ queries. The resolver queries several databases including a name server in a specified order. In case DNS servers are queried one of them returns either the requested information or a referral to another DNS server.

DNS's hierarchy has two dimensions. The first is the hierarchical domain names, such as www.softpanorama.org with hierarchy left to right.  Rightmost  (org) is the highest level of hierarchy, the second softpanorama is a subdomain of the org domain and www is a subdomain of softpanorama.  The rightmost components of FDNS name are often called top-level domains, or TLDs.  Among them  com, edu, and org are the most popular, but several dozens exists including one for each country on the planet (based of  ISO two-letter country codes). Together, the domain names which make up www.softpanorama.org, are called fully qualified domain name (FQDN).

• Name servers may be a primary or a secondary name server for its particular domain. Changes to primary domain name servers must be propagated to secondary name servers, as primary domain name servers own the database records. This is accomplished via a “zone transfer”, which copies a complete.

• There are also name servers called “caching-only” name servers. These servers will resolve name queries, but do not own or maintain any DNS database files.

• The client piece of the DNS architecture is known as a “resolver”, and the server piece is known as a “name server”.  Resolvers retrieve information associated with a domain name, and domain name servers store various information about the domain space and return information to the resolvers upon request .

The top-level domains are administered by various organizations that maintain so called root servers. All organization with root servers report to the governing authority called the Internet Corporation for Assigned Names and Numbers (ICANN). Administration of the lower-level domains is delegated to the organizations which bought the domain name from one of DNS registrars. A typical year fee for the domain is highly varied and fluctuates between $4 and $35. 

The top-level domain that you choose can depend on which one best suits the needs of your organization. Large international companies typically use the organizational domains, while small organizations or individuals often choose to use a country code. But this is true not for all countries. Country domains can be prohibitively expensive and can easily cost 10-100 times more that generic domains like .com, .net, .edu or .org.  That's why many web sites from some countries of former USSR are registered under generic domains, typically .com. 

And as any commercial enterprise domain business connected with DNS has its share of political issues.  First of all the ability to extend naming scheme by introducing new top level domains is a highly charged political power and is ripe with different types of abuses.  The second consideration is about a fair domain fee. How much it should cost to register the second level domain ?

There is also a phenomenon called domain hijacking when the organization that for some reason forgot to pay its year domain fee (expired domain)  discover that somebody else already registered the name. Or even that non-expired domain name suddenly migrated from their ownership to somebody else because somebody transferred the domain from one registrar to another. In old days the organization that not yet have Internet presence and try to get one often discover that their domain name is already registered by some individual who wants a neat sum of money for the return of their name. Also because of multiple top level domain different organizations may own them. For example linux.com, linus.org linux.edu can be owned by different organizations.  Important domains like linux.com can be sold for over a million dollars.

Everything below the secondary domain falls into a zone of authority maintained by the domain owner. It is the responsibility the zone owner, to design and implement the redundancy and robustness you need from DNS. Most TLD authorities require at least two working nameservers for a zone before they will delegate authority over it to the zone owner.

DNS has been designed to be redundant. When one server breaks down, the other servers for that domain will still be capable of answering queries about that zone on their own. All a subdomain's authoritative servers are listed in the domain above it. When your computer tries to find an address from a name, it has many alternative servers to query at each step in the process. If one server fails to answer within a set timeout, another will be queried. If they all fail then the query will fail and not return any result. The redundancy also provides load distribution between the servers that are authoritative for a domain.

If the two required nameservers of a zone were located in the same building, then power outage or a single router, or network switch failure could make DNS name service unavailable. If the two domain servers are also located in separate cities and use separate Internet providers then the company is pretty safe from one single failure taking out DNS service. Therefore the secondary name server generally should be geographically far apart from the primary, and in case the company has only one location probably should be implemented as a box in some hosting company or as a service.

The redundancy necessitates a zone duplication mechanism, a way to copy the zones from a master server to all the redundant slave servers of that zone (zone transfer). Until recently, these servers were usually called primary and secondary servers, not master and slave.

When zone file is updated on the master server, the slave server will either act on a notification of the update, or if the notification is lost, notice that a long time has elapsed since it last heard from the master server. It will then check whether there are any updates available. If the check fails, it will be repeated quite often until the master answers, making the duplication mechanism more robust against network failures. If the slave server has been incapable of contacting the master server for a long time, usually a week, it will not give up. Instead, it will stop serving queries from the old data it has stored. Serving old data masquerading as correct data can very well be worse than serving no data at all.

The rootservers are the most important servers on the entire Internet, which is why they are highly redundant. Right now, 13 root nameservers exist on different networks and on different continents. Recent attacks proved that they are pretty resilient and it is pretty unlikely that DNS will fail due to a rootserver failure.

It is up to organization how to implement its DNS server. Many organizations use Solaris for this purpose as one of more secure flavor of Unix. In Solaris DNS server is usually implemented using open source DNS package called BIND. Actually Sun ships Solaris with some version of bind preinstalled. Generally it does not make sense to preserve the original version of bind that comes with Solaris as more recent versions are often available (precompiled version can be found at Solaris Freeware site, but it is better to compile bind yourself using Studio 11 compiler).   See Solaris DNS Server Installation and Administration page for more info. 

Dr. Nikolai Bezroukov

Old News ;-)

Cooking with DNS & BIND - O'Reilly Media

Creating zone data and configuring a name server is just the beginning. Managing a name server over time requires an understanding of how to control it and which commands it supports. It takes familiarity with other tools from the BIND distribution, including nsupdate, used to send dynamic updates to a name server.

This chapter includes lots of recipes that involve ndc and rndc, programs that send control messages to BIND 8 and 9 name servers, respectively. These programs let an administrator reload modified zones, refresh slave zones, flush the cache, and much more. The list of commands the name server supports seems to grow with each successive release of BIND, so I've provided a peek at a few new commands in BIND 9.3.0 for the curious.

In the brave new world of dynamic zones, an administrator may have to make most of the changes to zone data using dynamic update, rather than by manually editing zone data files.

Figuring Out How Much Memory a Name Server Will Need

Problem

You need to figure out how much memory a name server will require.

Solution

While this answer may seem like a cop-out, the only sure-fire way to determine how much memory a name server will need is to configure it, start it, and then monitor it using a tool like top. After a week or so, the size of the named process should stabilize, and you'll know how much memory it needs.

Discussion

The reason it's so difficult to calculate how much memory a name server requires is that there are so many variables involved. The size of the named executable varies on different operating systems and hardware architectures. Zones have a unique mix of records. Zone data files may use lots of shortcuts (e.g., leaving out the origin, or even using a $GENERATE control statement) or none at all. The resolvers that use the name server may send a huge volume of queries, causing the name server's cache to swell, or may send just sporadic queries.

Testing a Name Server's Configuration

Problem

You want to test a name server's configuration before putting it into production.

Solution

Use the named-checkconf and named-checkzon programs to check the named.conf file and zone data files, respectively. named-checkconf reads /etc/named.conf by default, so if you haven't moved the configuration file into /etc yet, specify the pathname to the configuration file you want to test as the argument:

$ named-checkconf ~/test/named.conf

named-checkconf uses the routines in BIND (BIND 9.1.0 and later, to be exact) to make sure the named.conf file is syntactically correct. If there are any syntactic or semantic errors in named.conf, named-checkconf will print an error. For example:

$ named-checkconf /tmp/named.conf
/tmp/named.conf:3: missing ';' before '}'

named-checkzon uses BIND's own routines to check the syntax of a zone data file. To run it, specify the domain name of the zone and the name of the zone data file as arguments:

$ named-checkzone foo.example db.foo.example

If the zone contains any errors, named-checkzon prints an error. If the zone would load without errors, named-checkzon prints a message like this:

zone foo.example/IN: loaded serial 2002022400
OK

Once you've checked the configuration file and zone data, configure the name server to listen on a nonstandard port with the listen-on options substatement, and not to use a control channel:

controls { };

options {
    directory "/var/named";
    listen-on port 1053 { any; };
};

That way, the test name server won't interfere with any production name server you might already have running. Check the name server's syslog output (which should be clean, if you ran named-checkconf and named-checkzon) and query the name server with dig or another query tool, specifying the alternate port:

$ dig -p 1053 soa foo.example.

Once you're satisfied with the name server's responses to a few queries, you can remove the listen-on substatement, add a real controls statement and put it into production.

Discussion

Even though named-checkconf and named-checkzon first shipped with BIND 9.1.0, BIND 8's configuration syntax is similar enough to BIND 9's that you can easily use named-checkconf with a BIND 8 named.conf file. The zone data file format is exactly the same between versions, so you can use named-checkzon, too.

[Jul 15, 2008] Technology: Paul Vixie Responds To DNS Hole Skeptics

Posted by kdawson on Tuesday July 15, @08:07AM
from the be-afraid-be-very-afraid-then-get-patching dept.  

syncro writes "The recent massive, multi-vendor DNS patch advisory related to DNS cache poisoning vulnerability, discovered by Dan Kaminsky, has made headline news. However, the secretive preparation prior to the July 8th announcement and hype around a promised full disclosure of the flaw by Dan on August 7 at the Black Hat conference has generated a fair amount of backlash and skepticism among hackers and the security research community. In a post on CircleID, Paul Vixie offers his usual straightforward response to these allegations. The conclusion: 'Please do the following. First, take the advisory seriously — we're not just a bunch of n00b alarmists, if we tell you your DNS house is on fire, and we hand you a fire hose, take it. Second, take Secure DNS seriously, even though there are intractable problems in its business and governance model — deploy it locally and push on your vendors for the tools and services you need. Third, stop complaining, we've all got a lot of work to do by August 7 and it's a little silly to spend any time arguing when we need to be patching.'"

[May 15, 2008] DNS trouble knocks National Security Agency off Internet ITworld

A server problem at the U.S. National Security Agency has knocked the secretive intelligence agency off the Internet. The nsa.gov Web site was unresponsive at 7 a.m. Pacific time Thursday and continued to be unavailable
throughout the morning for Internet users.

The Web site was unreachable because of a problem with the NSA's DNS (Domain Name System) servers, said Danny McPherson, chief research officer with Arbor Networks. DNS servers are used to translate things like the Web addresses typed into machine-readable Internet Protocol addresses that computers use to find each other on the Internet.

The agency's two authoritative DNS servers were unreachable Thursday morning, McPherson said.

Because this DNS information is sometimes cached by Internet service providers, the NSA would still be temporarily reachable by some users, but unless the problem is fixed, NSA servers will be knocked completely off-line. That means that e-mail sent to the agency will not be delivered, and in some cases, e-mail being sent by the NSA would not get through.

"We are aware of the situation and our techs are working on it," a NSA spokeswoman said at 9:45 a.m. PT. She declined to identify herself.

A similar DNS problem knocked Youtube.com off-line in early May.

There are three possible reasons the DNS server was knocked off-line, McPherson said. "It's either an internal routing problem of some sort on their side or they've messed up some firewall or ACL [access control list] policy," he said. "Or they've taken their servers off-line because something happened."

That "something else" could be a technical glitch or a hacking incident, McPherson said.

In fact, the NSA has made some basic security mistakes with its DNS servers, according to McPherson.

• The NSA should have hosted its two authoritative DNS servers on different machines, so that if a technical glitch knocked one of the servers off-line, the other would still be reachable.
• Compounding problems is the fact that the DNS servers are hosted on a machine that is also being used as a Web server for the NSA's National Computer Security Center.

"Say there was some Apache or Windows vulnerability and hackers controlled that server, they would now own the DNS server for nsa.gov," he said. "That really surprised me. I wouldn't think that these guys would do something like that."

The NSA is responsible for analysis of foreign communications, but it is also charged with helping protect the U.S. government against cyber attacks, so the outage is an embarrassment for the agency.

"I am certain that someone's going to send an e-mail at some point that's not going to get through," McPherson said. "If it's related to national security and it's not getting through, then as a U.S. citizen, that concerns me."

(Anders Lotsson with Computer Sweden contributed to this report.)

[Feb 6, 2008] Industry milestone DNS turns 25

02/06/08 |Network World

The Domain Name System turned 25 last week. 

Paul Mockapetris is credited with creating DNS 25 years ago and successfully tested the technology in June 1983, according to several sources.

[an error occurred while processing this directive]

The anniversary of the technology that underpins the Internet -- and prevents Web surfers from having to type a string of numbers when looking for their favorite sites -- reminds us how network managers can't afford to overlook even the smallest of details. Now in all honesty, DNS has been on my mind lately because of a recent film that used DNS and network technology in its plot, but savvy network managers have DNS on the mind daily.

DNS is often referred to as the phone book for the Internet, it matches the IP address with a name and makes sure people and devices requesting an address actually arrive at the right place. And if the servers hosting DNS are configured wrong, networks can be susceptible to downtime and attacks, such as DNS poisoning. 

And in terms of managing networks, DNS has become a critical part of many IT organization's IP address management strategies. And with voice-over-IP and wireless technologies ramping up the number of IP addresses that need to be managed, IT staff are learning they need to also ramp up their IP address management efforts. Companies such as Whirlpool are on top of IP address management projects, but industry watchers say not all IT shops have that luxury. (Learn more about IP ADDRESS MANAGEMENT products from our IP ADDRESS MANAGEMENT Buyer's Guide)

"IP address management sometimes gets pushed to the back burner because a lot of times the business doesn't see the immediate benefit -- until something goes wrong," says Larry Burton, senior analyst with Enterprise Management Associates.

And the way people are doing IP address management today won't hold up under the proliferation of new devices, an update to the Internet Protocol (from IPv4 to IPv6) and the compliance requirements that demand detailed data on IP addresses.

"IP address management for a lot of IT shops today is manual and archaic. It is now how most would say to manage a critical network service," says Robert Whiteley, a senior analyst at Forrester Research. "Network teams need to fix how they approach IP address management to be considered up to date." [an error occurred while processing this directive]