- dns-wg - mailman.ripe.net

Re: DRAFT: "RIPE Guide To Setting Up a DNS Server"
by Berislav Todorovic 25 Jan '99

25 Jan '99

>> In particular I'd like to hear opinions concerning the structure, volume and >> topics covered. The SOA values recommended here are a proposal for the >> thursday WG meeting. Personally, I find the contents and structure to be a good skeleton for future work. Few comments: >> Now that you have a domain name, a list of secondaries for serving >> your zone and some address space, you can start constructing a zone. >> Consult the documentation of your DNS server software for where to >> start, this document will assist you in filling in the proper values. I'd add the following text: Generally speaking, most DNS software packages require two configuration file sets to operate: boot file and zone files. The boot file (e.g. named.boot in BIND 4, named.conf in BIND 8) contains the list of domains, being served by the DNS server, as well as some other necessary global operational parameters. The zone files contain information about particular domains they represent. In other words, each domain is represented by a separate zone file. >> ... >> DNS zone. For efficiency reasons, serial numbers are compared >> only. If the serial number at the primary is higher than the >> secondary's local copy, the zone is copied. (*) I'd add a footnote here: (*) To be precise, serial number comaprison is being done using modulo 2^31 arithmetic, i.e. "higher" means "higher modulo 2^31". Please refer to the RFC 1982 for more details. Also see chapter XXX of RFC 1537 for more details on one practical implication of such comparison. >> update their copy. Modern DNS server software will send out >> additional notifications from the primary to the secondaries upon >> reload of a modified zoen, so usually the information is >> distributed much faster than this. I'd add: (NOTE - to be able to use this feature, called NOTIFY option [RFC 1996], the secondary server has to support this feature. BIND 8 supports this feature). >> The NS RRs tell the world who is able to give out information about >> your zone. Enter a single NS RR for every server which is intended >> to provide secondary service for your zone, see the list mentioned >> earlier. Do not enter random nameservers' names just because you have >> seen them somewhere. The administrators may not want to deal with >> that additional load and they may even - as a defense - provide >> explicit non-service. Add the following text, for better reference: (this is oftenly called "lame delegation"). >> the order of NS records is not important The order of any records is not of any importance - DNS oftenly does its own record sorting! Concerning the MX section: I'd put it AFTER the CNAME section. In the MX section I'd change: >> 3) The domain name used must directly resolve into an address, which >> means you must not use an alias name here and an A resource record >> must exist for that name. Note that unless the name is part of >> your namespace you must not enter that A record yourself. Between "alias name" and "here and an ..." insert "(CNAME record)". >> For domain names in general, no character restrictions apply. >> Hostnames are restricted to letters (since the DNS is case I didn't get this clear. Seems to me like two mutually exclusive phrases. Things to be done: * Reverse mapping (with references to RIPE-185 (Guide to European LIRs), RFC 2317 (Classless IN-ADDR.ARPA Delegation)). * Add a separate chapter, called "DNS Recursion" and explain recursive and non-recursive mode of operation, forwarder and slave servers. That can be done in no more than 20 lines. Generally speaking, you're doing good work! Keep on moving ... ;-) Regards, Beri .-------. | --+-- | Berislav Todorovic, B.Sc.E.E. | E-mail: BERI(a)etf.bg.ac.yu | /|\ Hostmaster of the YU TLD | |-(-+-)-| School of Electrical Engineering | Phone: (+381-11) 3221-419 | \|/ Bulevar Revolucije 73 | 3218-350 | --+-- | 11000 Belgrade SERBIA, YUGOSLAVIA | Fax: (+381-11) 3248-681 `-------' --------------------------------------------------------------------

1 0

DRAFT: "RIPE Guide To Setting Up a DNS Server"
by Peter Koch 25 Jan '99

25 Jan '99

Dear RIPE DNS WG, find below a draft document "RIPE Guide To Setting Up a DNS Server" to serve as a basis for recommendations to customers on how to set up their DNS server. The target audience is the maintainer of a zone with population lower than 10 (the vast majority of zones, at least within the DE TLD), who usually has very low operational experience and too few changes to apply to develop such experience in "day to day" work. It was started from scratch intentionally, so there are a few items missing from previous similar drafts on this list. The document has already become larger than I intended, but those missing pieces should be identified and merged in (or part of this merged into the other). Comments are very welcome. In particular I'd like to hear opinions concerning the structure, volume and topics covered. The SOA values recommended here are a proposal for the thursday WG meeting. -Peter PS: Although it may give the impression, the draft was not posted as an I-D, I just borrowed that template. INTERNET-DRAFT Peter Koch Expires: July 1999 Universitaet Bielefeld January 1999 RIPE Guide To Setting Up a DNS Server <no file name, not yet submitted to the I-D maintainer> Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Comments should be sent to the author or the RIPE DNS WG mailing list <dns-wg(a)ripe.net>. Abstract This document is intended to guide novice and/or part time DNS zone administrators in getting their DNS zones up and running. It is not sufficiently detailed to replace a book about DNS. 1. Introduction The DNS is a distributed, redundant, hierarchical namimg scheme for mapping so called "domain names" into addresses and other Internet infrastructure elements. You will learn about those later. You will normally use two distinct services within the DNS. While using your web browser and email software your system will have to translate (foreign) domain names into IP addresses. This is called "resolving". The other task is presenting your domain name, once you have one, to other parties on the Internet to enable them to resolve your or your organisation's name into some address. This part is called "serving". While both deal with DNS and both tasks may even be carried out by the very same piece of software on your machine, they are different. This document is primarily concerned with setting up a DNS server, but at the end some information is provided on "DNS Koch Expires July 1999 [Page 1] INTERNET-DRAFT RIPE DNS Guide January 1999 resolving" issues. There are different Top Level Domains (TLDs) to register with, such as "COM" or those country-code based like "FR" for France and "DE" for Germany. You may also find offers for registration within "new" or "private" TLDs, e.g. "WEB". At the moment these are bogus. If in doubt, check the official list at [TBD]. To register a domain name, in most cases two or more nameservers need to be set up to serve the corresponding zones, i.e. answer queries dynamically sent in from all over the Internet. "in most cases" means, that some Top Level Domain (TLD) registries will allow the existence of real data instead of just pointers to nameservers in their database. Whether this is the case you should ask your ISP or the registry responsible for the TLD you are interested in. Do not forget to ask for the cost of making modifications to the data later. If your organisation is going to expose only a small number of systems to the globally visible Internet, maybe only a web server and a mail relay, you will have to publish only a very small set of data in the DNS. In this case - but sometimes also in others - it is not really necessary to bother with the operation of an own DNS server. Your ISP may offer running the DNS server and maintaining the zone data for you. This value added service, however, may require an additional fee. While DNS isn't rocket science, it is a mission critical service, and there are some trapdoors potentially disturbing the proper operation. You may wish to take the opportunity having this done by somebody who makes a living out of it. For those of you, who choose to do the job themselves, we want to help you navigate around the most common pitfalls. Apart from your own nameserver the DNS protocol requires a set of so called "secondary" or "slave" servers, which will publish the same data about your zones your server does, but which are placed at other parts of the Internet. In most cases your ISP will offer help in locating proper secondary servers or even run one or more of them themselves. Again, this service may require an additional fee, so please consult your ISP. You may find some documentation suggesting to have two nameservers at your installation. This is not considered reasonable practice and will, apart from increasing your work (and even network) load, give you nothing. Now that you have a domain name, a list of secondaries for serving your zone and some address space, you can start constructing a zone. Consult the documentation of your DNS server software for where to Koch Expires July 1999 [Page 2] INTERNET-DRAFT RIPE DNS Guide January 1999 start, this document will assist you in filling in the proper values. 2. DNS Resource Records The information in the DNS is handled in pieces of "resource records" (RRs). There are different types of RRs, every resource record is bound to a domain name (the "owner"). A single "owner" may own several RRs of equal or different types. We will only talk about "SOA", "NS", "MX", "A" and "CNAME" RRs. 2.1. The SOA RR Type While some people claim the Internet being the end of all authorities, one of the first things you will have to enter is a "Start Of Authority" record. There is a single SOA record per zone containing some meta information like who the maintainer is and how often secondaries should check with the primary for modifications to the zone. There are seven elements in an SOA record: 1) The MNAME (master name) must give the name of the primary master server for that zone, i.e. the machine you are running your DNS server on. There is no need to reserve a special name, like "ns" or "dns" for this system, so use the canonical name of that machine. [XXX explain FQDNs] 2) The RNAME is to publish a mail address of a person or role account dealing with this zone. The "@" must be converted to a "." before you enter this, so postmaster(a)bricks.example becomes postmaster.bricks.example. Be sure to name a working address here (NB: your domain is not yet registered, but the local part should be defined at your site). Do not accept any default your software may suggest without checking its validity. If your addresses follow the popular scheme "first.last(a)canonical.example", although technically possible, do not use any of these here. The distinction between the "." seperating first and last name and the translated "@" will eventually be lost, leading to an unreachable email adress due to wrong retranslation. The same caveat holds for other addressing schemes with dots in the local part ("10000.0815(a)kangooserve.example"). The best practice is to define (and maintain) a dedicated mail alias "hostmaster" [RFC2142] for your DNS operations. 3) The SERIAL number Secondaries have to check with the primary for new versions of a Koch Expires July 1999 [Page 3] INTERNET-DRAFT RIPE DNS Guide January 1999 DNS zone. For efficiency reasons, serial numbers are compared only. If the serial number at the primary is higher than the secondary's local copy, the zone is copied. If the serial at the primary is equal to or less than the one at the secondary nothing happens. This means that after every modification to the zone you have to increase the serial and you should in any case avoid to decrease it. Update the serial number even if you make mulltiple changes within short intervals, one of the secondaries may have fetched its new copy in the meantime. The serial number is a an unsigned 32bit integer with no further implied meaning. Also, the increments do not have any special meaning. You can grow the serial by 1, 10 or 170 every time as long as it just always increases. The serial number 0 should be avoided due to some problems in certian software versions. There is a popular scheme which builds the serial number by using the actual date, e.g. 1999012300 for a zone changed at January, 23rd, 1999. The trailing two digits leave enough space for 100 modifications per day. This scheme is called YYYYMMDDnn, some similar are also in use. Be sure to use a four digit year, notice that the month preceeds the day and do not forget to update the year value upon the first change every year. 4) The REFRESH value This value controls how frequently the secondaries will check with your primary to see whether your zone was modified and they must update their copy. Modern DNS server software will send out additional notifications from the primary to the secondaries upon reload of a modified zoen, so usually the information is distributed much faster than this. However, notification packages may be lost, so the secondary-initiated checks are still useful. A value of one day (86400 seconds) is recommended here. 5) The RETRY value Should a secondary be unable to reach the primary for whatever reason, the next attempt is started in intervals given by RETRY until the zone could be successfully checked or it expires (see below). Any value larger than REFRESH doesn't make sense, usually the maximum of two hours and a fraction of 1/6 to 1/4 of REFRESH are good choices. So, if you followed the recommendation above, enter 7200 (two hours) here. The lower the values for REFRESH and RETRY, the more load is put on the secondary servers. This is not a big deal for a single zone, but it has to scale for large nameservers serving several Koch Expires July 1999 [Page 4] INTERNET-DRAFT RIPE DNS Guide January 1999 thousand zones. Therefore your ISP resp. the operator(s) of your secondaries may give you additional advice and will probably recommend different values. If in doubt, ask them first. 6) The EXPIRE value Should a secondary be unable to check the zone with the primary for a period of time specified by EXPIRE, it will just do that - expire the zone. Unfortunately it is not precisely specified what that means, but from that time on you can no longer expect that secondary to hand out any useful information about your zone. Of course, this is a scenario you will want to avoid, benause it may lead users to wrong addresses or even make them feel your or your web site's domain name do no longer exist. There are several reasons, why a secondary's check would fail: temporary line failures, machine downtimes and most importantly: configuration errors at your primary. To give yourself a chance of detecting and repairing such problems, the EXPIRE value should be long enough to cover even a short holiday. A value of 3600 hours (3600000) is traditionally recommended here. Be especially warned that values of a week or less, while having no benefit, have drasticly proven to be too short. 7) The MINIMUM value There are three different meanings applied to this, of which the first appeared in the original protocol implementation but was never widely implemented. To explain the other two we need to tell about yet another DNS feature - caching. DNS servers are queried by DNS resolvers, and those resolvers usually remember (cache) any results seen for a certain amount of time. This way the total DNS traffic on the Internet, the server load and most importantly the response times will be reduced. There is both caching of RRs and negative caching, which means the knowledge of non-existance of a certain name or RR type will be maintained. The predicted lifetime (TTL) of such information is to be controlled by the zone administrator, every RR will be tagged with a TTL value when used to answer a DNS query. There are different requirements for caching and negative caching. While RRs in a well established, stable zone can be cached for a day or two without problems, negative responses should only be cached in the range of hours. The remaining real meanings for the MINIMUM field now correspond to values for either the default caching TTL or the negative cahing TTL. We are in a transition phase from the former to the latter, and actual interpretation depends on the software running on the primary and secondary servers. If the old default TTL meaning is implied, use 172800, otherwise 3600. If the servers Koch Expires July 1999 [Page 5] INTERNET-DRAFT RIPE DNS Guide January 1999 run different software, use 172800 here and explicitly set the TTL for the SOA RR to 3600. A complete example would look like this bricks.example. 3600 IN SOA red.bricks.example. hostmaster.bricks.example. ( 1999012300 86400 7200 3600000 172800 ) 2.2. The A RR Type One of the main tasks of the DNS is translating domain names in IP adresses. This is done with A RRs. Their data portion contains a single IP address in dotted quad notation, like here: yellow.bricks.example. IN A 192.168.8.15 Publishing addresses from the private address space should be avoided. [XXX so why doesn't the example comply?] 2.3. The NS RR Type The NS RRs tell the world who is able to give out information about your zone. Enter a single NS RR for every server which is intended to provide secondary service for your zone, see the list mentioned earlier. Do not enter random nameservers' names just because you have seen them somewhere. The administrators may not want to deal with that additional load and they may even - as a defense - provide explicit non-service. Apart from the secondaries you should enter a NS RR for your own name server here. However, this will make random sources direct DNS queries to your name server. There are several reasons why one might want to avoid this. Amongst others, you may live behind a dialup line and do not want it to be triggered by avoidable traffic. To accomplish this, there's a concept called "stealth" or "hidden" primary. It is implemented by not publishing NS RRs for the primary (and to be efficient, no NS RRs for any other of your systems, either). All the DNS queries are then answered by the secondaries. This is only useful if the list of nameservers handed to the TLD registry does not contain your server, so consult with your ISP first. They may or may not support this concept and there may be an additional charge. Koch Expires July 1999 [Page 6] INTERNET-DRAFT RIPE DNS Guide January 1999 The order of the NS RRs is not important, the protocol allows for arbitrary reshuffling of RRs of the same type at the same owner. So there's neither the need that the primary be the first in this "list" nor the guarantee that it will always be handed out in any particular position. bricks.example. IN NS red.bricks.example. 2.4. The MX RR Type Not every host is configured to receive mail and some domain names represent organisations, not single hosts, and should nonetheless be useful in addressing electronic mail. By using MX (mail exchanger) RRs you can define which host or group of host mail addressed to a certain domain should be sent to. Every MX RR has a precedence, lower values resulting in higher priority. The values have no intrinsic meaning, they're just for sorting the list. In this example bricks.example. IN MX 100 black.bricks.example. bricks.example. IN MX 200 mail-relay.YourISP.example. all mail to an address <user(a)bricks.example> will be sent to the host "black.bricks.example". Should that machine be unreachable, the mail would delivered to "mail-relay.YourISP.example" instead, which would later repeatedly try to bring the message to its destination. Do not enter any MX RRs pointing to a mail relay without prior agreement from that system's maintainers. They will usually not act as a relay for random targets, so your mail me be lost. In general your ISP will provide one or more mail relays, so ask them for assistance. Note that this relay for incoming mail may be different from that machine you send yourt outgoing mail to. As a target of an MX or NS resource record only domain names are allowed which directly resolve into an address. That means: 1) The name you enter must exist. Note that your software may let you enter names which do not exist without complaining. It is the DNS administrators responsibility to check this. A very helpful tool for this purpose is "host" [REF TBD]. 2) The name must really be a name. The DNS will not understand IP addresses here. Note however, that again your software may let you make the mistake but that it will definitely not bring you the results you wanted. Use only domain names here. Koch Expires July 1999 [Page 7] INTERNET-DRAFT RIPE DNS Guide January 1999 3) The domain name used must directly resolve into an address, which means you must not use an alias name here and an A resource record must exist for that name. Note that unless the name is part of your namespace you must not enter that A record yourself. 2.5. The CNAME RR Type It is possible to specify alias names for machines, e.g. if your machine "yellow.bricks.example" is also your web server, you can define an alias "www.bricks.example" to point to the canonical name, "yellow.bricks.example" in this case. www.bricks.example. IN CNAME yellow.bricks.example. The name at the right hand side is the canonical name, whereas the owner on the left turns out to be the alias name. There are some caveats: CNAME RRs, like sharks, eat all their siblings before they become visible, or in more formal wording: if a CNAME RR exists for an owner, no other RR for that owner may exist, neither CNAME nor any other type. This means you not only do not need to, but you must not define any other RR in parallel. All RRs at the canonical name will equally be valid for the alias. In the example above, a query for an MX RR for "www.bricks.example" will return the MX RRs for "yellow.bricks.example" if there are any, which better be the case. If you want your web server to be addressable by "bricks.example" in addition to "www.bricks.example", resist the temptation to define a CNAME RR for the owner "bricks.example" pointing to "www.bricks.example" (or anywhere else). This would invalidate your zone, because the necessary SOA and NS RRs cannot coexist with the CNAME RR. Your software may let you do this, but it will lead to unfortunate results, including zone expiry at the secondaries. Use CNAME RRs with care, and have them point to your own systems only. 2.6. Wildcard owners Apart from the owner names seen so far, the DNS supports "wildcard" owners, which cover all names "below" a paricular domain name, unless such owner name is explicitly defined. *.bricks.example. IN MX 100 red.bricks.example. This will make the DNS server return an appropriate response for queries for MX RRs for "green.bricks.example", "blue.red- bricks.example" and even "light.blue.bricks.example". However, the wildcard has two counter-intuitive properties: Koch Expires July 1999 [Page 8] INTERNET-DRAFT RIPE DNS Guide January 1999 1) It does not cover any owner name for which *any* type of RR is explicitly defined. If you associate an A RR with the name "blue.bricks.example", the wildcard above will not lead to an MX RR defined for "blue.bricks.example". It is even worse: the wildcard would not even work for "blue.bricks.example" if you just defined any record for "dark.blue.bricks.example". 2) It does not cover the name itself, which trivially follows from the previous paragraph. So, the wildcard above does not cover "red-bricks.example". Use of wildcard owners is most common, but not restricted to, for defining MX RRs. However, die to the problems described above and some other problems your mail server may encounter when it lives in a zone with wildcard MX RRs, they should be avoided. [XXX name useful cases] 3. Valid hostnames There has been a lot of confusion on which characters are valid in hostnames. Partly this has come from the question what a hostname is. A good rule of thumb is to consider every domain name with an A RR attached to it and every domain name expected to have an A RR attached to it (like targets in MX and NS RRs) a hostname. For domain names in general, no character restrictions apply. Hostnames are restricted to letters (since the DNS is case insensitive, no further distinction is necessary), digits, the hyphen and, of course, the dot to separate names on different domain levels (labels). A hyphen must not be the first or last character in a label. The underscore "_" is not a valid character for hostnames, neither are the ampersand or a space, to name a few. There's nothing magic about the "_", it is just that it seems to be popular but was not included in the allowed set once it was defined. TLD registries will usually, although registering domain names instaed of just hostnames, enforce hostname restrictions. They may also define additional syntax requirements. 4. Reverse Mapping TBD 5. Mistakes to avoid Practice has been showing that novice DNS administrators tend to make some particular mistakes more often than others. The following list deals with the most common misunderstandings. Koch Expires July 1999 [Page 9] INTERNET-DRAFT RIPE DNS Guide January 1999 5.1. Secondaries not necessarily act as resolvers or forwarders As mentioned earlier, there is a difference between serving DNS zones and resolving DNS queries. Both services may be offered by the same machine, but for security, performance and various operational reasons, your ISP may have dedicated different systems to either task. [...] 5.2. Zone transfer restrictions can be too strict A zone transfer (AXFR) is a bulk transfer of all the DNS data contained in a DNS zone. Secondaries copy the zone data from the primary by the way of an AXFR query. On several occasions, malicious individuals or groups have been using this zone transfer for harvesting names and addresses. Later they probe each system found for well known security holes to find victims for system breakins. To avoid this, some people suggest to restrict outgoing zone transfers on your DNS server. While this "information hhiding" may stop some kids, it will increase your system security be exactly zero. First, to work, this scheme would have to be implemented at all your secondaries, too. You can't be sure about that and doing so would sometimes be infeasible for the respective server maintainers. Even worse, nobody could stop a harvester from querying for particular or popular names within your zone, like "www", "mail" or "ftp". At last, an intruder would not have to bother with asking the DNS in advance. They just scan complete IP address ranges for vulnerable systems. So, to be safe, protect your end systems and network infrastructure, do not just hide information. However, even if you choose to restrict AXFR, you must not prevent your zone's secondary servers from transferring the data. In addition the TLD registry and your ISP may require to AXFR your zone data for validation purposes. A last word on this: not all AXFR attempts will show you some hacker is looking at your data. Sometimes there are just curious individuals, somebody tracking down a problem or one of the various projects, which scan through the DNS to produce statistics (the monthly RIPE DNS hostcount is a prominent example). If in doubt, consult your ISP. 5.4. enabling WINS lookup TBD 6. Acknowledgements TBD Koch Expires July 1999 [Page 10] INTERNET-DRAFT RIPE DNS Guide January 1999 7. References [ALLIU98] Albitz,P., Larson,M., Liu,C., "DNS and BIND", O'Reilly, 3rd ed., September 1998 [ALLAL98] Albitz,P., Larson,M., Liu,C., "DNS on Windows NT", O'Reilly, November 1998 [RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities", RFC 1034, STD 13, November 1987 [RFC1035] Mockapetris,P., "Domain Names - Implementation and Specification", RFC 1035, STD 13, November 1987 [RFC2219] Hamilton,M., Wright,R., "Use of DNS Aliases for Network Services", RFC 2219, BCP 17, October 1997 [RFC2142] Crocker,D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS", RFC 2142, May 1997 [.......] 8. Author's Address Peter Koch Universitaet Bielefeld Technische Fakultaet Postfach 10 01 31 D-33501 Bielefeld Germany +49 521 106 2902 <pk(a)TechFak.Uni-Bielefeld.DE> Koch Expires July 1999 [Page 11]

2 1

DRAFT: "RIPE Guide To Setting Up a DNS Server"
by Peter Koch 24 Jan '99

24 Jan '99

Dear RIPE DNS WG, find below a draft document "RIPE Guide To Setting Up a DNS Server" to serve as a basis for recommendations to customers on how to set up their DNS server. The target audience is the maintainer of a zone with population lower than 10 (the vast majority of zones, at least within the DE TLD), who usually has very low operational experience and too few changes to apply to develop such experience in "day to day" work. It was started from scratch intentionally, so there are a few items missing from previous similar drafts on this list. The document has already become larger than I intended, but those missing pieces should be identified and merged in (or part of this merged into the other). Comments are very welcome. In particular I'd like to hear opinions concerning the structure, volume and topics covered. The SOA values recommended here are a proposal for the thursday WG meeting. -Peter PS: Although it may give the impression, the draft was not posted as an I-D, I just borrowed that template. INTERNET-DRAFT Peter Koch Expires: July 1999 Universitaet Bielefeld January 1999 RIPE Guide To Setting Up a DNS Server <no file name, not yet submitted to the I-D maintainer> Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Comments should be sent to the author or the RIPE DNS WG mailing list <dns-wg(a)ripe.net>. Abstract This document is intended to guide novice and/or part time DNS zone administrators in getting their DNS zones up and running. It is not sufficiently detailed to replace a book about DNS. 1. Introduction The DNS is a distributed, redundant, hierarchical namimg scheme for mapping so called "domain names" into addresses and other Internet infrastructure elements. You will learn about those later. You will normally use two distinct services within the DNS. While using your web browser and email software your system will have to translate (foreign) domain names into IP addresses. This is called "resolving". The other task is presenting your domain name, once you have one, to other parties on the Internet to enable them to resolve your or your organisation's name into some address. This part is called "serving". While both deal with DNS and both tasks may even be carried out by the very same piece of software on your machine, they are different. This document is primarily concerned with setting up a DNS server, but at the end some information is provided on "DNS Koch Expires July 1999 [Page 1] INTERNET-DRAFT RIPE DNS Guide January 1999 resolving" issues. There are different Top Level Domains (TLDs) to register with, such as "COM" or those country-code based like "FR" for France and "DE" for Germany. You may also find offers for registration within "new" or "private" TLDs, e.g. "WEB". At the moment these are bogus. If in doubt, check the official list at [TBD]. To register a domain name, in most cases two or more nameservers need to be set up to serve the corresponding zones, i.e. answer queries dynamically sent in from all over the Internet. "in most cases" means, that some Top Level Domain (TLD) registries will allow the existence of real data instead of just pointers to nameservers in their database. Whether this is the case you should ask your ISP or the registry responsible for the TLD you are interested in. Do not forget to ask for the cost of making modifications to the data later. If your organisation is going to expose only a small number of systems to the globally visible Internet, maybe only a web server and a mail relay, you will have to publish only a very small set of data in the DNS. In this case - but sometimes also in others - it is not really necessary to bother with the operation of an own DNS server. Your ISP may offer running the DNS server and maintaining the zone data for you. This value added service, however, may require an additional fee. While DNS isn't rocket science, it is a mission critical service, and there are some trapdoors potentially disturbing the proper operation. You may wish to take the opportunity having this done by somebody who makes a living out of it. For those of you, who choose to do the job themselves, we want to help you navigate around the most common pitfalls. Apart from your own nameserver the DNS protocol requires a set of so called "secondary" or "slave" servers, which will publish the same data about your zones your server does, but which are placed at other parts of the Internet. In most cases your ISP will offer help in locating proper secondary servers or even run one or more of them themselves. Again, this service may require an additional fee, so please consult your ISP. You may find some documentation suggesting to have two nameservers at your installation. This is not considered reasonable practice and will, apart from increasing your work (and even network) load, give you nothing. Now that you have a domain name, a list of secondaries for serving your zone and some address space, you can start constructing a zone. Consult the documentation of your DNS server software for where to Koch Expires July 1999 [Page 2] INTERNET-DRAFT RIPE DNS Guide January 1999 start, this document will assist you in filling in the proper values. 2. DNS Resource Records The information in the DNS is handled in pieces of "resource records" (RRs). There are different types of RRs, every resource record is bound to a domain name (the "owner"). A single "owner" may own several RRs of equal or different types. We will only talk about "SOA", "NS", "MX", "A" and "CNAME" RRs. 2.1. The SOA RR Type While some people claim the Internet being the end of all authorities, one of the first things you will have to enter is a "Start Of Authority" record. There is a single SOA record per zone containing some meta information like who the maintainer is and how often secondaries should check with the primary for modifications to the zone. There are seven elements in an SOA record: 1) The MNAME (master name) must give the name of the primary master server for that zone, i.e. the machine you are running your DNS server on. There is no need to reserve a special name, like "ns" or "dns" for this system, so use the canonical name of that machine. [XXX explain FQDNs] 2) The RNAME is to publish a mail address of a person or role account dealing with this zone. The "@" must be converted to a "." before you enter this, so postmaster(a)bricks.example becomes postmaster.bricks.example. Be sure to name a working address here (NB: your domain is not yet registered, but the local part should be defined at your site). Do not accept any default your software may suggest without checking its validity. If your addresses follow the popular scheme "first.last(a)canonical.example", although technically possible, do not use any of these here. The distinction between the "." seperating first and last name and the translated "@" will eventually be lost, leading to an unreachable email adress due to wrong retranslation. The same caveat holds for other addressing schemes with dots in the local part ("10000.0815(a)kangooserve.example"). The best practice is to define (and maintain) a dedicated mail alias "hostmaster" [RFC2142] for your DNS operations. 3) The SERIAL number Secondaries have to check with the primary for new versions of a Koch Expires July 1999 [Page 3] INTERNET-DRAFT RIPE DNS Guide January 1999 DNS zone. For efficiency reasons, serial numbers are compared only. If the serial number at the primary is higher than the secondary's local copy, the zone is copied. If the serial at the primary is equal to or less than the one at the secondary nothing happens. This means that after every modification to the zone you have to increase the serial and you should in any case avoid to decrease it. Update the serial number even if you make mulltiple changes within short intervals, one of the secondaries may have fetched its new copy in the meantime. The serial number is a an unsigned 32bit integer with no further implied meaning. Also, the increments do not have any special meaning. You can grow the serial by 1, 10 or 170 every time as long as it just always increases. The serial number 0 should be avoided due to some problems in certian software versions. There is a popular scheme which builds the serial number by using the actual date, e.g. 1999012300 for a zone changed at January, 23rd, 1999. The trailing two digits leave enough space for 100 modifications per day. This scheme is called YYYYMMDDnn, some similar are also in use. Be sure to use a four digit year, notice that the month preceeds the day and do not forget to update the year value upon the first change every year. 4) The REFRESH value This value controls how frequently the secondaries will check with your primary to see whether your zone was modified and they must update their copy. Modern DNS server software will send out additional notifications from the primary to the secondaries upon reload of a modified zoen, so usually the information is distributed much faster than this. However, notification packages may be lost, so the secondary-initiated checks are still useful. A value of one day (86400 seconds) is recommended here. 5) The RETRY value Should a secondary be unable to reach the primary for whatever reason, the next attempt is started in intervals given by RETRY until the zone could be successfully checked or it expires (see below). Any value larger than REFRESH doesn't make sense, usually the maximum of two hours and a fraction of 1/6 to 1/4 of REFRESH are good choices. So, if you followed the recommendation above, enter 7200 (two hours) here. The lower the values for REFRESH and RETRY, the more load is put on the secondary servers. This is not a big deal for a single zone, but it has to scale for large nameservers serving several Koch Expires July 1999 [Page 4] INTERNET-DRAFT RIPE DNS Guide January 1999 thousand zones. Therefore your ISP resp. the operator(s) of your secondaries may give you additional advice and will probably recommend different values. If in doubt, ask them first. 6) The EXPIRE value Should a secondary be unable to check the zone with the primary for a period of time specified by EXPIRE, it will just do that - expire the zone. Unfortunately it is not precisely specified what that means, but from that time on you can no longer expect that secondary to hand out any useful information about your zone. Of course, this is a scenario you will want to avoid, benause it may lead users to wrong addresses or even make them feel your or your web site's domain name do no longer exist. There are several reasons, why a secondary's check would fail: temporary line failures, machine downtimes and most importantly: configuration errors at your primary. To give yourself a chance of detecting and repairing such problems, the EXPIRE value should be long enough to cover even a short holiday. A value of 3600 hours (3600000) is traditionally recommended here. Be especially warned that values of a week or less, while having no benefit, have drasticly proven to be too short. 7) The MINIMUM value There are three different meanings applied to this, of which the first appeared in the original protocol implementation but was never widely implemented. To explain the other two we need to tell about yet another DNS feature - caching. DNS servers are queried by DNS resolvers, and those resolvers usually remember (cache) any results seen for a certain amount of time. This way the total DNS traffic on the Internet, the server load and most importantly the response times will be reduced. There is both caching of RRs and negative caching, which means the knowledge of non-existance of a certain name or RR type will be maintained. The predicted lifetime (TTL) of such information is to be controlled by the zone administrator, every RR will be tagged with a TTL value when used to answer a DNS query. There are different requirements for caching and negative caching. While RRs in a well established, stable zone can be cached for a day or two without problems, negative responses should only be cached in the range of hours. The remaining real meanings for the MINIMUM field now correspond to values for either the default caching TTL or the negative cahing TTL. We are in a transition phase from the former to the latter, and actual interpretation depends on the software running on the primary and secondary servers. If the old default TTL meaning is implied, use 172800, otherwise 3600. If the servers Koch Expires July 1999 [Page 5] INTERNET-DRAFT RIPE DNS Guide January 1999 run different software, use 172800 here and explicitly set the TTL for the SOA RR to 3600. A complete example would look like this bricks.example. 3600 IN SOA red.bricks.example. hostmaster.bricks.example. ( 1999012300 86400 7200 3600000 172800 ) 2.2. The A RR Type One of the main tasks of the DNS is translating domain names in IP adresses. This is done with A RRs. Their data portion contains a single IP address in dotted quad notation, like here: yellow.bricks.example. IN A 192.168.8.15 Publishing addresses from the private address space should be avoided. [XXX so why doesn't the example comply?] 2.3. The NS RR Type The NS RRs tell the world who is able to give out information about your zone. Enter a single NS RR for every server which is intended to provide secondary service for your zone, see the list mentioned earlier. Do not enter random nameservers' names just because you have seen them somewhere. The administrators may not want to deal with that additional load and they may even - as a defense - provide explicit non-service. Apart from the secondaries you should enter a NS RR for your own name server here. However, this will make random sources direct DNS queries to your name server. There are several reasons why one might want to avoid this. Amongst others, you may live behind a dialup line and do not want it to be triggered by avoidable traffic. To accomplish this, there's a concept called "stealth" or "hidden" primary. It is implemented by not publishing NS RRs for the primary (and to be efficient, no NS RRs for any other of your systems, either). All the DNS queries are then answered by the secondaries. This is only useful if the list of nameservers handed to the TLD registry does not contain your server, so consult with your ISP first. They may or may not support this concept and there may be an additional charge. Koch Expires July 1999 [Page 6] INTERNET-DRAFT RIPE DNS Guide January 1999 The order of the NS RRs is not important, the protocol allows for arbitrary reshuffling of RRs of the same type at the same owner. So there's neither the need that the primary be the first in this "list" nor the guarantee that it will always be handed out in any particular position. bricks.example. IN NS red.bricks.example. 2.4. The MX RR Type Not every host is configured to receive mail and some domain names represent organisations, not single hosts, and should nonetheless be useful in addressing electronic mail. By using MX (mail exchanger) RRs you can define which host or group of host mail addressed to a certain domain should be sent to. Every MX RR has a precedence, lower values resulting in higher priority. The values have no intrinsic meaning, they're just for sorting the list. In this example bricks.example. IN MX 100 black.bricks.example. bricks.example. IN MX 200 mail-relay.YourISP.example. all mail to an address <user(a)bricks.example> will be sent to the host "black.bricks.example". Should that machine be unreachable, the mail would delivered to "mail-relay.YourISP.example" instead, which would later repeatedly try to bring the message to its destination. Do not enter any MX RRs pointing to a mail relay without prior agreement from that system's maintainers. They will usually not act as a relay for random targets, so your mail me be lost. In general your ISP will provide one or more mail relays, so ask them for assistance. Note that this relay for incoming mail may be different from that machine you send yourt outgoing mail to. As a target of an MX or NS resource record only domain names are allowed which directly resolve into an address. That means: 1) The name you enter must exist. Note that your software may let you enter names which do not exist without complaining. It is the DNS administrators responsibility to check this. A very helpful tool for this purpose is "host" [REF TBD]. 2) The name must really be a name. The DNS will not understand IP addresses here. Note however, that again your software may let you make the mistake but that it will definitely not bring you the results you wanted. Use only domain names here. Koch Expires July 1999 [Page 7] INTERNET-DRAFT RIPE DNS Guide January 1999 3) The domain name used must directly resolve into an address, which means you must not use an alias name here and an A resource record must exist for that name. Note that unless the name is part of your namespace you must not enter that A record yourself. 2.5. The CNAME RR Type It is possible to specify alias names for machines, e.g. if your machine "yellow.bricks.example" is also your web server, you can define an alias "www.bricks.example" to point to the canonical name, "yellow.bricks.example" in this case. www.bricks.example. IN CNAME yellow.bricks.example. The name at the right hand side is the canonical name, whereas the owner on the left turns out to be the alias name. There are some caveats: CNAME RRs, like sharks, eat all their siblings before they become visible, or in more formal wording: if a CNAME RR exists for an owner, no other RR for that owner may exist, neither CNAME nor any other type. This means you not only do not need to, but you must not define any other RR in parallel. All RRs at the canonical name will equally be valid for the alias. In the example above, a query for an MX RR for "www.bricks.example" will return the MX RRs for "yellow.bricks.example" if there are any, which better be the case. If you want your web server to be addressable by "bricks.example" in addition to "www.bricks.example", resist the temptation to define a CNAME RR for the owner "bricks.example" pointing to "www.bricks.example" (or anywhere else). This would invalidate your zone, because the necessary SOA and NS RRs cannot coexist with the CNAME RR. Your software may let you do this, but it will lead to unfortunate results, including zone expiry at the secondaries. Use CNAME RRs with care, and have them point to your own systems only. 2.6. Wildcard owners Apart from the owner names seen so far, the DNS supports "wildcard" owners, which cover all names "below" a paricular domain name, unless such owner name is explicitly defined. *.bricks.example. IN MX 100 red.bricks.example. This will make the DNS server return an appropriate response for queries for MX RRs for "green.bricks.example", "blue.red- bricks.example" and even "light.blue.bricks.example". However, the wildcard has two counter-intuitive properties: Koch Expires July 1999 [Page 8] INTERNET-DRAFT RIPE DNS Guide January 1999 1) It does not cover any owner name for which *any* type of RR is explicitly defined. If you associate an A RR with the name "blue.bricks.example", the wildcard above will not lead to an MX RR defined for "blue.bricks.example". It is even worse: the wildcard would not even work for "blue.bricks.example" if you just defined any record for "dark.blue.bricks.example". 2) It does not cover the name itself, which trivially follows from the previous paragraph. So, the wildcard above does not cover "red-bricks.example". Use of wildcard owners is most common, but not restricted to, for defining MX RRs. However, die to the problems described above and some other problems your mail server may encounter when it lives in a zone with wildcard MX RRs, they should be avoided. [XXX name useful cases] 3. Valid hostnames There has been a lot of confusion on which characters are valid in hostnames. Partly this has come from the question what a hostname is. A good rule of thumb is to consider every domain name with an A RR attached to it and every domain name expected to have an A RR attached to it (like targets in MX and NS RRs) a hostname. For domain names in general, no character restrictions apply. Hostnames are restricted to letters (since the DNS is case insensitive, no further distinction is necessary), digits, the hyphen and, of course, the dot to separate names on different domain levels (labels). A hyphen must not be the first or last character in a label. The underscore "_" is not a valid character for hostnames, neither are the ampersand or a space, to name a few. There's nothing magic about the "_", it is just that it seems to be popular but was not included in the allowed set once it was defined. TLD registries will usually, although registering domain names instaed of just hostnames, enforce hostname restrictions. They may also define additional syntax requirements. 4. Reverse Mapping TBD 5. Mistakes to avoid Practice has been showing that novice DNS administrators tend to make some particular mistakes more often than others. The following list deals with the most common misunderstandings. Koch Expires July 1999 [Page 9] INTERNET-DRAFT RIPE DNS Guide January 1999 5.1. Secondaries not necessarily act as resolvers or forwarders As mentioned earlier, there is a difference between serving DNS zones and resolving DNS queries. Both services may be offered by the same machine, but for security, performance and various operational reasons, your ISP may have dedicated different systems to either task. [...] 5.2. Zone transfer restrictions can be too strict A zone transfer (AXFR) is a bulk transfer of all the DNS data contained in a DNS zone. Secondaries copy the zone data from the primary by the way of an AXFR query. On several occasions, malicious individuals or groups have been using this zone transfer for harvesting names and addresses. Later they probe each system found for well known security holes to find victims for system breakins. To avoid this, some people suggest to restrict outgoing zone transfers on your DNS server. While this "information hhiding" may stop some kids, it will increase your system security be exactly zero. First, to work, this scheme would have to be implemented at all your secondaries, too. You can't be sure about that and doing so would sometimes be infeasible for the respective server maintainers. Even worse, nobody could stop a harvester from querying for particular or popular names within your zone, like "www", "mail" or "ftp". At last, an intruder would not have to bother with asking the DNS in advance. They just scan complete IP address ranges for vulnerable systems. So, to be safe, protect your end systems and network infrastructure, do not just hide information. However, even if you choose to restrict AXFR, you must not prevent your zone's secondary servers from transferring the data. In addition the TLD registry and your ISP may require to AXFR your zone data for validation purposes. A last word on this: not all AXFR attempts will show you some hacker is looking at your data. Sometimes there are just curious individuals, somebody tracking down a problem or one of the various projects, which scan through the DNS to produce statistics (the monthly RIPE DNS hostcount is a prominent example). If in doubt, consult your ISP. 5.4. enabling WINS lookup TBD 6. Acknowledgements TBD Koch Expires July 1999 [Page 10] INTERNET-DRAFT RIPE DNS Guide January 1999 7. References [ALLIU98] Albitz,P., Larson,M., Liu,C., "DNS and BIND", O'Reilly, 3rd ed., September 1998 [ALLAL98] Albitz,P., Larson,M., Liu,C., "DNS on Windows NT", O'Reilly, November 1998 [RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities", RFC 1034, STD 13, November 1987 [RFC1035] Mockapetris,P., "Domain Names - Implementation and Specification", RFC 1035, STD 13, November 1987 [RFC2219] Hamilton,M., Wright,R., "Use of DNS Aliases for Network Services", RFC 2219, BCP 17, October 1997 [RFC2142] Crocker,D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS", RFC 2142, May 1997 [.......] 8. Author's Address Peter Koch Universitaet Bielefeld Technische Fakultaet Postfach 10 01 31 D-33501 Bielefeld Germany +49 521 106 2902 <pk(a)TechFak.Uni-Bielefeld.DE> Koch Expires July 1999 [Page 11]

1 0

Re: DNS recommendations - the paper (fwd) -- sorry Piet!
by Alvaro Jose Fernandez Lago 27 Nov '98

27 Nov '98

Forwarded message: > > What about wildcard MXs in the paper? I feel the issue should be noted as per RFC1912, for example. Regards, Alvaro Fdez. Lago Hospital Xeral-Cies de Vigo, Spain alago(a)unicies.cesga.es

2 1

another DNS recommendation
by e07＠nikhef.nl 26 Nov '98

26 Nov '98

I'm biased, but I would add one other recommendation: If you are the maintainer of a certain DNS <zone> and your <zone> passes all tests via the command host -C -A -L 1 <zone> then your <zone> is probably in very good shape. -- Eric Wassenaar URL: ftp://ftp.nikhef.nl/pub/network/host.tar.Z Current version: 980903 This is contrib/host in the BIND distribution. (Also reread the message from Peter Koch to this mailing list dd. 14 May 1998)

2 1

[hallgren@fdn.org: Re: Hello]
by Michael Hallgren 25 Nov '98

25 Nov '98

Well,... mh -- Michael Hallgren, http://mh.graphnet.fr

1 0

DNS recommendations - the paper
by Elmar K. Bins 25 Nov '98

25 Nov '98

Content-Description: DNS recommendations RIPE DNS-WG paper DNS recommendations Originally by: Hans Niklasson <hasse(a)swip.net> Amar Andersson <amar(a)telia.net> Reworked by: Elmar K. Bins <ekb(a)ivm.net> (use the dns-wg(a)ripe.net list for discussion :-) ) Remark to dns-wg: Although (or maybe because of) being new to RIPE as an active person, I was very unsatisfied with the status of this paper after having attended Hans' presentation and thought that given experience with DNS getting the paper ready would not take one too long. Rationale: So what this paper should deliver is a structured guide to what a DNS administrator should regard when setting up her zones. Many of us know their parameters by heart whereelse others are new to the business and still have to look up parts of it. Not to mention copying broken zones as I did for a long time (and it was a pain to fix all of them). Scope: This documents act as a recommendation for configuring your DNS. This is NOT a requirement, only a recommendation of things to think about when setting up your DNS. Purpose: To decrease lame delegations and limit unecessary traffic due to resolving problems, among other things. Records: ----------------------------------------------------------------------------- ================================= SOA Start of Authority Record ================================= Synopsis @ IN SOA <originating dns server> <dottified admin email>\ ( <serial number> <refresh> <retry> <expire> <minimum TTL> ) Example @ IN SOA ns.isp.net. netmaster.isp.net. ( 1998100100 86400 3600 604800 345600 ) Semantics The SOA record gives the originating host's name, the email address of the person responsible for the zone, timeout values to be used by secondaries and the TTL preset/default. There is only one SOA record per zone. originating dns server: Canonical hostname of the DNS server authoritatively carrying this zone. In case of hidden primary setup, put the exposed primary. Don't forget to close with a dot. dottified admin email: The administrator's email address in a form where the "@" has been replaced by a dot. To regain the address, replace the first dot by an at sign. serial number: Changed zones are only reloaded if a higher serial number than the already known one is encountered, so be sure to increase this number with every change you want to be seen. refresh: Secondaries check every <refresh> seconds, whether the SOA on the primary has changed. If yes, a zone transfer is done. retry: A secondary having been unable to do a zone transfer because of unreachable of the primary retries every <retry> seconds. expire: The zone's information is considered invalid by the secondary if the primary could not be reached for <expire> seconds. minimum TTL: This is the default value for all records in the zone file which can be overriden by values for the individual records. After <minimum TTL> seconds, the zone information on the caching nameserver becomes invalid and has to be re-fetched from an authoritative server. NOTE: This field was intended to be a minimum value for all records in the zone but is now widely implemented as giving the default. Recommendations and remarks originating dns server: As stated above, insert the name of the originating server that is reachable from the Internet. dottified admin email: The email address here cannot contain dots left of the "@" sign, since it's always the _first_ dot that's being replaced. Remember: This email address must be valid. So it seems to be good practice to use a role account address instead of a personal address - just in case your admin leaves your company. serial number: There's a widely agreed upon form of the serial number that is both easily readable and less errorprone which reads YYYYMMDDnn with YYYY being the 4-digit year (year 2000 is near), MM the 2-digit month, DD the day (again 2 digits) and nn the number of the latest update of the zone on the same day. All of those fields lest the year are left-padded with zeroes. refresh: This timeout determines the "currentness" of the secondaries' information about a zone. Set it to a lower value if changes to the zone are expected in the near future, so your secondary servers stay up to date. 86400 (24 hours) seems a reasonable value to start with. NOTE: If you are running bind 8.x, you may keep this value pretty high and have your DNS server send notification signals to your secondaries. [jh] retry: The retry timeout should be fairly low to have the secondary regain authoritativeness as soon as possible after the primary has become available again. Of course, setting this too low will only mean wasting bandwidth. 3600 (1 hour) seems a reasonable value although most of us are using longer retry timeouts. expire: Old data is, speaking of customers, almost always better than no data at all, so keep this value high enough to be able to buy and install a machine within expiry time if your primary dies. 604800 (7 days) is the value used here. [ekb] minimum TTL: Like with the refresh value, if a quick change to the zone is expected in the near future, temporarily lower the minimum TTL. Don't forget to increase it to a reasonable value after the change is done, because this value is probably the most common source of bandwidth waste in the whole Internet ;-) 345600 (4 days) may already be too short for a stable zone. =========================== NS Name Server Records =========================== Synopsis [<zone>] [<TTL>] IN NS <authoritative server> Examples IN NS ns.isp.net. ; NS for all of the zone's domain bla IN NS ns.cust.com. ; subdelegation for bla.<zone> Semantics As you might have guessed already, this record denotes the supposed-to-be authoritative DNS servers for the current zone (or the zone given). authoritative server: The <authoritative server> given must be the FQDN for the nameserver machine. Check its correctness in advance and don't forget the trailing dot. Recommendations and remarks Have the zone's NS records, the registry's and RIPE's nameserver information consistent, and do not give nameservers with whose administrators you have not coordinated in advance. Remember that most registries require you to have at least two authoritative servers reachable via different routes. ============================== MX Mail Exchanger Records ============================== Synopsis [<host/subdom name>] [<TTL>] IN MX <preference> <mailhost> Examples IN MX 100 relay.isp.net. ; fallback MX for domain <zone> IN MX 10 mail.cust.com. ; final MX bla IN MX 100 relay.isp.net. ; fallback MX for bla.<zone> IN MX 10 blamail ; blamail.<zone> needs an A record Semantics MX records tell a foreign mail server where to deliver mail to addresses in our domain. preference: This field is the numerical preference for mail delivery to the machine mentioned. Lower values are tried first. mailhost: Mentions the name of a machine that accepts mail for our domain. Recommendations and remarks FQDNs are preferred, local (to <zone>) hosts are can be used as well. Verify that A records exist for the MX hosts and don't forget the trailing dot on FQDNs. Have at least two MX records to ensure delivery. It is not a good idea to have MX records point to CNAME'd hosts. This will almost certainly get you into a lot of trouble. Use hosts with proper A records instead. ======================= A Address Records ======================= Synopsis [<hostname>] [<TTL>] IN A <IPV4 address> [<IPV4 address> ...] Examples mail IN A 123.45.67.8 ; our mail host www IN A 123.45.67.10 123.45.67.11 ; multiple hardware IN A 123.45.67.9 ; <zone> as a hostname ;-) Semantics A records contain the data that performs name-to-number translation. Recommendations and remarks Do not use FQDNs in the <host> part. Hosts in subdomains à la "www.internal", which resolve to "www.internal.<zone>" are okay though. Remember that IP addresses do not end in a dot. Do not forget to maintain reverse delegation as well. ============================== CNAME Canonical Name Records ============================== Synopsis <alias> [<TTL>] IN CNAME <hostname> Example news IN CNAME news.isp.net. Semantics CNAME records provide a means to give aliases to machines. This can be used to have entries in one zone have the same data as hosts in a completely different zone. If a hosts IP address changes in the other domain there is no maintenance necessary on our side to change the hosts IP address Recommendations and remarks CNAME records are not being cached by name servers and thus should be used as rarely as possible to avoid unnecessary network traffic. It is not a good idea to have MX records point to CNAME'd hosts. ======================= PTR Reverse Records ======================= Synopsis <ip-fragment> [<TTL>] IN PTR <hostname> [<hostname> ...] Examples 123.45.67.8 IN PTR mail.cust.com. 10 IN PTR www.cust.com. Semantics PTR records provide the reversed functionality of A records, resolving IP addresses to hostnames. Recommendations and remarks Make sure that your PTR and A records match. Having a customer use machines without PTR records will resume in unresponsive FTP servers, which often do reverse lookups for security purposes. ========================= HINFO Host Info Records ========================= Synopsis <host> [<TTL>] IN HINFO <CPU> <OS> Examples play IN HINFO i586 Linux-2.1.107 Semantics HINFO records contain information about the CPU type and the operating system running on a host. Recommendations and remarks Giving away information about CPU and operating system may open security holes. There seem to be a few reasons to be this open to the Internet community, some of which can be found in RfC 1035. I would strongly recommend not using HINFO records for security reasons. The Internet is no more the safe haven it has been. The values here were once required to be standardized CPU and OS names (see RfC 1010 and descendants), but are more or less free strings nowadays. ============================================== WKS Well Known Service Description Records ============================================== Synopsis <host> [<TTL>] IN WKS <address> <protocol> <service> [<service>...] Examples mail IN WKS 123.45.67.8 UDP domain IN WKS 123.45.67.8 TCP smtp domain Semantics The Well Known Services record describes the record provided by a particular protocol on a particular interface. The protocol is usually UDP or TCP, although it can be any of the protocols in /etc/protocols. The services can be any of the /etc/services services that use a port below 256. Recommendations and remarks The WKS record is seldom used. ==================== TXT Text Records ==================== Synopsis <host> [<TTL>] IN TXT <text> Examples news IN TXT Yesterday's news are today's olds. Semantics The values found in TXT records are entirely up to free interpretation. ----------------------------------------------------------------------------- General recommendations, remarks and tips ----------------------------------------------------------------------------- Glue records "Glue records" is a term that describes entering A records into a zone for machines whose hostnames do not lie within <zone>. With these glue records one tries to achieve resolution for foreign machines that are being used e.g. as name servers or mail exchangers. Glue records should almost never be necessary, provided the ISP has set up their nameservers properly. If this is not the case, why would you trust them to have their mail relays functioning? If you use glue records, don´t add unnecessary ones. This can cause resolving problems if the host changes IP address. Trailing dots: Don´t forget to add a dot (".") to the end of the domain/hostname. If this is forgotten, this will have the DNS add <zone> to the domain/hostname again. This will cause resolving problems. Something like IN MX 10 mail.cust.com Will lead to IN MX 10 mail.cust.com.cust.com. when fully resolved. Legal characters: Only A-Z/a-z (case does not matter), 0-9 and - are recommended. In fact, the full range of 8 bit characters is allowed everywhere but in hostnames. Yet to be on the secure side, do not use more than the range mentioned above. Some services may be more restricted than DNS. General Points: Always use the latest version of the DNS software for your platform. If you use bind, you should consider changing to the 8.x versions. 4.x is expected to be obsoleted soon. Check for updates regulary, as new versions provide current security and bug fixes. Additional reading and references: RFC1034 ( Domain Names - Concepts and Facilities ) RFC1035 ( Domain Names - Implementation and Specification ) RFC1537 ( RFC1912 ) ( Common DNS Operational and Configuration Errors ) "DNS & BIND 2nd Edition" by Paul Albitz & Cricket Liu from O´Reilly & Associates Inc. ftp://ftp.ripe.net/internet-drafts/draft-ietf-dnsind-classless- inaddr-04.txt ( For reverse delegation methods for blocks smaller than /24, 256 addresses ) http://www.dns.net/dnsrd/ ( DNS Resources Directory ) === fin === Regards, Elmi. -- | \ / |\/| Gesellschaft fuer Internet, Vernetzung und Mehrwertdienste mbH | \/ | | Zissener Str. 8 - D-53498 Waldorf - +49 2636 9769-0 - Fax -999 The Net People. Elmar K. Bins (ekb(a)ivm.net) http://www.ivm.net/

6 21

Re: DNS recommendations - the paper
by Berislav Todorovic 25 Nov '98

25 Nov '98

>> How far should this paper go into detail? I think it should contain only necessary summary info, with links to RFC's and other documents useful for DNS setup, where necessary. Some additional hints and corrections, I found while reading your document: * In the "Scope:" section add: "This document doesn't replace any DNS related RFC or any other good book dealing with DNS. It is a simple collection of hints for DNS administrators". * In the SOA section: parentheses are placed wrongly - instead of: >> @ IN SOA ns.isp.net. hostmaster.isp.net. >> ( 1998100100 86400 3600 604800 345600 ) you should write (both in the syntax block and the example): >> @ IN SOA ns.isp.net. hostmaster.isp.net. ( >> 1998100100 86400 3600 604800 345600 ) EXPLANATION: parentheses are not a mandatory part of a SOA record - they only serve to tell the DNS that rdata is split over multiple lines. In other words, you can use them in other records too, e.g. www IN CNAME ( server.domain.com. ) ; --- Of course, noone uses this as well as you can write the SOA record in one line: @ IN SOA ns.isp.net. hostmaster.isp.net. 1998100100 86400 3600 604800 345600 * Regarding "minimum TTL" - higher values make problems with zones that change more oftenly, while lower make a lot of unecessary traffic. I think the following text should be added to the section on "minimum TTL": "Minimum TTL should closely correspond to the average time interval between two successive zone contents changes, but not greater than 345600 (4 days). For example, if the zone is changed almost once or twice a day, 86400 (1 day) is a reasonable value. If, however, the zone is changed not more than once a week, there is no need to have such a small value of minimum TTL". * In the NS record section - the phrase: "There should be at least two of them for every zone," should be updated by: "There need not to be more than six servers for a zone". * In the MX section, add the following after " ... a lot of trouble.": "Furthermore, it is forbidden by the current RFC documents". * In the CNAME section add: "Avoid pointing CNAMEs to other CNAMEs". * The PTR section contains a possible mistake - are you sure you can write: >> 123.45.67.8 IN PTR mail.cust.com. Wouldn't say so - I think you'll get: 123.45.67.8.67.45.123.in-addr.arpa. IN PTR mail.cust.com. EXPLANATION: like all other records, PTR's have record name as the first parameter in the record. The server will automatically concatenate the reverse domain name if it doesn't find a trailing dot. Therefore, I would rewrite the whole section in the following manner: Synopsis <ip-fragment> [<TTL>] IN PTR <hostname> [<hostname> ...] Examples 8.67.45.123.in-addr.arpa. IN PTR mail.cust.com. Semantics PTR records provide the reversed functionality of A records, resolving IP addresses to hostnames. <ip-fragment> is the reverse written IP address of the host, appended to "in-addr.arpa'. Recommendations and remarks: Don't write whole names of PTR's (8.67.45.123.in-addr.arpa). If your inverse domain name is 67.45.123.in-addr.arpa, then use: 8 IN PTR mail.cust.com. (copy other recommendations). Add the following: "If you're assigned a network less than /24 (former "C class"), read RFC 2317 and consult your ISP before you set up your reverse zone". * In the "Legal Characters" section add the following: "Comments in the zone file are provided starting with a semicolon ';'. DON'T USE comment delimiters used in programming languages or operating system scripts (some exapmles of WRONG comment delimiters: #, !, C, /* */, //, { } ...). NOTE: this states for the ZONE FILES only! Comment delimiters in the boot file may differ (e.g. ';' is used in bind 4 named.boot file, while "//" is used in bind 8 named.conf file for comments; zone files, however, use ';' in both cases!). Some hints for future document extensions: * Forwarders - pro et contra. * Security - xfer access lists - what to do and what not to do. Regards, Beri .-------. | --+-- | Berislav Todorovic, B.Sc.E.E. | E-mail: BERI(a)etf.bg.ac.yu | /|\ Hostmaster of the YU TLD | |-(-+-)-| School of Electrical Engineering | Phone: (+381-11) 3221-419 | \|/ Bulevar Revolucije 73 | 3370-106 | --+-- | 11000 Belgrade SERBIA, YUGOSLAVIA | Fax: (+381-11) 3248-681 `-------' --------------------------------------------------------------------

