Cisco Network Registrar User's Guide, 6.2
15 - Resource Records
Downloads: This chapterpdf (PDF - 258.0KB) The complete bookPDF (PDF - 18.62MB) | Feedback

Managing Resource Records

Table Of Contents

Managing Resource Records

Managing Resource Records

Adding Resource Records

Protecting Resource Record Sets

Editing Resource Records

Removing Resource Records

Removing Cached Records

Listing Records

Filtering Records

Deleting Leftover Zone Records After Recreating Zones

Using Service Location (SRV) Records

Using NAPTR Records

Managing Hosts in Zones

Adding Address, Canonical Name, and Pointer Records

Editing Hosts

Removing Hosts


Managing Resource Records


This chapter explains how to configure some of the more advanced DNS zone and server parameters by using the Cisco CNS Network Registrar Web UI and CLI. Before you proceed with the concepts in this chapter, read Chapter 14, "Managing Zones," which explains how to set up the basic properties of a primary and secondary DNS server and its zones.

Managing Resource Records

Resource records (RRs) comprise the data within a DNS zone. Although there is no fixed limit to the number of RRs a zone may own, in general, a zone may own one or more RRs of a given type (the zone always has a Start of Authority, or SOA, record). There are some exceptions depending on the types involved. All RRs have the entries described in Table 15-1.

Table 15-1 Resource Record Common Entries 

RR Entry
Description

Name

Owner of the record, such as a zone or hostname.

Class (not required for all formats)

Network Registrar supports only the IN (Internet) class.

TTL (time to live)

Amount of time to store the record in a cache, in seconds. If you do not include a TTL, Network Registrar uses the zone default TTL, defined as a zone attribute.

Type

Type of the record, such as A, NS, SOA, and MX. There are many types that various RFCs define, although fewer than ten are in common use.

Record data

Data types whose format and meaning varies with record type.


This section describes how to add, remove, edit, and filter RRs.

Adding Resource Records

Before adding or modifying RRs, keep in mind the two distinct zone edit modes that you can set and work in: staged and synchronous (see the "Staged and Synchronous Modes" section on page 14-1). For details on the RR syntax, see Appendix A, "Resource Records."

Administrator roles required for RR management are the dns-admin role at the local cluster and the central-dns-admin role at the regional cluster. The host-admin role at the local cluster and the central-host-admin role at the regional cluster can view host records only.


Step 1 In the Web UI, click DNS, then Forward Zones to open the List/Add Zones page at the local cluster, or the List Forward Zones page at the regional cluster.

Step 2 Click the View icon () in the RRs column of the zone name to open the List/Add DNS Server RRs for Zone page at the local cluster (see Figure 15-1).

Figure 15-1 List/Add DNS Server RRs for Zone Page (Local)

Note that by default at the regional cluster, this opens the List/Add CCM Server Protected RRs for Zone page, because the regional cluster defaults to staged (CCM) zone edit mode.


Tip You can toggle between the List/Add CCM Server Protected RRs for Zone page and the List/Add DNS Server RRs for Zone page. Whichever appears initially depends on whether you are set up with protected or unprotected RR edit capabilities (see the "Protecting Resource Record Sets" section).



Tip Records are listed in the formats that their respective RFCs specify, with only the first record in a set labeled with its name, and in DNSSEC order. To reduce or increase the items in the table, change the page size value at the bottom of the page, then click Change Page Size.


Step 3 Add the RR name, TTL (if not using the default TTL), type, and data as appropriate.

In the CLI, use zone name addRR to add a protected RR of a certain type. You can specify the name as a relative name, if the owner is in the same domain, an absolute name (by supplying the FQDN), or the same name as the zone name (by using the at [@] symbol). You can specify the zone edit mode as part of the command by using the -staged or -sync switches. For example:

nrcmd> zone example.com addRR -sync host101 A 192.168.50.101 

In the CLI, zone name addDNSRR type data adds an unprotected RR.

