Board index Linux DNS

Moderator: chandranjoy

DNS - How it works?

Postby chandranjoy » Wed Dec 22, 2010 6:12 pm

Understanding DNS

Image

Domain Name System (DNS) is a distributed database system for managing host names and their associated Internet Protocol (IP) addresses. Using DNS means that people can use simple names, such as "www.jkltoys.com" to locate a host, rather than using the IP address (xxx.xxx.xxx.xxx). A single server may only be responsible for knowing the host names and IP addresses for a small subset of a zone, but DNS servers can work together to map all domain names to their IP addresses. DNS servers working together is what allows computers to communicate across the Internet.

DNS data is broken up into a hierarchy of domains. Servers are responsible to know only a small portion of data, such as a single subdomain. The portion of a domain for which the server is directly responsible is called a zone. A DNS server that has complete host information and data for a zone is considered authoritative for the zone. An authoritative server can answer queries about hosts in its zone using its own resource records. The query process depends on a number of factors. Understanding DNS queries explains the paths a client can use to resolve a query.

Understanding zones

DNS data is divided into manageable sets of data called zones. Zones contain name and IP address information about one or more parts of a DNS domain. A server that contains all of the information for a zone is the authoritative server for the domain. Sometimes it may make sense to delegate the authority for answering DNS queries for a particular subdomain to another DNS server. In this case, the DNS server for the domain can be configured to refer the subdomain queries to the appropriate server.

For backup and redundancy, zone data is often stored on servers other than the authoritative DNS server. These other servers are called secondary servers, which load zone data from the authoritative server. Configuring secondary servers allows you to balance the demand on servers and also provides a backup in case the primary server goes down. Secondary servers obtain zone data by doing zone transfers from the authoritative server. When a secondary server is initialized, it loads a complete copy of the zone data from the primary server. The secondary server also reloads zone data from the primary server or from other secondaries for that domain when zone data changes.

DNS zone types

You can use iSeries(TM) DNS to define several types of zones to help you manage DNS data:

Primary zone
Loads zone data directly from a file on a host. A primary zone may contain a subzone, or child zone. It may also contain resource records such as host, alias (CNAME), address (A), or reverse mapping pointer (PTR) records.
Note: Primary zones are sometimes referred to as "master zones" in other BIND documentation.

Subzone
A subzone defines a zone within the primary zone. Subzones allow you to organize zone data into manageable pieces.

Child zone
A child zone defines a subzone and delegates responsibility for the subzone data to one or more name servers.

Alias (CNAME)
An alias defines an alternate name for a primary domain name.

Host
A host object maps A and PTR records to a host. Additional resource records may be associated with a host.


Secondary zone

Loads zone data from a zone's primary server or another secondary server. A secondary server maintains a complete copy of the zone for which it is a secondary.
Note: Secondary zones are sometimes referred to as "slave zones" in other BIND documentation.

Stub zone
A stub zone is similar to a secondary zone, but it only transfers the name server (NS) records for that zone.

Forward zone

A forward zone directs all queries for that particular zone to other servers.

Understanding DNS queries
Clients use DNS servers to find information for them. The request may come directly from the client, or from an application running on the client. The client sends a query message to the DNS server that contains a fully qualified domain name (FQDN), a query type, such as a particular resource record the client requires, and the class for the domain name, which is usually the Internet (IN) class. The following figure depicts the sample network from the Single DNS server with Internet access example.

Suppose host dataentry queries the DNS server for "graphics.mycompany.com". The DNS server will use its own zone data and respond with the IP address 10.1.1.253.

Now suppose dataentry requests the IP address of "www.jkl.com.". This host is not in the DNS server's zone data. There are now two paths that can be followed, recursion or iteration. If a DNS server is set to use recursion, the server can query or contact other DNS servers on behalf of the requesting client to fully resolve the name, then send an answer back to the client. If the DNS server queries another DNS server, the requesting server will cache the answer so it can use it the next time it receives that query. A client can attempt to contact other DNS servers on its own behalf to resolve a name. In this process, called iteration, the client uses separate and additional queries based on referral answers from servers.

DNS resource records

