Commonly used Record Types
The most commonly used record types are: A, CNAME, MX, NS, PTR and SOA.
A-Records (Host address)
• The A-record is the most basic and the most important DNS record type.
• They are used to translate human friendly domain names such as “www.jhsoft.com” into IP-addresses such as 23.211.43.53 (machine friendly numbers).
• A-records are the DNS server equivalent of the hosts file – a simple domain name to IP-address mapping.
• A-records are not required for all computers, but is needed for any computer that shares resources on a network.
• This record type is defined in RFC1035.
CNAME-Records (Canonical name for an alias)
CNAME-records are domain name aliases.
• Often computers on the Internet have multiple functions such as web-server, ftp-server, chat-server etc.
• To mask this, CNAME-records can be used to give a single computer multiple names (aliases).
• For example computer “xyz.com” may be both a web-server and an ftp-server, so two CNAME-records are defined:
• “www.xyz.com” = “xyz.com” and “ftp.xyz.com” = “xyz.com”.
• Sometimes a single server computer hosts many different domain names (take ISPs), and so CNAME-records may be defined such as “www.abc.com” =
• “www.xyz.com”.
• The most popular use the CNAME-record type is to provide access to a web-server using both the standard “www.domain.com” and “domain.com” (without the
• www).
• This is usually done by creating an A-record for the short name (without www), and a CNAME-record for the www name pointing to the short name.
• CNAME-records can also be used when a computer or service needs to be renamed, to temporarily allow access through both the old and new name.
• A CNAME-record should always point to an A-record to avoid circular references.
• This record type is defined in RFC1035.
MX-Records (Mail exchange)
MX-records identify mail server(s) responsible for a domain name.
• When sending an e-mail to “user@xyz.com”, your mail server must first look up the MX-record for “xyz.com” to see which mail server actually handles mail for
• “xyz.com” (this could be “mail.xyz.com” – or someone else’s mail server like “mail.isp.com”).
• Then it looks up the A-record for the mail server to connect to its IP-address.
• An MX-record has a “Preference” number indicating the order in which the mail server should be used.
• (Only relevant when multiple MX-records are defined for the same domain name).
• Mail servers will attempt to deliver mail to the server with the lowest preference number first, and if unsuccessful continue with the next lowest and so on.
• An MX-record identifies the name of a mail server server – not the IP-address.
• Because of this, it is important that an A-record for the referenced mail server exists (not necessarily on your server, but wherever it belongs), otherwise there may
• not be any way to find that mail server and communicate with it.
• Do not point an MX record to a CNAME-record. Many e-mail servers don’t handle this. Add another A-record instead.
• This record type is defined in RFC1035.
NS-Records (Authoritative name server)
NS-records identify DNS servers responsible (authoritative) for a zone.
• A zone should contain one NS-record for each of its own DNS servers (primary and secondaries).
• This mostly is used for zone transfer purposes (notify).
• These NS-records have the same name as the zone in which they are located.
• But the most important function of the NS-record is delegation.
• Delegation means that part of a domain is delegated to other DNS servers.
• For example all “.com” sub-names (such as “jhsoft.com”) are delegated from the “com” zone (hosted by the “InterNic”).
• The “com” zone contains NS-records for all “.com” sub-names (a lot!).
• You can also delegate sub-names of your own domain name (such as “subname.yourname.com”) to other DNS servers.
• You are in effect the “InterNic” for all sub-names of your own domain name (if you have a really cool domain name, you might even be able to sell sub-names for
• profit).
• To delegate “subname.yourname.com”, create NS-records for “subname.yourname.com” in the “yourname.com” zone.
• These NS-records must point to the DNS server responsible for “subname.yourname.com” for example “ns1.subname.yourname.com” – or a DNS server
• somewhere else like “ns1.othername.net”.
• An NS-record identifies the name of a DNS server – not the IP-address.
• Because of this, it is important that an A-record for the referenced DNS server exists (not necessarily on your server, but wherever it belongs), otherwise there may
• not be any way to find that DNS server and communicate with it.
• If an NS-record delegates a sub-name (“subname.yourname.com”) to a DNS server with a name in that sub-name (“ns1.subname.yourname.com”), an A-record for
• that server (“”ns1.subname.yourname.com”) must exist in the parent zone (“yourname.com”).
• This A-record is referred to as a “glue” record, because it doesn’t really belong in the parent zone, but is necessary to locate the DNS server for the delegated
• sub-name.
• This record type is defined in RFC1035.
PTR-Records (domain name pointer)
PTR-records map IP addresses to domain names (reverse of A-records).
• A PTR-record’s name is the IP address written in backward order with “in-addr.arpa.” appended to the end.
• As an example, looking up the domain name for IP address “1.2.3.4″ is done through a query for the PTR-record for “4.3.2.1.in-addr.arpa.”
• This record type is defined in RFC1035.
SOA-Records (Start of authority)
Each zone contains exactly one SOA-record, which holds the following properties for the zone:
• Name of primary DNS server
• The domain name of the primary DNS server for the zone.
• The zone should contain a matching NS-record.
• Mailbox of responsible person
• The email address (replace @ with a dot) of the person responsible for maintenance of the zone.
• The standard for this is the “hostmaster” username – such as “hostmaster.jhsoft.com” (= hostmaster@jhsoft.com).
• Serial number (Zone Transfers)
• Used by secondary DNS servers to check if the zone has changed.
• If the serial number is higher than what the secondary server has, a zone transfer will be initiated.
• Refresh Interval (see Zone Transfers)
• How often secondary DNS servers should check if changes are made to the zone.
• Retry Interval (see Zone Transfers)
• How often secondary DNS server should retry checking if changes are made – if the first refresh fails.
• Expire Interval (see Zone Transfers)
• How long the zone will be valid after a refresh.
• Secondary servers will discard the zone if no refresh could be made within this interval.
• Minimum (default) TTL
• Used as the default TTL for new records created within the zone.
• Also used by other DNS server to cache negative responses (such as record does not exist etc.).
• This record type is defined in RFC1035.
Less commonly used / experimental record types
The following are all less commonly used / experimental record types.
A6-Records (IPv6 host address)
• 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 be migrated to IPv6.
• IPv6 addresses are 128 bits long and 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.
• 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 A- and 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.
• A6-records are supposed to replace AAAA-records (see below).
• This record type is defined in RFC2874.
AAAA-Records (IPv6 host address)
• An AAAA-record specifies an absolute IPv6 address.
• This record type is supposed to be replaced by the A6 record type (see above).
• 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 subtree 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 12121234567 ( 1=USA, 212=New York area code, 1234567=number)
• The ISDN sub-address is an optional hexadecimal number.
• This record type is defined in RFC1183.
MB, MG, MINFO, MR Records (mailbox records)
• Most Internet 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 email 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.
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 domain names contained within the zone.
• To specify the “mailbox”, replace the email 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 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.
• This record type is however still considered experimental, and is 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 informational for people only and are not required for any DNS functions.
• 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.
WKS Records (Well Known Services)
• The Well Known Services (WKS) record lists the Well Known Services a host provides on a particular IP protocol. The common protocols are TCP and UDP.
• The common services are TIME, TELNET, FTP, or SMTP.
• This record type is defined in RFC1035.
The most commonly used record types are: A, CNAME, MX, NS, PTR and SOA.
A-Records (Host address)
• The A-record is the most basic and the most important DNS record type.
• They are used to translate human friendly domain names such as “www.jhsoft.com” into IP-addresses such as 23.211.43.53 (machine friendly numbers).
• A-records are the DNS server equivalent of the hosts file – a simple domain name to IP-address mapping.
• A-records are not required for all computers, but is needed for any computer that shares resources on a network.
• This record type is defined in RFC1035.
CNAME-Records (Canonical name for an alias)
CNAME-records are domain name aliases.
• Often computers on the Internet have multiple functions such as web-server, ftp-server, chat-server etc.
• To mask this, CNAME-records can be used to give a single computer multiple names (aliases).
• For example computer “xyz.com” may be both a web-server and an ftp-server, so two CNAME-records are defined:
• “www.xyz.com” = “xyz.com” and “ftp.xyz.com” = “xyz.com”.
• Sometimes a single server computer hosts many different domain names (take ISPs), and so CNAME-records may be defined such as “www.abc.com” =
• “www.xyz.com”.
• The most popular use the CNAME-record type is to provide access to a web-server using both the standard “www.domain.com” and “domain.com” (without the
• www).
• This is usually done by creating an A-record for the short name (without www), and a CNAME-record for the www name pointing to the short name.
• CNAME-records can also be used when a computer or service needs to be renamed, to temporarily allow access through both the old and new name.
• A CNAME-record should always point to an A-record to avoid circular references.
• This record type is defined in RFC1035.
MX-Records (Mail exchange)
MX-records identify mail server(s) responsible for a domain name.
• When sending an e-mail to “user@xyz.com”, your mail server must first look up the MX-record for “xyz.com” to see which mail server actually handles mail for
• “xyz.com” (this could be “mail.xyz.com” – or someone else’s mail server like “mail.isp.com”).
• Then it looks up the A-record for the mail server to connect to its IP-address.
• An MX-record has a “Preference” number indicating the order in which the mail server should be used.
• (Only relevant when multiple MX-records are defined for the same domain name).
• Mail servers will attempt to deliver mail to the server with the lowest preference number first, and if unsuccessful continue with the next lowest and so on.
• An MX-record identifies the name of a mail server server – not the IP-address.
• Because of this, it is important that an A-record for the referenced mail server exists (not necessarily on your server, but wherever it belongs), otherwise there may
• not be any way to find that mail server and communicate with it.
• Do not point an MX record to a CNAME-record. Many e-mail servers don’t handle this. Add another A-record instead.
• This record type is defined in RFC1035.
NS-Records (Authoritative name server)
NS-records identify DNS servers responsible (authoritative) for a zone.
• A zone should contain one NS-record for each of its own DNS servers (primary and secondaries).
• This mostly is used for zone transfer purposes (notify).
• These NS-records have the same name as the zone in which they are located.
• But the most important function of the NS-record is delegation.
• Delegation means that part of a domain is delegated to other DNS servers.
• For example all “.com” sub-names (such as “jhsoft.com”) are delegated from the “com” zone (hosted by the “InterNic”).
• The “com” zone contains NS-records for all “.com” sub-names (a lot!).
• You can also delegate sub-names of your own domain name (such as “subname.yourname.com”) to other DNS servers.
• You are in effect the “InterNic” for all sub-names of your own domain name (if you have a really cool domain name, you might even be able to sell sub-names for
• profit).
• To delegate “subname.yourname.com”, create NS-records for “subname.yourname.com” in the “yourname.com” zone.
• These NS-records must point to the DNS server responsible for “subname.yourname.com” for example “ns1.subname.yourname.com” – or a DNS server
• somewhere else like “ns1.othername.net”.
• An NS-record identifies the name of a DNS server – not the IP-address.
• Because of this, it is important that an A-record for the referenced DNS server exists (not necessarily on your server, but wherever it belongs), otherwise there may
• not be any way to find that DNS server and communicate with it.
• If an NS-record delegates a sub-name (“subname.yourname.com”) to a DNS server with a name in that sub-name (“ns1.subname.yourname.com”), an A-record for
• that server (“”ns1.subname.yourname.com”) must exist in the parent zone (“yourname.com”).
• This A-record is referred to as a “glue” record, because it doesn’t really belong in the parent zone, but is necessary to locate the DNS server for the delegated
• sub-name.
• This record type is defined in RFC1035.
PTR-Records (domain name pointer)
PTR-records map IP addresses to domain names (reverse of A-records).
• A PTR-record’s name is the IP address written in backward order with “in-addr.arpa.” appended to the end.
• As an example, looking up the domain name for IP address “1.2.3.4″ is done through a query for the PTR-record for “4.3.2.1.in-addr.arpa.”
• This record type is defined in RFC1035.
SOA-Records (Start of authority)
Each zone contains exactly one SOA-record, which holds the following properties for the zone:
• Name of primary DNS server
• The domain name of the primary DNS server for the zone.
• The zone should contain a matching NS-record.
• Mailbox of responsible person
• The email address (replace @ with a dot) of the person responsible for maintenance of the zone.
• The standard for this is the “hostmaster” username – such as “hostmaster.jhsoft.com” (= hostmaster@jhsoft.com).
• Serial number (Zone Transfers)
• Used by secondary DNS servers to check if the zone has changed.
• If the serial number is higher than what the secondary server has, a zone transfer will be initiated.
• Refresh Interval (see Zone Transfers)
• How often secondary DNS servers should check if changes are made to the zone.
• Retry Interval (see Zone Transfers)
• How often secondary DNS server should retry checking if changes are made – if the first refresh fails.
• Expire Interval (see Zone Transfers)
• How long the zone will be valid after a refresh.
• Secondary servers will discard the zone if no refresh could be made within this interval.
• Minimum (default) TTL
• Used as the default TTL for new records created within the zone.
• Also used by other DNS server to cache negative responses (such as record does not exist etc.).
• This record type is defined in RFC1035.
Less commonly used / experimental record types
The following are all less commonly used / experimental record types.
A6-Records (IPv6 host address)
• 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 be migrated to IPv6.
• IPv6 addresses are 128 bits long and 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.
• 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 A- and 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.
• A6-records are supposed to replace AAAA-records (see below).
• This record type is defined in RFC2874.
AAAA-Records (IPv6 host address)
• An AAAA-record specifies an absolute IPv6 address.
• This record type is supposed to be replaced by the A6 record type (see above).
• 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 subtree 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 12121234567 ( 1=USA, 212=New York area code, 1234567=number)
• The ISDN sub-address is an optional hexadecimal number.
• This record type is defined in RFC1183.
MB, MG, MINFO, MR Records (mailbox records)
• Most Internet 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 email 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.
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 domain names contained within the zone.
• To specify the “mailbox”, replace the email 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 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.
• This record type is however still considered experimental, and is 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 informational for people only and are not required for any DNS functions.
• 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.
WKS Records (Well Known Services)
• The Well Known Services (WKS) record lists the Well Known Services a host provides on a particular IP protocol. The common protocols are TCP and UDP.
• The common services are TIME, TELNET, FTP, or SMTP.
• This record type is defined in RFC1035.
No comments:
Post a Comment