Well, I think Greg Wooledge is right here
Let's rewind the discussion.
The original context was "why do I need to have a dot in my HELO string".
The reason you need a dot in your HELO string is because SMTP receivers
may reject you as a spammer (or incompetent, same end result) if you do
not have one.
That's all.
All this academic crap about nodes and empty lists is irrelevant.
But since we've gotten so off track already (and we all live for that,
right?)....
On 3/22/18 11:04 PM, Richard Hector wrote:
On 23/03/18 14:44, Miles Fidelman wrote:
When it comes to hosts, it is generally understood that the FQDN
consists of both the hostname and domainname, and an awful lot of
protocol specs cite (and quote) https://tools.ietf.org/html/rfc1983 -
the "Internet Users' Glossary" which says...
Fully Qualified Domain Name (FQDN)
The FQDN is the full name of a system, rather than just its
hostname. For example, "venera" is a hostname and
"venera.isi.edu" is an FQDN. See also: hostname, Domain Name
System.
Another reference, thanks. Still not specific.
Not sure what gets more specific than the glossary of terms used in
common by all the other RFCs.
Granted that it doesn't really cover the case where a node doesn't
designate a "system" (though one could consider DNS as a system, in
which case "." is the full name, and it doesn't have a hostname).
Now, arguably, "." is an FQDN specifying the very top of the DNS tree,
and "com" (or "com.") specifies the top of the com domain - but who
really cares. Particularly since the whole discussion started around
fully qualified HOST names.
This is my point. And AFAIK DNS would happily accept an A record for
com, and probably . too. (I haven't tried it in BIND; I should ...)
Interesting. Of course the authoritative records would have to be on
either on
*.root-servers.net.
or
*.gtld-servers.net.
(per the SOA and NS records)
Might be interesting to see how bind would work if you created a local
record.
Another common definition of an FQDN is that it uniquely identifies a
node in the DNS tree. By that view "." is the FQDN for the top of the
tree, and "com" (or "com." is the top of the .com domain - but who
really cares, except for pedantic purposes.
When talking about specs and RFCs (which maybe only I was), surely
pedantic purposes are what it's all about?
Well yes, but if one wants to get pedantic, one has to note that the
standards are explicitly vague about some things.
Notably:
RFC-1034, DOMAIN NAMES - CONCEPTS AND FACILITIES
3. DOMAIN NAME SPACE and RESOURCE RECORDS
3.1. Name space specifications and terminology
Starts with "The domain name space is a tree structure. Each node and
leaf on the
tree corresponds to a resource set (which may be empty)." and goes on
to say
"The domain name of a node is the list of the labels on the path from the
node to the root of the tree."
From there, and in other RFCs, there is some specificity ("MUSTs" &
"SHOULDs"), but there is also language like
"By convention," and a lot of "MAYs".
I.e., one can only be pedantic up to a point. And then one has to
accept that there are general understandings, as well as wide variances
in the way different people & software implement things.
There aren't any
nameservers that resolve "." or "com" or "mil" - implying that there are
no records in the system for them (maybe there should be, but that's
another question for another day).
There might not be A, AAAA or MX records, but there are certainly
servers, and they serve at least SOA and NS (and RRSIG) records for all
3 of those.
So there are. I stand corrected.
Cheers,
Miles
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra