Learning publishing DNS in Action Ebook_8 docx

Chapter 5Extract: number of zones: 5 debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is OFF server is up and running Further details ab

Trang 1

Chapter 5

Extract:

number of zones: 5

debug level: 0

xfers running: 0

xfers deferred: 0

soa queries in progress: 0

query logging is OFF

server is up and running

Further details about the program and its configuration can be found in the documentation, which

is a part of every BIND distribution

Overview of rndc commands:

Command Description

reload Reloads the configuration file and zone files

reconfig Reloads the configuration file and new or changed zone files; unchanged zone files are

not loaded stats Records the statistics into a file

querylog Switches on logging queries about the name server

dumpdb Records the server's cache memory in the dump file

stop Stops the server and records changes acquired by IXFR or by a dynamic update

into files halt Stops the server immediately

trace Increases the debugging level of the server by 1

notrace Sets the debugging level of the server at 0

flush Cleans the server's cache memory

status Displays the status of the server

5.2.1 Signals

The kill command can be used to send a signal to the named program in UNIX A similar group

of actions can be carried out using signals to those available using the rndc program The

following signals are usually processed: HUP, INT, IOT, TERM, KILL, USR1, and USR2 In the actual implementation of a name server, the parameters that were used during compiling the named

program are also important

The kill command has, as the second parameter, a process number (PID) You can find

out the process number the named program is running under by, for example, using the ps

command However, the named program writes the process number into the /path/named.pid file during its startup The location and the name of the file can be influenced during the compilation

of the named program

The syntax of the kill command, for example, with the HUP signal is the following:

kill —HUP 'cat /path/named.pid'

129

Trang 2

Tools for DNS Debugging and Administration

If you wish to start the diagnostics of the named program during its startup, you need to state the relevant parameter in the command line that is used to start the named program For more details, see the man named command

5.2.1.1 HUP Signal

The HUP signal forces the name server to read the data from the disk again However, the cache is not usually cleaned by the HUP signal

5.2.1.2 INT Signal

The INT signal extracts all data (authoritative and nonauthoritative) from the memory into a file usually called /tmp/named_dump.bd An example of a part of the file is as follows:

; Dumped at Fri Feb 16 18:12:49 1996

; Note: Cr=(auth, answer, addtnl, cache) tag only shown for non-authorised RR's

; Note: NT=milliseconds for any A RR which we've used as a nameserver

; Cache & Data

$ORIGIN

518339 IN NS A.ROOT-SERVERS.NET

5188339 IN NS H.ROOT-SERVERS.NET

5188339 IN NS B.ROOT-SERVERS.NET

5188339 IN NS C.ROOT-SERVERS.NET

5188339 IN NS D.ROOT-SERVERS.NET

5188339 IN NS E.ROOT-SERVERS.NET

5188339 IN NS I.ROOT-SERVERS.NET

5188339 IN NS F.ROOT-SERVERS.NET

5188339 IN NS G.ROOT-SERVERS.NET

86348 IN SOA A.ROOT-SERVERS.NET HOSTMASTER.INTERNIC.NET (

1996021400 10800 900 604800 86400) ;Cr=addtnl

;workgroup 548 IN A NXDOMAIN ;-$

cz 172768 IN NS NS.EUNET.CZ ;Cr=addtnl

172768 IN NS NS.CESNET.CZ ;Cr=addtnl

172768 IN NS NS.EU.NET ;Cr=addtnl

172768 IN NS SUNIC.SUNSET.SE ;Cr=addtnl

172768 IN NS NS.UU.NET ;Cr=addtnl

172768 IN NS SPARKY.ARL.MIL ;Cr=addtnl

$ORIGIN 48.192.IN-ADDR.ARPA

96 518384 IN NS NS.UU.NET ;Cr=addtnl

518384 IN NS UUCP-GW-1.PA.DEC.COM ;Cr=addtnl

518384 IN NS UUCP-GW-2.PA.DEC.COM ;Cr=addtnl

518384 IN NS NS.EU.NET ;Cr=addtnl

$ORIGIN 96.48.192.IN-ADDR.ARPA

