3.2. Host-Name Association Authorization (HNAA)
The introductory paragraphs in this section appear to be confused, or at
least confusing.
"However, a DNS domain name entry may include reccords that list any IP
Address. Even when a domain name is not legitimately associated with a
particular host (and it's IP Addresses), the forward-mapping DNS records
for that domain name might list the address."
This is correct, but it's talking about the opposite of what HNAA is
supposed to acheive: "Is the host's use of that domain name [...]
authorized?" HNAA is intended to verify the mapping from host to domain,
but the second paragraph wibbles for two sentences about the dodginess of
the mapping from domain to host.
Later on, in 3.1.2:
QUESTION: Is it safe to nonetheless suggest first
looking in in-addr.arpa? Is information
there merely incomplete or is it also
inaccurate. If the latter, we can't
recommend using it.
in-addr.arpa information can of course be inaccurate, especially if a host
is trying to claim an illegitimate association with a domain. Of course,
in that case the forward mapping(s) from the name(s) in the reverse
mapping will not include the lying address.
Section 3.2.2 is entirely confusing. How does a list of well-maintained
DNS zones help to verify that a host is not lying about its association? I
note that the well-maintainedness of a zone and a host from the point of
view of forward & reverse DNS and EHLO/HELO can be and is determined
dynamically by most MTAs.
As far as I can tell, the aim of HNAA is to require that a host's forward
and reverse DNS is correctly configured, and that it asserts the correct
name as the argument to EHLO/HELO. But it's fumbling around for some new
setup (also in the DNS!) that says the same thing.
--
Tony Finch <dot(_at_)dotat(_dot_)at> http://dotat.at/