1. RFC3493
https://tools.ietf.org/html/rfc3493
2. RFC6762
https://tools.ietf.org/html/rfc6762
3. For example, if /etc/resolv.conf has
nameserver 127.0.0.53
search foobar.com barbar.com
and we look up "localhost", nss-dns will send the following
queries to systemd-resolved listening on 127.0.0.53:53: first
"localhost.foobar.com", then "localhost.barbar.com", and
finally "localhost". If (hopefully) the first two queries
fail, systemd-resolved will synthesize an answer for the
third query.
When using nss-dns with any search domains, it is thus
crucial to always configure nss-files with higher priority
and provide mappings for names that should not be resolved
using search domains.
4. There are currently more than 1500 top-level domain names
defined, and new ones are added regularly, often using
"attractive" names that are also likely to be used locally.
Not looking up multi-label names in this fashion avoids
fragility in both directions: a valid global name could be
obscured by a local name, and resolution of a relative local
name could suddenly break when a new top-level domain is
created, or when a new subdomain of a top-level domain in
registered. Resolving any given name as either relative or
absolute avoids this ambiguity.
