For deployments in which the GRM DNS server will handle all DNS queries for a content provider namespace, the GRM DNS server must assume the identity of the existing authoritative DNS nameserver. Masquerading as the authoritative DNS nameserver ensures that client DNS queries are ultimately resolved by the GRM DNS server. To achieve this configuration, you must assign the GRM DNS server the public IP address that was previously assigned to the authoritative DNS nameserver, or change the DNS hierarchy to point to the GRM DNS server IP address. The authoritative DNS nameserver must then be reconfigured with a new IP address.
After the GRM DNS server has assumed the identity of the back-end DNS nameserver, all DNS queries for domains associated with the CDN are resolved by the GRM DNS server. DNS queries for non-CDN domains and other DNS operations are proxied to the back-end DNS nameserver.
For example, consider a content provider that wants to redirect all requests for images.foo.com to the GRM DNS server. To achieve the redirection, the content provider defines images.foo.com in the GRM domain list on the GRM DNS server.
If the GRM DNS server receives a local DNS (LDNS) query for movies.foo.com, it determines whether movies.foo.com should be redirected. Because movies.foo.com has not been defined in the GRM domain list, the GRM DNS server proxies the query to the back-end DNS nameserver, which responds to the LDNS query.
When the GRM DNS server takes over the DNS services for a content provider, the number of content providers that the CDN hoster services is a determining factor for the best location for the GRM DNS server.
When the CDN hoster provides DNS services for only one content provider, the best solution is to deploy the GRM DNS server in the content provider's data center with the content provider's DNS nameserver.
The GRM DNS server is responsible for querying the appropriate back-end nameserver if the GRM DNS server does not redirect a particular FQDN. The GRM DNS server also informs the GRM agent caches about back-end DNS nameservers to use for resolving cache misses.
If a cache miss occurs, a GRM agent cache queries the same back-end nameservers if host-name rewriting is through DNS CNAME rewriting. Alternatively, if host-name rewriting is through NetCache accelerator rules, the GRM agent cache queries origin servers directly.
In this scenario, a content provider's DNS nameservers and the GRM DNS server are not collocated. The GRM DNS server is in the CDN hoster's data center. Each content provider continues to "own" its data. By pointing the GRM DNS server to a DNS nameserver in the content provider's location, the content provider's primary DNS nameserver does not need to send updates to the slave nameservers (the GRM DNS servers) in the data center in order to keep files synchronized.
The GRM DNS server is responsible for querying the appropriate back-end nameserver if the GRM DNS server does not redirect a particular FQDN. The GRM DNS server also informs the GRM agent caches about back-end DNS nameservers to use for resolving cache misses.
If a cache miss occurs, a GRM agent cache queries the same back-end nameservers if host-name rewriting is through DNS CNAME rewriting. Alternatively, if host-name rewriting is through NetCache accelerator rules, the GRM agent cache queries origin servers directly.
Note
Enabling the Iterative DNS feature and using it in combination with the Nameserver-to-Domain Mapping option reduces the query load on the back-end nameservers. These options are on the DNS - General page in the Appliance Manager (Setup tab > DNS > General).
The following table provides of an overview of the DNS-related steps required to complete GRM-related configuration if the GRM DNS server is taking over DNS for a content provider.
Copyright © 1994-2002, Network Appliance, Inc. All rights
reserved.
Part No. 210-00374
File: grmdns5.htm
Last updated: 11/12/02 17:45:14