Step 4 By default, RRs are protected, which means that DNS updates cannot overwrite them (see the "Protecting Resource Record Sets" section). To unprotect the RRs, click the Locked icon () to the left of the record name to change it to the Unlocked icon (). Likewise, to protect the record, click the Unlocked () icon to change it to the Locked icon ().

Step 5 Click Add Resource Record.


Protecting Resource Record Sets

When an RR is protected, DNS updates cannot modify the record. Most administratively created RRs are protected. However, RRs created by DNS updates must be unprotected to allow the server to modify them. You can set this protection status for each RR set on the List/Add DNS Server RRs for Zone page.

Note that only the primary DNS server can recognize this protection status; secondary servers do not recognize the protection status of their RRs.

In the Web UI, on the List/Add Zones page at the local cluster or the List Forward Zones page at the regional cluster, click the View icon () in the RRs column of the zone name. Then, on the List/Add DNS Server RRs for Zone page (see Figure 15-1):

To unprotect the RR set, click the Locked icon () to the left of the RR set name to change it to the Unlocked icon ().

To protect the RR set, click the Unlocked () icon to change it to the Locked icon ().

Note that you cannot change the protection on the List/Add CCM Protected RRs for Zone page. The Locked icon () always appears and you cannot change it.

In the CLI, to protect the RR sets, use zone name protect-name rrset-name; to unprotect the zone, use the unprotect-name rrset-name action instead. For example:

nrcmd> zone example.com protect-name boston 
100 Ok
protected boston
nrcmd> zone example.com unprotect-name boston 
100 Ok
unprotected boston

Editing Resource Records

You can edit RRs as an individual record or as an RR set:

Individual RRs—Click the Edit icon () next to the record name to open the Edit RR in Zone page.

RR sets—Click the name of the record to open the Edit RR Set in Zone page.

Removing Resource Records

You can remove RRs from a zone. In the Web UI, on the List/Add DNS Server RRs for Zone page or List/Add CCM Server Protected RRs for Zone page:

To remove an entire record name set, click the Delete icon () next to the record set name in the list, then confirm the deletion.

To remove individual records from the set, click the name of the record set to open the Edit RR Set page, click the Delete icon next to the individual record in the list, then confirm the deletion.

In the local cluster CLI, there are two removal commands, depending on the type of RR to remove:

Use zone name removeRR to remove any RR. You must specify the owner. If you omit the data, Network Registrar removes all records of the specified type for the specified owner. Similarly, if you omit the type, Network Registrar removes all records for the specified owner.

Use zone name removeDNSRR to remove unprotected RRs only.

Removing Cached Records

Removing cached records removes nonauthoritative RRs from both in-memory and persistent (nonauthoritative) cache. The DNS server must be running to remove cached records. Changes take effect immediately; you do not need to reload the server.


Step 1 In the Web UI, click DNS, then DNS Server to open the Manage DNS Server page.

Step 2 Click the Run icon () in the Commands column to open the DNS Server Commands page.

Step 3 For the Remove nonauthoritative RR set command, if you want to:

Remove the entire cached RR set, enter just the name of the RR set; omit the type and data values.

Remove the cached RR name, enter the name and type of RR.

Remove the specific cached record, enter the name, type, and data.

Step 4 Click the Run icon () for that command. You should get a confirmation message.

Step 5 Click Return.

In the CLI, use dns removecachedRR name type data to remove cached RRs in the memory and persistent caches. With the type and data omitted, this removes the entire RR set; if the type is included without the data, this removes the name set; with the name, type, and data included, this removes the specific record only.


Listing Records

You can display all the RRs, or only the staged or synchronized ones. The server must be operating to display the synchronized records.

In the Web UI, on the List/Add CCM Server Protected RRs for Zone page or List/Add DNS Server RRs for Zone page, view the records on the page, then click Return to Zone List.

In the CLI, use zone name listRR to display RRs in the named zone. You can also specify whether you want all records or only staged (CCM) or synchronized (DNS) records (see the "Filtering Records" section for details). For example:

nrcmd> zone example.com listRR dns 

Filtering Records

You might want to filter records to display only one type of record, such as an A or PTR record.

