Most of the query capacity of authority servers is dedicated to mitigate denial-of-service attacks, and most of them operate at less than 1% of capacity. That said, I don't know if this also applies to recursive servers of ISPs, so such an advice should come with a warning on how to use the DNS system in this case. But neither the available capacity or the usage warning would solve the usual issue programmers have with DNS is that DNS is considered slow. That was said to be the main reason for browsers not supporting DANE (DNSSEC-based certificates), so this might be hard to overcome. Rubens
On 8 Jul 2020, at 19:44, Edmon <edmon@registry.asia> wrote:
Perhaps we can say that before linkification automagically happens, a DNS lookup should be done to confirm that the domain exists? Or would that unnecessarily burden the DNS? Modern instant messengers do try to grab the web information too in fact when something gets linkified.
Edmon
-----Original Message----- From: UA-discuss <ua-discuss-bounces@icann.org> On Behalf Of Andrew Sullivan Sent: Monday, January 1, 2018 2:12 AM To: ua-discuss@icann.org Subject: Re: [UA-discuss] Universal Acceptance now on Wikipedia...https://en.wikipedia.org/wiki/Universal_Acceptance
On Sat, Dec 30, 2017 at 04:35:39PM +0000, Andre Schappo wrote:
I have just worked how to properly present IDNs in Apple Mail. By properly present I mean without any ASCII, so no https:// or www
I already made a remark about this, but maybe I haven't stated it in a way that is easily understood.
The current complaint -- the thing the USAG is attempting to fix -- is that there are these old conventions on the Internet that got turned into "rules" that programs enforce. The consequence of this is, of course, that innovation can't happen because the programs are automatically doing "the right thing" that turn out to be wrong. They're validating domain names using the LDH rule. Or they're using some static list of TLDs that do not reflect the correct current contents of the root zone. Or they're mistrusting IDNs that they don't understand. Or whatever.
When linkification assumes that every string of the form substring1.substring2.substring3 (and so on) is actually the host-part of a URI properly written as https://substring1.substring2.substring3/, then it creates _the very same_ kind of problem we are trying to combat. That is, the program is doing some automatic validation or modification of text in such a way that perfectly legitimate uses are broken. Not everything that is an apparent hostname actually _is_ a hostname, and not every actual hostname is the host- part of an http(s) URI/URL. For instance, I often find myself including host names for ssh access to people, and when that gets linkified as http(s) it actually gets in the way of using the infomation conveniently.
Presumably there will be future DNS uses that are also not https, since there are present ones.
I think it is bad to recommend linkification at all for things that do not have a scheme associated (i.e. that are not presented as URIs), and I think the USAG should make clear ways in which such a practice is harmful.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.