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 GeoffHuston, 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!