In the Web UI, you can filter RRs right from the List/Add CCM Protected Server RRs for Zone page (see Figure 15-1) or List/Add DNS Server RRs for Zone page. Look for the Name and Type fields just below the Add Resource Record button.

By default, RRs are sorted alphabetically by name, starting with the top-of-zone records (marked with the @ symbol), and secondarily sorted by type, then data. You can also sort them by:

Protected state—You can click All, Unprotected (), or Protected ().

Name prefix—Starting characters in the name. Note that that the * character matches exactly that character in the name. For example, entering al returns alberta, allen.wrench, and allie, whereas entering al* returns al* and al*ert.

RR type—Click one of the RR types in the drop-down list, such as A or TXT.

When the selection is complete, click Filter List. This returns just the filtered entries in the table below the fields. To return to the full, unfiltered list, click Clear Filter.

In the CLI, you can use zone name listRR option to filter records. This helps determine whether DNS update is working and what dynamic entries are in the system. The options are:

all—Displays all records (the default if omitted).

ccm—Displays the CCM protected RRs only (the default for the local cluster).

dns—Displays the DNS live RRs only (the default for the regional cluster).

Deleting Leftover Zone Records After Recreating Zones

You can delete leftover static zone records after you delete a zone and then recreate it. Dynamic RRs are automatically deleted when you recreate the zone.

This function is currently not available in the Web UI. In the CLI, use zone name cleanRR if you periodically delete and reimport zones, which can cause your database to grow. This command uses the DNS server's historical zone data to determine what part to remove. It does not print a list of records to be deleted or prompt you for confirmation. You can safely run it any time.

Using Service Location (SRV) Records

Windows 2000 domain controllers use the service location (SRV) RR to advertise services to the network. This RR is defined in the RFC 2782, "A DNS RR for specifying the location of services (DNS SRV)." The RFC defines the format of the SRV record (DNS type code 33) as:

_service._protocol.name ttl class SRV priority weight port target 

There should always be an A record associated with the SRV record's target so that the client can resolve the service back to a host. In the Microsoft Windows 2000 implementation of SRV records, the records might look like this:

myserver.example.com A 10.100.200.11
_ldap._tcp.example.com SRV 0  0  389  myserver.example.com
_kdc._tcp.example.com SRV 0  0  88  myserver.example.com
_ldap._tcp.dc._msdcs.example.com SRV 0  0  88  myserver.example.com

An underscore (_) always precedes the service and protocol names. In the example, _kdc is the Key Distribution Center. The priority and weight help a client choose between target servers providing the same service (the weight differentiating those with equal priorities). If the priority and weight are all set to zero, the client orders the servers randomly. For more information on SRV records, see Appendix A, "Resource Records."


Note For a description of how Windows 2003 and XP clients interoperate with DNS and DHCP servers, including scavenging dynamic RRs, see the "Configuring DNS Update for Windows Clients" section on page 27-14.


Using NAPTR Records

Network Registrar supports Naming Authority Pointer (NAPTR) RRs. These records help with name resolution in a particular namespace and are processed to get to a resolution service. Because NAPTR records are a proposed standard, RFC 3403, Network Registrar only validates their numeric record fields. However, the proposed standard requires a value for each field, even if it is null (""), and there are no default values. See Appendix A, "Resource Records" for the syntax of NAPTR records.

When using a NAPTR record to locate a Session Initiation Protocol (SIP) proxy, see the proposed standard, RFC 2916 or RFC 3263. In RFC 2916, the ENUM working group of the Internet Engineering Task Force specifies NAPTR records to map E.164 addresses to Universal Resource Identifiers (URIs). Using the NAPTR record resolves a name in the E.164 international public telecommunication namespace to a URI, instead of providing the name of a service to use as a resolver. The U flag was added to the NAPTR record for this purpose.

For example, to specify a SIP proxy for the phone number +4689761234, add a NAPTR record at the name 4.3.2.1.6.7.9.8.6.4.e164.arpa. with this content:

