On 06/05/2021 15:34, David Wright wrote: > [cut] > I thought the page rather full of gobbledegook, talking about SRV > records and CDN instances. As for trying a different mirror, the only > occurrence of "mirror" is "This service provides mirrors for the > following Debian archive repositories". > > And the instance chosen, "cdn-fastly.deb.debian.org" is not actually > among these mysterious SRV records, "_http._tcp.deb.debian.org", > "prod.debian.map.fastly.net" and "dpvctowv9b08b.cloudfront.net" that > we're not even told how to obtain. SRV records are a DNS record type. That is, when you want to know what IPv4 address example.org maps to, you ask for an A record; when you want to know what IPv6 address it maps to, you ask for an AAAA record. DNS holds much more than just IP address records, though. You can ask it "What servers handle the mail for the domain example.org?" (MX records), "What is the geographical location of example.org?" (LOC records) and "What are the SSH host keys of example.org, so that I don't have to hassle users about trusting fingerprints?" (SSHFP records). SRV records answer the question "Where is the ... service for .... located?" They are a more sophisticated response than a CNAME because they contain quite a bit of information. Firstly, SRV records should follow a defined format. "Everyone knows" that to get to the web server on example.org, you open port 80 at www.example.org, don't they? But what if you don't want to host it there? With an SRV record at _http._tcp.example.org (HTTP is always served over TCP, but the format is always _service._protocol.name), you can point it elsewhere. The content of an SRV record consists of a string with four space-separated fields: Priority, Weight. Port and Target. Priority and Weight are used together, and any client which handles SRV records is supposed to read them all to provide weighted load-balancing. Port and Target are the most interesting parts here, though. With these, you can tell a suitable client that the "HTTP" service for "example.org" is actually on port 8080 of "dev.example.org" and, the client will connect there instead of port 80. Now, SRV records aren't magic. Many protocols either predate the idea of SRV records, or just don't use it. Some protocols mandate its use. In the case of HTTP, though, it would appear that the choice to use SRV records is a client choice. If the User Agent performs an SRV lookup (like _newer_ apt/apt-get versions do), then they can be redirected. Otherwise, they will make the assumption to use the well-known addresses. For more information, please re-read https://en.wikipedia.org/wiki/SRV_record
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature