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