c# .net pdf viewer : Add page number to pdf file control SDK platform web page wpf html web browser Ron%20Aitchison%20-%20Pro%20DNS%20and%20BIND%2010%20-%20201120-part1342

CHAPTER 8  DNS TECHNIQUES 
198 
@               IN   MX  10  mail.example.com. 
*               IN   MX  10  mail.example.com. 
Here, an MX query for bill.example.com, joe.example.com, and everythingelse.example.com will 
return the host mail.example.com. The following example shows how an existing RR will block the 
operation of the wildcard: 
; zone file for example.com 
$TTL 2d ; zone default = 2 days 
$ORIGIN example.com. 
@               IN   MX  10  mail.example.com. 
*               IN   MX  10  mail.example.com. 
subdomain   IN  MX  10  mail.example.net. 
As before, MX queries will return mail.example.com except queries for subdomain.example.com, 
which will return mail.example.net, and any undefined names below subdomain such as 
bill.subdomain.example.com will return NXDOMAIN (no name). 
The wildcard examples shown are terminal wildcards—the * is on the extreme left of the left-hand 
(owner) name. Non-terminal wildcards are legal, but usually the result of imprecise understanding of 
wildcard functionality. A non-terminal wildcard is where the * is not on the extreme left of the left-hand 
name; for example, joe.*.example.com is a non-terminal wildcard. BIND provides the check-wildcard 
(see Chapter 12) statement to check and warn of fail on non-terminal wildcards. 
A wildcard can’t do anything that can’t be done by one or more (perhaps many more) RRs. There is 
no essential reason to use wildcards other than to reduce the amount of data that may otherwise have to 
be defined. Whether this reduction in administrative effort is worth the potentially confusing effect of 
using wildcards in RRs is a matter for local decision. 
Zone File Construction 
This book takes a very formal approach to the design and construction of zone files. Some readers may 
even consider it excessively pedantic at times. This approach is adopted for reasons of safety. It is always 
good practice to add $ORIGIN directives, use FQDNs where sensible, and be long-winded rather that use 
cryptically short forms. This is partly because it makes sense to become thoroughly familiar with a 
subject before indulging in some of the more esoteric forms possible and partly because someone may 
have to try to understand a hieroglyphic zone file at 3 AM with a dark zone and a senior manager 
breathing down their neck. That someone may be you. 
However, it’s also fun to kick over the traces, break the rules, let your hair down, and rejoice in the 
vanity of incomprehensibility. Good judgment should be used to decide when this is practical, possible, 
or even desirable.  
As an example, this book insists in Chapter 7 that IPv4 and IPv6 loopback reverse maps should use 
distinct zone files. However, rules can be broken. The following single zone file may used to reverse map 
both the IPv4 and IPv6 loopback address: 
$TTL 86400 ; 24 hours 
@ IN SOA @ hostmaster (2010020800 12h 15m 1w 3h) 
@ IN NS localhost. 
1.0.0 IN PTR localhost. 
Since there is no $ORIGIN statement, it is synthesized as the zone name that appears in the 
named.conf file. For this file to work, the zone clauses for the IPv4 and IPv6 reverse-mapped loopback 
must be: 
Add page number to pdf file - insert pages into PDF file in C#.net, ASP.NET, MVC, Ajax, WinForms, WPF
Guide C# Users to Insert (Empty) PDF Page or Pages from a Supported File Format
add page to pdf reader; add page number to pdf print
Add page number to pdf file - VB.NET PDF Page Insert Library: insert pages into PDF file in vb.net, ASP.NET, MVC, Ajax, WinForms, WPF
Easy to Use VB.NET APIs to Add a New Blank Page to PDF Document
add and delete pages in pdf; add page number to pdf preview
CHAPTER 8 ■ DNS TECHNIQUES 
199
// named.conf fragment 
… 
zone “127.IN-ADDR.ARPA” in{ // IPv4 reverse loopback 
… 
zone “0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA” in{ // IPv6 reverse
loopback 
This example is presented to give the reader who is comfortable with the basics of zone files some
feel for the possibilities (or abuses) of zone file construction. Is it worth the saving of one file and
perhaps six lines of additional definition? Probably not. Is it fun? Definitely. 
Split Horizon DNS 
BIND 9’s view clause was introduced in Chapter 7 as an alternative method of providing a stealth server.
It has many other usages and this section introduces one more example to illustrate its potential power. 
The term split horizon is normally used to describe a name server that will give different responses
(IP addresses) based on the source address or some other characteristic of the query. While it has similar
configuration properties to the stealth server, it can be used in a variety of unique situations such as: 
Geographic mapping: If, for example, a web service is replicated in a number of
locations (for either performance or access latency reasons), then a specific IP
address may be returned based on the source address of the query to ensure the
shortest possible path from the user to the service. For those familiar with anycast
this could be considered a poor man's anycast service. 
Naming Consistency: Assume a corporate in-house LDAP service where highly
secure data is maintained on one server that is only accessible to certain
individuals or organizational sections, each of which have unique or identifiable
IP addresses or address ranges; all other users can access another server
containing only insecure data. For reasons of consistency (scripts, configuration
files, etc.), it’s required that both secure and insecure LDAP services be named,
say, ldap.example.com. 
Other possibilities may strike imaginative readers. The unifying element is that some characteristic
of the incoming query will cause the DNS to generate a query-dependent result. 
The BIND configuration provides the following functionality: 
1. Assume you want geographic users to get the lowest possible latency from a
web service with a name of www.example.com.  
2. Assume you have a single worldwide e-mail server called mail.example.com. 
3. Assume addresses 172.16.x.x originate in Mordor and you want them to be
serviced by a local web server (172.1.1.1) we have installed in the vicinity. 
4. Assume addresses 172.15.x.x and 172.14.x.x originate in Gondor and you want
them to be serviced by a local web server (17.2.1.1) we have installed in the
vicinity. 
5. All other originations will default to a www.example.com at 192.168.1.2. 
6. For simplicity, assume an authoritative-only server is being configured. 
C# PDF File Split Library: Split, seperate PDF into multiple files
If your page number is set as 1, then the two output PDF files will contains the first page and the later three pages Add necessary references:
adding page numbers to pdf document; add page to pdf preview
VB.NET PDF File Split Library: Split, seperate PDF into multiple
can split target multi-page PDF document file to one-page PDF files or PDF file to smaller PDF documents by every given number of pages Add necessary references
add page numbers pdf files; add page to pdf in preview
CHAPTER 8  DNS TECHNIQUES 
200 
The BIND 'named.conf' fragment is: 
// View based geographic name server for EXAMPLE, INC. 
// global options 
options { 
… 
recursion no;         // authoritative only 
}; 
… 
// map service to geographic origination 
view "gondor" { 
match-clients { 172.15/16; 172.14/16; }; // originate in gondor 
zone "example.com" { 
type master; 
// zone file will return www.example.com = 172.2.1.1 
file "view/gondor.example.com"; 
… 
}; 
}; // end view 
view "mordor" { 
match-clients { 172.16/16; }; // originate in mordor 
zone "example.com" { 
type master; 
// zone file will return www.example.com = 172.1.1.1 
file "view/mordor.example.com "; 
… 
}; 
}; // end view 
// default for everything else lies outside views 
zone "example.com" { 
type master; 
// zone file will return www.example.com = 192.168.1.2 
file "view/master.example.com"; 
… 
}; 
All the required zones must be declared in each view and for simplicity of configuration an 
authoritative-only server is assumed, which does not require root.servers, localhost or reverse 
mapping files. 
Queries that do not satisfy the match-clients statements fall through to use the default (outside view 
clause) zone file. If it is more understandable, the default zone could have been wrapped in a view clause 
with a name of, say, "default" using a match-clients { any; }; statement, as shown:  
// default for everything else lies in a default view 
view "default" 
match-clients { "any"; }; // must be in the last clause 
zone "example.com" { 
type master; 
// zone file will return www.example.= 192.168.1.2 
file "view/master.example.com.default"; 
}; 
}; 
C# PDF insert text Library: insert text into PDF content in C#.net
pageIndex, The page index of the PDF page that will be 0
add pages to pdf; add page numbers to a pdf file
C# PDF File & Page Process Library SDK for C#.net, ASP.NET, MVC
Highlight Text. Add Text. Add Text Box. Drawing Markups. PDF users to do multiple manipulations on PDF file and page Please note that, PDF page number starts from
add page number pdf; add page pdf reader
CHAPTER 8 ■ DNS TECHNIQUES 
201
The configuration uses the only the match-clients statement. Two other statements, match-
destination and match-recursive-only (neither of which is applicable in the example) may also be used 
to select which view is used. 
DNSBL (DNS Blacklists) 
DNS software simply translates a name to an address. That apparently simple fact has caused DNS 
software and specially constructed zone files to be used for a variety of non-DNS purposes, the most 
frequently used example of which is e-mail blacklists. Other exotic applications are discussed later in the 
section.  
services) to define 
the IP addresses or netblocks of well known sources of SPAM. DNSBL describes a method of using 
used to interrogate the blacklist that is organized as a conventional reverse mapping zone file (see 
Chapter 3). Assuming the blacklist is held at the domain name blacklist.example.com, the process 
works as follows: 
1. The receiving SMTP Agent extracts the IP address of the sending SMTP Agent; 
for example 192.168.2.135. 
2. 
135.2.168.192. 
3. 
name of 135.2.168.192.blacklist.example.com 
4. A DNS A RR query is issued to the domain name of 
135.2.168.192.blacklist.example.com 
5. 
address is in the blacklist) or an NXDOMAIN error (the IP address is not in the 
blacklist). 
6. For those IP addresses which appear in the blacklist, the DNSBL may optionally 
blacklisting. 
7. The fact that an A RRset is returned confirms that the queried IP address does 
appear in the specific blacklist. One or more A RRs may be returned, each of 
which will, by convention, lie in the IPv4 loopback range of 127/8 (127.0.0.1 - 
127.0.0.255). Each A RR address may have a specific meaning; it may be used as 
a return code and a representative example is shown later in this section. 
8.  IPv6 addresses may also be interrogated using such blacklists via the standard 
IPv6 reversed nibble process (see Chapter 5) and may be mixed in the same file 
as IPv4 addresses but will yield a brutally long name, as is illustrated in the 
example blacklist file below. Even when used with IPv6 addresses, an A query is 
still used to interrogate the DNSBL. 
DNSBL usage has now been defined in RFC 5782 which has INFORMATIONAL status. 
C# PDF Text Search Library: search text inside PDF file in C#.net
Add necessary references: Description: Search specified string from all the PDF pages. eg: The first page is 0. 0
add pdf pages together; adding pages to a pdf document
C# PDF delete text Library: delete, remove text from PDF file in
Add necessary references: RasterEdge.Imaging.Basic.dll. matchString, The string wil be deleted from PDF file, -. 0
adding page numbers to a pdf in preview; add page to a pdf
CHAPTER 8  DNS TECHNIQUES 
202 
Example blacklist zone file 
The following shows a blacklist zone file fragment: 
$TTL 2d # default RR TTL 
$ORIGIN blacklist.example.com 
IN      SOA   ns1.example.com. hostmaster.example.com.( 
2010080800 ; sn = serial number 
3h         ; refresh 
15m        ; retry = refresh retry 
3w         ; expiry 
3h         ; nx= nxdomain ttl 
IN      NS      ns1.example.com. 
IN      NS      ns2.example.com. 
# black list records - using origin substitution rule 
# order not important other than for local usage reasons 
2.0.0.127      IN      A 
127.0.0.2 
# black list RRs 
135.2.168.192  IN  A   127.0.0.2 # presence result 
IN  TXT "Optional - Some explanation for black listing" 
# the above entries expand to 135.2.168.192.blacklist.example.com 
... 
135.17.168.192 IN      A       127.0.0.2 # presence result 
... 
# IPv6 addresses may be mixed with IPv4 addresses in the same zone file 
result 
# Maps IPv6 address 2001:0db8:0000::1 
no inconsistency in this;  the returned address is simply a result value or code not a meaningful address. 
Note: An A RR for the address 127.0.0.2, by convention and RFC 5782, should always be present in any DNSBL 
system to allow for external testing and confirmation of operation. Bear in mind that spammers may also use this 
knowledge to mount DoS attacks on the DNSBL. 
Blacklist Return Addresses 
Many blacklist sites wish to provide some granularity in the results they return—specifically, one or 
more reasons why the IP address is in the DNSBL. There are two ways to do this. First, the IP address 
returned may be used to indicate the reason. If the IP is listed for more than one reason, multiple A RRs 
each with a different IP address can be used. Second, subdomains can be used to stream lists. Thus, the 
reversed IP address may be appended to a domain name open.blacklist.example.com to check for, say, 
an open SMTP relay or appended to, say, spam.blacklist.example.com to check for the presence of a 
C# PDF Text Highlight Library: add, delete, update PDF text
200F); annot.EndPoint = new PointF(300F, 400F); // add annotation to The string wil be highlighted from PDF file, 0
adding a page to a pdf in reader; adding page numbers to a pdf document
C# Word - Split Word Document in C#.NET
your page number is set as 1, then the two output Word files will contains the first page and the later three pages respectively. C# DLLs: Split Word File. Add
adding page numbers to pdf files; add pages to pdf acrobat
CHAPTER 8 ■ DNS TECHNIQUES 
203
known spam source. While the later method may appear to require more queries, typically the context of 
the query will limit the actual number. Thus, in this example if a receiving MTA wishes to check for a 
known spam source, only one query is actually required. Indeed, some DNSBL providers even combine 
both approaches by using a specific address as a result code but place all entries in all subdomains. In 
this case, the validating MTA must carefully process or filter the results or use them in some form of 
weighting system. 
There is no standard, or even consensus, on usage of either subdomain names or the address(es) 
returned by the DNS A RR query other that it lies in the netblock 127/8 (127.0.0.0 - 127.255.255.255) and 
must exclude 127.0.0.1 (to avoid confusion with the real loopback address). In most cases, e-mail 
software that uses DNSBL access will return a failing code if any address is returned (the IP is in the list). 
When reviewing a number of DNSBL web sites to obtain the value of return addresses, there were no 
obvious patterns and RFC 5782 is silent on the issue.  
The following is the meaning of the returned address(es) when using the SORBS blacklist 
(www.au.sorbs.net/using.shtml) and is presented only as an illustrative example: 
127.0.0.2  - Open HTTP Proxy Server (http.dnsbl.sorbs.net) 
127.0.0.3  - Open SOCKS Proxy Server (socks.dnsbl.sorbs.net) 
127.0.0.4  - Open Proxy Server not listed in the SOCKS or  
HTTP lists. (misc.dnsbl.sorbs.net) 
127.0.0.5  - Open SMTP relay server (smtp.dnsbl.sorbs.net) 
127.0.0.6  - Hosts sending spam/UCE/UBE to SORBS, netblocks  
127.0.0.7  - Web servers email vulnerabilities (e.g. FormMail scripts) 
(web.dnsbl.sorbs.net) 
.net) 
127.0.0.10 - Dynamic IP Address ranges (dul.dnsbl.sorbs.net) 
127.0.0.12 - Domain names with no emai originating (nomail.rhsbl.sorbs.net)  
In this list, the name associated with each IP address (for example, block.dnsbl.sorbs.net) refers to 
a subdomain to which the target IP address may be appended and which will yield the corresponding 
IPv4 address code. 
Since DNSBLs are zone files, they may be transferred using normal zone transfer methods 
(AXFR/IXFR – see Chapter ), assuming the provider enables such a service. This offers a relatively simple 
method of distributing updates and reducing loads. Thus, to slave a local copy of a DNSBL from 
blacklist.example.com at IP address 192.168.2.23 would simply require a slave zone to be incorporated 
into the local named.conf file: 
// local named.conf 
… 
zone “blacklist.example.com”{ 
type slave; 
file “slave/blacklist.example.com” 
masters {192.168.2.23;}; 
notify no; // inhibits notify propagation 
… 
CHAPTER 8  DNS TECHNIQUES 
204 
Additional Usage 
While the terminology—DNSBL—defines the above to be a blacklist, there’s nothing to stop such a zone 
file being used as, say, a whitelist to speed up handling of incoming mail by using the SMTP Agent's IP 
addresses. Always assuming your favorite mail software will support such a concept and format. 
Furthermore, by prepending domain names or full e-mail addresses, such a whitelist may be even more 
useful. For example, assume the following zone file fragment for whitelist.example.com: 
$TTL 2d # default RR TTL 
$ORIGIN whitelist.example.com 
... 
# whitelist records - using origin substitution rule 
# order not important other than for local usage reasons 
       
2.0.0.127      IN      A 
127.0.0.2 
# white list RRs 
IN      TXT     "Optional - Some explanation for white listing" 
# the above entries expand to 135.2.168.192.blacklist.example.com 
... 
135.17.168.192 IN      A       127.0.0.2 # generic list 
... 
# name based RRs for white listing 
friend.com     IN      A       127.0.0.1 # all domain email addresses 
# expands to friend.com.whitelist.example.com 
joe.bigbank.my      IN      A       127.0.0.2 # single address 
# expands to joe.bigbank.my.whitelist.example.com 
... 
In this file, the e-mail address joe@bigbank.com replaces @ with a dot before issuing an A query in a 
manner similar to that used in the SOA RR email field. Thus, the resulting A query will be for 
joe.bigbank.my.whitelist.example.com. 
No known implementations of such a whitelist system exist. It is presented simply to provide 
imaginative readers with possible addition uses of DNS. Vouch By Reference (RFC 5518) outlines a 
scheme using TXT RRs, rather than the A RRs described here, to provide reputation information for a 
variety of named entities. Those of a curious disposition may find this RFC yields some more interesting 
ideas. 
DNS TTLs and Time Values 
The DNS TTL field on each RRset is used exclusively by resolvers (recursive or caching name servers) to 
discard expired records from their caches. DNS TTL values reflect a balance between three issues: 
1. DNS load: The lower the TTL, the more frequently the authoritative name 
server (and possibly the DNS hierarchy) is accessed. If the TTL is not carefully 
chosen, DNS reliability may become more important than the reliability of, say, 
the corporate web server—not a particularly desirable outcome. 
CHAPTER 8 ■ DNS TECHNIQUES 
205
2. DNS Changes: The lower the TTL, the quicker changes will propagate through 
various external caches. Conversely, the longer the TTL, the longer invalid 
records may be maintained in external caches.  
3.   Cache poisoning: Every query from a resolver to the authoritative name server 
also offers a DNS poisoning possibility. Simply stated, the longer the TTL, the 
ay be 
poisoned. 
These are competing and mutually exclusive requirements, thus any TTL value is always a trade-off. 
While the $TTL directive is very convenient for creating a zone-wide TTL value, it’s not always 
appropriate. To paraphrase George Orwell, all RRs are equal but some RRs are more equal than others. 
The group of RRs at the zone apex (or root)—SOA, NS, and MX RRs—are frequently and collectively 
referred to as the infrastructure RRs. These RRs have different properties than those of address RRs—
such as A/AAAA RRs—in that they involve multiple DNS queries. The first query will read, say, the MX 
RRset and subsequent queries will return the A (or AAAA) RR(s) of the names pointed to in the MX RRset, 
similarly with NS RRs. 
How frequently does the name of the infrastructure servers, such as name servers or mail servers, 
change? The server's IP address(es) (the A or AAAA RRs) will likely change—perhaps even very 
frequently—but their names? Thus, the MX RRs could run with a TTL of multiple weeks while the 
A/AAAA RR(s) may run with only hours. The net effect of even this trivial strategy would be to reduce the 
load on authoritative name servers significantly.  
Note DNS simply translates a name to an IP address. It does not know, or care, what is returned by the 
hostname
command for the host at that IP address. Thus, if an authoritative name server for the domain 
example.com
is hosted at 192.168.2.1, it can be defined as, say, 
ns1.example.com
in an NS RR even if its 
hostname
is, say, 
superfast.example.com
. The A RRs for 
ns1.example.com
and, if required, 
superfast.example.com,
will both point to the same IP. If this double A RR definition offends, then a dreaded 
CNAME RR could be used to achieve the same goal. The point is that NS RRs can stay stable while only the 
corresponding A RRs change. 
It is inappropriate to think of a single domain TTL; rather, think in terms of an appropriate TTL 
value for the major RRs and RR groups. Table 8–3 discusses both TTLs and other DNS time values. 
Table 8–3. TTLs and Other DNS Time Values 
SOA RR
The only value in the SOA that normally changes is the serial number. However, the 
cached copy of the zone’s SOA has an incorrect serial number there are no negative 
implications. If DDNS is being used, the primary master referenced in the SOA is used 
to confirm which DNS to update, and if this name is likely to change, the TTL value 
may need to be lower than would otherwise be desirable. TTL values of 2-7 days (or 
perhaps significantly longer) may be appropriate for this RR. 
CHAPTER 8  DNS TECHNIQUES 
206 
SOA Refresh
The refresh parameter of the SOA RR defines when the slave will read the master's 
SOA and compare its current serial number with that received from the master. If it 
can’t reach the master, the slave will continue to service the domain until the expiry 
value is reached. If NOTIFY is being used, there is little merit in setting refresh to 
anything but 12-24 hours, perhaps even longer, since its only real use is in cases where 
the NOTIFY was lost or blocked. If NOTIFY is not being used, then this value will 
determine the rate at which zone changes are propagated and should be set to, 
perhaps, 1 to 6 hours.
SOA Expiry
The expiry parameter of the SOA RR defines when the slave will stop responding to 
zone requests if it cannot reach the master and has a significant effect on overall DNS 
availability. Setting this to a very high value (2+ weeks) will ensure that even if the 
master name server is out for an extended period, DNS service will continue for the 
zone using the zone slave copies. 
NS RR
NS RRsets simply point to the name of the authoritative servers for the domain and 
thus can be made very stable. If the host of a name server changes, this will require a 
7 days, perhaps even weeks, are appropriate. In the event that an NS change is 
required (for example, changing to an external DNS supplier), this would typically be 
transition period would probably be a wise move before restoring to a very high value 
after the change.
MX RR
The MX RR is similar to the NS RR in that it simply provides the name of the mail 
advantage in having anything but long TTLs (typically weeks) for MX RRs. The 
preference parameter of the MX RR provides for resilience, not the TTL. Again, if mail 
servers are to be changed (as opposed to their A/AAAA RRs), this will typically be a 
planned activity and changing the TTL to a lower value (hours) during the transition 
A/AAAA RR
increased load. The most charitable explanation for low TTLs may be for fast fail-over 
in the event of catastrophic server failure. This needs some examination. Both NS and 
MX RRs provide for alternative forms of resilience and can be discounted. In the case 
where TCP services are provided by hosts (for example, FTP or HTTP), then TCP error 
recovery, which typically takes around 1 minute 30 seconds or longer, will be invoked 
before a client is even aware of the problem. Multiple A/AAAA RRs can result in a very 
fast automatic roll-over and is completely independent of the TTL value. Not all 
software supports the use of multiple A/AAAA RRs but all the major web browsers and 
many tested FTP clients do. In cases where a single IP address may need to be 
replaced quickly, a TTL value of 900-1800 (15-30 minutes) is really the lowest sensible 
value imaginable. Otherwise, the TTL should be set to the acceptable propagation 
delay, say, 2-12 hours or higher.
CHAPTER 8 ■ DNS TECHNIQUES 
207
SRV/NAPTR RR
These two RRs are similar in characteristic to infrastructure RRs in that they define a 
days) are appropriate.
TXT/SPF RR
The SPF RR may contain a mixture of names and IP addresses. If using explicit IP 
addresses within the record definition, it has properties similar to the A/AAAA RR 
above. If only names are used, the properties are those of the infrastructure RRs (NS, 
MX, SOA).
TXT/DKIM RR 
The DKIM TXT RR contains the public key used to authenticate incoming mail. Such 
public keys may be compromised or rolled over (replaced) periodically. The safest 
approach is to change the DKIM selector value and create a new DKIM TXT RR at this 
new name with the new public key (see the DKIM section earlier in this chapter). In 
even longer. If changing the selector value is not practical, then the TTL needs to be 
set to an acceptable value during which invalid mail may be accepted as valid mail. 
Google’s Gmail, as an example, uses a TTL value of 300 (5 minutes) on its DKIM TXT 
RR. 
DNSSEC RRs 
The TTL values used with DNSKEY RRs particularly are significant in the context of 
key maintenance for DNSSEC. This is discussed in-depth in Chapter 11. 
RFC 1912 also provides useful advice on the above issues, as well as others, and is well worth the 
reader’s time investment. Finally, since there are usually more A (or AAAA) RRs in a zone and they are 
most likely to change frequently, default all these to the $TTL value for the zone and use explicit 
overrides on all other RR types. Minimum typing, maximum flexibility—can life get any better? 
Summary 
This chapter covered a number of common name server configurations and also illustrated some more 
subtle uses of the DNS system. The next chapter describes the use of various DNS diagnostic tools and 
techniques to cover the situations when head-scratching fails to yield the required results. 
Documents you may be interested
Documents you may be interested