16 86385 IN PTR relay6.UU.NET

$ORIGIN 147.IN-ADDR.ARPA

230 518391 IN NS BUBO.VSLIB.CZ ;Cr=addtnl

518391 IN NS NS.CESNET.CZ ;Cr=addtnl

1 3591 IN PTR bubo.vslib.cz

0 IN SOA mh.company.com hostmaster.company.com (

94082701 10800 3600 360000 1 29600 )

240 IN SOA mh.company.com hostmaster.company.com (

1996020801 28800 3600 604800 864000 )

Trang 3

Chapter 5

1 IN PTR Ceske-Budejovice.company.com

$ORIGIN MIL

ARL 518368 IN NS ADMII.ARL.mil ;Cr=addtnl

518368 IN NS VGR.ARL.ARMY.mil ;Cr=addtnl

518368 IN NS SLADW.ARL.mil ;Cr=addtnl

518368 IN NS DNS1.ARL.mil ;Cr=addtnl

$ORIGIN ARL.MIL

DNS1 518368 IN A 131.218.24.3 ;Cr=addtnl

SLADW 518368 IN A 155.148.8.2 ;Cr=addtnl

518368 IN A 155.148.6.90 ;Cr=addtnl

ADMII 518368 IN A 128.63.31.4 ;Cr=addtnl

518368 IN A 128.63.5.4 ;Cr=addtnl

518368 IN A 192.5.25.5 ;Cr=addtnl

SPARKY 81548 IN A 128.63.48.85 ;NT=481 Cr=answer

81548 IN A 192.5.23.200 ;NT=745 Cr=answer

$ORIGIN ARL.ARMY.MIL

VGR 518368 IN A 128.63.16.6 ;Cr=addtnl

518368 IN A 128.63.4.4 ;Cr=addtnl

518368 IN A 128.63.2.6 ;Cr=addtnl

$ORIGIN SUNSET.SE

SUNIC 172768 IN A 192.36.125.2 ;NT=459 Cr=addtnl

172768 IN A 192.36.148.18 ;NT=459 Cr=addtnl

$ORIGIN COM

GreatCircle 172787 IN NS MILES.GreatCircle.COM ;Cr=addtnl

172787 IN NS NS.UU.NET ;Cr=addtnl

pvt IN SOA mh.company.com hostmaster.company.com (

1996020802 10800 3600 360000 129600 )

$ORIGIN company.com

Ceske-Budejovice IN A 193.85.240.1

IN HINFO "Cisco" ""

$ORIGIN unl.company.com

p56x01 IN MX 10 mh.company.com

$ORIGIN NET

pvt 172781 IN NS ns.provider.net ;Cr=addtnl

172781 IN NS NS1.PROVIDER.NET ;Cr=addtnl

172781 IN NS NS0.PIPEX.NET ;Cr=addtnl

172781 IN NS NS1.PIPEX.NET ;Cr=addtnl

$ORIGIN ROOT-SERVERS.NET

A 518339 IN A 198.41.0.4 ;NT=475 Cr=addtnl

B 518339 IN A 128.9.0.107 ;NT=16833 Cr=addtnl

C 518339 IN A 192.33.4.12 ;NT=19544 Cr=addtnl

D 518339 IN A 128.8.10.90 ;NT=1040 Cr=addtnl

E 518339 IN A 192.203.230.10 ;NT=1279 Cr=addtnl

F 518339 IN A 192.5.5.241 ;NT=1076 Cr=addtnl

G 518339 IN A 192.112.36.4 ;NT=411 Cr=addtnl

H 518339 IN A 128.63.2.53 ;NT=19544 Cr=addtnl

I 518339 IN A 192.36.148.17 ;NT=940 Cr=addtnl

$ORIGIN UU.NET

NS 172787 IN A 137.39.1.3 ;NT=940 Cr=addtnl

$ORIGIN EU.NET

NS 172784 IN A 192.16.202.11 ;NT=280 Cr=addtnl

$ORIGIN pipex.NET

ns0 172781 IN A 158.43.128.8 ; Cr=addtnl

