[dns-operations] [Ext] How should work name resolution on a modern system?

[Paul Hoffman]

On Jun 15, 2022, at 1:57 PM, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> 
> On Wed, Jun 15, 2022 at 04:24:01PM -0400, Dave Lawrence via dns-operations wrote:
> 
>> I'm aware "SSAC also recommends that the use of DNS resource records
>> such as A, AAAA, and MX in the apex of a TopLevel Domain (TLD) be
>> contractually prohibited where appropriate and strongly discouraged in
>> all cases," yet still note that saying "getaddrinfo should not result
>> in single label 'A' or 'AAAA' DNS queries" is a meaningful policy
>> change to an API that's older than some of the people on this mailing
>> list.
> 
> The IETF tends to be very conservative in leave lots of lattitude in its
> specifications for various potential corner cases.  The caution is often
> times warranted, and yet in the same 3 decades or so nothing has changed
> the fact that A/AAAA records at TLDs are profoundly fragile.

What is "profoundly fragile" about A or AAAA records at any level of the DNS hierarchy?

Also note that the example given earlier is a ccTLD, not a gTLD. ICANN does not have contracts with (most of) the ccTLD admins.

> So as a platform library maintainer, I'd be stricter than IETF was
> willing to be, and would in fact have getaddrinfo(3) return an empty
> list for "some-tld" and even "some-tld.", with the notable exception of
> "localhost", whith the nsswitch code sending no A/AAAA DNS queries for
> TLDs.  Only /etc/hosts and other local sources would be consulted.

Advocating that a library not check for valid data (even if you believe that it is "profoundly fragile" seems more likely to lead to damage than checking for it.

--Paul Hoffman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2584 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20220615/95c732a4/attachment.bin>