c# : winform : pdf viewer : Adding pages to a pdf document in preview software application project winforms windows html UWP Ron%20Aitchison%20-%20Pro%20DNS%20and%20BIND%2010%20-%20201148-part1372

CHAPTER 12 ■ BIND 9 CONFIGURATION REFERENCE 
481
Table 12–13. Type Statement Values 
Value 
Description 
master 
The server has a master copy of the zone data (which is loaded from a local filestore) 
and provides authoritative answers for the zone. 
slave 
A
(not timed out) zone data. The masters statement specifies one or more IP addresses of 
When the TTL specified by the refresh parameter of the zone’s SOA RR is reached or a 
NOTIFY message is received, the slave will query the SOA RR from the zone master. If 
the sn parameter (serial number) is greater than the current value, a zone transfer is 
expiry 
value is reached, it will stop responding for the zone. Authentication of the master can 
also be done with per-server TSIG keys (see the entry for the masters statement 
changed using the masters statement. If a file statement is defined, the zone data will 
be written to this file whenever the zone is changed and reloaded from this file on a 
server restart. If no file statement is defined, the slave will require a zone transfer from 
permitted to transfer zones if requested and are subject to any controlling allow-
transfer statements. 
forward 
A zone of type forward is simply a way to configure forwarding, perhaps to a unique 
name server, on a per-domain or per-zone basis. To be effective, both a forward and 
forwarders statement should be included. If no forwarders statement is present or an 
empty list is provided, no forwarding will be done for the domain, canceling the effects 
of any forwarders in the global options clause. 
hint 
uses the hint’s zone file to find a root name server and get the most recent list of root 
name servers. If no hint zone is specified for class IN, the server uses a compiled-in 
default set of root servers. Classes other than IN have no built-in default hints. The hint 
zone is only required for a name server that provides recursive services or a master or 
for the zone. 
stub 
A stub zone is similar to a slave zone except that it replicates only the NS records of a 
DNS—they are a feature specific to the BIND implementation and should not be used 
in general. 
delegation-only This indicates that only referrals (or delegations) will be made for the zone; it’s 
recommended only for use with TLDs, not leaf (non-TLD) zones. The generation of 
referrals in leaf zones is determined by the use of the delegation-only statement and 
the RRs contained in the zone file; that is, a zone consisting of an SOA RR, NS RRs, and 
glue records will only be able to generate referrals (see also Chapter 9). 
Adding pages to a pdf document in preview - 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 to pdf preview
Adding pages to a pdf document in preview - 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 document to pdf pages; add a page to a pdf document
CHAPTER 12 ■ BIND 9 CONFIGURATION REFERENCE 
482 
Summary 
This chapter is a reference for the command-line options used when BIND is loaded and for all the
entities used in a named.conf file—the file that controls the detailed behavior of BIND. 
The named.conf file statements were defined to be of three types—comments, clauses, or
statements. This book rigorously uses the term clause to refer to a collection or group of statements in
the interest of clarity and consistency. Much BIND documentation uses a variety of terms such as
sectionsclausesstatementsoptions, and phrases to define the two entity types (excluding comments)
contained in the named.conf file. Advanced readers may well be comfortable with different terms being
applied to the same type of entity or, even worse (but depressingly frequent), the same term being
applied to completely different entities. Such an environment, however, is neither edifying nor
conducive to creating safe, error-free BIND configurations—the ultimate objective of this book. The
terms were selected after consulting Merriam-Webster Online and BIND’s source code. 
The available clauses are listed alphabetically in Table 12–3. Statements are listed alphabetically in
Table 12–5, together with very short descriptions and categorization. The individual statements are then
described in detail in alphabetic order within each category, with a simple example in every case and
more complex examples where appropriate. It is hoped that such categorization will allow the reader to
dip into the specific section required and also to allow browsing of statements when looking to control
or affect the behavior of similar types of operations such as queries. Many statements can be used in
more than one clause; Table 12–6 lists each statement alphabetically and the clauses in which it can be
used. 
The next chapter contains reference material on zone files and the directives and RRs that may be
used in them. 
C# PDF insert image Library: insert images into PDF in C#.net, ASP
picture, digital photo, scanned signature or logo into PDF document page in this technical problem, we provide this C#.NET PDF image adding control, XDoc
add page numbers to pdf in preview; add page numbers to pdf document in preview
C# PDF insert text Library: insert text into PDF content in C#.net
Supports adding text to PDF in preview without adobe reader installed Ability to change text font, color, size and location and output a new PDF document.
add pages to pdf in preview; adding page to pdf
C H A P T E R   13 
■ ■ ■ 
483
Zone File Reference 
This chapter is intended to be a reference for zone file directives and resource records. Table 13–1 
contains a list of all current RRs defined by IANA (www.iana.org/assignments/dns-parameters), their 
support status within BIND and Windows DNS software, the RFCs that define them, and a very brief 
description of the RR type. This provides you with a quick overview of the formidable list of RRs available 
and will enable you to browse them more effectively. This chapter features descriptions of the syntax for 
each directive and resource record; in most cases their use is illustrated with one or more examples. 
RRs have two representations: a textual form, in which they appear in a zone file as described in this 
chapter, and a binary format, also called the wire format, used when one or more RRs are transmitted in 
a query, query response, or similar network operation. The binary format of RRs is defined in Chapter 15. 
The following section reviews the zone file format rules and is then followed by material on the zone file 
directives and finally the resource records descriptions. 
DNS Zone File Structure 
Zone files describe a domain’s characteristics—the hosts and services supported—in a form that may be 
used by DNS software. The files are textual and may be read or edited using any standard text editor. 
They can contain three types of entries: 
1. Comments: All comments start with a ; (semicolon) and continue to the end of 
the line. Comments can occupy a single line or be added to any of the following 
record types. 
2. Directives: All directives start with $ and are used to control processing of the 
zone files. 
3. Resource Records: RRs are used to define the characteristics, properties, or 
entities contained within the domain or zone. RRs are contained on a single 
line with the exception that entries enclosed in parentheses can spread across 
multiple lines. 
The following is a zone file fragment that illustrates the preceding points and record types: 
; this is a full-line comment 
$TTL 12h    ; directive - comment terminates the line 
$ORIGIN example.com. 
; Start of Authority (SOA) record defining the zone (domain) 
; illustrates an RR record spread over more than one line 
; using the enclosing parentheses 
@  IN  SOA  ns1.example.com. hostmaster.example.com. ( 
2010121500 ; sn = serial number 
3h         ; ref = refresh 
VB.NET PDF insert text library: insert text into PDF content in vb
Visual Studio .NET PDF SDK library supports adding text content to adobe PDF document in VB Add text to PDF in preview without adobe reader component
add pages to pdf online; add page number pdf
C# Create PDF Library SDK to convert PDF from other file formats
more, you can also protect created PDF file by adding digital signature following example will tell you how to create a PDF document with 2 empty pages.
add blank page to pdf preview; add page to pdf online
CHAPTER 13  ZONE FILE REFERENCE 
484 
15m        ; ret = refresh retry 
3w         ; ex = expiry 
3h      ; nx = nxdomain ttl 
; single line RR 
IN  NS  ns1.example.com. ;with a comment 
... 
You can also write the preceding SOA RR a single line, in which case there’s no need for the 
parentheses: 
@  IN  SOA  ns1.example.com. hostmaster.example.com. 2003080800 3h 15m 3w 3h 
If parentheses are used, the ( (open parenthesis) must appear on the first line. 
DNS Directives 
Zone file directives control the processing of zone files. There are three standardized directives: $TTL, 
$ORIGIN, and $INCLUDE (RFC 1035). A fourth directive, $GENERATE, is supported by BIND but is not 
standardized. 
The 
$ORIGIN
Directive 
The $ORIGIN directive was standardized in RFC 1035 and defines the domain name that will be appended 
to any name that appears in an RR and does not end with a dot—frequently called a relative or an 
unqualified name—to create a fully qualified domain name (FQDN). This process is called the $ORIGIN 
substitution rule throughout this book. 
The $ORIGIN Substitution Rule 
If a name appears in a Resource Record and does not end with a dot, then the value of the last, or only, 
$ORIGIN value will be appended to the name. If the name does end with a dot, then it is a fully qualified 
domain name and nothing will be appended to the name. The terminating dot in an FQDN is 
interpreted as the root of the domain tree or hierarchy. An FQDN unambiguously defines a name to the 
root. 
$ORIGIN Syntax 
$ORIGIN domain-name 
domain-name is usually an FQDN—it ends with a dot—to avoid confusion. However, it obeys the normal 
rules of $ORIGIN substitution if it does not end in a dot. The “Define a DKIM Record” section in Chapter 
8 shows an example of non-FQDN usage.  $ORIGIN directives can appear anywhere in a zone file and will 
be used from the point they are defined onwards until replaced with another $ORIGIN, like so: 
$ORIGIN example.com. 
; unqualified names from here will append example.com. 
www              IN  A 192.168.2.2 ; unqualified 
; www expands to www.example.com. 
... 
ftp.example.com. IN A 192.168.2.3 ; FQDN 
C# Word - Insert Blank Word Page in C#.NET
Word document pages and how to split Word document in C# .NET class application. By using reliable APIs, C# programmers are capable of adding and inserting
add page numbers pdf file; add pages to pdf file
C# PowerPoint - Insert Blank PowerPoint Page in C#.NET
PowerPoint document pages and how to split PowerPoint document in C# .NET class application. By using reliable APIs, C# programmers are capable of adding and
add and delete pages in pdf; adding pages to a pdf document in preview
CHAPTER 13 ■ ZONE FILE REFERENCE 
485
... 
$ORIGIN us.example.com. 
; unqualified names from here will append us.example.com. 
www              IN  A 192.168.254.2 ; unqualified 
; www expands to www.us.example.com. 
... 
The $ORIGIN directive is not mandatory. If an $ORIGIN directive is not present, BIND will assume that 
the $ORIGIN value is the name of the zone clause that defines the zone file in named.conf (described in 
Chapter 12). This book always uses $ORIGIN directives in zone files for three reasons: 
1. With the $ORIGIN directive present, a zone file is self-descriptive and self-
contained; it requires no reference to any external information. 
2. The $ORIGIN substitution rule (defined previously) is much less confusing. The 
value to be substituted is immediately apparent—the last $ORIGIN directive. 
3. Not all software may use the same default assumptions about the $ORIGIN 
directive as does BIND. Zone files are more portable when the $ORIGIN directive 
is included. 
Tip For a further insight into the use of the $ORIGIN directive, have a look at a zone file on a slave server after 
the zone file has been transferred (assuming the 
file
statement was used in the slave definition). You will see 
that BIND 9 constructs its zone files with an $ORIGIN directive at every level of the hierarchy. 
The 
$INCLUDE
Directive 
The $INCLUDE directive allows inclusion in situ of an external file containing additional directives or RRs. 
It’s typically used in maintenance of larger zone files; that is, individual parts of a single zone file can be 
modified by clients without exposing the global parameters or other client parts to either inspection or 
corruption. Alternatively, it can be used to add RRs to a zone file that were created externally such as KEY 
or DNSKEY RRs generated by the dnssec-keygen utility for use in secure DNS operations. Unlike the 
include statement used in the named.conf file, which is typically used to secure sensitive (private) keys, 
there is no corresponding need for the $INCLUDE in the zone file—any keys appearing in a zone file will 
always be public. This directive is standardized in RFC 1035. The RFC is silent on the topic of embedded 
$INCLUDE directives in the included files, so to err on the side of safety they should not be used. 
$INCLUDE Syntax 
$INCLUDE filename [domain-name] 
The filename parameter may be an absolute path (for example, /absolute/path/to/file) or a relative 
path (for example, relative/path/to/file). If the relative path format is used, then the base directory is 
assumed to be the same location as the zone file. The optional domain-name parameter may be used to set 
an explicit $ORIGIN to be used in the included file; however, an included file can also contain one or more 
$ORIGIN directives as shown in the fragments that follow. The scope of $ORIGIN directives when used with 
an included file is limited to the included file only. On termination of the include operation, the value of 
$ORIGIN is restored to the value before the $INCLUDE directive. 
C# PowerPoint - How to Process PowerPoint
programmed in C# class to develop user-defined PowerPoint slide adding and inserting It enables you to move out useless PowerPoint document pages simply with a
add page numbers to pdf online; adding page numbers pdf file
C# TIFF: TIFF Editor SDK to Read & Manipulate TIFF File Using C#.
APIs to process Tiff file and its pages, like merge to Tiff, like Word, Excel, PowerPoint, PDF, and images. assemblies into your C# project by adding reference.
add pages to pdf document; add page pdf
CHAPTER 13  ZONE FILE REFERENCE 
486 
The first zone file fragment shows an included file with no $ORIGIN directives. In this case, the 
included file will use the current $ORIGIN directive in operation at the point of inclusion, like so: 
$ORIGIN us.example.com. 
... 
mail       IN      A   192.168.35.12 
; expands to mail.us.example.com. 
$INCLUDE /var/named/zones/sub.example.com ; absolute path no $ORIGIN 
ftp        IN      A   192.168.35.16 
; expands to ftp.us.example.com. 
The following fragment shows expansion of the /var/named/zones/sub.example.com include file: 
; INCLUDE file statements 
www       IN       A  192.168.23.15 
; expands to www.us.example.com 
... 
; end of included file 
The following fragment shows the use of an explicit $ORIGIN on the $INCLUDE directive: 
$ORIGIN us.example.com. 
... 
mail       IN      A   192.168.35.15 
; expands to mail.us.example.com. 
$INCLUDE sub.example.com uk.example.com. ; overrides current $ORIGIN 
; $ORIGIN reverts to value before the $INCLUDE directive 
ftp        IN      A   192.168.35.16 
; expands to ftp.us.example.com 
The included fragment in sub.example.com uses the explicit $ORIGIN on the $INCLUDE directive: 
; INCLUDE file statements 
www       IN       A  192.168.23.15 
; expands to www.uk.example.com 
... 
; end of included file 
The following fragments achieve the same result as the previous ones but may be less confusing 
because of the explicit use of an $ORIGIN directive in the included file: 
$ORIGIN us.example.com. 
... 
mail       IN      A   192.168.35.15 
; expands to mail.us.example.com. 
$INCLUDE sub.example.com ; no $ORIGIN 
; $ORIGIN reverts to value before the $INCLUDE directive 
ftp        IN      A   192.168.35.16 
; expands to ftp.us.example.com 
The included fragment uses an explicit $ORIGIN directive: 
; INCLUDE file statements 
$ORIGIN uk.example.com. 
www       IN       A  192.168.23.15 
; expands to www.uk.example.com 
... 
; end of included file 
VB.NET PDF insert image library: insert images into PDF in vb.net
supports inserting image to PDF in preview without adobe This smart and mature PDF image adding component of RasterEdge VB.NET PDF document processing SDK
add page number to pdf print; add page number to pdf online
CHAPTER 13 ■ ZONE FILE REFERENCE 
487
The preceding fragment is self-contained and self-descriptive. 
The 
$TTL
Directive 
Every resource record may take an optional Time to Live (TTL) value specified in seconds. The $TTL 
directive was standardized in RFC 2038 and defines the default TTL value applied to any RR that does 
not have an explicit TTL defined. TTL in the context of DNS means the time in seconds that a record may 
be cached (stored) by another name server acting as a resolver. (Caching is explained in Chapter 4.) 
$TTL Syntax 
$TTL time-in-seconds 
The following shows a typical $TTL directive: 
$TTL 172800 ; 2 days 
BIND provides a short format to allow the time value to be written without resorting to a calculator 
or some strenuous mental arithmetic. The case-insensitive values are m = minutes, h = hours, d = days, w = 
weeks. This book uses the standard BIND short format throughout simply to make the time values easy 
to understand quickly. While most DNS software has adopted the BIND short form convention, it’s not 
universal; and if zone files are to be ported between BIND and other DNS software, the short forms 
should be used with care. The preceding $TTL could be written in any of the following forms when using 
the BIND short format: 
$TTL 2d 
$TTL 48h 
$TTL 2880m 
$TTL 1d24h 
The time-in-seconds value may be in the range 0, which indicates the record should never be 
cached, to a maximum of 2147483647 (roughly 68 years). The current best practice recommendation 
(RFC 1912) suggests a value greater than one day; on RRs that rarely change, longer values should be 
considered. This book typically uses a $TTL value of 172800 (2 days), which represents a reasonable 
balance between name server load and speed of change. The “ DNS TTL and Time Values” section in 
Chapter 8 describes other considerations that may affect TTLs in certain RR types.  
The $TTL directive must appear before any RR to which it will be applied and for that reason it is 
normally defined at the beginning of the zone file. A $TTL directive continues in force until superseded 
by another $TTL directive. 
Note In older versions of BIND (prior to BIND 9), the default $TTL was defined in the SOA RR (described later in 
this chapter), which reflected the standards then in force. RFC 2308 defines both implementation of the $TTL 
directive and the revised use of the last field (previously known as the min field) in the SOA RR to mean the 
NXDOMAIN (negative) caching time and is commented throughout this book as nx = nxdomainttl to reflect current 
usage. 
CHAPTER 13  ZONE FILE REFERENCE 
488 
The 
$GENERATE
Directive 
The $GENERATE directive is BIND-specific and should not be used if zone files will be ported between 
BIND and other RFC-compliant DNS software. 
$GENERATE is provided to ease generation of repetitive sequences of RRs. Only NS, PTR, A, AAAA, 
DNAME, and CNAME RRs are supported. The most obvious use for $GENERATE is when creating zone files 
used in delegation of reverse subnet maps. The reverse-map zone files involve a series of RRs that 
increment by a single value. The following fragment shows an extract from the reverse delegation zone 
file described in Chapter 8: 
$ORIGIN 199.168.192.IN-ADDR.ARPA. 
..... 
65            IN  CNAME   65.64/26 
66            IN  CNAME   66.64/26 
67            IN  CNAME   67.64/26 
.... 
125           IN  CNAME   125.64/26 
126           IN  CNAME   126.64/26 
The following $GENERATE directive would create the preceding full sequence: 
$GENERATE 65-126 $ CNAME $.64/26 
$GENERATE Syntax 
$GENERATE start-stop[step] lhn type rhn 
In the $GENERATE syntax, start is the starting value of the generated sequence and stop is the ending 
value. step is optional and indicates the value to be added on each iteration; if omitted, 1 is assumed. lhn 
indicates the value of the left-hand name. An lhn value of $ indicates the current iteration value that will 
be substituted as shown in the example. The type field is the RR type, and only CNAME, NS, A, AAAA, 
DNAME, and PTR are supported. rhn is the left-hand name; again, $ indicates the current iteration value 
will be substituted. The rhn and lhn values will have normal $ORIGIN substitution rules applied. 
The corresponding PTR records used in normal reverse-map zone files will typically have unique 
host names that can’t be used with the $GENERATE directives; for example, bill, fred, www, etc. do not have 
an iterator relationship, but if host names were sequentially numbered, such as PC65 to PC126, the 
$GENERATE directive could be applied to them. Occasionally one wishes life was that simple! 
DNS Resource Records 
A large number of resource records have been defined over the life of the DNS specifications. These RRs 
are of two types: real RRs (for want of any better terminology) that appear in a zone file, and meta (or 
pseudo) RRs that only appear in the QUESTION SECTION or ADDITIONAL SECTION of queries (see Chapter 
15). Table 13–2 describes the meta (or pseudo) RRs. Table 13–1 shows the currently assigned RRs (they 
appear in zone files) from IANA (www.iana.org/assignments/dns-parameters) and their current support 
status in BIND and Windows DNS (Windows Server 2008 R2). The code column identifies the RR type, 
which is used only in the binary format when the RR is transmitted and does not appear in the text 
version of the RR; it’s provided for information and cross-referencing purposes only. Table 13–1 also 
shows the documentation status in this book (Reference column). The RRs are shown in alphabetic 
order for convenience. 
CHAPTER 13 ■ ZONE FILE REFERENCE 
489
Table 13–1. Resource Record Status 
RR Name 
Code Reference BIND Windows Specification 
Notes 
Yes 
Yes 
Yes 
RFC 1035 
Forward map. Host to 
IPv4 address. 
A6 
38 
Yes 
Yes 
No 
RFC 2874 
Experimental. Forward 
map. Host to IPv6 
address. 
AAAA 
28 
Yes 
Yes 
Yes 
RFC 3596 
Forward map. Host to 
IPv6 address. 
AFSDB 
18 
Yes 
Yes 
Yes 
RFC 5864, 1183 AFS Database location. 
APL 
42 
Yes 
Yes 
No 
RFC 3123 
Experimental. Stands 
for Address Prefix Lists. 
Supplies lists of IP 
addresses for any 
required purpose. 
ATMA 
34 
Yes 
No 
No 
None 
Private. Stands for ATM 
Address. Defined by the 
ATM forum (document 
reference af-saa-
0069.000.pdf). 
CERT 
37 
Yes 
Yes 
No 
RFC 4398 
CERT RRs define 
various security 
certificate formats, such 
as X.509, for storage in 
the DNS. 
CNAME 
Yes 
Yes 
Yes 
RFC 1035 
Stands for Canonical 
Name (Alias). Maps an 
alias name to another 
name. 
DHCID 
49 
Yes 
Yes 
No 
RFC 4701 
Used by DCP Servers to 
ensure only a single 
host can update A or 
AAAA RRs. 
DLV 
32769 Yes 
Yes 
No 
RFC 4431 
Functionally equivalent 
to DS, used by DNSSEC 
in alternative trust 
chains  
DNAME 
39 
Yes 
Yes 
No 
RFC 2672, 4592 Experimental. Used for 
reverse-map delegation, 
especially IPv6. 
CHAPTER 13  ZONE FILE REFERENCE 
490 
RR Name 
Code Reference BIND Windows Specification 
Notes 
DNSKEY 
48 
Yes 
Yes 
Yes 
RFC 4034 
DNSKEY RRs define the 
public key used in 
DNSSEC operations 
only. The KEY RR is used 
for all other public keys. 
DS 
43 
Yes 
Yes 
Yes 
RFC 4034 
Delegation Signer RRs 
are only used in 
DNSSEC operations 
and are placed in 
parent zones at the 
point of delegation to a 
child zone to create 
chains of trust. 
EID 
31 
No 
No 
No 
None 
Private RR. Stands for 
Endpoint Identifier. 
GPOS 
27 
No 
Yes 
No 
RFC 1712 
Stands for Geographical 
Position. Made obsolete 
by LOC RR. 
HINFO 
13 
Yes 
Yes 
Yes 
RFC 1035 
Textual host OS and 
hardware description. 
HIP 
55 
Yes 
Patch No 
RFC 5205 
Host Identity Protocol 
IPSECKEY 
45 
Yes 
No 
No 
RFC 4025 
IPSECKEY RRs define 
keys and other 
properties used in IPSec 
operations. 
ISDN 
20 
Yes 
Yes 
Yes 
RFC 1183 
Maps a host to an ISDN 
E.164 address. 
KEY 
25 
Yes 
Yes 
No 
RFC 4034, 3755, 
3445 
KEY RRs define public 
keys for use in 
cryptographic security 
operation, such as 
SIG(0). The exception: 
DNSSEC (DNSSEC), 
which uses the DNSKEY 
RR exclusively. 
KX 
36 
Yes 
Yes 
No 
RFC 2230 
Key Exchanger. Returns 
an alternative host 
name. 
Documents you may be interested
Documents you may be interested