Yes, but this assumes you're talking about internet registrations. For internal DNS this is irrelevant.
You can also enable to relay for anybody, namely for the root domain. It is your decision.
www.de is a valid FQDN on the internet. It has an “A” record, so you can connect to it (it’s running a small web server, although it’s just redirecting elsewhere).de. Technically this is perfectly valid, and there is nothing in the RFCs that would disallow that. In practice it isn’t done because users would have to use the canonical (some call this “absolute”) form to access it, and most users don’t know how to do this. Hosts usually perform canonicalization, i.e. the resolver appends its own domain to names that are unqualified, i.e. names that don’t contain a dot. To write a TLD as a qualified (“absolute”) name, you have to append a dot. So, to access a hypothetical web server running on the TLD de, you would have to write https://de./ (note the dot). If you’re curious, you can try this yourself at home with BIND and a zone file for the example domain.
That’s what sendmail does.
That's a root domain record. They're very popular nowadays. I would much rather have proper host records ("www" should be a host or an alias to a host, for example), but I appear to be very much in the minority.
The dot is not a domain. It's used to prevent origin substitution, both in zone files, and for the resolver, as Olli@ points out. I think origin substitution is also called "canonicalization", which is quite a typeful.
I used UW-IMAP for years, and was also very happy with it. Eventually my mailbox file got too big and started causing problems. I've just read that the author of UW-IMAP refused to add support for maildirs due a disagreement with DJB:
www.courier-mta.org
I suspect this behavior was deliberately added when MX records were introduced. The standard before then was that mail would be sent to a particular host with an A record. This is from back in the day when having a mail account meant having a user account on some big Unix machine on campus. That approach works to this day if your domain does not have an MX record.
Actually, both is correct.
host -a . or drill . any that lists the delegation for the root name servers.Of course, that’s what the RFC requires. If there is no MX record, then the address record (A or AAAA) is used, with an implicit preference of 0.
Turns out there's another very special TLD under ".", "arpa".
Indeed – I dismissed it earlier, having overlooked this paragraph:
Although this document makes specific reference to [RFC7788], it is
not intended that the use of 'home.arpa.' be restricted solely to
networks where HNCP is deployed. Rather, 'home.arpa.' is intended to
be the correct domain for uses like the one described for '.home' in
[RFC7788]: local name service in residential homenets.I don't love it. The other subdomain for ARPA, "in-addr" is clearly meant to specify the Internet protocol class. Stuffing home under arpa seems to violate Section 2.1 of RFC 3172. I know it's only a recommendation, but still, it's messy.
tools.ietf.org
Don't forget ip6.arpa.
Indeed, it's a misuse. Looks like IETF wanted to reserve some TLD, but IANA didn't agree…
