--On Friday, July 18, 2014 23:18 +1000 Mark Andrews
<ma...@isc.org> wrote:

>> At least in the near term, some SMTP Server ("MTA")
>> implementations will conform to that rule (many already use
>> it) and some won't.   For the latter, they will presumably do
>> what the SMTP specs say to do.  In summary, that is to look
>> up the address(es) associated with the root and try to open a
>> mail
> 
> No.  Lookup the address _at_ _the_ _root_.  This is _not_ the
> addresses of the root servers.

I tried to make clear that I'm ignorant of many of the details
here, so, if there is no issue, I apologize for wasting people's
time. 

If the answer to those questions is "not an issue", that is the
answer and the end of the discussion.

However, because I'm paranoid, let me mention an issue in
passing without any reason to believe that it is a problem in
practice.

For SMTP (and at least some other applications) there has always
been a question about what to do with DNS queries in mixed IPv4
and IPv6 environments when the application wants to get both
sets of addresses.  I vaguely remember an idea about a query
type of "ADDEESS" (or equivalent) that would return both A and
AAAA RRs but, as far as I know, it didn't go anywhere.  If there
are best practices recommendations for applications writers in
this area, I don't think they have been widely disseminated in
the applications development community.  The poor bewildered
application author then has two choices, both of which appear to
be rational.  One is to issue two queries, one for A RRs and one
for AAAA, and then sort things out in the application.   The
other is to issue an ANY query and sort the relevant information
out from it.   I at least superficially understand the problems
with the latter and you obviously understand them much better.
But, should an application writer make that choice (and, again,
clear advice has not been broadly disseminated), a query for the
root does get back address records.

It is probably sensible to conclude that the number of
implementations that are that stupid doesn't make the issue
worth worrying about but that should be your conclusion, not
mine, because I am obviously out of my depth here.

    john



    


_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to