Hi, Is there anyway to intentionally and immediately get on Google's DNS blacklist in order to avoid similar outages in the future affecting only IPv6 traffic? http://www.google.com/intl/en_ALL/ipv6/statistics/data/no_aaaa.txt
Or maybe the smart thing to do is building another ISP controllable blacklist of broken domains and tell BIND on the caches to return only A records for blacklisted domains. Or the other way around: only AAAA records for IPv4 broken/blacklisted domains... Regards, Manu On Tue, Nov 11, 2014 at 3:18 AM, Lorenzo Colitti <[email protected]> wrote: > On Sun, Nov 9, 2014 at 8:10 PM, Jeroen Massar <[email protected]> wrote: >> >> > Another fun question is why folks are relying on PMTUD instead of >> > adjusting their MTU settings (e.g., via RAs). >> >> Because why would anybody want to penalize their INTERNAL network? > > > Lowering the MTU from 1500 to 1280 is only a 1% penalty in throughput. I'd > argue that that 1% is way less important than the latency penalty. > >> Because you can't know if that is always the case. > > > I'm not saying that PMTUD shouldn't work. I'm saying that if you know that > your Internet connection has an MTU of 1280, setting an MTU of 1500 on your > host is a bad idea, because you know for sure that you will experience a > 1-RTT delay every time you talk to a new destination. > >> As you work at Google, ever heard of this QUIC protocol that does not >> >> use TCP? >> >> Maybe you want to ask your colleagues about that :) > > > Does QUIC work from behind your tunnel? If so, maybe my colleagues have > already solved that problem. > >> >> > (Some parts of) Google infrastructure do not do >> > PMTUD for the latency reasons above and for reasons similar to those >> > listed >> > in https://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem-00 >> > . >> >> As such, you are ON PURPOSE breaking PMTUD, instead trying to fix it >> with some other bandaid. > > > The draft explains some of the reasons why infrastructure is often built > this way.