A DNS zone database is made up of a collection of resource records. Each resource record specifies information about a particular object. For example, address mapping (A) records map a host name to an IP address, and reverse-lookup pointer (PTR) records map an IP address to a host name. The server uses these records to answer queries for hosts in its zone. For more information, use the table to view DNS resource records.

1.TXT - Text records -

The TXT record specifies multiple strings of text, up to 255 characters long each, to be associated with a domain name. TXT records may be used along with responsible person (RP) records to provide information about who is responsible for a zone.

2.SOA - Start of Authority records
The SOA record specifies that this server is authoritative for this zone. An authoritative server is the best source for data within a zone. The SOA record contains general information about the zone and reload rules for secondary servers.

3.PTR - Reverse-lookup Pointer records

The PTR record specifies the domain name of a host for which you want a PTR record defined. PTR records allow a host name lookup, given an IP address.

4.KEY - Public Key records

The KEY record specifies a public key that is associated with a DNS name. The key could be for a zone, a user, or a host.

5.NS - Name Server records

The NS record specifies an authoritative name server for the host/domain.

6.MX - Mail Exchanger records

The MX records defines a mail exchanger host for mail sent to this domain. These records are used by SMTP (Simple Mail Transfer Protocol) to locate hosts that will process or forward mail for this domain, along with preference values for each mail exchanger host. Each mail exchanger host must have a corresponding host address (A) records in a valid zone.

7.AAAA - IP Version 6 Address records

he AAAA record specifies the 128-bit address of a host. AAAA records are used like A records to map a host name to its IP address. Use AAAA records to support IP version 6 addresses, which do not fit the standard A record format.

8.CNAME - Canonical Name records

The CNAME record specifies the actual domain name of this object. When DNS queries an aliased name and finds a CNAME record pointing to the canonical name, it then queries that canonical domain name.

9.A - Address Mapping records
The A record specifies the IP address of this host. A records are used to resolve a query for the IP address of a specific domain name.


Mail and MX records

Mail and MX records are used by mail routing programs such as Simple Mail Transfer Protocol (SMTP). Refer to the lookup table in DNS resource records for more information about the types of mail records supported by iSeries(TM) DNS.

DNS includes information for sending electronic mail by using mail exchanger information. If the network is using DNS, an SMTP (Simple Mail Transfer Protocol) application does not simply deliver mail addressed to host TEST.IBM.COM by opening a TCP connection to TEST.IBM.COM. SMTP first queries the DNS server to find out which host servers can be used to deliver the message.

Delivering mail to a specific address

DNS servers use resource records that are known as mail exchanger (MX) records. MX records map a domain or host name to a preference value and host name. MX records are generally used to designate that one host is used to process mail for another host. The records are also used to designate another host to try to deliver mail to if the first host cannot be reached. In other words, they allow mail that is addressed to one host to be delivered to a different host.

Multiple MX resource records may exist for the same domain or host name. When multiple MX records exist for the same domain or host, the preference (or priority) value of each record determines the order in which they are tried. The lowest preference value corresponds to the most preferred record, which will be tried first. When the most preferred host cannot be reached, the sending mail application tries to contact the next, less preferred MX host. The domain administrator, or the creator of the MX record, sets the preference value.

A DNS server can respond with an empty list of MX resource records when the name is in the DNS server's authority but has no MX assigned to it. When this occurs, the sending mail application may try to establish a connection with the destination host directly. Note: Using a wild card (example: *.mycompany.com) in MX records for a domain is not recommended.

Example: MX record for a host
In the following example, the system should, by preference, deliver mail for fsc5.test.ibm.com to the host itself. If the host cannot be reached, the system might deliver the mail to psfred.test.ibm.com or to mvs.test.ibm.com (if psfred.test.ibm.com also cannot be reached). This is an example of what these MX records would look like:

fsc5.test.ibm.com IN MX 0 fsc5.test.ibm.com
IN MX 2 psfred.test.ibm.com
IN MX 4 mvs.test.ibm.com


Ref: http://securitytnt.com/dns-amplification-attack/
Enjoy Folks :)
chandranjoy
Site Admin
 
Posts: 283
Joined: Fri Oct 23, 2009 11:19 pm

Return to DNS

Who is online

Users browsing this forum: No registered users and 1 guest


cron