Hallo @UHDFreak , heb je daar als consument last van of zo, want ik zie het probleem niet, als mijn internet maar gewoon goed werkt met de afgesproken snelheid.

@UHDFreak, welk verkeer bedoel je dan? Kun je daar eens een traceroute van laten zien?

Of ik er last van heb of niet, maakt verder niet uit. Ik vraag me gewoon af waarom KPN het nodig vind om alle DNS verzoeken naar Duitsland te sturen i.p.v. Nederland, het land waar ik woon. Bij navraag bij Quad9 is mij verteld dat KPN dit doet.

Ik heb hier een voorbeeld. Maar ook als ik een tracert doe naar de DNS van Quad9 kom ik ook in Duitsland uit.

Mogelijk omdat naar mijn weten KPN niet direct (of in elk geval mbt. voorkeur peering) op de AMS-IX zit en Frankfurt in dit geval (netwerk technisch) het dichtstbij is.

Hoi @UHDFreak . Ik heb oprecht geen idee. Soms zijn routeringen niet juist ingesteld en heb je er last van. In dit geval lijkt me dat niet aan de orde en staat het KPN vrij om hierin bepaalde keuzes te maken. Of geld hierbij een rol speelt weet ik niet. 

Het viel mij halverwege maart ook al op dat de ping van zowel Cloudfare als Quad9 omhoog schoot. Ik heb het sindsdien verder in de gaten gehouden. Niet alleen thuis, maar ook op werk is de endpoint van Quad9 en sommige Cloudfare DNS-servers in Frankfurt. Wat @UHDFreak ook zegt, en je kunt zien in de tijd die een ping in beslag neemt in de afbeelding heironder, is dat AdGuard DNS zelfs via Frankfurt naar Zweden gaat. Level3 gaat overigens ook naar Frankfurt Geel gearceerd is wat eerst naar Amsterdam gerouteerd werd en nu naar Frankfurt gaat:

Tijdens de traceroute (vanuit de router direct op de NT) wijzigt de endpoint ook, ene keer naar Amsterdam de andere keer naar Frankfurt:

Level3 traceroute: 

traceroute to 4.2.2.1 (4.2.2.1), 30 hops max, 60 byte packets
 1  static.kpn.net (195.190.228.1)  1.896 ms  1.851 ms  1.990 ms
 2  * * *
 3  * * *
 4  ae-11.edge7.Amsterdam1.Level3.net (4.68.37.173)  4.681 ms  4.688 ms  4.640 ms
 5  nl-srk03a-ri1-ae-2-0.aorta.net (84.116.135.145)  4.413 ms nl-srk03a-ri1-ae-3-0.aorta.net (84.116.135.149)  4.361 ms ae2.3207.edge5.Frankfurt1.level3.net (4.69.163.22)  9.988 ms
 6  213.46.182.142 (213.46.182.142)  5.412 ms a.resolvers.level3.net (4.2.2.1)  10.579 ms  10.587 ms

AdGuard traceroute, gaat zelfs naar Stockholm via Frankfurt terwijl er in Amsterdam een AdGuard DNS staat:

traceroute to 94.140.14.14 (94.140.14.14), 30 hops max, 60 byte packets
 1  static.kpn.net (195.190.228.1)  1.945 ms  1.871 ms  1.853 ms
 2  * * *
 3  * * *
 4  nl-ams02a-rc2-lag-11-0.aorta.net (84.116.130.150)  10.011 ms  10.017 ms  10.011 ms
 5  de-fra02a-rc1-ae-14-0.aorta.net (84.116.130.149)  10.672 ms  9.973 ms  10.637 ms
 6  de-fra05a-ri1-ae-4-0.aorta.net (84.116.137.202)  10.623 ms  10.764 ms  10.748 ms
 7  se-sto01a-ra2-ge-0-1-0-5.aorta.net (213.46.176.38)  10.737 ms  10.719 ms  10.671 ms
 8  dns.adguard.com (94.140.14.14)  9.864 ms  9.858 ms  9.943 ms

Hier zie je onderling ook verschil tussen de Cloudfare servers:

Hieronder de screenshots van de ‘verhoging’ in ping naar Quad9:

Verhoging van Cloudfare: 

Wat betreft Quad9 zie je dat op 28 maart 2022 tussen 14:40 en 16:20 de ping van 3,7 ms naar 9,0 ms ging. Dat is het moment waarbij Quad9 naar Frankfurt gerouteerd wordt. Voor Cloudfare was dit moment op 22 maart 2022 tussen 01:40 en 03:20. De ping van bijvoorbeeld 1.1.1.1 lag ervoor op 5,7 ms en sindsdien op 10,7 ms. Opvallend is dat Smokeping aangeeft dat de IPv6-variant van 1.1.1.1 wel een lagere ping heeft, wat betekent dat deze naar Amsterdam gaat. Wellicht helpen deze momenten met het achterhalen waardoor het verkeer niet meer naar Amsterdam gaat, maar naar Frankfurt.

Overigens zijn ping en traceroute niet bruikbaar om DNS verkeer te analyseren. Daarvoor gebruik je “dnsping” en “dnstraceroute” (onder linux, of deze tools ook voor windows bestaan weet ik niet).

De reden hiervoor is dat ping en traceroute het ICMP protocol gebruiken en DNS over het algemeen UDP (poort 53) gebruikt. DNS providers kunnen dus op een internet exchange een DNS resolver neerzetten, waarnaar het UDP verkeer op poort 53 van het specifieke IP adres ge-offload wordt. ICMP verkeer naar datzelfde IP adres zal dan niet ge-ofload worden en verder worden gestuurd naar de “main” server van de DNS provider.

(disclaimer: of dit het geval is weet ik niet, dat hangt natuurlijk af van de betreffende DNS providers en internet exchanges waarover het verkeer wordt gestuurd)

ik heb persoonlijk de cloudflare CTO een bericht gestuurd waarmee  ik direct contact heb op twitter, hij heeft de problemen doorgezet naar het netwerk team van cloudflare,

bedankt voor de screens @Leroy98 

Cloudflare en Quad9 zijn gelukkig weer aangepast naar de NL servers.

zou zomaar kunnen ja

Cloudflare en Quad9 zijn gelukkig weer aangepast naar de NL servers.

zou zomaar kunnen ja

Bedankt voor de moeite die je genomen hebt.

Cloudflare en Quad9 zijn gelukkig weer aangepast naar de NL servers.

zou zomaar kunnen ja

Is dit een reactie van Quad9 of van Cloudflare?

Leuk detail voor de echte speed seekers. Op IPv6 lijkt de resolving sneller te zijn. Dit is een grafiek van een echt DNS verzoek en niet slechts ICMP/PING.