Summary of the Amazon DynamoDB Service Disruption in Northern Virginia (US-EAST-1) Region
AWS has published its summary of the Summary of the Amazon DynamoDB Service Disruption in Northern Virginia (US-EAST-1) Region which made the headlines on 20 October 2025: https://www.bbc.co.uk/news/articles/cev1en9077ro "...why did it make the internet fall apart" Perhaps the most surprising part of the reporting is how much noise was made about it, at least in the UK, sometimes equating to impending hyped doom reports of the "death of the net predicted" and mixing into a it a good measure of "it's always a DNS problem...". I'll spare you the links to the articles, just search for them on a search engine. What's more interesting is the actual AWS summary which they have published: https://aws.amazon.com/message/101925/ Having been around for long enough to have seen the 'net grow over the years, the first thing that struck me is the complexity of these cloud networks that now form most of the Internet. No longer is this just a simple server -> client scenario with a handful of routers and TCP/IP. The way by which the Heart of today's world works, aka the "back end" to all of our Apps and Web sites is way more complicated than I ever imagined. Yes, one of my companies is an AWS customer so I wasn't a total novice into the AWS instances, NLB, EC2 and Route 53. But the process by which this all works (supposedly like clockwork and sometimes not) surpassed my imagination. And this is where I discovered the "seamless scale" whereas you can keep track of the whole ecosystem of virtual machine instances and load balancers using a constantly updated dynamic DNS. I frankly do not know how to give it a name, but the times of manually inputting listings into a file at /var/named/data/example.hosts is long gone! So here's my question: is the DNS fit for purpose for the use AWS is making of it? I wonder whether we could ask if anyone on the SSAC could explain this to us in a few minutes during the ALAC meeting with the SSAC on Sunday? Kindest regards, Olivier
The answer to your question is a solid "no" - DNS is not the system that we need as the network evolves into a world less of fixed hosts with IP addresses to applications that move about, (and at the service end) sometimes splitting, sometimes merging, and with things always going on and off line. Moreover, these days, in our internet-of-apps we often want a service that is ascertained by attribute(s) rather than by name. I wrote a short (four page) note about this for a cloud computing meeting about 15 years ago... On Entity Associations In A Cloud Network https://www.cavebear.com/archive/public/cloud-entities.pdf Since you mentioned the AWS outage - I would like to append my ever stated, rarely heard plea that we begin to consider what we need to do to the net to transform it into the lifeline grade utility that many people believe (incorrectly) it to be. Speaking as a person who grew up in a family of radio, tv, and electronics repairmen (always men) we are building our network much like a passenger aircraft company that builds their craft to fly in nice weather but has never really delved into what could happen during a storm. (Trying to land at Van Nuys airport during horrific Santa Ana winds with a dead radio and a failing fuel system is an excellent way to learn about the need for pre-made plan Bs.) --karl-- On 10/24/25 12:01 PM, Olivier MJ Crépin-Leblond via At-Large wrote:
AWS has published its summary of the Summary of the Amazon DynamoDB Service Disruption in Northern Virginia (US-EAST-1) Region which made the headlines on 20 October 2025:
https://www.bbc.co.uk/news/articles/cev1en9077ro "...why did it make the internet fall apart"
Perhaps the most surprising part of the reporting is how much noise was made about it, at least in the UK, sometimes equating to impending hyped doom reports of the "death of the net predicted" and mixing into a it a good measure of "it's always a DNS problem...". I'll spare you the links to the articles, just search for them on a search engine.
What's more interesting is the actual AWS summary which they have published: https://aws.amazon.com/message/101925/
Having been around for long enough to have seen the 'net grow over the years, the first thing that struck me is the complexity of these cloud networks that now form most of the Internet. No longer is this just a simple server -> client scenario with a handful of routers and TCP/IP. The way by which the Heart of today's world works, aka the "back end" to all of our Apps and Web sites is way more complicated than I ever imagined.
Yes, one of my companies is an AWS customer so I wasn't a total novice into the AWS instances, NLB, EC2 and Route 53. But the process by which this all works (supposedly like clockwork and sometimes not) surpassed my imagination.
And this is where I discovered the "seamless scale" whereas you can keep track of the whole ecosystem of virtual machine instances and load balancers using a constantly updated dynamic DNS. I frankly do not know how to give it a name, but the times of manually inputting listings into a file at /var/named/data/example.hosts is long gone!
So here's my question: is the DNS fit for purpose for the use AWS is making of it?
I wonder whether we could ask if anyone on the SSAC could explain this to us in a few minutes during the ALAC meeting with the SSAC on Sunday?
Kindest regards,
Olivier
_______________________________________________ At-Large mailing list -- at-large@icann.org To unsubscribe send an email to at-large-leave@icann.org
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.
Oh, by-the-way, I don't mean, in the text below, that DNS is no longer usable. Rather than we need an additional naming system (perhaps based on attributes) that can lead to stable DNS names (thus obviating a need for the kind of short-lived DNS name-mapping juggling that goes on now.) As has been oft said in computer science - and networking - one can solve many problems by adding an additional layer of indirection. --karl-- On 10/24/25 12:19 PM, Karl Auerbach wrote:
The answer to your question is a solid "no" - DNS is not the system that we need as the network evolves into a world less of fixed hosts with IP addresses to applications that move about, (and at the service end) sometimes splitting, sometimes merging, and with things always going on and off line.
Moreover, these days, in our internet-of-apps we often want a service that is ascertained by attribute(s) rather than by name.
I wrote a short (four page) note about this for a cloud computing meeting about 15 years ago...
On Entity Associations In A Cloud Network
https://www.cavebear.com/archive/public/cloud-entities.pdf
Since you mentioned the AWS outage - I would like to append my ever stated, rarely heard plea that we begin to consider what we need to do to the net to transform it into the lifeline grade utility that many people believe (incorrectly) it to be. Speaking as a person who grew up in a family of radio, tv, and electronics repairmen (always men) we are building our network much like a passenger aircraft company that builds their craft to fly in nice weather but has never really delved into what could happen during a storm. (Trying to land at Van Nuys airport during horrific Santa Ana winds with a dead radio and a failing fuel system is an excellent way to learn about the need for pre-made plan Bs.)
--karl--
On 10/24/25 12:01 PM, Olivier MJ Crépin-Leblond via At-Large wrote:
AWS has published its summary of the Summary of the Amazon DynamoDB Service Disruption in Northern Virginia (US-EAST-1) Region which made the headlines on 20 October 2025:
https://www.bbc.co.uk/news/articles/cev1en9077ro "...why did it make the internet fall apart"
Perhaps the most surprising part of the reporting is how much noise was made about it, at least in the UK, sometimes equating to impending hyped doom reports of the "death of the net predicted" and mixing into a it a good measure of "it's always a DNS problem...". I'll spare you the links to the articles, just search for them on a search engine.
What's more interesting is the actual AWS summary which they have published: https://aws.amazon.com/message/101925/
Having been around for long enough to have seen the 'net grow over the years, the first thing that struck me is the complexity of these cloud networks that now form most of the Internet. No longer is this just a simple server -> client scenario with a handful of routers and TCP/IP. The way by which the Heart of today's world works, aka the "back end" to all of our Apps and Web sites is way more complicated than I ever imagined.
Yes, one of my companies is an AWS customer so I wasn't a total novice into the AWS instances, NLB, EC2 and Route 53. But the process by which this all works (supposedly like clockwork and sometimes not) surpassed my imagination.
And this is where I discovered the "seamless scale" whereas you can keep track of the whole ecosystem of virtual machine instances and load balancers using a constantly updated dynamic DNS. I frankly do not know how to give it a name, but the times of manually inputting listings into a file at /var/named/data/example.hosts is long gone!
So here's my question: is the DNS fit for purpose for the use AWS is making of it?
I wonder whether we could ask if anyone on the SSAC could explain this to us in a few minutes during the ALAC meeting with the SSAC on Sunday?
Kindest regards,
Olivier
_______________________________________________ At-Large mailing list -- at-large@icann.org To unsubscribe send an email to at-large-leave@icann.org
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.
On October 24, 2025 at 15:54 at-large@icann.org (Karl Auerbach via At-Large) wrote:
Oh, by-the-way, I don't mean, in the text below, that DNS is no longer usable. Rather than we need an additional naming system (perhaps based on attributes) that can lead to stable DNS names (thus obviating a need for the kind of short-lived DNS name-mapping juggling that goes on now.)
As has been oft said in computer science - and networking - one can solve many problems by adding an additional layer of indirection.
--karl--
Isn't that what host names are? -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
In our internet naming system "host names" are synonyms for IP addresses which are labels on network interfaces on host machines. In our evolving internet of applications - typically floating in a conceptual "cloud" - the binding between a specific instance of an application service and a host/network interface is something that is rather dynamic and changeable, even during the existence of a client-to-service session. DNS is sort of becoming like MAC addresses - it is becoming less and less visible to users who are getting more used to dealing with other sorts of naming systems, often application specific naming systems. DNS can well be (and usually ought to be) underneath. But DNS isn't designed for the kind of dynamics that can occur with the increased rates of user-to-service binding (and changes to those bindings) that are becoming more typical. Much of the magic of DNS comes from caching. And caching is troublesome in a world where client and service relationships are potentially changeable, even within a few seconds. I am not sure that any single higher-than-DNS name (or attribute) lookup system will be right for all applications, so we may end up with several of these higher level systems. This would largely be as visible to users as are the lookups inside AWS, Facebook, or other systems that are evolving their own notion of "names". In the old ISO/OSI world they had a concept of "application titles" which are distinct from network addresses. But even that is perhaps too static for they way our internet is becoming more a world of pieces of code that may run in many places - or may be started or moved as loads and connectivity and location change. --karl-- On 10/25/25 1:14 PM, bzs@theworld.com wrote:
On October 24, 2025 at 15:54 at-large@icann.org (Karl Auerbach via At-Large) wrote:
Oh, by-the-way, I don't mean, in the text below, that DNS is no longer usable. Rather than we need an additional naming system (perhaps based on attributes) that can lead to stable DNS names (thus obviating a need for the kind of short-lived DNS name-mapping juggling that goes on now.)
As has been oft said in computer science - and networking - one can solve many problems by adding an additional layer of indirection.
--karl--
Isn't that what host names are?
Yes also taking on that point it's interesting that the growing distribution of virtual spaces for code, data and models are likely to be cryptographically demarcated and abstracted from hosting physical infrastructures. In that environment routing proof is cryptographically intrinsic and that may stimulate fresh thinking about the role of naming and also techniques for indirection mapping layers you mentioned before. That doesn't kill DNS but it may focus future best practices and suitability as host for carbuncle protocol developments. C Karl Auerbach via At-Large <at-large@icann.org> writes:
In our internet naming system "host names" are synonyms for IP addresses which are labels on network interfaces on host machines.
In our evolving internet of applications - typically floating in a conceptual "cloud" - the binding between a specific instance of an application service and a host/network interface is something that is rather dynamic and changeable, even during the existence of a client-to-service session.
DNS is sort of becoming like MAC addresses - it is becoming less and less visible to users who are getting more used to dealing with other sorts of naming systems, often application specific naming systems.
DNS can well be (and usually ought to be) underneath. But DNS isn't designed for the kind of dynamics that can occur with the increased rates of user-to-service binding (and changes to those bindings) that are becoming more typical.
Much of the magic of DNS comes from caching. And caching is troublesome in a world where client and service relationships are potentially changeable, even within a few seconds.
I am not sure that any single higher-than-DNS name (or attribute) lookup system will be right for all applications, so we may end up with several of these higher level systems. This would largely be as visible to users as are the lookups inside AWS, Facebook, or other systems that are evolving their own notion of "names".
In the old ISO/OSI world they had a concept of "application titles" which are distinct from network addresses. But even that is perhaps too static for they way our internet is becoming more a world of pieces of code that may run in many places - or may be started or moved as loads and connectivity and location change.
--karl--
On 10/25/25 1:14 PM, bzs@theworld.com wrote:
On October 24, 2025 at 15:54 at-large@icann.org (Karl Auerbach via At-Large) wrote:
Oh, by-the-way, I don't mean, in the text below, that DNS is no longer usable. Rather than we need an additional naming system (perhaps based on attributes) that can lead to stable DNS names (thus obviating a need for the kind of short-lived DNS name-mapping juggling that goes on now.)
As has been oft said in computer science - and networking - one can solve many problems by adding an additional layer of indirection.
--karl--
Isn't that what host names are?
_______________________________________________ At-Large mailing list -- at-large@icann.org To unsubscribe send an email to at-large-leave@icann.org
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.
-- Christian de Larrinaga
Just to avoid the possibility of re-inventing the wheel how much of this idea is covered by systems like CORBA (1991, now mostly obsolete tho latest release was 2014), X.500, and LDAP (a simplified subset of X.500)? And Microsoft's Active Directory? Or logical extensions thereof (where is ____?) https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture https://en.wikipedia.org/wiki/X.500 https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol https://en.wikipedia.org/wiki/Active_Directory or the various "See Also" on those wikipedia pages (Apple Open Directory, etc etc etc)? And I guess URIs/URLs in general? There's a rich history of people throwing themselves against this idea of locating objects in a network, particularly at a generic level (where is a printer I can use which does two-sided color printing and is at least 20ppm? Or a game server for <GAME> or whatever.) Also, the CDNs like Akamai dabble in this more than a little. Geoff Houston had a great article in a recent "Internet Protocol Journal" (May 2025, V28.1), "The IPv6 Transition", which goes way beyond what the title might imply and talks about how between NAT, CGNAT, CDNs, DNS, and DDNS "this ain't yer grandparents internet anymore"...you'd have to read the article, it's only several pages long but I had several "oh yeah he's right" moments reading it. On October 25, 2025 at 14:27 karl@cavebear.com (Karl Auerbach) wrote:
In our internet naming system "host names" are synonyms for IP addresses which are labels on network interfaces on host machines.
In our evolving internet of applications - typically floating in a conceptual "cloud" - the binding between a specific instance of an application service and a host/network interface is something that is rather dynamic and changeable, even during the existence of a client-to-service session.
DNS is sort of becoming like MAC addresses - it is becoming less and less visible to users who are getting more used to dealing with other sorts of naming systems, often application specific naming systems.
DNS can well be (and usually ought to be) underneath. But DNS isn't designed for the kind of dynamics that can occur with the increased rates of user-to-service binding (and changes to those bindings) that are becoming more typical.
Much of the magic of DNS comes from caching. And caching is troublesome in a world where client and service relationships are potentially changeable, even within a few seconds.
I am not sure that any single higher-than-DNS name (or attribute) lookup system will be right for all applications, so we may end up with several of these higher level systems. This would largely be as visible to users as are the lookups inside AWS, Facebook, or other systems that are evolving their own notion of "names".
In the old ISO/OSI world they had a concept of "application titles" which are distinct from network addresses. But even that is perhaps too static for they way our internet is becoming more a world of pieces of code that may run in many places - or may be started or moved as loads and connectivity and location change.
--karl--
On 10/25/25 1:14 PM, bzs@theworld.com wrote:
On October 24, 2025 at 15:54 at-large@icann.org (Karl Auerbach via At-Large) wrote:
Oh, by-the-way, I don't mean, in the text below, that DNS is no longer usable. Rather than we need an additional naming system (perhaps based on attributes) that can lead to stable DNS names (thus obviating a need for the kind of short-lived DNS name-mapping juggling that goes on now.)
As has been oft said in computer science - and networking - one can solve many problems by adding an additional layer of indirection.
--karl--
Isn't that what host names are?
-- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
Indeed, resource discovery has long been a difficult problem. I was particularly intrigued by the old IF-MAP work from a couple of decades ago. (There is a modern if-map but I am not sure it bears any resemblance - I don't seem to be able to quickly drag up any references to that old work - in other words I am having a resource discovery problem. ;-) I notice all the avahi and other resource announcements bouncing around my home network. The older methods that I've seen seemed derived from the kind of hard, usually somewhat pre-fixed and ordained taxonomies that are often used to index books in libraries, not the kind of somewhat more free form stuff that we are seeing from search engines and "AI" tools. (In our businesses we have to deal with export control regulations so I am always banging my head against the hard, and increasingly obsolete, taxonomies used by the import and export people in governments. Sometimes the choice can have some serious financial side effects. Same problem seems to exist in medical procedure coding.) There are several dimensions - such as whether targets register their existence to a registration point or whether they just pop up and announce. Back when I was doing entertainment grade video there were some horrid "solutions" that conflated DNS proximity with both proximity to a service and a good path to that service. That was what drove me to begin, but not finish, what I called the Fast Path Characterization Protocol to quickly and cheaply evaluate the suitability of a proposed client-to-service binding - https://www.cavebear.com/archive/fpcp/fpcp-sept-19-2000.html ) And I've hit the common flaws - such as finding the nearest printer, which happens to be one floor directly above me. Yes, it is close but it will take me a long walk, stairs (or elevator) to get there. I've long been intrigued by perhaps the most successful resource discovery system on our world: Insects finding one another for reproduction. The method is chemical - pheromones. Those have some nice properties - such as the "find me" signal is attenuated with distance. I've played with some protocol designs based on random lofting of UDP packets that contain several announcements, each with a TTL, and relay points that expire items with TTL expiration, and add other announcements. And I've played with "designated noses" to act as collectors that can announce that they exist using the same methods. The barrier I hit was that in chemistry I've got lots and lots of data bits - long chains can carry a lot of data - and that network packets are not even close to large enough to obtain the kinds of announcements which could be possible. (This is similar to some ideas that I have to adopt CRISPR techniques for very-long pattern matching to facilitate things like crypto cracking and also video compression - yes, I am imagining a kind of chemical-bio-electronic computational system.) No single resource discovery system will meet all needs. Rather I foresee that there will be a need for various methods depending on the application space. And I suspect that URL/URI structures (with DNS names) will be part of the inner (but often hidden from users) machinery of these methods. --karl-- On 10/26/25 6:57 PM, bzs@theworld.com wrote:
Just to avoid the possibility of re-inventing the wheel how much of this idea is covered by systems like CORBA (1991, now mostly obsolete tho latest release was 2014), X.500, and LDAP (a simplified subset of X.500)? And Microsoft's Active Directory? Or logical extensions thereof (where is ____?)
https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture https://en.wikipedia.org/wiki/X.500 https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol https://en.wikipedia.org/wiki/Active_Directory
or the various "See Also" on those wikipedia pages (Apple Open Directory, etc etc etc)? And I guess URIs/URLs in general?
There's a rich history of people throwing themselves against this idea of locating objects in a network, particularly at a generic level (where is a printer I can use which does two-sided color printing and is at least 20ppm? Or a game server for <GAME> or whatever.)
Also, the CDNs like Akamai dabble in this more than a little.
Geoff Houston had a great article in a recent "Internet Protocol Journal" (May 2025, V28.1), "The IPv6 Transition", which goes way beyond what the title might imply and talks about how between NAT, CGNAT, CDNs, DNS, and DDNS "this ain't yer grandparents internet anymore"...you'd have to read the article, it's only several pages long but I had several "oh yeah he's right" moments reading it.
On October 25, 2025 at 14:27 karl@cavebear.com (Karl Auerbach) wrote:
In our internet naming system "host names" are synonyms for IP addresses which are labels on network interfaces on host machines.
In our evolving internet of applications - typically floating in a conceptual "cloud" - the binding between a specific instance of an application service and a host/network interface is something that is rather dynamic and changeable, even during the existence of a client-to-service session.
DNS is sort of becoming like MAC addresses - it is becoming less and less visible to users who are getting more used to dealing with other sorts of naming systems, often application specific naming systems.
DNS can well be (and usually ought to be) underneath. But DNS isn't designed for the kind of dynamics that can occur with the increased rates of user-to-service binding (and changes to those bindings) that are becoming more typical.
Much of the magic of DNS comes from caching. And caching is troublesome in a world where client and service relationships are potentially changeable, even within a few seconds.
I am not sure that any single higher-than-DNS name (or attribute) lookup system will be right for all applications, so we may end up with several of these higher level systems. This would largely be as visible to users as are the lookups inside AWS, Facebook, or other systems that are evolving their own notion of "names".
In the old ISO/OSI world they had a concept of "application titles" which are distinct from network addresses. But even that is perhaps too static for they way our internet is becoming more a world of pieces of code that may run in many places - or may be started or moved as loads and connectivity and location change.
--karl--
On 10/25/25 1:14 PM, bzs@theworld.com wrote:
On October 24, 2025 at 15:54 at-large@icann.org (Karl Auerbach via At-Large) wrote:
Oh, by-the-way, I don't mean, in the text below, that DNS is no longer usable. Rather than we need an additional naming system (perhaps based on attributes) that can lead to stable DNS names (thus obviating a need for the kind of short-lived DNS name-mapping juggling that goes on now.)
As has been oft said in computer science - and networking - one can solve many problems by adding an additional layer of indirection.
--karl--
Isn't that what host names are?
On October 26, 2025 at 20:27 karl@cavebear.com (Karl Auerbach) wrote:
Indeed, resource discovery has long been a difficult problem.
I was particularly intrigued by the old IF-MAP work from a couple of decades ago. (There is a modern if-map but I am not sure it bears any resemblance - I don't seem to be able to quickly drag up any references to that old work - in other words I am having a resource discovery problem. ;-)
I notice all the avahi and other resource announcements bouncing around my home network.
The older methods that I've seen seemed derived from the kind of hard, usually somewhat pre-fixed and ordained taxonomies that are often used to index books in libraries, not the kind of somewhat more free form stuff that we are seeing from search engines and "AI" tools.
Ted Nelson and Roger Gregory's (also Mark Miller and some others) indexing system for Project Xanadu used "transfinite numbers", a general term which also describes the Dewey Decimal system which they called "tumblers" (ISTR "humbers", "huge numbers".) https://en.wikipedia.org/wiki/Project_Xanadu See in particular the "17 rules" on that page, and "Tumbler" The idea isn't all that complicated as I understood it. If you have a resource like 1.1.1.1 you can address a related, more specific resource (perhaps a paragraph in that document or another document) by inserting another number like 1.1.1234.1.1 or 1.1.1.789.1. The devil is in the details just like in the Dewey Decimal system but the point is you can keep branching horizontally (related) or vertically (specificity) and, given an index, can relate back to its origin documents. The "who points at me?" problem among other things. The BIG issue is whether one attacks it like a taxonomy, something Yahoo tried to do in its earlier days, or do you sweep the entire net and index on the fly as Google does building relevance tables. Thus far Google has won. The major AI systems are following Google's lead. (my only response comment in this note)
(In our businesses we have to deal with export control regulations so I am always banging my head against the hard, and increasingly obsolete, taxonomies used by the import and export people in governments. Sometimes the choice can have some serious financial side effects. Same problem seems to exist in medical procedure coding.)
There are several dimensions - such as whether targets register their existence to a registration point or whether they just pop up and announce. Back when I was doing entertainment grade video there were some horrid "solutions" that conflated DNS proximity with both proximity to a service and a good path to that service. That was what drove me to begin, but not finish, what I called the Fast Path Characterization Protocol to quickly and cheaply evaluate the suitability of a proposed client-to-service binding - https://www.cavebear.com/archive/fpcp/fpcp-sept-19-2000.html )
And I've hit the common flaws - such as finding the nearest printer, which happens to be one floor directly above me. Yes, it is close but it will take me a long walk, stairs (or elevator) to get there.
I've long been intrigued by perhaps the most successful resource discovery system on our world: Insects finding one another for reproduction. The method is chemical - pheromones. Those have some nice properties - such as the "find me" signal is attenuated with distance.
I've played with some protocol designs based on random lofting of UDP packets that contain several announcements, each with a TTL, and relay points that expire items with TTL expiration, and add other announcements. And I've played with "designated noses" to act as collectors that can announce that they exist using the same methods.
The barrier I hit was that in chemistry I've got lots and lots of data bits - long chains can carry a lot of data - and that network packets are not even close to large enough to obtain the kinds of announcements which could be possible.
(This is similar to some ideas that I have to adopt CRISPR techniques for very-long pattern matching to facilitate things like crypto cracking and also video compression - yes, I am imagining a kind of chemical-bio-electronic computational system.)
No single resource discovery system will meet all needs. Rather I foresee that there will be a need for various methods depending on the application space. And I suspect that URL/URI structures (with DNS names) will be part of the inner (but often hidden from users) machinery of these methods.
--karl--
On 10/26/25 6:57 PM, bzs@theworld.com wrote:
Just to avoid the possibility of re-inventing the wheel how much of this idea is covered by systems like CORBA (1991, now mostly obsolete tho latest release was 2014), X.500, and LDAP (a simplified subset of X.500)? And Microsoft's Active Directory? Or logical extensions thereof (where is ____?)
https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture https://en.wikipedia.org/wiki/X.500 https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol https://en.wikipedia.org/wiki/Active_Directory
or the various "See Also" on those wikipedia pages (Apple Open Directory, etc etc etc)? And I guess URIs/URLs in general?
There's a rich history of people throwing themselves against this idea of locating objects in a network, particularly at a generic level (where is a printer I can use which does two-sided color printing and is at least 20ppm? Or a game server for <GAME> or whatever.)
Also, the CDNs like Akamai dabble in this more than a little.
Geoff Houston had a great article in a recent "Internet Protocol Journal" (May 2025, V28.1), "The IPv6 Transition", which goes way beyond what the title might imply and talks about how between NAT, CGNAT, CDNs, DNS, and DDNS "this ain't yer grandparents internet anymore"...you'd have to read the article, it's only several pages long but I had several "oh yeah he's right" moments reading it.
On October 25, 2025 at 14:27 karl@cavebear.com (Karl Auerbach) wrote:
In our internet naming system "host names" are synonyms for IP addresses which are labels on network interfaces on host machines.
In our evolving internet of applications - typically floating in a conceptual "cloud" - the binding between a specific instance of an application service and a host/network interface is something that is rather dynamic and changeable, even during the existence of a client-to-service session.
DNS is sort of becoming like MAC addresses - it is becoming less and less visible to users who are getting more used to dealing with other sorts of naming systems, often application specific naming systems.
DNS can well be (and usually ought to be) underneath. But DNS isn't designed for the kind of dynamics that can occur with the increased rates of user-to-service binding (and changes to those bindings) that are becoming more typical.
Much of the magic of DNS comes from caching. And caching is troublesome in a world where client and service relationships are potentially changeable, even within a few seconds.
I am not sure that any single higher-than-DNS name (or attribute) lookup system will be right for all applications, so we may end up with several of these higher level systems. This would largely be as visible to users as are the lookups inside AWS, Facebook, or other systems that are evolving their own notion of "names".
In the old ISO/OSI world they had a concept of "application titles" which are distinct from network addresses. But even that is perhaps too static for they way our internet is becoming more a world of pieces of code that may run in many places - or may be started or moved as loads and connectivity and location change.
--karl--
On 10/25/25 1:14 PM, bzs@theworld.com wrote:
On October 24, 2025 at 15:54 at-large@icann.org (Karl Auerbach via At-Large) wrote:
Oh, by-the-way, I don't mean, in the text below, that DNS is no longer usable. Rather than we need an additional naming system (perhaps based on attributes) that can lead to stable DNS names (thus obviating a need for the kind of short-lived DNS name-mapping juggling that goes on now.)
As has been oft said in computer science - and networking - one can solve many problems by adding an additional layer of indirection.
--karl--
Isn't that what host names are?
-- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
Dear All, Dear Olivier, I have already shared it with my SSAC colleagues. Please feel free to ask any questions in the meeting regarding it. This also applies to other security and stability questions ;)! Have a nice one! Best, Matthias Am 2025-10-24 21:01, schrieb Olivier MJ Crépin-Leblond via At-Large:
AWS has published its summary of the Summary of the Amazon DynamoDB Service Disruption in Northern Virginia (US-EAST-1) Region which made the headlines on 20 October 2025:
https://www.bbc.co.uk/news/articles/cev1en9077ro "...why did it make the internet fall apart"
Perhaps the most surprising part of the reporting is how much noise was made about it, at least in the UK, sometimes equating to impending hyped doom reports of the "death of the net predicted" and mixing into a it a good measure of "it's always a DNS problem...". I'll spare you the links to the articles, just search for them on a search engine.
What's more interesting is the actual AWS summary which they have published: https://aws.amazon.com/message/101925/
Having been around for long enough to have seen the 'net grow over the years, the first thing that struck me is the complexity of these cloud networks that now form most of the Internet. No longer is this just a simple server -> client scenario with a handful of routers and TCP/IP. The way by which the Heart of today's world works, aka the "back end" to all of our Apps and Web sites is way more complicated than I ever imagined.
Yes, one of my companies is an AWS customer so I wasn't a total novice into the AWS instances, NLB, EC2 and Route 53. But the process by which this all works (supposedly like clockwork and sometimes not) surpassed my imagination.
And this is where I discovered the "seamless scale" whereas you can keep track of the whole ecosystem of virtual machine instances and load balancers using a constantly updated dynamic DNS. I frankly do not know how to give it a name, but the times of manually inputting listings into a file at /var/named/data/example.hosts is long gone!
So here's my question: is the DNS fit for purpose for the use AWS is making of it?
I wonder whether we could ask if anyone on the SSAC could explain this to us in a few minutes during the ALAC meeting with the SSAC on Sunday?
Kindest regards,
Olivier _______________________________________________ At-Large mailing list -- at-large@icann.org To unsubscribe send an email to at-large-leave@icann.org
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.
participants (5)
-
bzs＠theworld.com -
Christian de Larrinaga -
Karl Auerbach -
Matthias M. Hudobnik -
Olivier MJ Crépin-Leblond