NS1 172781 IN A 158.43.92.7 ; Cr=addtnl

$ORIGIN provider.net

131

Trang 4

ns1 172781 IN A 194.149.103.201 ; Cr=addtnl

ns 172781 IN A 194.149.105.18 ; Cr=answer

; Hints

$ORIGIN

3600 IN NS NS.INTERNIC.NET

$ORIGIN NIC.DDN.MIL

NS 3600 IN A 192.112.36.4

$ORIGIN ARL.ARMY.MIL

AOS 3600 IN A 128.63.4.82

$ORIGIN NASA.GOV

NS 3600 IN A 128.102.16.10

$ORIGIN UMD.EDU

$ORIGIN ISI.EDU

NS1 3600 IN A 128.9.0.107

$ORIGIN NYSER.NET

C 3600 IN A 192.33.4.12

$ORIGIN NORDU.NET

NIC 3600 IN A 192.36.148.17

$ORIGIN INTERNIC.NET

NS 3600 IN A 198.41.0.4 ;NT=683

5.2.1.3 IOT Signal

The IOT signal ensures the extraction of the statistics, usually into the /tmp/named.stats file Here is an example:

###(82490113) Fri Feb 16 18:01:53 1996

551359 time since boot (secs) number of seconds from the start

551359 time since reset (secs)

631708 input packets number of input packets

637573 output packets number of output packets

621627 queries number of queries

0 iqueries number of inversion queries

552 duplicate queries number of queries repeated after reaching the interval

13053 responses number of responses from distant name servers

282 duplicate responses number of repeated responses from name servers

426098 OK answers number of answers without an error indication

178 FAIL answers number of answers with an error indication

2 FORMERR answers number of refused answers

3525 system queries number of queries of a local server

3 prime cache calls how many times the data about the root servers were read

2 check_ns calls how many times the TTL field expired for records describing access to the root name servers; after such expiration the file is read again

345 bad responses drooped number of faulty responses from distant servers

2 martian responses number of responses sent by "Martians"

(responses from unknown distant servers)

194894 negative responses cached number of cached negative responses

0 unknown query types number of queries about unknown record types

520940 A queries number of queries about A type of records

14 NS queries number of queries about NS type of records

Trang 5

Chapter 5

819 SOA queries number of queries about SOA type of records

2 MR queries number of queries about MR type of records

13045 PTR queries number of queries about PTR type of records

86064 MX queries number of queries about MX type of records

2 AXFR queries number of queries about AXFR type of records (zone transfer)

425 ANY queries number of queries about ANY type of records (*)

5.2.1.4 TERM Signal

The TERM signal properly stops the named program Information obtained by the IXFR or by Dynamic Update is saved into files

5.2.1.5 KILL Signal

The KILL signal immediately stops the named program; this termination is abnormal It is

recommended to use this signal only in a situation when the TERM signal doesn't work

5.2.1.6 USR1 and USR2 Signals

The USR1 signal is used for turning on the debugging output into the /tmp/named.run file Another USR1 signal increases the debugging level, i.e., the quantity of recorded information There are up to 11 levels The USR2 signal is used for turning the debugging output off

completely (and not to gradually decrease the debugging level) The debugging output records individual steps of a name server

The following example is an example of debugging level 1 It is a translation of the

test97.provider.net name to an IP address As the name was submitted without a dot, the default company.com domain was first added after the name The translation of test97.provider.net .company.com was not successful; the following attempt is to translate test97.provider.net The query was sent to an authoritative name server for the provider.net domain, which has an IP address 158.43.128.8

Debug turned ON, Level 1 (Kill -USR1 .)

datagram from [193.85.240.30].1824, fd 5, len 39; now Fri Feb16 18:18:56 1996 req: nlookup(test97.provider.net.company.com) id 512 type=1

req: found 'test97.provider.net.company.com' as 'company.com' (cname=0) ns_req: answer – [193.85.240.30].1824 fd=5 id=2 Local

datagram from [193.85.240.30].1825, fd 5, len 32; now Fri Feb16 18:18:56 1996 req: nlookup(test97.provider.net) id 718 type=1