100 10 "u" "sip+E2U" "/^.*$/sip:info@tele2.se/" .

This sets these fields of the NAPTR record:

order = 100 
preference = 10 
flags = "u" 
service = "sip+E2U" 
regexp = "/^.*$/sip:info@tele2.se/" 
replacement = . 

After you configure these fields, the DNS client dealing with phone number +4689761234 can now find an SIP service URI by replacing the number with sip:info@tele2.se. The E.164 zone mostly uses the NAPTR record for wholesale replacement of the input telephone number. Section 3.2.3 of RFC 2916 includes an example of one transformation to a Lightweight Directory Access Protocol (LDAP) query that preserves some of the digits. The E.164 zone does not map to service location (SRV) records because it wants to obtain a SIP URL that is more humanly readable to the left of the at (@) symbol.


Step 1 In the Web UI, on the List/Add Zones page, click the View icon () in the Configuration RRs or Active Server RRs column.

Step 2 Enter the owner of the record in the Name field.

Step 3 Enter the TTL (if necessary).

Step 4 Click NAPTR in the Type drop-down list.

Step 5 Enter the data as a string embedded in quotes and separated by spaces:

a. Order

b. Preference

c. Flags

d. Service

e. Regular expression

f. Replacement string

For example:

"100 10 u sip+E2U /^.*$/sip:info@tele2.se/ ." 

Step 6 Click Add Resource Record.

In the CLI, use zone name addRR.

Step 7 Refresh the list if necessary.

Step 8 Reload the server.


Managing Hosts in Zones

You can manage the RRs for a host by configuring the host record rather than the individual RRs. When you define a host, an Address (A) record is created automatically for it. If the reverse zone for the host exists, the associated Pointer (PTR) can also be created automatically.

Adding Address, Canonical Name, and Pointer Records

In the regional and local cluster Web UIs, adding a host adds its A record, CNAME record, and, if you wish, its PTR record for the reverse zone (if it exists). By accessing the RRs for the host's zone, you can add additional RRs:


Step 1 In the Web UI, click Hosts. If there multiple zones, also click Zones, then click the name of the zone for which you want to add host records on the List Zones page. (If there is only one zone, the List/Add hosts for Zone page appears and the Zones tab is inactive.)

Step 2 On the List/Add Hosts for Zone page (see Figure 4-10 on page 4-20), enter the name of the host, optionally its alias name, and its IP address. If you want to create a corresponding Pointer (PTR) record (if the reverse zone exists), click a check mark in the Create PTR Records? box.

Step 3 Click Add Host.

In the CLI, to create a zone's A records, aliases, and PTR records for existing reverse zones in a single operation, use zone name addHost hostname address alias [alias] for each host.

Step 4 Click DNS, then Forward Zones to open the List/Add Zones page at the local cluster, or the List Forward Zones page at the regional cluster.

Step 5 Click the View icon () in the RRs column next to the name of the zone for which you want to add additional A records. This opens the List/Add CCM Server Protected RRs for Zone page or List/Add DNS Server RRs for Zone page. For an additional A record, add a hostname in the Name field, click A in the Type drop-down list, add an IP address for the host in the Data field, then click Add Resource Record.

In the CLI, to list the created hosts, use zone name listHosts .


Editing Hosts


Step 1 In the Web UI, click Hosts. If you get the List Zones page, click a zone name to open the List/Add Hosts in Zone page. If there is only one zone, this page opens immediately.

Step 2 Click the name of the host you want to edit, which opens the Edit Host page.

Step 3 You can edit the hostname or its IP address, or you can delete the host by using the Delete icon ().

Step 4 Click Modify Host.

In the CLI, you have to remove the host using zone name removeHost and add it again by using zone name addHost.


Removing Hosts

Removing a host removes only the A RRs for that host.

In the local cluster Web UI, on the List/Add Hosts in Zone page, click the Delete icon () next to the host that you want to remove, then confirm the deletion. You can also delete addresses for hosts on the Add Host and Edit Host page.

In the CLI, use zone name removeRR hostname A, then confirm the removal using zone name listHosts.