4 3

Re: DNS recommendations - the paper
by Elmar K. Bins 25 Nov '98

25 Nov '98

BERI(a)etf.bg.ac.yu (Berislav Todorovic) wrote: > * In the "Scope:" section add: "This document doesn't replace any DNS > related RFC or any other good book dealing with DNS. It is a simple > collection of hints for DNS administrators". agreed. > * In the SOA section: parentheses are placed wrongly - instead of: True. Corrected. > EXPLANATION: parentheses are not a mandatory part of a SOA record - they > only serve to tell the DNS that rdata is split over multiple lines. In > other words, you can use them in other records too, e.g. I've added the explanation as well. > "Minimum TTL should closely correspond to the average time interval > between two successive zone contents changes, but not greater than > 345600 (4 days). For example, if the zone is changed almost once or > twice a day, 86400 (1 day) is a reasonable value. If, however, the > zone is changed not more than once a week, there is no need to have > such a small value of minimum TTL". I like this explanation, so I added it. > * In the NS record section - the phrase: "There should be at least two > of them for every zone," should be updated by: "There need not to be > more than six servers for a zone". I cannot second that. People tend more to have fewer NS servers than they are about to add more than six. Maybe both statements should be included here. I see no danger from more than six servers but I do see trouble brewing if you only have one (which, btw, no NIC will accept). I've added the part about "more than six". > * In the MX section, add the following after " ... a lot of trouble.": > "Furthermore, it is forbidden by the current RFC documents". > > * In the CNAME section add: "Avoid pointing CNAMEs to other CNAMEs". Added them and removed the part about "trouble" in the MX section. > * The PTR section contains a possible mistake - are you sure you can write: > > >> 123.45.67.8 IN PTR mail.cust.com. > > Wouldn't say so - I think you'll get: > > 123.45.67.8.67.45.123.in-addr.arpa. IN PTR mail.cust.com. > > EXPLANATION: like all other records, PTR's have record name as the first > parameter in the record. The server will automatically concatenate the > reverse domain name if it doesn't find a trailing dot. Yes, I think this is true. Problem is, this is not a real-life example. My zones only contain something like " 8 IN PTR mail.cust.com." since they are loaded as zones for (e.g.) 67.45.123.in-addr.arpa. Maybe we should really complete the example as shown above (thanks, that was not my own example, so I overlooked it). > "If you're assigned a network less than /24 (former "C class"), > read RFC 2317 and consult your ISP before you set up your reverse > zone". Ah, you're addressing the drive-my-own-server customer here. Ok :-) But I guess we need not go into the details of classless reverse delegation... > * In the "Legal Characters" section add the following: "Comments in the zone added (more briefly though) > Some hints for future document extensions: > > * Forwarders - pro et contra. > * Security - xfer access lists - what to do and what not to do. This concerns bind operation, not zones ;-) If somebody wants to set up recommendations for this I'd be happy to read... Regards, Elmi. -- | \ / |\/| Gesellschaft fuer Internet, Vernetzung und Mehrwertdienste mbH | \/ | | Zissener Str. 8 - D-53498 Waldorf - +49 2636 9769-0 - Fax -999 The Net People. Elmar K. Bins (ekb(a)ivm.net) http://www.ivm.net/