req: found 'test97.provider.net' as 'provider.net' (cname=0)

forw: forw – [158.43.128.8].53 ds=7 nsid=3 0ms retry 4sec

datagram from [158.43.128.8].53, fd 5, len 196; now Fri Feb 16 18:18:57 1996 update_msg: msglen:196, c:9

update failed (-10)

send_msg – [193.85.240.30] (UDP 5 1825) id=3

Debug turned OFF (kill -USR2 .)

133

Trang 6

5.3 Errors in DNS Configuration

The 10 most common errors in DNS configuration are as follows:

1 Every host in the Internet should have a domain name correctly established in the DNS Some services check the existence of the name in the DNS and do not

communicate with the host if this DNS name does not exist

2 The domain name must not contain any other symbols than ASCII letters, digits, and

a dash (not underscore!) A name should not consist of digits only A name must not start or end with a dash RFC 1033 permits the use of an underscore in a domain

name; however, it is not defined as a standard and some implementations have

problems with it, and it is therefore better to avoid its use

3 Full domain names must end with a dot A dot is not used at the end of an IP address

4 The symbol @ in a mail address for an SOA record must be replaced by a dot

5 The right side of an NS record must include a canonical name; it must not include an

IP address

6 An A record and matching PTR record must include identical information

7 An alias must not be used on the right side of PTR, MX, NS, and CNAME records If

you want the host to have the same name as the domain, use the following construction:

company.com IN NS ns1.company.com

IN NS ns2.company.com

IN A 1.2.3.4

8 Corresponding PTR record must exist for every A record A host with more

addresses must have more PTR records

9 Lame delegation: an authoritative name server does not contain the data for a

domain This situation usually happens after crashing a secondary name server

A typical example of lame delegation is a situation where the primary name server works correctly and a secondary name server is incorrectly configured (a record in named.boot

or named.conf file is missing, a zone transfer has not been carried out, and so on) This name server that has not been configured may be then set in a superordinate domain as an authoritative name server for a domain

A query about the name of this domain is requested from somewhere The superior name server answers that the query should be sent to the incorrectly configured name server as

it is the authority The query is then sent to the server, which has not been configured, but should be the authority This server does not know the answer

10 A glue record is not added in reverse domains

11 If the name server has several IP addresses in subordinate zone, the superior domain must contain glue records for all IP addresses

Trang 7

6

Domain Delegation and

Registration

The process of delegating a domain is carried out in several steps:

1 Setting up a primary Domain Name Server

2 Configuring a secondary name server for the domain, or requesting the configuration

of the name server from your Internet service provider

3 Requesting that the domain be delegated to a higher-level domain

4 If the domain is a second-level domain, registering the domain in an Internet registry

domain database

Let us say that, somewhere in the world, there is a magical land that uses the top-level domain tld

as its country code This top-level domain is similar to com, info, cz, fj, ru, de, or other domains used in neighboring fairytale lands The wise old TLD manager of this land controls the primary name server for the tld domain in this country called ns.manager-tld.tld The secondary name servers for the tld domain are held by his good friends, the hostmasters of other TLDs that are equally accessible from any place on the globe

The hostmaster of a company called Company Ltd also works in this far-away country This

company decides to establish and use the company.tld domain Company Ltd has a leased line connection to the Internet If the company only had a dial-up connection to the Internet, it would not be allowed to administer its name server itself In that case, the company would have to assign the administration of its domain to its Internet Service Provider

6.1 Example 1

The hostmaster of the company decides to administer the primary name server on one of the

company's computers The server is called ns.company.tld and has the IP address 194.149.10.11 The ns.company.tld server runs on UNIX and BIND version 4.9 (Windows 2000/2003 has a similar configuration.) The administrator wants to administer the secondary name server on an ISP name server called ns.provider.net

Trang 8

Domain Delegation and Registration

The following diagram shows the hierarchy of name servers, and the sections below describe the individual configuration files or their sections that specify the required delegation:

Figure 6.1: Domain delegation

6.1.1 Server ns.company.tld

