Hi,

Am 24.05.2020 um 23:50 schrieb Marco d'Itri:
> On May 24, Max Grobecker <max.grobec...@ml.grobecker.info> wrote:
> 
>> This is a growing problem and
> [citation needed]

There is no chance to get a reasonable amount IPv4 addresses anymore, if you 
are new on the market. [1]
In Germany, for example, this is not only true for new providers. Even some 
long-established providers are using
CGNAT on their residential connections to safe IPv4 addresses which then can be 
"sold" to business customers that demand public IPv4 space.

So, many providers are tending to use CGNAT. On those connections, you have no 
IPv4 address - there is only IPv6 available
and some sort of IPv6-to-IPv4 tunneling or translation mechanism. These are not 
very reliable, unfortunately.

A burst of DNS queries of a DNS resolver, which is behind this NAT, can then 
lead to the problem, that not all your
UDP queries are working properly. Queries made over IPv6 are working well 
usually, because these packets are simply routed
and don't need to pass some sort of fancy NAT or XLAT or AFTR [2] mechanisms.
Running your own DNS resolver (for whatever reason) behind a CGNAT tends to be 
unrealiable, depending on how much load and packet rate
the provider's NAT/XLAT/AFTR router has to handle.


[1] 
https://www.ripe.net/manage-ips-and-asns/ipv4/ipv4-run-out?pk_vid=b4e6c3add231af651590838678f7957f
[2] Address Family Translation Router



>> if Fastly is not able to fix it, you 
>> maybe should stop making "deb.debian.org" the default mirror.
> Or maybe you should use a different mirror, if the current default does 
> not work for you. This is one of the reasons why we have many.

OK, I was a bit harsh in the first place.
But Debian as a customer should simply bring this topic to Fastly.
Yes, we or Debian can't fix the whole internet. But why don't we try?

Fastly prove they are able to do IPv6 (since they are delivering the mirror 
traffic over IPv6) and I guess, they have
sort of interest in delivering stable and _fast_ service. Not or not reliably 
resolving Fastly domains is the opposite of stable and fast ;-)

Reply via email to