1 / 55

Configuring DNS

Configuring DNS. Berkeley Internet Name Domain BIND. Most widely used DNS server Type: System-V managed service Packages: bind, bind-utils Daemons: named Config Files: /etc/named/conf and /var/named/* Related: redhat-config-bind , caching-nameserver , openssl. /etc/sysconfig/named.

devin
Download Presentation

Configuring DNS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Configuring DNS

  2. Berkeley Internet Name Domain BIND • Most widely used DNS server • Type: System-V managed servicePackages: bind, bind-utilsDaemons: namedConfig Files: /etc/named/conf and /var/named/*Related: redhat-config-bind, caching-nameserver, openssl

  3. /etc/sysconfig/named • Used by the named script to allow options to be passed to the named at startup

  4. 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

  5. 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

  6. 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; };};

  7. 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

  8. 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.

  9. 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

  10. 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

  11. 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”;};

  12. Special Zones • Root zone: “.” zone “.” { type hint; file “named.ca”; }; • Loopback zone “0.0.127.in-addr-arpa” • Specified like other reverse lookup zones

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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

  18. Resource Records • Three general types of Resource Records • Setup • Address mapping • Miscellaneous

  19. 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

  20. 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

  21. 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

  22. SOA • Every Zone must have one @ IN SOA ns.redhat.com. root.redhat.com. ( 2003120101; serial number 300; refresh 60; retry 1209600; expire 43200; 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

  23. 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.

  24. 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

  25. Address Mapping examples • A record: maps hostname to IP address mail IN A 192.100.100.3 login.redhat.com. IN A 192.100.100.4 • CNAME record: defines address aliases pop IN CNAME mail ssh IN CNAME login.redhat.com. • PTR record: maps IP address to hostname 3.100.100.192.in-arrd.arpa IN PTR mail.redhat.com. 4.100 IN PTR login.redhat.com.

  26. 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

  27. 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.

  28. 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

  29. 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

  30. 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

  31. 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

  32. 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

  33. 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

  34. 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’

  35. DNS Creating subdomains

  36. 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

  37. 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.

  38. 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

  39. Advanced DNS

  40. Logging • 1 logging stanza per named.conf • With as many channels and categories • Example logging{ 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; }; };

  41. 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

  42. Logging Categories • Categories Category transfer{xfer-in; xfer-out;}; • Types • default config parser queries lame-serversstatistics panic update ncache xfer-in xfer-outdb 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; };

  43. 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; };

  44. 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

  45. 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.

  46. 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

  47. 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 ); ] }

  48. Key • Not yet widely implemented • Adds authentication to name servers key 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

  49. 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

  50. 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

More Related