On 11/12/24 13:23, James Knott wrote:
On 11/12/24 15:21, Lew Wolfgang wrote:
Thus, the "routing" function is handled by DNS instead of routing tables
in individual routers.

The routing is done by the router, after it examines the specific field in the http header.  This means it has to go into the packet, into the http header, read the destination and then forward accordingly.  A DNS server cannot do that, as all it does is hand out an address for the given names.  It requires a lookup table on the router, to match a name with an address.

I don't think I was being clear enough.  With SNI the DNS system functions
sort of as a router in the Internet as it has developed.  Permit me to
include below part of the write up by Geoff Huston, Chief Scientist at
APNIC.

Regards,
Lew

It’s domain names that operate as service identifiers, and its domain names that underpin the
user tests of authenticity of the online service. It’s the DNS that increasingly is used to steer
users to the ‘best’ service delivery point for content or service. From this perspective
addresses, IPv4 or IPv6, are not the critical resource for a service and its users. The ‘currency’
of this form of CDN network is names.

So where are we in 2024? Today’s public Internet is largely a service delivery network using
CDNs to push content and service as close to the user as possible. The multiplexing of multiple
services onto underlying service platforms is an application-level function tied largely to TLS
and service selection using the SNI field of the TLS handshake. We use DNS for ‘closest match’
service platform selection, aiming for CDNs to connect directly to the access networks where
users are located. This results in a CDN’s routing table with an average path length designed
to converge to just 1! From this aspect the DNS has supplanted the role of routing! While we
don’t route ‘names’ on today’s Internet, it functions in a way that is largely equivalent to a
named data network. – In other words, no longer addresses but names.

There are a few additional implications of this architectural change for the Internet. TLS, like it
or not (and there is much to criticize about the robustness of TLS), is the sole underpinning of
authenticity in the Internet. DNSSEC has not gathered much momentum to date. DNSSEC is
too complex, too fragile and just too slow to use for most services and their users. Some value
its benefits highly enough that they are prepared to live with its shortcomings, but that’s not
the case for most name holders and most users, and no amount of passionate exhortations
about DNSSEC will change this! It supports the view that it’s not the mapping of a name to an
IP address that’s critical. What is critical is that the named service can demonstrate that it is
operated by the owner of the name. Secondly, the Routing PKI, the framework for securing
information being passed in the BGP routing protocol, is really not all that useful in a network
where there is no routing!

The implication of these observations is that the transition to IPv6 is progressing very slowly
not because this industry is chronically short-sighted. There is something else going on here.
IPv6 alone is not critical to a large set of end-user service delivery environments. We’ve been
able to take a 1980s address-based architecture and scale it more than a billion-fold by
altering the core reliance on distinguisher tokens from addresses to names. There was no real
lasting benefit in trying to leap across to just another 1980s address-based architecture –
meaning IPv6 – with only a few annoying stupid differences, apart from longer addresses!