Comment 13 for bug 615545

Excerpts from cloudcontrol's message of Thu Jan 12 23:27:07 UTC 2012:
> Hi Folks,
>
> To whoever manages DNS for this repository: a more elegant solution not
> requiring an package patches would have been to follow this practice for
> DNS on EC2.
>
> Try to use CNAMES to the fully-qualified domain name EC2 instead of A
> records. For example, at the moment you are using:
>
> us-west-1.ec2.archive.ubuntu.com. 600 IN A 10.162.150.127
>
> This address is apparently not routable from the outside world (perhaps
> to avoid bandwidth charges?)
>
> Had you used a routable EC2 Elastic IP, and a CNAME record pointing to
> the EC2 assigned FQDN, lookup requests by VPC servers would have the
> public elastic IP returned like this:
>
> ;; ANSWER SECTION:
> us-west-1.ec2.archive.ubuntu.com. 600 IN CNAME ec2-108-20-220-125.compute-1.amazonaws.com.
> ec2-108-20-220-125.compute-1.amazonaws.com. 300 IN A 108.20.220.125
>
> Lookup requests by VPC servers would have the public elastic IP
> returned, while instances launched normally in EC2 would receive the
> private address:
>
> ;; ANSWER SECTION:
> us-west-1.ec2.archive.ubuntu.com. 600 IN CNAME ec2-108-20-220-125.compute-1.amazonaws.com.
> ec2-108-20-220-125.compute-1.amazonaws.com. 300 IN A 10.252.111.96
>
> I've made these addresses up, of course, and I understand you have
> multiple servers for each hostname, but we use this method with
> weighted round robin DNS on EC2 as well and it works as in the example
> above.

Interesting, I didn't know that Amazon's servers worked this way, responding
with the internal IP.

I believe the EC2 mirrors are currently being migrated to S3:

http://cloud.ubuntu.com/2012/01/regional-s3-backed-ec2-mirrors-available-for-testing/

I am not sure how this will affect VPC instances.