[UA-discuss] Universal Acceptance now on Wikipedia...https://en.wikipedia.org/wiki/Universal_Acceptance

[Rubens Kuhl]

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 at 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 at icann.org> On Behalf Of Andrew
>> Sullivan
>> Sent: Monday, January 1, 2018 2:12 AM
>> To: ua-discuss at 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 at 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/ua-discuss/attachments/20200708/8088b9c9/signature.asc>