Recommendations for DNS

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 at canonical.example'
   does not qualify for 1:1 translation. Usually you would (and you do, indeed)
   recommend using a canonical address like 'hostmaster at 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 at 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 at schizo.example telling you that the address
      postmaster at schizo.example does not exist and then asking you to send
      further questions to, guess, postmaster at 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