An A6-record is used to specify the IPv6 address (or part of the IPv6 address) for a host.
A6-records expands the functionality of AAAA-records by adding support for aggregation and renumbering.
A lookup for an IPv6 records could involve several A6-records which each specify only part of the final address.
This is achieved through the additional prefix-length and prefix name fields.
This record type is defined in RFC2874.
AAAA-Records (IPv6 host address)
An AAAA-record is used to specify the IPv6 address for a host.
IPv6 is the future replacement for the current IP address system (also known as IPv4).
The current IPv4 addresses are 32 bits long ( x . x . x . x = 4 bytes), and therefore “only” support a total of 4,294,967,296 addresses - less than the global population.
With this limitation there is an increasing shortage of IPv4 addresses.
To solve the problem, the whole Internet will eventually have to be migrated to IPv6.
IPv6 addresses are 128 bits long and are written in hexadecimal numbers separated by colons (:) at every four digits.
Zeros can be skipped - for example: 4C2F::1:2:3:4:567:89AB.
Few applications and network devices currently support IPv6 and IPv6 addresses are not yet generally available, but this is expected to change rapidly.
This record type is defined in RFC1886.
AFSDB-Records (AFS Data Base location)
An AFSDB-record maps a domain name to an AFS (Andrew File System) database server.
The server name points to an A-record for the database server, and the sub-type indicates server type:
1 = AFS version 3.0 volume location server for the named AFS cell.
2 = DCE authenticated server.
This record type is defined in RFC1183.
ATMA-Records (Asynchronous Transfer Mode address)
An ATMA-record maps a domain name to an ATM address.
The ATM address can be specified in either E.164 format (decimal) or NSAP format (hexadecimal).
This record type is defined in “ATM Name System Specification Version 1.0″ published by the ATM Forum.
DNAME-Records (Non-Terminal DNS Name Redirection)
A DNAME-record is used to map / rename an entire sub-tree of the DNS name space to another domain.
It differs from the CNAME-record which maps only a single node of the name space.
This record type is defined in RFC2672.
HINFO-Records (Host information)
A HINFO-record specifies the host / server’s type of CPU and operating system.
This information can be used by application protocols such as FTP, which use special procedures when communicating with computers of a known CPU and operating system type.
Standard CPU and operating system types are defined in RFC1700 (Page 206 / 214).
The standard for a Windows PC is “INTEL-386″ / “WIN32″.
This record type is defined in RFC1035.
ISDN-Records (ISDN address)
The ISDN-record maps a domain name to an ISDN (Integrated Services Digital Network) telephone number.
The ISDN phone numbers / DDI (Direct Dial In) used should follow ITU-T E.163/E.164 international telephone numbering standards.
For example 911262242222 ( 91=India, 1262=Rohtak, Haryana area code, 242222=number)
The ISDN sub-address is an optional hexadecimal number.
This record type is defined in RFC1183.
LOC-Records (Location information)
This record type is used to specify geographical location information about hosts, networks, and subnets.
A LOC-record describes a location with the following properties:
- Latitude / Longitude.
- Altitude.
- Size (diameter of the location described).
- Horizontal / Vertical precision of the data.
Because of the binary storage format used, only the first digit of the size and precision properties can be non-zero.
Additional interesting and practical information about LOC-records is available at http://www.ckdhr.com/dns-loc/
This record type is defined in RFC1876.
MB, MG, MINFO, MR Records (mailbox records)
Most Internet e-mail servers only support MX-records.
Only use MB, MG, MINFO and MR records if you have specific requirements for these.
To specify “mailbox” names, replace the e-mail address @ sign with a dot (.).
MB-records (Mailbox)
Maps a mailbox to a host (server).
The host must be the same as a valid A-record already defined in the same zone.
MG-records (Mail group member)
Used to specify mail group members (one MG-record per member).
Each member mailbox must be identical to a valid mailbox (MB-record).
MINFO-records (Mailbox or mail list information)
Specifies the mailbox of the responsible person and optionally a mailbox for errors for this mailbox or list.
Each mailbox must be the same as a valid mailbox (MB-record) that already exist in the zone.
MR-records (Renamed mailbox)
Specifies a renamed mailbox.
An MR-record can be used as a forwarding entry for a user who has moved to a different mailbox.
These record types are defined in RFC1035.
NAPTR-Records (Naming Authority Pointer)
NAPTR-records are used to store rules used by DDDS (Dynamic Delegation Discovery System) applications.
One example is “ENUM” which allows an end user to type a telephone number into e.g. a web browser and access a listing of Internet resources (URI) for that number, such as addresses for IP telephony, e-mail or web sites.
For more information on “ENUM”, see http://www.ripe.net/enum or http://enum.nic.at
The “Order” field is a number (0 to 65535) specifying the order in which multiple NAPTR records must be processed (low to high) by the application.
The “Preference” field is equivalent to the Priority value in the DDDS algorithm. It is a number (0-65535) that specifies the order (low to high) in which NAPTR records with equal Order values should be processed.
The “Flags” field contains flags to control aspects of the rewriting and interpretation of the fields in the record. Flags are single characters from the set A-Z and 0-9. The use of this field is specified by the individual DDDS application.
The “Services” field specifies the service parameters applicable to this delegation path. The individual DDDS application specifies the possible values for this field.
The “Reg. Exp.” field contains a substitution expression that is applied to the original string held by the client in order to construct the next domain name to lookup. See the DDDS algorithm specification for the syntax of this field.
The “Replacement” field specifies the next domain name (fully qualified) to query for depending on the potential values found in the flags field. This field is used when the regular expression is empty (a simple replacement operation). The “Reg.Exp.” and “Replacement” fields are mutually exclusive (only one can contain a value).
This record type is defined in RFC3403.
NSAP-Records (NSAP address)
An NSAP-record maps a domain name to an NSAP address.
The NSAP address is entered using hexadecimal digits - any NSAP address format is allowed.
This record type is defined in RFC1706.
RP-Records (Responsible person)
An RP-record specifies the mailbox of the person responsible for the host (domain name).
A SOA-record defines the responsible person for an entire zone, but a zone may contain a large number of individual hosts / domain names for which different people are assigned responsibility.
The RP-record type makes it possible to identify the responsible person for individual host names contained within the zone.
To specify the “mailbox”, replace the e-mail address @ sign with a dot (.).
Optionally specify the domain name for a TXT-record with additional information (such as phone and address).
This record type is defined in RFC1183.
RT-Records (Route through)
An RT-record specifies an intermediate host that provides routing to the domain name (host) of the record.
This can be used by computers which are not directly connected to the Internet, or wide area network (WAN).
A preference value is used to set priority if multiple intermediate routing hosts are specified - lower values tried first.
For each intermediate host specified, a corresponding host (A) address resource record is needed in the current zone.
This record type is defined in RFC1183.
SRV-Records (location of service)
SRV-records are used to specify the location of a service.
They are recently being used in connection with different directory servers such as LDAP (Lightweight Directory Access Protocol), and Windows 2000/2003 directory services.
They can also be used for advanced load balancing and to specify specific ports for services - for example that a web-server is running on port 8080 instead of the usual port 80 (theoretical example - this is not yet supported by any major browsers).
This record type is however NOT supported by most programs in use today, including web-browsers.
The name of a SRV-record is defined as “_service._protocol.domain” - for example “_ftp._tcp.xyz.com”.
Most internet services are defined in RFC1700 (page 15), and the protocol is generally TCP or UDP.
The “service location” is specified through a target, priority, weight, and port:
- Target is the domain name of the server (referencing an A-record).
- Priority is a preference number used when more servers are providing the same service (lower numbers are tried first).
- Weight is used for advanced load balancing.
- Port is the TCP/UDP port number on the server that provides this service.
This record type is defined in RFC2782.
TXT-Records (Descriptive text)
TXT-records are used to hold descriptive text.
They are often used to hold general information about a domain name such as who is hosting it, contact person, phone numbers, etc.
TXT-records are also used for SPF.
SPF is a spam fighting method which uses DNS TXT-records to define which hosts are permitted so send e-mails for a domain. For details please see http://openspf.org
This record type is defined in RFC1035.
X25-Records (X.25 PSDN address)
An X25-records maps a domain name to a Public Switched Data Network (PSDN) address number.
Numbers used with this record should follow the X.121 international numbering plan.
This record type is defined in RFC1183.
Thats it !!! …what else ? …u want any other thing here….just contact me …u r welcome !!!
hello friends ….new post..regarding basic terms related to DNS
Hosts File
Before DNS servers were invented, domain name translation depended entirely on the “hosts file”, a text file stored on your organization’s server, or on your PC. The hosts file listed, line by line, Internet domain names and their associated IP addresses. The master host file was compiled and stored on the machines at the Network Information Center (NIC) and was downloaded by on a regular basis by everyone accessing the Internet. Obviously this hosts file quickly grew much to large to be manageable. As the Internet grows, new domain names are added by the minute, and it is impossible for every computer on the Internet to keep downloading this file.
The solution of course was the DNS server system. Unlike the hosts file, DNS servers don’t rely on a single large mapping file. Instead DNS servers only contain information about the domain names they are directly responsible for and some limited reference data on how to find other domain names.
Computers (including those running Windows) can still use the “hosts” file for name to IP-address translation instead of DNS, and this works fine on a small network where there are few changes and a limited number of computers to maintain.
On Windows 95/98/Me the “hosts” file is located in the “c:\windows” directory, on Windows NT4/2000 in the “c:\winnt\system32\drivers\etc” directory, and on Windows XP/2003 in the “c:\windows\system32\drivers\etc” directory
A sample “hosts” file is supplied with Windows named “hosts.sam” located in the same directory.
Please note that the host file must be named “hosts” without any extension and it must be located in the above directories for Windows to automatically use it without a DNS server.
Host file line example:
1.2.3.4 hosta.com hostb.com
Defines an A-Record (hosta.com=1.2.3.4), a PTR-record (4.3.2.1.in-addr.arpa=hosta.com) and a CNAME-record (hostb.com=hosta.com).
TTL (Time To Live)
All DNS records have a TTL property, specifying the amount of time other DNS servers and applications are allowed to cache the record.
When a DNS record is stored in the cache of a DNS server, the record’s TTL is continuously reduced as time go by, and when the TTL finally reaches zero the record is removed from the cache.
When a DNS server passes DNS records from the cache along to applications and other DNS servers, it supplies the current TTL value - not the original. This way the original TTL is guaranteed no matter how many DNS servers the record passes through.
Even when a DNS server reports that a certain record does not exist, this information is cached using the “minimum TTL” from a SOA-record supplied in the response.
Setting a record’s TTL to zero, means that applications and DNS servers are not allowed to cache the record.
When deciding on the TTL, you need to consider how often the record will be changed.
Because of caching, changes to a DNS record will not reach the entire network until the original TTL has expired - a good reason for setting a short TTL.
But caching helps reduce network traffic. The longer the TTL, the longer the record will live in other DNS server caches around the world, and so fewer requests to the original DNS server are needed - a good reason for setting a long TTL.
Generally, for a record pointing to a server/device with a static IP address and no need for quick updates, a TTL of one day is a good starting point.
However, if the record is for a host with a dynamic IP address or for server which is part of a failover set , you should be using a TTL value of a few minutes or less.
Most DNS servers will not cache a DNS record for more than one week.
Root DNS Records
At the top of the domain name hierarchy is the root domain (typically references by a single dot, or <root>). Information about this domain resides on 13 root DNS servers located around the world.
All Internet DNS servers are configured with references to these root servers referred to as the “root file”, “hints file” or “cache file”.
Below the root domain are the top-level domains, which are either country specific or generic. Examples of country specific top-level domains are in (India) and CA (Canada), while generic top-level domains include the well-known COM (commercial organizations), EDU (educational institutions), GOV (governmental organizations), and NET (network organizations), among others. Note that top-level domains outside the U.S. are typically country specific, while U.S.-based sites typically use generic names. Below the top-level domains are the second-level domains (anuragbhatia.com google.com), and then the third-level domains, and so on down the chain.
To locate any domain name, a DNS server generally starts by asking one of the root servers (unless it already has a closer match cached)
The root server will supply references (NS-records) to DNS servers responsible for the next level (.com, .net, etc.).
The DNS server then repeats the request to one of those server, which will supply references to the next level (for example anuragbhatia.com), and so it goes on until the requested domain name is found.
This process is know as recursion.
This way a DNS server can locate any name in the world, as long as it knows the addresses of the root DNS servers.
DNS Recursion
DNS requests can either be “recursive” or “non-recursive”.
Client applications typically requests that the DNS server performs recursion for them by setting an “RD” (recursion desired) flag in the request packet. This is a recursive request.
Client applications do this both because they do not posses the ability to resolve domain names themselves, and also to take advantage of centralized caching on the DNS server.
However, when a DNS server sends requests to other DNS servers as part of the recursion process, these requests are typically non-recursive (the RD flag is not set).
The DNS server indicates back to the client if it is willing to perform recursion or not by setting or not setting an “RA” (recursion available) flag in the response packet.
When a DNS server receives a recursive request from a client that it is willing to perform recursion for, it will go through the process of resolving the requested domain name by first asking the root servers, which respond with a referral to the top level DNS servers, then asking one of those servers, which respond with a referral to the next level DNS servers, etc.
When a DNS server receives a non-recursive request or a request from a client that it is not willing to perform recursion for, it typically responds immediately with whatever local data it has available at the time without doing any additional processing.
Round Robin
Round Robin is a method of managing server (web, ftp, mail etc.) congestion by distributing connection load across multiple servers containing identical content.
Round robin works on a rotating basis in that one record is handed out, then moves to the back of the list; the next record is handed out, then it moves to the end of the list; and so on, depending on the number of servers being used. This works in a looping fashion.
Let’s say a company has one domain name and with an identical home page residing on three web servers with three different IP addresses. When one user accesses the home page he/she will be sent to the first IP address. The second user who accesses the home page will be sent to the next IP address, and the third user will be sent to the third IP address. In each case, once the IP address is given out, it goes to the end of the list. The fourth user, therefore, will be sent to the first IP address and so forth.
Round Robin kicks in whenever two or more records with the same name and type exist in your own records or cached data - such as two A-records with identical names (but different IP addresses).
Zones
Domains are broken into “zones” for which individual DNS servers are responsible.
A domain represents the entire set of names / machines that are contained under an organizational domain name.
For example all domain names ending with “.com” are part of the “com” domain.
A zone is a domain less any sub-domains delegated to other DNS servers (see NS-records).
A DNS server could be responsible (authoritative) for all records under the “xyz.com” domain, but by defining NS-records for “abc.xyz.com”, part of the domain is delegated to another DNS server - and perhaps even a different company/entity.
A zone contains exactly one SOA-record describing the general properties of the zone, and any number of other DNS records.
Entire zones can transferred from a primary DNS server to secondary DNS servers through Zone Transfers.
Zone Transfers
When changes are made to a zone and its records on the primary server, a zone transfer is used to update DNS records on secondary DNS servers.
A primary server has the “master” copy of a zone, and secondary servers keep copies of the zone for redundancy.
When changes are made to zone data on the primary, they must be distributed to the secondary servers.
Most DNS servers automatically notifies secondary servers whenever changes are made, and most DNS servers will request a Zone Transfer whenever such a notification is received.
For this to work correctly, NS-records (and corresponding A-records) for each secondary DNS server must exist in the zone.
Secondary servers also periodically check for changes, by polling the SOA-record of the zone from the primary server, and checking the serial number.
In addition to whatever other changes are made to a zone and its records, the serial number of the SOA-record is always incremented.
The periodic polling by the secondary servers is controlled by the refresh, retry, and expire parameters of the SOA-record.
The secondary server waits the “refresh” interval before checking with the primary for a new serial number. If this check cannot be completed, new checks are started every “retry” interval.
If the secondary finds it impossible to perform a serial check within the “expire” interval, it discards the zone.
When the poll shows that the zone has changed (higher serial number), the secondary server will request a zone transfer.
The actual zone transfer operation transfers all the records in the zone from the primary to the secondary server (similar to FTP).
Reverse Look Up / “in-addr.arpa”
Reverse DNS is IP address to domain name mapping - the opposite of forward (normal) DNS which maps domain names to IP addresses.
Reverse DNS is maintained in a separate set of data from forward DNS.
For example, forward DNS for “abc.com” pointing to IP address “1.2.3.4″, does not necessarily mean that reverse DNS for IP “1.2.3.4″ also points to “abc.com”.
Reverse DNS is mostly used by humans for such things as tracking where a web-site visitor came from, or where an e-mail message originated etc.
Reverse DNS is typically not as critical in as forward DNS - visitors will still reach your web-site just fine without any reverse DNS for your web-server IP or the visitor’s IP.
However there is one important exception: Many e-mail servers on the Internet (including AOL’s) are configured to reject incoming e-mails from any IP address which does not have reverse DNS.
So if you run your own e-mail server, reverse DNS must exist for the IP address that outgoing e-mail is sent from.
It does not matter what the reverse DNS record for your IP address points to as long as it is there. If you host multiple domains on one e-mail server, just setup reverse DNS to point to whichever domain name you consider primary.
(e-mail servers checking for reverse DNS know that it is normal to host many domains on a single IP address and it would be impossible to list all those domains in reverse DNS for the IP).
A special PTR-record type is used to store reverse DNS entries. The name of a PTR-record is the IP address with the segments reversed + “.in-addr.arpa”. For example the reverse DNS entry for IP 1.2.3.4 would be stored as a PTR-record for “4.3.2.1.in-addr.arpa”.
Reverse DNS is also different from forward DNS in who points (delegates) the zone to your DNS server.
With forward DNS, you point the zone to your DNS server by registering that domain name with a registrar.
With reverse DNS, your Internet connection provider (ISP) must point the zone (”….in-addr.arpa”) to your DNS server.
Without this delegation from your ISP, your reverse zone will not work.
If you are assigned the class C network 1.2.3.X, your ISP can delegate DNS authority for the “3.2.1.in-addr.arpa” domain name to your DNS server.
Your DNS servers should in this case have a zone called “3.2.1.in-addr.arpa” containing PTR-records for all active IP addresses in the class C network (1.2.3.0 - 1.2.3.255).
It is also possible to delegate “in-addr.arpa” authority for less than one class C network (256 IP addresses).
This can be achieved in different ways, but typically follows the style described in RFC2317.
(Please note: Many ISPs will not do this sub-delegation if you only have one or a few IP addresses. In this case your ISP has probably already setup some default reverse DNS for your IP addresses)
For example if you are assigned network 1.2.3.24/29 (1.2.3.25 to 1.2.3.30 subnet mask 255.255.255.248), the owner of the class C 1.2.3.X (your ISP) would have these DNS entries on his DNS server:
NS 24/29.3.2.1.in-addr.arpa = your-dns-server-name1
NS 24/29.3.2.1.in-addr.arpa = your-dns-server-name2
CNAME 25.3.2.1.in-addr.arpa = 25.24/29.3.2.1.in-addr.arpa
CNAME 26.3.2.1.in-addr.arpa = 26.24/29.3.2.1.in-addr.arpa
CNAME 27.3.2.1.in-addr.arpa = 27.24/29.3.2.1.in-addr.arpa
CNAME 28.3.2.1.in-addr.arpa = 28.24/29.3.2.1.in-addr.arpa
CNAME 29.3.2.1.in-addr.arpa = 29.24/29.3.2.1.in-addr.arpa
CNAME 30.3.2.1.in-addr.arpa = 30.24/29.3.2.1.in-addr.arpa
And your DNS server would have a zone named “24/29.3.2.1.in-addr.arpa” with the following records:
NS 24/29.3.2.1.in-addr.arpa = your-dns-server-name1
NS 24/29.3.2.1.in-addr.arpa = your-dns-server-name2
PTR 25.24/29.3.2.1.in-addr.arpa = name1.your-domain-name
PTR 26.24/29.3.2.1.in-addr.arpa = name2.your-domain-name
PTR 27.24/29.3.2.1.in-addr.arpa = name3.your-domain-name
PTR 28.24/29.3.2.1.in-addr.arpa = name4.your-domain-name
PTR 29.24/29.3.2.1.in-addr.arpa = name5.your-domain-name
PTR 30.24/29.3.2.1.in-addr.arpa = name6.your-domain-name
A reverse lookup for IP 1.2.3.27 (PTR-record for “27.3.2.1.in-addr.arpa”), would first return an alias (CNAME-record) for “27.24/29.3.2.1.in-addr.arpa” from the class C owner’s DNS server, which is then translated to “name3.your-domain-name” by your DNS server.
Well thats all for this……hope u got a good sleep in reading this ! …just kidding…..