configuring dns. berkeley internet name domain bind most widely used dns server type: system-v...

Post on 11-Jan-2016

228 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

TRANSCRIPT

Configuring DNS

Berkeley Internet Name Domain BIND

Most widely used DNS server Type: System-V managed service

Packages: bind, bind-utilsDaemons: namedConfig Files: /etc/named/conf and /var/named/*Related: redhat-config-bind, caching-nameserver, openssl

/etc/sysconfig/named

Used by the named script to allow options to be passed to the named at startup

Configuring BIND

Default config file is /etc/named.conf Read by named during startup or

service named reload [RedHat Linux]

/etc/init.d/bind start [Debian] Text file specifying zones, options etc. Check the log files to ascertain if the service

started correctly

Config. File Basics

Comments can be in C, C++ or Shell style/* comment */// comment# comment

Directives such as options, zone and server precede blocks in bracesAll statements, including blocks end with semicolon

Relative pathnames will be prefixed with directory option, or /var/named if none specified

Global Options

Declared in the options directiveoptions { directory “/var/named”; forwarders { 147.252.1.37; }; allow-query { 147.252.234/24; }; allow-transfer { 147.252.234/24; };};

Global Options 2

directory: Base directory of all relative paths specified in named.conf

forwarders: Server forwards queries it cannot answer to name servers at the addresses in this list, if it gets no answer, it will try a root-name server unless the forward-only option is set

Global Options 3

allow-Query: Specifies the range(s) of IP addresses allowed to query this DNS server. If the option is not set, then all hosts can query this server

allow-Transfer: specifies hosts that are allowed to copy the database. Should be used to limit zone transfers. By default zone transfers are not permitted unless explicitly stated using the allow-transfer statement.

Master Zones

Declared with the zone directivezone “comp.dit.ie” {type master;file “comp.dit.ie.zone”;};

Specified file should contain the zone's database, but its name is not critical

Slave Zones

Declared with the zone directivezone “comp.dit.ie” {type slave;masters {147.252.224.70; };file “comp.dit.ie.zone”;};

The file directive is not essential, but if specified, it should probably match the name given on the master DNS in the corresponding zone file

When slave starts, it asks Master for the serial no. on the master zone file to see if they match

Reverse Lookup Zones

Zone name ends with special suffix.in-addr.arpa

Declared within the zone directivezone “1.10.14.in-addr.arpa” {type slave;masters {14.10.1.5;};file “1.10.14.in-addr.arpa”;};

Special Zones

Root zone: “.”

zone “.” {

type hint;

file “named.ca”;

}; Loopback zone

“0.0.127.in-addr-arpa” Specified like other reverse lookup zones

Special Zones Every BIND configuration should include a root

zone. The root zone is used when a query is unresolvable

by any other configured zones, so it is the ‘default’ zone

Zone type is ‘hint’ (unless the server being configured is a root name server)

named.ca contains info about root servers on the internet

ftp://rs.internic.net/domain

Special Zones

Loopback zones should be configured, although they are not strictly necessary

Many programs use the loopback address to implement inter-process communication (IPC)

These programs use the loopback address 127.0.0.1

Address Match Lists

A list of semi-colon separated IP addresses, networks or named address match lists

Used with some directives for access control Can use acl directive to create custom named

address match list

acl “mylist” {192.168.0/24; 192.168.1.12; };

Trailing, non significant, zeros can be dropped

Address Match Lists

Some global options such as allow-query take an address list as an argument

4 pre-defined match lists none - No IP addresses match any – All IP addresses match localhost – Any IP address of the name server matches localnets – Any network on which the name server has an

IP address matches

Zone Files Usually reside in /var/named Begins with $TTL (time to live). This defines the

default time in seconds which you want resolving nameservers to cache your zone’s information

$TTL 86400 First resource record is zone’s start of authority Zone’s data in additional zone records FQDNs in zone files end with a . BIND assumes the names that don’t end with . need

the name of the current domain appended

Resource Records

Three general types of Resource Records Setup Address mapping Miscellaneous

Resource Records

SOA defines start of authority NS specifies a name server A associates names with IP addresses CNAME aliases one name to another PTR points an IP address to a name MX specifies a mail exchanger

Resource Records Syntax

[domain] [ttl] [class] <type> <rdata> [domain] Specify domain or use current [ttl] how long to cache the record [class] record classification usually IN <type> record type (SOA, MX, A etc) <rdata> specific data for the record TTL values may be set on a per-record basis, overriding the

default ttl value. Most common class is the IN (Internet) class

