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 !!!