1 0

remove
by Didier Windmeulen 25 Nov '98

25 Nov '98

----- Original Message ----- From: Niels Bakker <niels(a)euro.net> To: <dns-wg(a)ripe.net> Sent: mercredi 25 novembre 1998 0:01 Subject: Re: DNS recommendations - the paper >Quoth Randy Bush: > >>> @ IN SOA ns.isp.net. netmaster.isp.net. >>> ( 1998100100 86400 3600 604800 345600 ) >> s/netmaster/hostmaster/ see RFC 2142 >> >> or, i think it was piet who recommended being conservative, and do not >> relying on aliases, rather use a real mailbox name. > >So that person can safely go on a two-week holiday? > >I'd rather put in a real hostname and not rely on MX records, including >possible breakage. If you're real paranoid, register your domain also as >a host with InterNIC (sort of 'ibm.com'), make its address the address of >your primary mail exchanger; even if InterNIC has a minor screw-up - like >"forgetting" your NS records - there's a chance your A record survives. > >This happened some time ago, unfortunately (for IBM, who were one of the >domains lost this way) the host known at InterNIC as 'ibm.com' didn't run >any SMTP daemon. > >(Remember that sendmail falls back to A records if it can't find any MX > records for a host.) > >Good comments for the rest, I agree wholeheartedly with all of them, also >with those from other people. > >Take care, > >-- >Niels Bakker, * * EuroNet Internet BV >Network Operations * * Herengracht 208-214 > * 1016 BS Amsterdam >NJB9 * +31 (0)20 535 5555 > >

1 0