INTERNET-DRAFT Peter Koch Expires: July 2001 Universitaet Bielefeld January 2001 RIPE DNS WG Guide To Setting Up a DNS Server draft-koch-ripe-dns-setup-guide-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Comments should be sent to the author or the RIPE DNS WG mailing list . 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 naming 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 Koch Expires July 2001 [Page 1] INTERNET-DRAFT RIPE DNS Guide January 2001 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 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". Although some new so called "generic" TLDs are expected to go into operation during the year 2001, at the moment these are bogus. If in doubt, check the official list provided by the Internet Assigned Numbers Authority (IANA) [IANATLD] or the Internet Corporation for Assigned Names and Numbers (ICANN) [ICANN]. 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 a 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. Koch Expires July 2001 [Page 2] INTERNET-DRAFT RIPE DNS Guide January 2001 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 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. Computers have names and these names can be abbreviated or full names. Usually you will name your systems by their first name only, which should be sufficiently unambiguous because a single name can exist only once per domain. So, while there may be different systems called "red" they will have different full names like "red.bricks.example", "red.phone.example" or "red.cordless.phone.example". Those long forms are called "fully qualified domain names" (FQDNs). In some contexts, e.g. in zone data files, you may use either abbrevated names ("red", "red.cordless") or FQDNs. To identify an FQDN as such, in a zone file you must add a trailing "." to that domain name. This dot is a marker only, it is not part of the domain name. Koch Expires July 2001 [Page 3] INTERNET-DRAFT RIPE DNS Guide January 2001 Names marked as FQDNs are used unmodified, all others will have appended a suffix called the "current origin", usually the name of the zone itself. In a zone data file for "bricks.example" then "red" is expanded to "red.bricks.example" while "red.phone.example." would mean "red.phone.example". "red.phone.example" however would be expanded to "red.phone.example.bricks.example", so be careful to use the trailing dot where necessary. See also section 5.1. 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@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@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@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 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 multiple 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 intrinsic 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 certain software versions. There is a popular scheme which builds the serial number by using the actual date, e.g. 2001012301 for a zone changed at January, Koch Expires July 2001 [Page 4] INTERNET-DRAFT RIPE DNS Guide January 2001 23rd, 2001. The trailing two digits leave enough space for 99 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 precedes 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 zone, so usually the information is distributed much faster than this. However, notification packtes 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 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, because 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 Koch Expires July 2001 [Page 5] INTERNET-DRAFT RIPE DNS Guide January 2001 enough to cover even a short holiday. A value of 3600 hours (3600000 seconds) 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 specification but was never widely implemented. To explain the other two we first need to talk about yet another DNS feature - caching. DNS servers are queried by DNS resolvers, and those resolvers usually remember (cache) every result 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-existence 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 caching 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 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. ( 2001012301 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 Koch Expires July 2001 [Page 6] INTERNET-DRAFT RIPE DNS Guide January 2001 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, so the line above just serves as an example and should not appear in the real world. You may have heard of IPv6, the next generation internet protocol. The address structure and format are different from what is currently used (IPv4), so new RR types have been defined to support the new protocol. Since the new scheme is a bit more sophisticated we just skip it here. For more information about IPv6 and its availability please consult your ISP. 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. 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. bricks.example. IN NS dns.YourISP.example. Koch Expires July 2001 [Page 7] INTERNET-DRAFT RIPE DNS Guide January 2001 Since DNS serving and resolving are different services do not just use those machines or their IP addresses when asked to configure "nameservers" for your PCs and workstations (see also section 5.2). 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 will be sent to the host "black.bricks.example". Should that machine be unreachable, the mail would be 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 your 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 administrator's responsibility to check this. A very helpful tool for this purpose is "host" [HOST]. 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. 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. Koch Expires July 2001 [Page 8] INTERNET-DRAFT RIPE DNS Guide January 2001 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.bricks.example" and even "light.blue.bricks.example". However, the wildcard has two counter-intuitive properties: 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 Koch Expires July 2001 [Page 9] INTERNET-DRAFT RIPE DNS Guide January 2001 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 "bricks.example". Use of wildcard owners is most common, but not restricted to, for defining MX RRs. However, due 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 or at least be used with wariness. 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 instead of just hostnames, enforce hostname restrictions. They may also define additional syntax requirements. When talking about letters being allowed in hostnames, those are still restricted to the 26 letters A-Z from the Latin alphabet. Recently various proposals have come up to internationalize domain names. This would extend the available characters to include e.g. german umlauts or the "thorn" and various aother language or character set dependent letters (including Asian and other languages). While some registries and providers already actively operate with these extended sets, the standardization process is still in progress. The competing proposals are not compatible with each other and sometimes need specially tailored software to work. You should not expect any such name to be visible or unambiguously identifyable throughout the whole Internet. When dealing with internationalized domain names you should exercise extreme care and Koch Expires July 2001 [Page 10] INTERNET-DRAFT RIPE DNS Guide January 2001 best consult a trustworthy expert in DNS protocol and operations issues. 4. Reverse Mapping Apart from translating names into IP adresses the DNS also provides the complementary service. At various occasions an IP address is given and an application or user is interested in the or a name corresponding to that adress. The DNS does not offer true searching capabilities, so simply starting at the root ('.') and searching for an A resource record containing a given IP address is not feasible. Instead, an additional infrastructure, called the reverse mapping tree, is maintained to provide for simple translation from adresses into names. 4.1. Conventional Reverse Mapping To find the name corresponding to an address (we keep talking about IPv4 adresses - the IPv6 case is a bit more complicated, but not yet really relevant) this address is first reversed bytewise. For example, "192.168.8.15" is rewritten as "15.8.168.192". This is to have the local part left, like the hostname part in domain names. Then, the domain "IN-ADDR.ARPA" is appended, making the above example "15.8.168.192.IN-ADDR.ARPA". Another RR type, called PTR (for pointer) is used to associate a host name with that domain name just crafted to represent the IP address: 15.8.168.192.IN-ADDR.ARPA. IN PTR yellow.bricks.example. (XXX IN-ADDR.ARPA zone is separate, may reside on same server) 4.2. Classless Delegation The previous section dealt with setting up a complete reverse mapping zone. To have the authority over such zone, you need to have authority over at least 256 contiguous IP addresses or a /24 respectively. Your network or the set of addresses given to you may be smaller, so you would share a /24 with other people and thus also share the authority and responsibilty for the reverse mapping with those people. This doesn't work out and a technique called classless delegation [RFC2317] is used to distribute the reverse mapping between a group of customers sharing a /24. (XXX no further details, refer to 2317 and ISP documentation, ISP policies and procedures differ) 4.3. 127.0.0.1 and "localhost" handling Koch Expires July 2001 [Page 11] INTERNET-DRAFT RIPE DNS Guide January 2001 There is a special IP address, 127.0.0.1, which always refers to the local system. So, nobody really owns this address and there is no single name correctly referring to this address (XXX). You should set up a zone "127.IN-ADDR.ARPA" with an SOA RR in it. The timer values do not really matter here, but you can use those from the earlier section. The RNAME and MNAME fields should refer to you and your nameserver like for any other zone. The software may insist that you add an NS RR, which is never used but needed to make the zone sane. The NS RR should point to the real name of the nameserver, like that one in MNAME. Apart from that the zone should contain only a single PTR RR: 1.0.0 IN PTR localhost. The trailing dot makes "localhost" an FQDN. Although this domain name has been reserved for exactly this purpose, not all root nameservers are configured to map "localhost" into the IP address 127.0.0.1. The strategy here is slightly different anyway. Most application software will treat "localhost" as an unqualified or short name thus adding the local domain before issuing a query. Therefore you should have an A RR like this in your zone: localhost IN A 127.0.0.1 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. 5.1. Missing trailing dots TBD 5.2. 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. [XXX ...] 5.3. 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 Koch Expires July 2001 [Page 12] INTERNET-DRAFT RIPE DNS Guide January 2001 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 hiding" 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 cracker 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 [RIPEHOCO] is a prominent example). If in doubt, consult your ISP. 5.4. Firewalls blocking UDP DNS traffic TBD 5.5. WINS lookup enabled TBD 6. Security Considerations The DNS as it is used today is insecure by design in that it does not provide data origin authentication. That means you can not be sure that a response to a DNS query reflects what the zone administrators in charge entered into their system. Various attacks, like "cache poisoning" make use of this weakness. Modern DNS software tries to prevent some attacks, but it cannot be perfect. In addition DNS software (as any other software) may contain bugs which might be exploited to gain unauthorized access to your system. Koch Expires July 2001 [Page 13] INTERNET-DRAFT RIPE DNS Guide January 2001 To prevent problems in this regard you should take the usual precautions like proactively monitoring your system, reading and following the bulletins issued by SIRTs (like CERT/CC [CERTCC]) and your software vendor and probably following the relevant security mailing lists. Nothing of these measures is really DNS specific. With regard to cache poisoning you should try to differentiate between the serving and the resolving service and restrict both to the appropriate level. For example, it is usually not necessary to allow random systems on the Internet to query your nameserver for domain names other than those served by it authoritatively, while you will provide this service for your own systems. A protocol extension called "Secure DNS" or DNSSEC has been specified to provide for data origin authentication, consequently addressing the security problems inherently present in the DNS protocol itself. Implementations are available, however deployment strategies and processes are still to be developed. Ask your ISP and your TLD registry for details. 7. Acknowledgements TBD 8. Glossary TBD / (XXX refer to FYIs 4 and 7?) 9. References [ALLIU98] Albitz,P., Liu,C., "DNS and BIND", O'Reilly, 3rd ed., Sep- tember 1998 [ALLALI98] Albitz,P., Larson,M., Liu,C., "DNS on Windows NT", O'Reilly, 1st ed., October 1998 [CERTCC] CERT/CC, "CERT Coordination Center", http://www.cert.org/ [DNSRD] Salamon,A., "DNS Resources Directory (DNSRD)", http://www.dns.net/dnsrd/ [HOST] Wassenaar,E., "host", http://www.nikhef.nl/user/e07/tools/host.html [IANATLD] Internet Assigned Numbers Authority, "Domain Name Ser- vices", http://www.iana.org/domain-names.htm Koch Expires July 2001 [Page 14] INTERNET-DRAFT RIPE DNS Guide January 2001 [ICANN] The Internet Corporation for Assigned Names and Numbers, http://www.icann.org/ [RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities", RFC 1034, STD 13, November 1987 [RFC1035] Mockapetris,P., "Domain Names - Implementation and Specif- ication", RFC 1035, STD 13, November 1987 [RFC1537] Beertema,P., "Common DNS Data File Configuration Errors", RFC 1537, October 1993 [RFC1912] Barr,D., "Common DNS Operational and Configuration Errors", RFC 1912, February 1996 [RFC2142] Crocker,D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS", RFC 2142, May 1997 [RFC2219] Hamilton,M., Wright,R., "Use of DNS Aliases for Network Services", RFC 2219, BCP 17, October 1997 [RFC2317] Eidnes,H., de Groot,G., Vixie,P., "Classless IN-ADDR.ARPA delegation", RFC 2317,, BCP 20, March 1998 [RFC2606] Eastlake,D., Panitz,A., "Reserved Top Level DNS Names", RFC 2606, BCP 32, June 1999 [RFC2828] Shirey,R., "Internet Security Glossary", RFC 2828, FYI 36, May 2000 [RIPE192] RIPE DNS working group, "Simple DNS Configuration Exam- ple", RIPE 192, February 2000 [RIPE203] Koch,P., "Recommendations for DNS SOA Values", RIPE 203, November 1999 [RIPEHOCO] RIPE NCC, "The RIPE Region Hostcount", http://www.ripe.net/ripencc/pub-services/stats/hostcount/ 10. Author's Address Peter Koch Universitaet Bielefeld Technische Fakultaet D-33594 Bielefeld Germany +49 521 106 2902 Koch Expires July 2001 [Page 15] INTERNET-DRAFT RIPE DNS Guide January 2001 Koch Expires July 2001 [Page 16]