Het verschil tussen dig en ping ontgaat me, ik dacht dat het gelijke resultaten zou moeten opleveren.
Maar dat doet er ook niet zoveel toe denk ik.
Op de links die ik gaf kan je zien dat er op het moment dat ik dit schrijf 15 probes actief zijn op het Freedom netwerk, en alle 15 kunnen ze de DNS servers in kwestie niet bereiken.
De probe die ik hier heb draait op een nanopi-neo-plus2, ik zou denken dat daar iets Linuxerigs op draait en dus dattie dig doet.
Maar RIPE heeft het over pingā¦
Anyway, of het nou pingt of digt, het lijkt me niet goed dat de probes die servers niet kunnen bereiken.
[edit]
O wachtā¦
RIPE zegt UDP Unreachable: 15, TCP Unreachable: 0
Kan je diggen met UDP?
(ik weet niks van Linux, behalve dat ik er vlekken van in mijn nek krijg )
Ik sluit me aan bij @anon49073608 over je analyse, top!
Het is vast wel verstandig als die partijen weten dat het ergens niet helemaal goed gaat, maar of wij dat moeten doen?
Ik beheers het jargon niet eens dat bij deze discipline hoort
Veel van de root servers zijn geen enkelvoudige systemen, maar hebben replicaās die via anycast beschikbar zijn.
Dus niet iedereen hoeft hetzelfde beeld van het internet te hebben. Vanuit een ISP waarschijnlijk wel, maar golbaal gezien niet.
Zoals Noci ook al vermeldde, worden de root-servers niet in 1 locatie gehost, maar d.m.v. anycast zijn ze over de hele wereld verdeeld.
Het lijkt me goed om dit probleem bij Fusix aan te melden.
Je kan forceren dat dig IPv6 gebruikt door een -6 argument te gebruiken.
Ik zie vanuit mijn DSL verbinding hetzelfde probleem: twee root servers zijn niet bereikbaar.
Daarnaast heb ik het idee (maar geen harde gegevens) dat af en toe IPv6 connectiviteit minder is dan het zou moeten. Packet loss en servers die onbereikbaar zijn. Servers die via een andere Ipv6 verbinding gewoon bereikbaar blijken. IK zal de komende tijd eens wat metingen doen als ik tijd kan vinden.
Zowel A als J-root worden door Verisign beheert. Ik heb Verisign hier al meerdere keren over gemaild zonder ook maar een antwoord te krijgen. En zoals al eerder is opgemerkt wordt gebruik gemaakt van anycast. Wat het ook een best een naar geval maakt om op te lossen.
Kortom dit is een bekend probleem. Dat heel eerlijk gezegd ook niet een hoge prio heeft. Er zijn immers 11 andere root-DNS-servers over die prima over IPv6 te bereiken zijn.
Bovendien denk ik dat dit zichzelf gaat oplossen wanneer Freedom wat meer vet op de botten heeft en kan gaan peeren met wie weet Verisign.
Met mijn beperkte toegang ziet het er uit als een routeringsprobleem ergens op internet.
Ik zie vanuit mijn modem wel verkeer verstuurd worden naar A en J root-servers, maar nooit antwoord.
Vanuit het netwerk van mijn werkgever en van de partij waar ik een VPS heb kan ik ze wel bereiken, al zitten de subnets dan wel achter een ander AS (anycast netwerken)
Voor atlas bezitters in het Freedom netwerk lijkt het nadeel te zijn dat ze niet aan de benodigde 95% icmp replies komen voor de tags āIPv6 Stable ā¦dā
Stability
These tags indicate a level of stability and reliability beyond that signified by the āCapableā and āWorksā tags (see above). In order for a probe to qualify for a Stable tag, it must have at least a 95% success rate for at least 95% of the time for the ICMP ping measurements that it performs. This means that occasional outages or connectivity problems are allowed so long as they are short and infrequent. The effects of widely unreliable or unreachable targets are controlled for by considering the success rate relative to measurements by other RIPE Atlas probes to the same targets.
$ traceroute6 a.root-servers.net
traceroute to a.root-servers.net (2001:503:ba3e::2:30), 30 hops max, 80 byte packets
1 lo1.cmbr.nikhef-1.connected.by.freedom.nl (2a10:3780::226) 0.554 ms 0.605 ms 0.629 ms
2 2a10:3780::2:1 (2a10:3780::2:1) 3.349 ms 3.320 ms 3.337 ms
3 2a00:a7c0:20:1197:e::1 (2a00:a7c0:20:1197:e::1) 8.087 ms 8.113 ms 8.111 ms
4 br0.eqxam6.nl.fusixnetworks.net (2a00:a7c0:e20a::6) 0.703 ms 0.684 ms 0.655 ms
5 xe-0-0-17-0.a02.amstnl02.nl.bb.gin.ntt.net (2001:728:0:5000::106d) 1.281 ms 1.246 ms 1.216 ms
6 ae-5.r24.amstnl02.nl.bb.gin.ntt.net (2001:728:0:2000::65) 0.924 ms 4.113 ms 0.916 ms
7 ae-15.r20.londen12.uk.bb.gin.ntt.net (2001:728:0:2000::171) 6.388 ms 6.371 ms 6.352 ms
8 ae-0.a02.londen12.uk.bb.gin.ntt.net (2001:728:0:2000::26a) 5.914 ms 5.876 ms 5.901 ms
9 * * *
10 * * *
11 * * *
12 * * *
etc.
Sinds gistermiddag is het lijntje naar j.root-servers.net ook weer stuk: klik
Je zou haast gaan denken dat iemand upstream een oude backup heeft teruggezet
In een eerdere poging hielp het niet om NTT ipv Telia te gebruiken. Daarom verbaasde me dat het nu wel hielp.
Maar ja dit zijn zgn. anycast root-servers. Heel kort samengevat wil dat zeggen dat er meerdere servers hetzelfde IP-adres gebruiken. Deze servers staan op meerdere plekken in het internet. BGP maakt de keuze welke server de beste route geeft. Je hebt dus geen twee servers met elk een eigen IP-adres waar je even naar kunt kijken. Het gaat dus om tientallen servers met hetzelfde IP-adres en dat maakt het best lastig debuggen. Want als je door een BGP-beslissing ergens op een andere server terecht komt kan het ineens niet of wel weer werken.
Omdat A en J beide door Verisign worden beheerd, vermoed ik dat daar het probleem zit. Nu zit Freedom sinds kort aan de AMS-IX en Verisign zit daar ook. Ik heb ze een peering request gestuurd. De route over AMS-IX kan op zich wel helpen maar zo krijgen we mogelijk ook een ingang bij Verisign.
Dank je, goed om te weten dat het nog steeds aandacht heeft en dat er aan gewerkt wordt
Raar maar waar: j.root-servers.net doet het intussen weer, alleen a.root-servers.net is nog onbereikbaar.
)
