Hello, thanks for coming up with this again.
SOA The address in this field must be a valid e-mail address to the administrator for the DNS. *** It's also good practise to have role address instead of =09=09personal, ie root.. admin.. hostmaster..=20 =09=09(when domain-administrator is leaving your company, you=20 =09=09only change the alias for role address).
the three most common errors are: 1) Use of '@' in the DNS representation of the email address. It is essential that the '@' be encoded as '.'. One reason even knowledgable people use '@' is that you cannot publish addresses containing a dot in the local part this way. So, the popular scheme 'first.last@canonical.example' does not qualify for 1:1 translation. Usually you would (and you do, indeed) recommend using a canonical address like 'hostmaster@canonical.example' to avoid this. Another class of addresses are those from e.g. CompuServe. Just don't use them. 2) Useless defaults an unfortunately increasingly popular DNS server software suggests "administrator" either as a single label or with the zone name or probably the primary's name concatenated to it. While the first is even syntactically incorrect, mails to one of the latter nearly always bounces because the addresses have never been made valid. 3) copy 'n paste While it is tempting to use 'ns.bad.example' as the primary server for 'bad.example' and then to use 'root.ns.bad.example' as the "hostmaster" address, customers often forget one of the following: a) In most cases, although there exists an A-RR for ns.bad.example, that is not the "real" name of the host specified. To receive mail for root@ns.bad.example, the host must be informed to treat ns.bad.example as local. One of the strangest errors is receiving a mail from postmaster@schizo.example telling you that the address postmaster@schizo.example does not exist and then asking you to send further questions to, guess, postmaster@schizo.example. b) In other environments ns.bad.example is set up to handle DNS but for various reasons will not accept SMTP connections and does not have MX RRs defined for its name. During the last five years I've been sending hundreds of emails every month after evaluating the DE hostcount and most of the undeliverable mail fail due to one of the errors above (usually 15-20% of the tickets bounce.)
domain.xx. 3600 SOA dns.domain.xx admin.domain.xx.=20
IMHO there's no need to have a TTL of 3600 for the SOA, except that the software mentioned above seems to default to this value.
28800 ; refresh (8 hours) 7200 ; retry (2 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day)
As I probably mentioned in Amsterdam, an expire of just one week is almost always way too short. An Easter weekend with some days off for the administrator too easily destroy the zone completely. The value should be at least 4 weeks, because there is really no benefit from shorter expire. For the other fields fixed values are probably not appropriate in a recommendation. The usual case of one host inside a zone can have far larger TTLs and the values of refresh and retry depend on whether NOTIFY is available or not. Additionally, they are only relevant for the providers of secondary service. If an ISP will allow the customer a refresh of 30 minutes, it's their problem. If, however, the default TTL is only 3600, that affects third parties.
MX When pointing a domain to a mailserver/hostname, don=B4t forget to add a glue record ( A ) for this.
It's the other way round. If customer X adds MX RRs to his zone pointing to the providers mail relay, the customer MUST NOT add any A-RRs for that host. Modern versions of BIND fortunately do not allow out of zone data.
domain.xx. 86400 MX 10 mail.domain.xx. =20 mail.domain.xx 86400 A 192.168.0.1
maybe we should recommend As a target of an MX or NS resource record only domain names are allowed which directly resolve into an address. That means: 1) The name you enter must exist. Note that your software may let you enter names which do not exist without complaining. It is the DNS administrators responsibility to check this. A very helpful tool for this purpose is host ["reference here"]. 2) The name must really be a name. The DNS will not understand IP addresses here. Note however, that again your software may let you make the mistake but that it will definitely not bring you the results you wanted. Use only domain names here. 3) The domain name used must directly resolve into an address, which means you must not use an alias name here and an A resource record must exist for that name. Note that unless the name is part of your namespace you must not enter that A record yourself.
A A gluerecord can only point to an IP address. Avoid the term "glue record" here.
-Peter