From kurt at planning.viaginterkom.de Mon Nov 23 14:55:10 1998 From: kurt at planning.viaginterkom.de (Kurt Kayser) Date: Mon, 23 Nov 1998 14:55:10 +0100 (MET) Subject: DNS-help document available? Message-ID: <199811231355.OAA15256@planning.viaginterkom.de> Hi! Last time in Edinburgh we've started a document about basic DNS setup procedures. Did somebody continue on it? Where's the latest version available? Thanks, Kurt -- || Kurt Kayser - Internet Planning Engineer || || Viag Interkom - Riesstr. 25 - 80992 Munich - Germany|| || Tel: +49 89 1480 3827 - Fax: 3878 || From liman at sunet.se Mon Nov 23 18:43:12 1998 From: liman at sunet.se (Lars-Johan Liman) Date: Mon, 23 Nov 1998 18:43:12 +0100 Subject: DNS-help document available? In-Reply-To: Your message of "Mon, 23 Nov 1998 14:55:10 +0100 (MET)" <199811231355.OAA15256@planning.viaginterkom.de> References: <199811231355.OAA15256@planning.viaginterkom.de> Message-ID: <19981123184312P.liman@flaptop.pilsnet.sunet.se> kurt at planning.viaginterkom.de: > Hi! > Last time in Edinburgh we've started a document about basic DNS > setup procedures. Did somebody continue on it? Where's the latest > version available? Hmm. There was the paper from Hans Niklasson and Amar Andersson. We (as in Randy Bush, Hans Niklasson from Tele2, Nic Lewis from the Linx (if memory serves me), you, and me) started to "develop" it a bit, and ran into a situation that lead to major overhaul, so we decided to put out the original paper and go on editing a second paper. This was all done on my laptop, and the documents still live there in the status they were left in Edinburgh. I seem to remember mailing one version or another back to Hans, but I don't know what he did with it. Hans? So, there are some bits and pieces on my hard drive, if anyone feels like picking up the ball, but there might be more consistent versions elsewhere. Best regards, /Liman #------------------------------------------------------------------------- # What the DNS really needs, is CLUE records ... ;-) #------------------------------------------------------------------------- # Lars-Johan Liman ! Internet: liman at sunet.se # Ebone/NORDUnet/SUNET Operations Centre ! HTTP : //www.sunet.se/~liman # Royal Institute of Technology, Sweden ! Voice : Int +46 8 - 790 65 60 #------------------------------------------------------------------------- From ekb at ivm.net Tue Nov 24 11:34:13 1998 From: ekb at ivm.net (Elmar K. Bins) Date: Tue, 24 Nov 1998 11:34:13 +0100 Subject: DNS-help document available? In-Reply-To: <199811231355.OAA15256@planning.viaginterkom.de>; from Kurt Kayser on Mon, Nov 23, 1998 at 02:55:10PM +0100 References: <199811231355.OAA15256@planning.viaginterkom.de> Message-ID: <19981124113413.A5989@org> kurt at planning.viaginterkom.de (Kurt Kayser) wrote: > Hi! > > Last time in Edinburgh we've started a document about basic DNS > setup procedures. Did somebody continue on it? Where's the latest > version available? I did and submitted it to the original authors. There was exactly _one_ response: "We will look through it and comment". Fin. I will submit my version to the list asap. Best 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 at ivm.net) http://www.ivm.net/ From ekb at ivm.net Tue Nov 24 11:35:09 1998 From: ekb at ivm.net (Elmar K. Bins) Date: Tue, 24 Nov 1998 11:35:09 +0100 Subject: DNS recommendations - the paper Message-ID: <19981124113509.B5989@org> Content-Description: DNS recommendations RIPE DNS-WG paper DNS recommendations Originally by: Hans Niklasson Amar Andersson Reworked by: Elmar K. Bins (use the dns-wg at 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 \ ( ) 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 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 seconds. expire: The zone's information is considered invalid by the secondary if the primary could not be reached for 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 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 [] [] IN NS Examples IN NS ns.isp.net. ; NS for all of the zone's domain bla IN NS ns.cust.com. ; subdelegation for bla. 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 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 [] [] IN MX Examples IN MX 100 relay.isp.net. ; fallback MX for domain IN MX 10 mail.cust.com. ; final MX bla IN MX 100 relay.isp.net. ; fallback MX for bla. IN MX 10 blamail ; blamail. 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 ) 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 [] [] IN A [ ...] 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 ; as a hostname ;-) Semantics A records contain the data that performs name-to-number translation. Recommendations and remarks Do not use FQDNs in the part. Hosts in subdomains ? la "www.internal", which resolve to "www.internal." 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 [] IN CNAME 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 [] IN PTR [ ...] 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 [] IN HINFO 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 [] IN WKS
[...] 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 [] IN TXT 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 . 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 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 at ivm.net) http://www.ivm.net/ From randy at psg.com Tue Nov 24 19:46:52 1998 From: randy at psg.com (Randy Bush) Date: Tue, 24 Nov 1998 10:46:52 -0800 (PST) Subject: DNS recommendations - the paper References: <19981124113509.B5989@org> Message-ID: great improvement. but i will make comments if only to cause discussion. i would also ask what happened to the idea of a concrete simple example? > @ 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. > Semantics > originating dns server: > dottified admin email: why not use, or at least refer to, the proper names for the fields, per 1035, MNAME, RNAME, ...? > 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. and note that 'higher' is in modulo arithmetic as defined in RFC 1982, which gives cute tricks for 'rolling' in the space. > originating dns server: > As stated above, insert the name of the originating > server that is reachable from the Internet. s/originating/primary/ > 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. this is controversial. i think it was piet who recommended that it not be an alias, because when dns is broken, other things like alias resolution may be broken as well. > expire: > 604800 (7 days) is the value used here. [ekb] ghaque! i use 30 days. maybe i am more liberal because i secondary for a lot of zones in very difficult to reach places. i think piet recommended 30 days for tlds and 7 for others. so i guess this is ok, as we're not talking tlds here. > Examples > IN NS ns.isp.net. ; NS for all of the zone's domain > bla IN NS ns.cust.com. ; subdelegation for bla. might it be best if you showed the correct practice of two serverd for each zone? > authoritative server: > The given must be the FQDN > for the nameserver machine. Check its correctness in > advance and don't forget the trailing dot. mabe hammer in that cnames are not allowed here. > ============================== > MX Mail Exchanger Records > ============================== > > preference: > This field is the numerical preference for mail delivery > to the machine mentioned. Lower values are tried first. while 'preference' is the proper name for the field, it is often called 'cost', the higher the less preferred. > ======================= > A Address Records > ======================= > > Synopsis > [] [] IN A [ ...] please do not use the term 'hostname' as it causes great controversy re charset. > www IN A 123.45.67.10 123.45.67.11 ; multiple hardware is this syntax legal? i believe you need www A 123.45.67.10 123.45.67.11 > Recommendations and remarks > Do not use FQDNs in the part. Hosts in subdomains > \340 la "www.internal", which resolve to "www.internal." > are okay though. Remember that IP addresses do not end in > a dot. Do not forget to maintain reverse delegation as well. \340? > ============================== > CNAME Canonical Name Records > ============================== > > Synopsis > [] IN CNAME again, not 'hostname' please. i believe that the rdata for a cname is an arbitrary domain name. > Semantics > CNAME records provide a means to give aliases to machines. not just machines. > Glue records > "Glue records" is a term that describes entering A records into > a zone for machines whose hostnames do not lie within . s/do not/do/ i.e. foo. soa () ns bar ns feen bar a 666.42.77.11 feen a 147.28.0.42 and it is absolutely critical that you do NOT have glue rrs for names outside the current zone. a cute and good sanity check is, a glue rr must never need a terminating dot on the label. > 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. it may be worth noting that conventions in certain areas (classless in-addr, etc.) use a wider character set. but when not so needed, it is wise to avoid special chars. > Additional reading and references: i would add rfcs 1982, 2181, 2182. randy From BERI at etf.bg.ac.yu Tue Nov 24 20:07:00 1998 From: BERI at etf.bg.ac.yu (Berislav Todorovic) Date: Tue, 24 Nov 1998 20:07 +0100 Subject: DNS recommendations - the paper Message-ID: <6E835C166C018598@etf.bg.ac.yu> >> > serial number: >> > Changed zones are only reloaded if a higher serial number add "on the secondary servers" between "reloaded" and "if a ..." >> > Synopsis >> > [] [] IN A [ ...] Wrong, of course ... RFC 1035 says clearly: 3.4.1. A RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ADDRESS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: ADDRESS A 32 bit Internet address. Hosts that have multiple Internet addresses will have multiple A records. Regards, Beri .-------. | --+-- | Berislav Todorovic, B.Sc.E.E. | E-mail: BERI at 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 `-------' -------------------------------------------------------------------- From ekb at ivm.net Tue Nov 24 21:01:24 1998 From: ekb at ivm.net (Elmar K. Bins) Date: Tue, 24 Nov 1998 21:01:24 +0100 Subject: DNS recommendations - the paper In-Reply-To: ; from Randy Bush on Tue, Nov 24, 1998 at 10:46:52AM -0800 References: <19981124113509.B5989@org> Message-ID: <19981124210124.X5989@org> Randy, thanks for your comments. I already changed the paper partially according to them... randy at psg.com (Randy Bush) wrote: > i would also ask what happened to the idea of a concrete simple example? Can you provide one? ;-) > s/netmaster/hostmaster/ see RFC 2142 True. > or, i think it was piet who recommended being conservative, and do not > relying on aliases, rather use a real mailbox name. Nobody stops you from having a real hostmaster mailbox (like I have :-) ) > why not use, or at least refer to, the proper names for the fields, per > 1035, MNAME, RNAME, ...? I've added them although I don't think that anybody really cares... > > 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. > > and note that 'higher' is in modulo arithmetic as defined in RFC 1982, which > gives cute tricks for 'rolling' in the space. Good heavens - I never understood that part (arithmetics...). Can you give an easy explanation or would the audience think that "beware of possible wrapping" might suffice here? > > originating dns server: > > As stated above, insert the name of the originating > > server that is reachable from the Internet. > > s/originating/primary/ The originating server need not at all be exposed in one of the NS records as long as it exists (think of "hidden primary" setups). I don't even know whether this machine needs to exist (given the RNAME is valid). This is the reason why I chose "originating". Any other comments on this one? RFC pointers? > > 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. > > this is controversial. i think it was piet who recommended that it not be > an alias, because when dns is broken, other things like alias resolution may > be broken as well. I'm not speaking of aliases here, but of role accounts which may or may not have real mailboxes. Maybe we should make clear that true mailboxes are recommended for more failsafe operation. I've added a paragraph to the SOA semantics part: To ensure reachability even in case of serious DNS and other problems, make this address point to a true mailbox, not an alias. > > expire: > > 604800 (7 days) is the value used here. [ekb] > > ghaque! i use 30 days. maybe i am more liberal because i secondary for > a lot of zones in very difficult to reach places. i think piet recommended > 30 days for tlds and 7 for others. so i guess this is ok, as we're not > talking tlds here. Well you have your satellite dish - maybe it needs cleaning? ;-) Honest, if you have RETRY set to the appropriate value (let it have a couple hundred tries) it should work (lest there are broken lines involved which I always fix by making the zone primary until the problem is solved...). > > Examples > > IN NS ns.isp.net. ; NS for all of the zone's domain > > bla IN NS ns.cust.com. ; subdelegation for bla. > > might it be best if you showed the correct practice of two serverd for each > zone? It's just the syntax example. If we get a simple running config together it of course should have two NS records per zone minimum. Or should we add them here already? > > authoritative server: > > mabe hammer in that cnames are not allowed here. nailed. > > preference: > > This field is the numerical preference for mail delivery > > to the machine mentioned. Lower values are tried first. > > while 'preference' is the proper name for the field, it is often called > 'cost', the higher the less preferred. Thanks for this line. Added ;-) > > Synopsis > > [] [] IN A [ ...] > > please do not use the term 'hostname' as it causes great controversy re > charset. Hmm. What term would be most appropriate? > is this syntax legal? i believe you need > > www A 123.45.67.10 > 123.45.67.11 True and changed (*blush*) > \340? Oh, I tried to be french here :-D (a-accent-grave) > > Synopsis > > [] IN CNAME > > again, not 'hostname' please. i believe that the rdata for a cname is an > arbitrary domain name. Hmm. Wouldn't "hostname" help the beginner without confusing the pro? Otherwise we'd have to define a couple RDATA types... > > Semantics > > CNAME records provide a means to give aliases to machines. > > not just machines. I couldn't come up with an easy explanation of what's possible. The RFC is not very readable in many places, and the term "owner" sure wouldn't do good here, would it? Any ideas on how to change this? > > Glue records > > "Glue records" is a term that describes entering A records into > > a zone for machines whose hostnames do not lie within . > > s/do not/do/ Hmm. I took this paragraph from the original. I'm not sure I have understood what you call "glue" correctly...RFC2181 reads "Glue" above includes any record in a zone file that is not properly part of that zone, including nameserver records of delegated sub- zones (NS records), address records that accompany those NS records (A, AAAA, etc), and any other stray data that might appear. So I took glue for the import interface ;-) Can anyone come up with a good explanation? (Have me be the experiment candidate for this ;-) ). > it may be worth noting that conventions in certain areas (classless in-addr, > etc.) use a wider character set. but when not so needed, it is wise to > avoid special chars. Added a bit about this. Reads now: Only A-Z/a-z (case does not matter), 0-9 and - are recommended, even if a wider character set is in use in certain areas (e.g., classless in-addr resolution). If you can do without special characters, avoid them. > i would add rfcs 1982, 2181, 2182. Added these too. One for general discussion: How far should this paper go into detail? The basic intention was to have a guideline on how to set up stable DNS servers. The professional should IMHO at one time or another try to understand the RFCs... Regards, Elmi. PS: Oh well, to avoid mailing the paper too often, the current version can always be found at http://detebe.org/~ekb/dns/recommendations.txt -- | \ / |\/| 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 at ivm.net) http://www.ivm.net/ From ekb at ivm.net Tue Nov 24 21:02:39 1998 From: ekb at ivm.net (Elmar K. Bins) Date: Tue, 24 Nov 1998 21:02:39 +0100 Subject: DNS recommendations - the paper In-Reply-To: <6E835C166C018598@etf.bg.ac.yu>; from Berislav Todorovic on Tue, Nov 24, 1998 at 08:07:00PM +0100 References: <6E835C166C018598@etf.bg.ac.yu> Message-ID: <19981124210239.Y5989@org> BERI at etf.bg.ac.yu (Berislav Todorovic) wrote: > >> > serial number: > >> > Changed zones are only reloaded if a higher serial number > > add "on the secondary servers" between "reloaded" and "if a ..." Good idea. Done :-) > >> > Synopsis > >> > [] [] IN A [ ...] > > Wrong, of course ... RFC 1035 says clearly: Yes, thanks. 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 at ivm.net) http://www.ivm.net/ From BERI at etf.bg.ac.yu Tue Nov 24 22:03:00 1998 From: BERI at etf.bg.ac.yu (Berislav Todorovic) Date: Tue, 24 Nov 1998 22:03 +0100 Subject: DNS recommendations - the paper Message-ID: <7EC8F6216C018598@etf.bg.ac.yu> >> 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 [] IN PTR [ ...] 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. 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 at 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 `-------' -------------------------------------------------------------------- From bmanning at ISI.EDU Tue Nov 24 22:21:10 1998 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Tue, 24 Nov 1998 13:21:10 -0800 (PST) Subject: DNS recommendations - the paper In-Reply-To: from "Randy Bush" at Nov 24, 98 10:46:52 am Message-ID: <199811242121.AA06320@zed.isi.edu> > > www IN A 123.45.67.10 123.45.67.11 ; multiple hardware > > is this syntax legal? i believe you need > > www A 123.45.67.10 > 123.45.67.11 the syntax is not legal, you are correct in your revised example. I'd also note that it would be prudent to use IP prefixes and domains expressly reserved for documentation use instead of other, viable prefixes/domain lables. ... Nov 24 13:20:45 darkstar named[25281]: rr-domain/rrset.ep.net: line 14: database format error () Nov 24 13:20:45 darkstar named[25281]: primary zone "test.zone" rejected due to errors (serial 1925620) ... ; rrset.ep.net. IN SOA ns.isi.edu. bmanning.isi.edu. ( 1925620 ; Serial 10800 ; Refresh - 3hrs 900 ; Retry - 15min 604800 ; Expire - 1000hrs 129600 ) ; Minimum - 36hrs IN NS NS.ISI.EDU. in ns dot.ep.net. ; ; test in a 192.168.2.11 192.0.2.11 ; .... Good references: RFC 1536; RFC 1912 --bill From randy at psg.com Tue Nov 24 22:44:42 1998 From: randy at psg.com (Randy Bush) Date: Tue, 24 Nov 1998 13:44:42 -0800 (PST) Subject: DNS recommendations - the paper References: <7EC8F6216C018598@etf.bg.ac.yu> Message-ID: > * 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". we may have a human language problem here. "need not be" means "is allowed but is not required." > * In the MX section, add the following after " ... a lot of trouble.": > "Furthermore, it is forbidden by the current RFC documents". and eliminate the stuff about trouble. > * The PTR section contains a possible mistake - are you sure you can write: >>> 123.45.67.8 IN PTR mail.cust.com. yes, but only in the in-addr.arpa. zone does it have useful meaning. randy From BERI at etf.bg.ac.yu Tue Nov 24 23:02:00 1998 From: BERI at etf.bg.ac.yu (Berislav Todorovic) Date: Tue, 24 Nov 1998 23:02 +0100 Subject: DNS recommendations - the paper Message-ID: <86FE0427FC018598@etf.bg.ac.yu> >> * The PTR section contains a possible mistake - are you sure you can write: >> 123.45.67.8 IN PTR mail.cust.com. >> >> yes, but only in the in-addr.arpa. zone does it have useful meaning. OK - I took my "toy" (an old Linux box w/BIND 8.1.2 installed). I created a bogus reverse zone 1.168.192.in-addr.arpa. Here is the zone file: @ IN SOA ns.nic.yu. hostmaster.nic.yu. ( 1997092300 10800 3600 604800 86400 ) IN NS ns.nic.yu. IN NS ns2.nic.yu. 192.168.1.1 IN PTR aaa.yyy.zz. 2 IN PTR bbb.yyy.zz. Remark: the first record is created according to the Elmar's text. The latter is a regular record. Now, watch what host utility gives: ~> host 192.168.1.1 192.168.1.1 has no PTR record (Authoritative answer) ~> host 192.168.1.2 Name: bbb.yyy.zz Address: 192.168.1.2 Conclusion? Let's see what really happened: ~> host -alv 1.168.192.in-addr.arpa 1.168.192.in-addr.arpa. 86400 IN NS ns.nic.yu. 1.168.192.in-addr.arpa. 86400 IN NS ns.nic.yu. 2.1.168.192.in-addr.arpa. 86400 IN PTR bbb.yyy.zz. 192.168.1.1.1.168.192.in-addr.arpa. 86400 IN PTR aaa.yyy.zz. Look at the last PTR record - think it looks ok? ;-) Regards, Beri .-------. | --+-- | Berislav Todorovic, B.Sc.E.E. | E-mail: BERI at 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 `-------' -------------------------------------------------------------------- From randy at psg.com Tue Nov 24 23:05:33 1998 From: randy at psg.com (Randy Bush) Date: Tue, 24 Nov 1998 14:05:33 -0800 (PST) Subject: DNS recommendations - the paper References: <86FDC411BC018598@etf.bg.ac.yu> Message-ID: >> yes, but only in the in-addr.arpa. zone does it have useful meaning. > OK - I took my "toy" (an old Linux box w/BIND 8.1.2 installed). 0 - i use rfcs not amateur pseudo-unix wannabe systems 1 - i meant THE in-addr.arpa. zone, not the .in-addr.arpa. zone. randy From BERI at etf.bg.ac.yu Tue Nov 24 23:15:00 1998 From: BERI at etf.bg.ac.yu (Berislav Todorovic) Date: Tue, 24 Nov 1998 23:15 +0100 Subject: DNS recommendations - the paper Message-ID: <88D2D258CC0188D8@etf.bg.ac.yu> >> >> yes, but only in the in-addr.arpa. zone does it have useful meaning. >> > OK - I took my "toy" (an old Linux box w/BIND 8.1.2 installed). >> >> 0 - i use rfcs not amateur pseudo-unix wannabe systems BIND works everywhere the same way - Unix implementation is irrelevant. Besides, I've just tested the same on a Sun - same result. >> 1 - i meant THE in-addr.arpa. zone, not the .in-addr.arpa. zone. I agree with that remark - sorry for my previous misinterpretation of your message ... ;-) Nevertheless, in the case of in-addr.arpa zone the IP address should be reversed, e.g. 8.67.45.123. Regards, Beri .-------. | --+-- | Berislav Todorovic, B.Sc.E.E. | E-mail: BERI at 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 `-------' -------------------------------------------------------------------- From randy at psg.com Tue Nov 24 23:26:08 1998 From: randy at psg.com (Randy Bush) Date: Tue, 24 Nov 1998 14:26:08 -0800 (PST) Subject: DNS recommendations - the paper References: <88D292428C0188D8@etf.bg.ac.yu> Message-ID: > BIND works everywhere the same way unfortunately true. that's why i use the rfcs. randy From hallgren at fdn.org Tue Nov 24 23:47:41 1998 From: hallgren at fdn.org (Michael Hallgren) Date: Tue, 24 Nov 1998 23:47:41 +0100 Subject: DNS recommendations - the paper In-Reply-To: <88D2D258CC0188D8@etf.bg.ac.yu>; from Berislav Todorovic on Tue, Nov 24, 1998 at 11:15:00PM +0100 References: <88D2D258CC0188D8@etf.bg.ac.yu> Message-ID: <19981124234741.B14527@fdn.org> On Tue, Nov 24, 1998 at 11:15:00PM +0100, Berislav Todorovic wrote: > >> >> yes, but only in the in-addr.arpa. zone does it have useful meaning. > >> > OK - I took my "toy" (an old Linux box w/BIND 8.1.2 installed). > >> > >> 0 - i use rfcs not amateur pseudo-unix wannabe systems > > BIND works everywhere the same way - Unix implementation is irrelevant. > Besides, I've just tested the same on a Sun - same result. > Yep. I believe Bind is (thougbperhaps not resently - Microsoft) somehow become praxis ;-) > >> 1 - i meant THE in-addr.arpa. zone, not the .in-addr.arpa. zone. > > I agree with that remark - sorry for my previous misinterpretation of > your message ... ;-) Nevertheless, in the case of in-addr.arpa zone > the IP address should be reversed, e.g. 8.67.45.123. > We all do have the right to do # while ; would be more fun. No hard feelings. Michael > Regards, > Beri > > .-------. > | --+-- | Berislav Todorovic, B.Sc.E.E. | E-mail: BERI at 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 > `-------' -------------------------------------------------------------------- > -- -- Michael Hallgren, http://mh.graphnet.fr From niels at euro.net Wed Nov 25 00:01:49 1998 From: niels at euro.net (Niels Bakker) Date: Wed, 25 Nov 1998 00:01:49 +0100 (MET) Subject: DNS recommendations - the paper In-Reply-To: Message-ID: <981124235716.21781C-100000@venus.euro.net> 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 From dw at hote.net Wed Nov 25 00:07:03 1998 From: dw at hote.net (Didier Windmeulen) Date: Wed, 25 Nov 1998 00:07:03 +0100 Subject: remove Message-ID: <000901be17ff$2a540000$50cb4ac3@winddid> ----- Original Message ----- From: Niels Bakker To: 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 > > From randy at psg.com Wed Nov 25 00:13:26 1998 From: randy at psg.com (Randy Bush) Date: Tue, 24 Nov 1998 15:13:26 -0800 (PST) Subject: DNS recommendations - the paper References: <981124235716.21781C-100000@venus.euro.net> Message-ID: >>> @ 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 not discussing MX RRs. mailbox names. the reason i mention piet's recommendation is twofold, i think he used to chair this group, and he wrote one of those silly rfc things. though checking 1537, this point seems not to have made the final cut. piet, you still around? > (Remember that sendmail falls back to A records if it can't find any MX > records for a host.) i think of it the other way, but with the same result. mail will be sent to the (address in rdata of the) A RR unless some one put in an MX RR because the (interface denoted in the) A RR can not accept mail. randy From hallgren at fdn.org Wed Nov 25 00:22:27 1998 From: hallgren at fdn.org (Michael Hallgren) Date: Wed, 25 Nov 1998 00:22:27 +0100 Subject: DNS recommendations - the paper In-Reply-To: ; from Randy Bush on Tue, Nov 24, 1998 at 03:13:26PM -0800 References: <981124235716.21781C-100000@venus.euro.net> Message-ID: <19981125002227.A14686@fdn.org> On Tue, Nov 24, 1998 at 03:13:26PM -0800, Randy Bush wrote: > >>> @ 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 > > not discussing MX RRs. mailbox names. the reason i mention piet's > recommendation is twofold, i think he used to chair this group, and he > wrote one of those silly rfc things. though checking 1537, this point > seems not to have made the final cut. piet, you still around? > > > (Remember that sendmail falls back to A records if it can't find any MX > > records for a host.) > > i think of it the other way, but with the same result. mail will be sent > to the (address in rdata of the) A RR unless some one put in an MX RR > because the (interface denoted in the) A RR can not accept mail. Yes. that's the point. Correct me if I'm mistaken, but I take an MX RR rather as a modulation over a zone. Michael > > randy > -- Michael Hallgren, http://mh.graphnet.fr From bmanning at ISI.EDU Wed Nov 25 00:18:01 1998 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Tue, 24 Nov 1998 15:18:01 -0800 (PST) Subject: DNS recommendations - the paper In-Reply-To: from "Randy Bush" at Nov 24, 98 03:13:26 pm Message-ID: <199811242318.AA07308@zed.isi.edu> > > >>> @ 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 > > not discussing MX RRs. mailbox names. the reason i mention piet's > recommendation is twofold, i think he used to chair this group, and he > wrote one of those silly rfc things. though checking 1537, this point > seems not to have made the final cut. piet, you still around? RFC 1537 was obsoleted by RFC 1912 --bill From niels at euro.net Wed Nov 25 00:35:44 1998 From: niels at euro.net (Niels Bakker) Date: Wed, 25 Nov 1998 00:35:44 +0100 (MET) Subject: DNS recommendations - the paper In-Reply-To: Message-ID: <981125002020.21628A-100000@venus.euro.net> [ If you reply to the list, please don't Cc me, I'm subscribed. Thanks ] Quoth Randy Bush: > not discussing MX RRs. mailbox names. the reason i mention piet's I know, I just changed the subject. :) (Piet who, by the way? It being a common Dutch name & all.) >> (Remember that sendmail falls back to A records if it can't find any MX >> records for a host.) > i think of it the other way, but with the same result. mail will be sent > to the (address in rdata of the) A RR unless some one put in an MX RR > because the (interface denoted in the) A RR can not accept mail. The same result, but you should add MX records if a host will at some point receive mail (at its hostname). The Bat Book advises you to always add MX records; sendmail looks up the MX record anyway, first by asking for "any" information, if there isn't any MX info it'll ask specifically for it, causing more DNS traffic. Say: example.com. IN A 1.2.3.4 Sending mail to nobody at example.com will cause one additional DNS lookup, whereas if you added example.com. IN MX 10 example.com. sendmail (or any mailer daemon following the RFCs for that matter) will find the MX record immediately and get the A record at the same time, thus knowing exactly where to send the mail in one try. Unfortunately I don't have my RFCs greppable currently, else I could quote the one that says that you should add an MX pointing elsewhere for a host that is incapable of receiving mail, so that mail to postmaster@ has a better chance of ending up somewhere where it'll be read, in case of trouble with . I guess that practice was from before the explosion of dialup hosts, though. Take care, -- Niels. From randy at psg.com Wed Nov 25 01:17:08 1998 From: randy at psg.com (Randy Bush) Date: Tue, 24 Nov 1998 16:17:08 -0800 (PST) Subject: DNS recommendations - the paper References: <981125002020.21628A-100000@venus.euro.net> Message-ID: > [ If you reply to the list, please don't Cc me, I'm subscribed. Thanks ] procmail is your friend :0 Wh: msgid.lock | formail -D 8192 msgid.cache > Piet who, by the way? Beertema. > you should add MX records if a host will at some point receive mail (at > its hostname). no. not at all needed. > The Bat Book advises you to always add MX records poor and unnecessary advice. > Unfortunately I don't have my RFCs greppable currently, else I could quote > the one that says that you should add an MX pointing elsewhere for a host > that is incapable of receiving mail i think we all agree that, if X can not receive mail directly, there should be an MX for X pointing to an SMTP server. the point is that, if X runs an SMTP server, then there is no need for an MX for X. randy From randy at psg.com Wed Nov 25 01:40:37 1998 From: randy at psg.com (Randy Bush) Date: Tue, 24 Nov 1998 16:40:37 -0800 (PST) Subject: DNS recommendations - the paper References: <19981124113509.B5989@org> <19981124210124.X5989@org> Message-ID: >> i would also ask what happened to the idea of a concrete simple example? > Can you provide one? ;-) this is from a real tld. you may want to tune timing for a subdomain. @ 14400 SOA nshost.example. mymailbox.nshost.example. ( 1999811220 ; serial 86400 ; refresh every one day 3600 ; retry every hour 2592000 ; expire in 30 days 14400 ) ; default TTL of 4 hours NS nshost.example. NS offnet.host.example. A 10.666.42.77 ; if someone else spools your mail, ; because @ can not receive mail, then MX 100 friendly.mail.spool.example. www CNAME @ >> or, i think it was piet who recommended being conservative, and do not >> relying on aliases, rather use a real mailbox name. > Nobody stops you from having a real hostmaster mailbox (like I have :-) ) nice tricky excuse. but i thought we were trying to be simple and clear. >>> 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. >> and note that 'higher' is in modulo arithmetic as defined in RFC 1982, >> which gives cute tricks for 'rolling' in the space. > Good heavens - I never understood that part (arithmetics...). Can you > give an easy explanation or would the audience think that "beware of > possible wrapping" might suffice here? see rfc 1982. >>> originating dns server: >>> As stated above, insert the name of the originating >>> server that is reachable from the Internet. >> s/originating/primary/ > The originating server need not at all be exposed in one of the NS records > as long as it exists (think of "hidden primary" setups). I don't even know > whether this machine needs to exist (given the RNAME is valid). This is > the reason why I chose "originating". Any other comments on this one? RFC > pointers? i would suggest minimizing invention of new terminology, if only so that the neophyte reader's newly-gained knowledge gives them tools to deal with the rest of the documents and people in the world. > To ensure reachability even in case of serious DNS and other > problems, make this address point to a true mailbox, not an > alias. cool! >>> Examples >>> IN NS ns.isp.net. ; NS for all of the zone's domain >>> bla IN NS ns.cust.com. ; subdelegation for bla. >> might it be best if you showed the correct practice of two serverd for each >> zone? > It's just the syntax example. which the neophyte reader will follow. do not make it an incorrect one. >>> Synopsis >>> [] [] IN A [ ...] >> please do not use the term 'hostname' as it causes great controversy re >> charset. > Hmm. What term would be most appropriate? label is, i believe, the correct term. or maybe domain name. >> \340? > Oh, I tried to be french here :-D (a-accent-grave) q: what do you call someone who speaks only one language a: an american >>> Synopsis >>> [] IN CNAME >> again, not 'hostname' please. i believe that the rdata for a cname is an >> arbitrary domain name. > Hmm. Wouldn't "hostname" help the beginner without confusing the pro? the pros are clearly well confused to the level of nuclear weapons. why set up the tyros to fall into the trap? > Otherwise we'd have to define a couple RDATA types... why? the rfcs call it 'cannonical name' >>> Semantics >>> CNAME records provide a means to give aliases to machines. >> not just machines. > I couldn't come up with an easy explanation of what's possible. The RFC > is not very readable in many places, and the term "owner" sure wouldn't > do good here, would it? Any ideas on how to change this? CNAMEs map nicknames to cannonical names. CNAMEs have very few uses (see above example, RFC 2317, ...). Be especially aware that nicknames must not be used as the right hand of NS, MX, ... RRs. >>> Glue records >>> "Glue records" is a term that describes entering A records into >>> a zone for machines whose hostnames do not lie within . >> s/do not/do/ > Hmm. I took this paragraph from the original. I'm not sure I have > understood what you call "glue" correctly...RFC2181 reads they have one and only one use, when the rhs of an ns rr names a server which has a domain name which is within the domain of the above soa. e.g. example. SOA ... NS foo NS bar foo A 10.666.42.77 bar A 192.168.666.42 note that foo and bar could be expressed without final dots. this is what i meant when i said glue is only used when the rhs of an ns rr can be correctly written without the trailing dot. > How far should this paper go into detail? 42 mfg, randy From e07 at nikhef.nl Wed Nov 25 03:24:34 1998 From: e07 at nikhef.nl (Eric Wassenaar) Date: Wed, 25 Nov 1998 03:24:34 +0100 Subject: another DNS recommendation Message-ID: <9811250224.DA00404@nikhefh.nikhef.nl> I'm biased, but I would add one other recommendation: If you are the maintainer of a certain DNS and your passes all tests via the command host -C -A -L 1 then your 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) From Piet.Beertema at cwi.nl Wed Nov 25 11:07:37 1998 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Wed, 25 Nov 1998 11:07:37 +0100 Subject: DNS recommendations - the paper In-Reply-To: "Your message of Tue, 24 Nov 1998 10:46:52 -0800 (PST) " Message-ID: > @ 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. Me? Conservative? :-) Both approaches have pros and cons. In "old" times an alias file could become corrupt or get lost, but that wouldn't affect mail directly to mailboxes. "hostmaster" and "postmaster", being longer than 8 chars, usually were aliases, On the other hand, a *personal* mailbox wasn't a good idea, because it usually was unattended when the person was on holidays. Besides, a vacation notice from a postmaster or hostmaster is never a good idea. So, if I remember correctly, I suggested to put a real, but shared mailbox there. > ======================= > A Address Records > ======================= > > Synopsis > [] [] IN A [ ...] please do not use the term 'hostname' as it causes great controversy re charset. True. Officially you should use the term "label" here. But I wouldn't be that conservative (;-)), because in general an A record *is* associated with a host(name), and the charset is a different issue. > Recommendations and remarks > Do not use FQDNs in the part. Hosts in subdomains > \340 la "www.internal", which resolve to "www.internal." > are okay though. Remember that IP addresses do not end in > a dot. Do not forget to maintain reverse delegation as well. \340? Charset... ;-) > ============================== > CNAME Canonical Name Records > ============================== > > Synopsis > [] IN CNAME again, not 'hostname' please. i believe that the rdata for a cname is an arbitrary domain name. Correct. Not even a "label". > Glue records > "Glue records" is a term that describes entering A records into > a zone for machines whose hostnames do not lie within . s/do not/do/ That has always been hard to explain. XX. SOA () ns.foo.xx. A 1.2.3.4 foo.xx. NS ns.foo.xx. bar.yy. NS ns.bar.yy. The ns.foo.xx A RR *must* be there, otherwise there's no "bootstrap" for the foo.xx domain. But many people don't see ns.foo.xx as lying within the XX zone, but in the foo.xx zone. In fact it's in both. That also implies that it can have different [default] TTL's in both zone files. On the other hand ns.bar.yy is definitely outside the current zone file, so there may be *no* glue record for it in this zone file. a cute and good sanity check is, a glue rr must never need a terminating dot on the label. Right. But sometimes I tend to be conservative, so I always put the FQDN in NS records. Piet From Piet.Beertema at cwi.nl Wed Nov 25 11:18:12 1998 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Wed, 25 Nov 1998 11:18:12 +0100 Subject: DNS recommendations - the paper In-Reply-To: "Your message of Wed, 25 Nov 1998 00:35:44 +0100 (MET) " <981125002020.21628A-100000@venus.euro.net> Message-ID: Piet who, by the way? kremvax!chernenko :-) Piet From ekb at ivm.net Wed Nov 25 11:18:24 1998 From: ekb at ivm.net (Elmar K. Bins) Date: Wed, 25 Nov 1998 11:18:24 +0100 Subject: DNS recommendations - the paper In-Reply-To: <7EC8990D4C018598@etf.bg.ac.yu>; from Berislav Todorovic on Tue, Nov 24, 1998 at 10:03:00PM +0100 References: <7EC8990D4C018598@etf.bg.ac.yu> Message-ID: <19981125111824.J5989@org> BERI at 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 at ivm.net) http://www.ivm.net/ From ekb at ivm.net Wed Nov 25 11:19:21 1998 From: ekb at ivm.net (Elmar K. Bins) Date: Wed, 25 Nov 1998 11:19:21 +0100 Subject: DNS recommendations - the paper In-Reply-To: ; from Randy Bush on Tue, Nov 24, 1998 at 01:44:42PM -0800 References: <7EC8F6216C018598@etf.bg.ac.yu> Message-ID: <19981125111921.K5989@org> randy at psg.com (Randy Bush) wrote: > > * The PTR section contains a possible mistake - are you sure you can write: > >>> 123.45.67.8 IN PTR mail.cust.com. > > yes, but only in the in-addr.arpa. zone does it have useful meaning. Seems like I was fighting with line length limitation here ;-) 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 at ivm.net) http://www.ivm.net/ From randy at psg.com Wed Nov 25 11:20:08 1998 From: randy at psg.com (Randy Bush) Date: Wed, 25 Nov 1998 02:20:08 -0800 (PST) Subject: DNS recommendations - the paper References: <981125002020.21628A-100000@venus.euro.net> Message-ID: >> Piet who, by the way? > kremvax!chernenko :-) rad! randy From ekb at ivm.net Wed Nov 25 11:27:10 1998 From: ekb at ivm.net (Elmar K. Bins) Date: Wed, 25 Nov 1998 11:27:10 +0100 Subject: DNS recommendations - the paper In-Reply-To: ; from Randy Bush on Tue, Nov 24, 1998 at 03:13:26PM -0800 References: <981124235716.21781C-100000@venus.euro.net> Message-ID: <19981125112710.L5989@org> randy at psg.com (Randy Bush) wrote: > >>> @ 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 Well, the point is, here the domain name points to the mail machine ;-) Does everybody agree that we should recommend an A-RR'd record here? > > (Remember that sendmail falls back to A records if it can't find any MX > > records for a host.) > > i think of it the other way, but with the same result. mail will be sent > to the (address in rdata of the) A RR unless some one put in an MX RR > because the (interface denoted in the) A RR can not accept mail. Let's put it this way: If MX records are found, mailers try to deliver there. If not, A records are used. So whichever way you put it, if MX records are existent, they will get in your way ;-) Elmi. From ekb at ivm.net Wed Nov 25 11:31:42 1998 From: ekb at ivm.net (Elmar K. Bins) Date: Wed, 25 Nov 1998 11:31:42 +0100 Subject: DNS recommendations - the paper In-Reply-To: ; from Randy Bush on Tue, Nov 24, 1998 at 04:17:08PM -0800 References: <981125002020.21628A-100000@venus.euro.net> Message-ID: <19981125113142.M5989@org> randy at psg.com (Randy Bush) wrote: > > The Bat Book advises you to always add MX records > > poor and unnecessary advice. Opinions may differ here... > i think we all agree that, if X can not receive mail directly, there should > be an MX for X pointing to an SMTP server. > > the point is that, if X runs an SMTP server, then there is no need for an MX > for X. There is a need if you want to provide failsafe SMTP service. No MX records, no fallback mailer (like "no hands, no cookies")... Elmi. From Piet.Beertema at cwi.nl Wed Nov 25 11:35:31 1998 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Wed, 25 Nov 1998 11:35:31 +0100 Subject: DNS recommendations - the paper In-Reply-To: "Your message of Wed, 25 Nov 1998 11:27:10 +0100 " <19981125112710.L5989@org> Message-ID: > >>> @ 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 Well, the point is, here the domain name points to the mail machine ;-) Does everybody agree that we should recommend an A-RR'd record here? No. According to Murphy an A-RR'ed address will be unreachable when you need it most. Then how am I going to tell that you'll have a fair chance reaching the contact at another RR'd address? Apart from that, I don't want to change the contact information when I move to another "primary" mailhost for a given domain. And why should I? We have MX RR's, don't we? Piet From randy at psg.com Wed Nov 25 11:36:18 1998 From: randy at psg.com (Randy Bush) Date: Wed, 25 Nov 1998 02:36:18 -0800 (PST) Subject: DNS recommendations - the paper References: <981125002020.21628A-100000@venus.euro.net> <19981125113142.M5989@org> Message-ID: >> the point is that, if X runs an SMTP server, then there is no need for an >> MX for X. > There is a need if you want to provide failsafe SMTP service. nope. all you have done is shuffle it to another non-destination spool. let's stick to the standards, not religion/fantasy. randy From alago at galeno.unicies.cesga.es Wed Nov 25 10:58:36 1998 From: alago at galeno.unicies.cesga.es (Alvaro Jose Fernandez Lago) Date: Wed, 25 Nov 1998 11:58:36 +0200 (GMT+0200) Subject: DNS recommendations - the paper (fwd) -- sorry Piet! Message-ID: <199811250958.LAA06153@galeno.unicies.cesga.es> 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 at unicies.cesga.es From Piet.Beertema at cwi.nl Wed Nov 25 11:45:25 1998 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Wed, 25 Nov 1998 11:45:25 +0100 Subject: DNS recommendations - the paper In-Reply-To: "Your message of Wed, 25 Nov 1998 11:31:42 +0100 " <19981125113142.M5989@org> Message-ID: > > The Bat Book advises you to always add MX records > poor and unnecessary advice. Opinions may differ here... I've been through this discussion numerous times. Seen from the outside world, CWI e-mail addresses may *only* be "user at cwi.nl" or "My.Name at cwi.nl". Internally we work with addresses including the mailhosts only for reaching those mailhosts, and MX does play a role here. Therefore the cwi.nl zone file doesn't contain MX records, except where *absolutely necessary*, i.e.: - for the domain cwi.nl itself; - for the mailhosts (fallback!). All additional MX records would be non-functional and mere pollution of the zone file. Piet From Piet.Beertema at cwi.nl Wed Nov 25 11:51:56 1998 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Wed, 25 Nov 1998 11:51:56 +0100 Subject: DNS recommendations - the paper In-Reply-To: "Your message of Tue, 24 Nov 1998 13:44:42 -0800 (PST) " Message-ID: > * 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". we may have a human language problem here. "need not be" means "is allowed but is not required." It also means "there's usually no point in having more". Piet From Piet.Beertema at cwi.nl Wed Nov 25 12:08:10 1998 From: Piet.Beertema at cwi.nl (Piet Beertema) Date: Wed, 25 Nov 1998 12:08:10 +0100 Subject: DNS recommendations - the paper In-Reply-To: "Your message of Tue, 24 Nov 1998 16:40:37 -0800 (PST) " Message-ID: CNAMEs map nicknames to cannonical names. Fortunately they're not *that* agressive. :-) CNAMEs have very few uses (see above example, RFC 2317, ...). Be especially aware that nicknames must not be used as the right hand of NS, MX, ... RRs. Having CNAMEs in the RHS of an NS RR is not explicitly forbidden (yet?), so there's only an indirect way to explain why they are: they collide with glue RRs, leading to a violation of the rule that CNAMEs may not have any other RRs associated with them: XX. SOA () ns.foo.xx. A 1.2.3.4 foo.xx. NS ns.foo.xx. foo.xx. SOA () @ NS ns.foo.xx. ns.foo.xx. CNAME myhost.foo.xx. This leads to the illegal combination: ns.foo.xx. CNAME myhost.foo.xx. ns.foo.xx. A myhost.foo.xx. but not [visibly] in either of the zone files themselves! Piet From hallgren at fdn.org Wed Nov 25 22:06:58 1998 From: hallgren at fdn.org (Michael Hallgren) Date: Wed, 25 Nov 1998 22:06:58 +0100 Subject: DNS recommendations - the paper In-Reply-To: ; from Randy Bush on Wed, Nov 25, 1998 at 02:36:18AM -0800 References: <981125002020.21628A-100000@venus.euro.net> <19981125113142.M5989@org> Message-ID: <19981125220658.C272@fdn.org> On Wed, Nov 25, 1998 at 02:36:18AM -0800, Randy Bush wrote: > >> the point is that, if X runs an SMTP server, then there is no need for an > >> MX for X. > > There is a need if you want to provide failsafe SMTP service. > > nope. all you have done is shuffle it to another non-destination spool. > > let's stick to the standards, not religion/fantasy. Yes, 'cause hackin' up a workable solution \neq standards. We have to fight ourselves out of patching. Maybe I'm a bit of a fascist, maybe not, but we have to consider scalability and production. I exchanged a bit of mail (with Randy and other's yesterday night), convincing me of the one way rfc approach... after all, it's not a nightmare to get put a zone in operation... but to stay clean is a valuable effort. BTW, looked into the M$soft implementaion... virgin experience... to be ctd;-) One (important) gain running the rfc way is KISS :-) Michael > > randy > -- Michael Hallgren, http://mh.graphnet.fr From randy at psg.com Wed Nov 25 22:11:42 1998 From: randy at psg.com (Randy Bush) Date: Wed, 25 Nov 1998 13:11:42 -0800 (PST) Subject: DNS recommendations - the paper References: <981125002020.21628A-100000@venus.euro.net> <19981125113142.M5989@org> <19981125220658.C272@fdn.org> Message-ID: > One (important) gain running the rfc way is KISS :-) Klaus Wirth taught many good lessons. I will be lazy and not look up exact quotes, but Do not ask what can be added, but rather how much can be omitted. I did not leave it out because I ran out of ink. If there is not a clear, simple, single, correct way, then leave it for next time. randy From hallgren at fdn.org Wed Nov 25 22:20:20 1998 From: hallgren at fdn.org (Michael Hallgren) Date: Wed, 25 Nov 1998 22:20:20 +0100 Subject: [hallgren@fdn.org: Re: Hello] Message-ID: <19981125222020.A4086@fdn.org> Well,... mh -- Michael Hallgren, http://mh.graphnet.fr -------------- next part -------------- An embedded message was scrubbed... From: Michael Hallgren Subject: Re: Hello Date: Wed, 25 Nov 1998 21:45:51 +0100 Size: 3736 URL: From Philipp.Buehler at xlink.net Wed Nov 25 08:33:50 1998 From: Philipp.Buehler at xlink.net (Philipp Buehler) Date: Wed, 25 Nov 1998 08:33:50 +0100 Subject: another DNS recommendation In-Reply-To: <9811250224.DA00404@nikhefh.nikhef.nl>; "Eric Wassenaar" on 25.11.1998 @ 03:24:34 MET References: <9811250224.DA00404@nikhefh.nikhef.nl> Message-ID: <19981125083350.A19446@xlink.net> Eric Wassenaar wrote: > I'm biased, but I would add one other recommendation: > > If you are the maintainer of a certain DNS > and your passes all tests via the command > host -C -A -L 1 > then your is probably in very good shape. > It is, but a zone can "fail" for different fwd and rev-mappings, which is really not bad. And for lot of services (virtual httpd) not to avoid. ciao -- Philipp Buehler, aka fIpS | | double-p on IRC Don't take me higher -- don't light my fire cause I'm afraid -- it could burn me to death --Oomph!, 1994 From Philipp.Buehler at xlink.net Thu Nov 26 15:22:33 1998 From: Philipp.Buehler at xlink.net (Philipp Buehler) Date: Thu, 26 Nov 1998 15:22:33 +0100 Subject: DNS recommendations - the paper (fwd) -- sorry Piet! In-Reply-To: <199811250958.LAA06153@galeno.unicies.cesga.es>; "Alvaro Jose Fernandez Lago" on 25.11.1998 @ 10:58:36 MET References: <199811250958.LAA06153@galeno.unicies.cesga.es> Message-ID: <19981126152233.B200@xlink.net> Alvaro Jose Fernandez Lago wrote: > Forwarded message: > > > > > What about wildcard MXs in the paper? > > I feel the issue should be noted as per RFC1912, for example. > Wildcards in A-RR too? Nice to setup virtual Webservers really fast, w/o waiting for the NS-Update. ciao -- Philipp Buehler, aka fIpS | | double-p on IRC Don't take me higher -- don't light my fire cause I'm afraid -- it could burn me to death --Oomph!, 1994