DNS is an application layer on top of the Internet layer that lets you have host names (i.e. “www.google.com”) towards the user side instead of IP addresses (i.e. 127.0.0.1).
However the internet layer only understands IP addresses so any application that is using hostnames internally and for displaying to the user has to translate them into IP addresses (using DNS) as it has to use those for the internet layer to know which hosts it wants to talk to.
URLs are yet something else: they’re a text format for encoding protocol, host if applicable (in name or in IP address), IP port if applicable and protocol specific stuff (i.e. the page address on a website) to form an application level “address”, which is more than just the host address (as that’s only a machine on the network, not a service hanging from an IP port on that machine waiting for requests).
People are so used to web URLs that they often don’t know URLs can encode more than just pages in what they think as “normal” web addresses (such as http://www.google.com/ and https://www.google.com/) and can actually support the same protocol in a different port (http://www.google.com:8080/ - note that this one probably doesn’t work because google just uses the default port for HTTP which is 80 and doesn’t have an HTTP server running in 8080), host identification by IP address instead of hostname (i.e. http://127.0.0.1) and even different protocols (i.e. ftp://127.0.0.1).
It’s the Internet Protocol packets that hold the TCP segments and UDP packets.
Yep now I remember. You’re right, it’s the IP addresses. DNS just maps those addresses to URLs
DNS is an application layer on top of the Internet layer that lets you have host names (i.e. “www.google.com”) towards the user side instead of IP addresses (i.e. 127.0.0.1).
However the internet layer only understands IP addresses so any application that is using hostnames internally and for displaying to the user has to translate them into IP addresses (using DNS) as it has to use those for the internet layer to know which hosts it wants to talk to.
URLs are yet something else: they’re a text format for encoding protocol, host if applicable (in name or in IP address), IP port if applicable and protocol specific stuff (i.e. the page address on a website) to form an application level “address”, which is more than just the host address (as that’s only a machine on the network, not a service hanging from an IP port on that machine waiting for requests).
People are so used to web URLs that they often don’t know URLs can encode more than just pages in what they think as “normal” web addresses (such as http://www.google.com/ and https://www.google.com/) and can actually support the same protocol in a different port (http://www.google.com:8080/ - note that this one probably doesn’t work because google just uses the default port for HTTP which is 80 and doesn’t have an HTTP server running in 8080), host identification by IP address instead of hostname (i.e. http://127.0.0.1) and even different protocols (i.e. ftp://127.0.0.1).