[At-Large] The SSAC has published SAC123 and SAC122

Thu Dec 21 19:31:51 UTC 2023

You make good points.

I have long accepted the concept of competing root systems and have 
suggested various ways in which they could co-exist without causing 
discomfort for users, particularly with regard to collisions between 
divergent versions of the same TLD string. (See my year 1999 note: 
https://www.cavebear.com/archive/cavebear/growl/issue_2.htm#multiple_roots )

As you mention, we most definitely have some strong neo-root (as opposed 
to fully distinct competing root) systems, such as Google's 8.8.8.8, 
Comcast's 75.75.75.75, Cloudflare's 1.1.1.1, etc (and their IPv6 
equivalents.)  Whether the query streams to these are being data mined 
is unknown to me. However, I doubt that in today's world of "shareholder 
value" that commercial companies, particularly those who strongly 
leverage their revenue streams from personal network usage data they 
gather, will long resist the temptation to monetize those query streams 
- indeed I would be surprised if some have not done so already.  One may 
ask, as I will do here: Why are these for-profit companies spending 
not-inconsequential amounts of money to deploy services that are 
redundant with the legacy root system?  We would be naive to think that 
these for-profit companies will long expend shareholder owned assets 
without expectation of some compensating business advantage or revenue 
stream.

The legacy root server system has one characteristic that we too often 
overlook: It is run at an extremely high level of professionalism.  It 
is so high that there is usually no incentive to look to any other offering.

And that professionalism has little to do with ICANN.

For instance, remember the limitation (caused by the way that names are 
encoded into 512 byte UDP DNS packets) that places a limit of about 13 
root name servers?  Remember the contention that that caused in the 
early days of ICANN because those 13 places were not equitably 
distributed around the world?  It was not ICANN that came up with the 
notion of anycast groups of name servers, rather it was the external 
community that created the idea and it was the root server operators who 
went forth and did the work to make it happen - they did not give ICANN 
notice of this, nor await ICANN permission, nor did they ask for ICANN 
funding - they just did it.  And as a result, the net is a better place.

DNS technology is not the perfect answer to all questions - I've written 
about how DNS is insufficient to support the naming needs of net based 
distributed applications that move, split, and merge like blobs in a 
lava lamp.  E.g. My 2010 note "On Entity Associations In A Cloud 
Network" https://www.cavebear.com/archive/public/cloud-entities.pdf

And I see some well intentioned efforts that are trying to push DNS for 
uses that it is not necessarily appropriate or in ways that could create 
unnecessary risks of code flaws that could lead to attacks or security 
vulnerabilities (this is especially true in the Internet-of-Things world 
where code is often weak and relies on use in a confined, non-stressful 
network environment.  For example, should the coming generation of 
TCP/IP based Engine Control Units [ECU] in a vehicle have to implement 
Punycode and UTF-8 or ought they take the safer path of simply rejecting 
any non-ASCII names?)

         --karl--

On 12/21/23 3:34 AM, Christian de Larrinaga via At-Large wrote:
> I suspect it may well be too late (20 years too late!) to use the
> "reserve for posterity" approach for namespaces. A call to do this would
> no doubt be taken up at WIPO not ICANN anyway given the long standing
> issue with ICANN surrendering names as solely for business and
> governmental utility over its designed use for edge to edge resolution
> services. That would further push DNS away from the Internet edge and so
> itself be destabilising.
>
> There's also a question whether the single root argument made by IAB
> in 2000 is still gospel in a world where e2e offers secure
> frameworks for attestations of an infinite variety of namespaces and
> identifiers than is even conceivable for the DNS infrastructure.
>
> Particularly as DNS resolution is interpretative (punycode etc) today
> and largely anycast with geographical routing depending source and
> destination addressing which in turn depend on unofficial geo IP
> databases which are far from dependable given the growth in over and
> under private networks using their own choice of gateways into the
> "Internet". I am almost never in the place "The Internet" tells me I am
> in!
>
> But I take your insider political perspective on the ICANN
> firmament. But it rather confirms my concern that ICANN has been far to
> comfortable with the DNS industry as a private club believing everybody
> has to go through the DNS that it "controls".
>
> The reality is ICANN does not control the DNS just access to the root
> server resolution system. That is implemented as a tax and unsurprising
> if users think differently
>
> C
>
>
> Alejandro Pisanty via At-Large <at-large at atlarge-lists.icann.org> writes:
>
>> 1.  ( ) text/plain          (*) text/html
>>
>> Matthias,
>>
>> thanks very much for this rich information. The summaries alone should be considered as strong alarm signs. The
>> foci of attention of ALAC and At-Large seem way out of phase, lagging years behind these developments. This is
>> not uniform; some RALOs are in even worse shape, considering recent publicly available evidence.
>>
>> Alejandro Pisanty
>>
>> On Thu, Dec 21, 2023 at 12:21 AM Matthias M. Hudobnik via At-Large <at-large at atlarge-lists.icann.org> wrote:
>>
>>   Hi colleagues, the SSAC has published SAC123 and SAC122.
>>
>>    
>>
>>    
>>
>>   ### SSAC Report on the Evolution of Internet Name Resolution (SAC123):
>>
>>   ·         Internet name resolution is evolving beyond just the global DNS to include alternative naming systems
>>   that are experimenting with different approaches for reasons like speed, privacy, censorship resistance, and
>>   governance.
>>
>>   ·         Many alternative systems adopt DNS name syntax to leverage existing software.
>>
>>   ·         Two concerning trends are increased ambiguity where the same name can resolve differently in
>>   different systems, and less visibility of names to end users even as names remain vital for security and trust.
>>
>>   ·         Maintaining integrity and coordination in the shared domain namespace is important.
>>
>>   ·         The report explores different perspectives on these trends from end users and developers.
>>
>>   ·         It identifies proposals to facilitate namespace coordination and recommends ICANN continue tracking
>>   these issues and provide regular updates to the community.
>>
>>   I highly recommend having a look at chapter: 7.1 End Users (some key aspects as follows):
>>
>>   ·         Domain names used to play an important role for end users in discovering web resources, but search
>>   engines have now replaced them as the primary method of discovery.
>>
>>   ·         End users today rarely directly interact with domain names due to the dominance of search engines and
>>   mobile devices. Features like browser "omnibars" also allow more free-form input.
>>
>>   ·         Other identifiers like QR codes and social media handles now also compete for users' attention rather
>>   than domain names.
>>
>>   ·         Domain names are becoming less visible in users' environments, yet they still provide an underlying
>>   ubiquitous resolution context relied upon by other technologies.
>>
>>   ·         Surveys found search engines are by far the predominant method for accessing websites, with domain
>>   name usage declining. QR code usage is increasing but still limited except in Asia.
>>
>>   ·         Decreased domain name visibility makes it easier for fraudsters to deceive users with lookalike names.
>>   Users are also generally unaware that some TLDs signal a different resolution context.
>>
>>   In summary, domain names are no longer the primary method end users employ to find and access Internet
>>   resources, decreasing their visibility and understandability while introducing security issues.
>>
>>    
>>
>>   Link to the report:
>>   https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-123-15-12-2023-en.pdf
>>   
>>
>>    
>>
>>    
>>
>>   ### SSAC Report on Urgent Requests in gTLD Registration Data Policy (SAC122)
>>
>>   ·         Focus is on handling of Urgent Requests in proposed gTLD registration data policy
>>
>>   ·         Urgent Requests refer to imminent threats to life, injury, infrastructure or child exploitation
>>
>>   ·         Proposed policy requires response to Urgent Requests in 24 hours generally
>>
>>   ·         SSAC contends proposed policy for Urgent Requests is not fit for purpose
>>
>>   ·         Definition and required response times are incompatible
>>
>>   ·         Questions if need and rationale for separate Urgent Request process is fully justified
>>
>>   ·         Existing ICANN policy and industry practices offer useful precedents
>>
>>   ·         Proposed extensions allow responses up to 7 days, not reflecting urgency
>>
>>   ·         Lack of concrete data on frequency and handling of such requests currently
>>
>>   ·         Risks reputation of ICANN multistakeholder model effectiveness
>>
>>   -          Provides 3 recommendations
>>
>>   §  Add structure to ensure Urgent Requests handled expediently
>>
>>   §  Tighten response time requirements to be fit for purpose
>>
>>   §  Gather data on Urgent Requests for future policy making
>>
>>   Link to the report:
>>   https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-122-12-12-2023-en.pdf
>>   
>>
>>    
>>
>>   Have a nice evening!
>>
>>   Best,
>>
>>   M.
>>
>>    
>>
>>   ______________________________
>>
>>   Ing. Mag. Matthias M. Hudobnik
>>
>>   FIP • CIPP/E • CIPT • DPO • CIS LA
>>
>>   matthias at hudobnik.at
>>
>>   http://www.hudobnik.at
>>
>>   @mhudobnik
>>
>>   _______________________________________________
>>   At-Large mailing list
>>   At-Large at atlarge-lists.icann.org
>>   https://atlarge-lists.icann.org/mailman/listinfo/at-large
>>
>>   At-Large Official Site: http://atlarge.icann.org
>>   _______________________________________________
>>   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.
>