Setup Resource Records

The SOA designates the beginning of a zone’s data, and sets default parameters fo this domain

Should contain at least one DNS that is authoritative for the zone (may be a slave server to mask master server’s identity)

A list of name servers that can be references is commonly included

SOA

Every Zone must have one@ IN SOA ns.redhat.com. root.redhat.com. (2003120101; serial number300; refresh60; retry1209600; expire43200; minimum ttl for negative answers) Values can now be in seconds, minutes(M), hours(H), days(D) or

weeks(W)The @ symbolises the current domain redhat.com in this example

SOA Explanation

Serial, for update comparison purposes Refresh: slave server delay Retry: Delay after slave server refresh failed Expire: Upper limit of slave serving data in absence

of update from master Min TTL..: How long should a nameserver cache a

‘no such host’ answer from an authoritative nameserver in a different domain.

Last string specifies contact details.

Address Mapping Records

An A resource record maps a hostname (FQDN or not) and an IP address

A CNAME record should only point to an A record

PTR Records are the inverse of an A record, map an IP address to a hostname

Address Mapping examples

A record: maps hostname to IP addressmail IN A 192.100.100.3login.redhat.com. IN A 192.100.100.4

CNAME record: defines address aliasespop IN CNAME mailssh IN CNAME login.redhat.com.

PTR record: maps IP address to hostname3.100.100.192.in-arrd.arpa IN PTR mail.redhat.com.4.100 IN PTR login.redhat.com.

NS name server

There should be an NS record for each master or slave serving your zone

NS records point to any slave servers that should be consulted by the client’s name server if the master should fail

@ IN NS ns.redhat.com.

Redhat.com IN NS ns1.redhat.com. FQDNs must be used for NS records

Miscellaneous Resource Records

MX (Mail exchanger records) which have a preference associated with them are used by remote MTAs (Message Transfer Agents) for delivery of Email.

HINFO records were intended to provide information on a hosts’ architecture and OS. Not a great idea.

MX & HINFO: examples

MX associates a domain with a host to handle mail for that domain

redhat.com. IN MX 5 mail.redhat.com.

redhat.com. IN MX 10 lava.redhat.com.

HINFO provides additional host data

mail IN HINFO i686 Linux-2.0.36

Example zone file: 1/3

$TTL 86400

@ IN SOA ns.redhat.com. root.redhat.com. (

20003120101 ;serial # YYYYMMDDCC

3H ;refresh 3 hours

1M ;retry 1 minute

2W ;expiration 2 weeks

1D) ;minimum ttl

Example zone file: 2/3

@ IN NS ns.redhat.com.

redhat.com. IN NS ns1.redhat.com.

ns.redhat.com. IN A 192.100.100.1 ; A

ns1 IN A 192.100..100.2 ; A

mail IN A 192.100.100.3

login IN A 192.100.100.4

lava IN A 192.100.100.10

www 0 IN A 192.100.100.5 ; ttl=0

Example zone file: 3/3

pop IN CNAME mail ; alias pop to mail

imap IN cname pop; bad idea

@ IN MX 5 mail.redhat.com. ; used first

redhat.com. IN MX 10 lava.redhat.com. ; used if mail is down

Round-Robin Load Sharing through DNS

Load balancing can be achieved through the simple use of multiple A records

www 0 IN A 192.168.34.3

www 0 IN A 192.168.34.4

www 0 IN A 192.168.34.5 DNS traffic will increase due to instant time-out of 0

ttl

BIND Utilities

host: gather host/domain information host –a ns.redhat.com host –al redhat.com

dig send queries directly to name server dig @ns redhat.com any

nslookup is deprecated

BIND Syntax utilities

BIND will fail to start if there are any configuration errors in the config files

After any configuration change, you should run named-checkconf

to examine /etc/named.conf named-checkzone redhat.com /var/named/rethat.com.zone

To examine a specific zone configuration file Should be done before making a new configuration ‘live’

DNS

Creating subdomains

Delegating Sub Domains

It is possible to set up and manage an entire subdomain as part of a zone that includes its parent domain

Sometimes necessary to delegate management of DNS for a subdomain to another name server

We will delegate authority for the support.example.com subdomain from the example.com domain.

example.com is managed by ns.example.com support.example.com is managed by

ns.support.example.com

Delegating Subdomains

Set up a zone to manage support.example.com on ns.example.com

Parent zone needs to delegate authority for the subdomain to the new server.

Do this by creating an NS records for the subdomain in the parent’s zone database to point to the new name server or servers This is called a “delegation record”