This server acts as a primary server for the company.tld zone

File named.boot

primary company.tld company.tld.zone

File company.tld.zone

@ IN SOA ns.company.tld hostmaster.company.tld (

1998082402 ; Serial

28800 ; Refresh 8 hours

7200 ; Retry 2 hour

604800 ; Expire 7 days

86400 ) ; Minimum TTL 1 day

; ns records specifying the authoritative nameservers

IN NS ns.company.tld

IN NS ns.provider.net

; valid record A for the ns.company.tld server

ns IN A 194.149.10.11

6.1.2 Server ns.provider.net

This server acts as secondary name server for the company.tld zone

File named.boot

secondary company.tld 194.149.10.11 company.tld.zone

Trang 9

Chapter 6

Now let us verify that the primary and secondary name servers are configured and functioning properly Do not test the servers from the computers on which the primary or secondary name server of the tld domain is running The simplest test can be done using the nslookup command Run nslookup and type server ns.company.tld to direct the resolver to this name server The ls –d command lists the content of the configured zone Then direct the resolver to the secondary name server(s) You should see the same zone data If the command does not list the zone content, you have to look for and correct any misconfigurations on the servers

You can also use more user-friendly tools such as the dig program (for more information visit

http://www.kloth.net/services/dig.php) or other more sophisticated tools such as dnswalk

(for more information visit http://www.visi.com/~barr/dnswalk/) If you do not want to allow zone content to be listed from outside computers, you should follow these three steps:

1 Allow the whole zone to be read without limitations, but only put one or two RR

records into the zone

2 Let the administrator of the superior zone make a delegation (see the following section)

3 Set up restrictions to only allow zone transfer between the authoritative name servers

of this zone and fill the zone database with the real data

6.1.3 Server ns.manager-tld.tld

This name server is a primary name server for the tld domain

You can now specify the information that needs to be added into the tld zone configuration file (on the ns.manager-tld.tld name server) The administrator of the tld domain will add this information after the appropriate administrative procedures have been carried out

File tld.zone

; ns records ensuring the delegation of a domain

company IN NS ns.company.tld

; glue record for the ns.company.tld server:

ns.company IN A 194.149.10.11

This registration enables your zone to be translated from any computer on the Internet, and not just from those computers whose resolvers are directed to your name server when testing the zone, as was recommended in the last section

6.2 Example 2

For its branch office, Company Ltd plans to create a subdomain within the company.tld domain called branch.company.tld The branch will administer its own name server called

ns.branch.company.tld with the IP address 194.149.10.129 The secondary name server for the

branch.company.tld domain will be configured on the ns.company.tld name server

The following list shows the individual configuration files or their sections that specify the required delegation The bold lines are the lines that relate to the delegation of the branch.company.tld

domain These lines have been added to the configuration files from the previous example

137

Trang 10

Domain Delegation and Registration

6.2.1 Server ns.company.com

File named.boot

primary company.tld company.tld.zone

secondary branch.company.tld 194.149.10.129

branch.company.tld.zone

File company.tld.zone

@ IN SOA ns.company.tld hostmaster.company.tld (

1998082402 ; Serial

7200 ; Retry 2 hour

; ns records specifying authoritative nameservers

; glue A record for the ns.company.tld server:

ns IN A 194.149.10.11

;

; delegation of the branch.company.tld subdomain to the

ns.branch.company.tld name ,server

; following ns records specifying the delegation:

branch IN NS ns.branch.company.tld

; glue record for the nsbranch.company.tldz server

ns.branch IN A 194.149.10.129

6.2.2 Server ns.branch.company.tld

File named.boot

primary branch.company.tld branch.company.tld.zone

File branch.company.tld.zone

@ IN SOA ns.branch.company.tld hostmaster.branch.company.tld (

1998082502 ; Serial

7200 ; Retry 2 hour

; ns clauses determining the authoritative nameservers

IN NS ns.branch.company.tld

; valid A record for the ns.branch.company.tld server

ns IN A 194.149.10.129

Định dạng
Số trang	20
Dung lượng	1,92 MB