support.example.com. IN NS ns.support.example.com.

Delegating Subdomains

To get the address for this name server for support.example.com, we need to look up an A record on the name server for support.example.com

We need a “glue” record in the zone file for example.com on ns.example.com pointing to the ns.support server

ns.support IN A 192.100.100.10

Parent zone will need NS records (and A records) for all authoritative name servers managing the delegated zone

Advanced DNS

Logging 1 logging stanza per named.conf

With as many channels and categories

Examplelogging{ channel example_log{ file "/var/log/named/example.log" versions 3 size 2m; severity info;

print-severity yes; print-time yes; print-category yes;

};channel "default_stderr" { stderr; severity info; };};

Logging options

Severity critical, error, warning, notice, info debug [ level ] dynamic (set by –d option from command line)

Printing options print-category, print-severity, print-time

Logging Categories

• Categories

Category transfer{ xfer-in; xfer-out;};

• Types default config parser queries lame-servers

statistics panic update ncache xfer-in xfer-out db event-lib packet notify cname security os insist maintenance load response-checks

Default categories

category default { default_syslog; default_debug; };

category panic { default_syslog; default_debug; };

More global options

recursion: Whether the name server will look outside its domain

listen-on: restricts which interface a name server uses

listen-on port 53 { 9.53.150.239; }; notify transfer-format: either one-answer or many-answer

Update { 9.53.150.239; };

DNS enhancements: DNS Notify

RFC 1996 (1996): Specified DNS Notify message Original operation:

Slave will poll master for updates Refresh option controls the frequency of this Results in network traffic and latency with changes

Notify message is sent from master to the slave when the zone definition changes

DNS enhancements: Incremental zone transfer

RFC 1995: Allows incremental updates of the zone definition

Original operation: Entire zone definition is transferred Wasteful of bandwidth

Slave server sends a IXFR message with the serial number of the current copy of the database.

Master identifies the changes and sends the updated records only.

DNS enhancements: Dynamic DNS

Modern networks are not static IP addresses change rapidly (DHCP) DNS does not handle change well

Dynamic DNS Require Update in zone definition:

allow-update { 192.168.0.145; }; Allows zone definitions to be updated dynamically Integrated into Active Directory

Server

Modifies the behaviour of the naming server with regard to individually specified servers

server ipaddr

{

[ bogus ( yes | no ); ]

[ transfers value;]

[ transfer-format ( one-answer |

many-answers ); ]

}

Key

Not yet widely implemented Adds authentication to name serverskey key-name {

algorithm alg-id;secret secret-string;};

In the zone definition add:update-security

Unsecured :No security (standard operation)

Presecured :Won’t accept new records without authentication

Controlled :Can add new records, but not change existing ones

More Resource Records

SOA defines start of authority NS specifies a name server A associates names with IP addresses CNAME aliases one name to another PTR points an IP address to a name MX specifies a mail exchanger AAAA specifies an IPv6 address TXT specifies a text string SRV specifies a service record

AAAA and IPV6 support

RFC1886 (Dec1995) defined AAAA: 128bit IPv6 address IP6.INT: IPv6 equivalent of IN-ADDR.APPR extension to query types and resolution to handle IPv6

addresses

Alternative standard was proposed (RFC2874) which defined A6: allowed chaining of addresses

RFC3364 (2002) decided in favour of AAAA

TXT record

Allows arbitrary text (up to 65535 bytes) to be defined in the configuration fileTXT “text string 1” text_string2 “last one”

Query with dig txt option Used for arbitrary applications which need extra info

E.g. anti-spam protection for mail servers

SRV record & DNS Service Discovery (DNS-SD)

Supports browsing of services as well as names through DNS

_http._tcp.example.com. SRV 10 5 80. www.example.com _[service name]._[protocol].[domain name] Priority Weighting (for load balancing) Port number for the service Hostname

DNS and load balancing

There are two types of load balancing possible with DNS Balancing the load between hosts whose name is

served by DNS Balancing the load between name servers

Round-Robin Load Sharing through DNS

Load balancing can be achieved through the simple use of multiple A records

www 0 IN A 192.168.34.3

www 0 IN A 192.168.34.4

www 0 IN A 192.168.34.5 DNS traffic will increase due to instant time-out of 0

ttl

BIND and load balancing

BIND will automatically load balance between name servers

BIND remembers the time the last query took (Round Trip Time). If it has never queried it before, the RTT=0

On each successful query, the RTT will be increased a little

On any resend, the RTT will be increased a lot

top related