PDA

Bekijk Volledige Versie : ipv6 leaseweb



unchained
30/06/11, 17:17
Ik heb voor de server die ik nog bij leaseweb heb staan native ipv6 aangevraagd.

Nu merk ik echter na het instellen dat het gewone surfen een stuk trager lijkt te zijn,
wat niet het geval was toen ik de hurricane tunnel gebruikte.

Iemand diezelfde ervaring, of tips om dit misschien op te lossen?
(kan altijd dat ik wat over het hoofd zie?)

WebMeso
30/06/11, 17:34
Misschien heb je hier wat aan. (http://www.webhostingtalk.nl/ipv6/169060-drie-ipv6-ongemakken-voor-de-hostingklant.html#post1203673)

Yourwebhoster
30/06/11, 17:38
Ik heb voor de server die ik nog bij leaseweb heb staan native ipv6 aangevraagd.

Nu merk ik echter na het instellen dat het gewone surfen een stuk trager lijkt te zijn,
wat niet het geval was toen ik de hurricane tunnel gebruikte.

Iemand diezelfde ervaring, of tips om dit misschien op te lossen?
(kan altijd dat ik wat over het hoofd zie?)

vergelijken met een tracert of als het even kan een mtr. IPv6 heeft niet altijd de meest logische routes helaas zoals IPv4 deze wel kan hebben.

unchained
30/06/11, 17:50
@webmeso: daar had ik ook al eens gekeken, maar echt nuttig artikeltje is dat niet he :)

het punt was, en is, dat ik aan mijn kant (thuis, ipv4) niets aangepast heb, en enkel op de server de tunnel heb verwijderd en het native ipv6 heb ingesteld.
daarna werd de verbinding over ipv4 trager - terwijl dit voorheen, met de tunnel, niet zo was.

wat ik me dan afvraag is waarom het (opmerkbare) verschil.

@yourwebhoster : ipv6 van de server uit naar bv google geeft een goede trace en mtr staat me ook aan.
het is dan ook niet zozeer dat ipv6 slecht reageert (de moeite om dat te testen heb ik zelfs nog niet gedaan met de native ips)

het probleem dat ik nu heb is dus dat ipv4 verbindingen sneller blijken als je een ipv6 tunnel gebruikt, dan dat je native gebruikt.
iets wat volgens mij eigenlijk niet zou mogen (ik zou zeggen, kunnen, maar alles kan tegenwoordig)?

edit: overzichtje van hoe merkbaar de vertraging is
geen vertraging: redirect naar een andere html
lichte vertraging: static site
merkbare vertraging: ajax site
enorme vertraging: webmail (roundcube)

Yourwebhoster
30/06/11, 17:52
@yourwebhoster : ipv6 van de server uit naar bv google geeft een goede trace en mtr staat me ook aan.
het is dan ook niet zozeer dat ipv6 slecht reageert (de moeite om dat te testen heb ik zelfs nog niet gedaan met de native ips)

het probleem dat ik nu heb is dus dat ipv4 verbindingen sneller blijken als je een ipv6 tunnel gebruikt, dan dat je native gebruikt.
iets wat volgens mij eigenlijk niet zou mogen (ik zou zeggen, kunnen, maar alles kan tegenwoordig)?

Daar ben ik wel benieuwd naar, heb je dit gemeten dmv ping (IPv4)?

Geert-Jan
30/06/11, 18:00
ondanks dat we er van uit gaan dat de instellingen goed zijn,
- Wat waren je tunnel IPv6 instellingen?
- Wat zijn je nieuwe (native) IPv6 instellingen?

unchained
30/06/11, 18:03
Daar ben ik wel benieuwd naar, heb je dit gemeten dmv ping (IPv4)?

de ping voorheen (gemiddeld tussen de 25 en 28) en nu (gemiddeld tussen de 26 en 28) scheelt eigenlijk niets.
ook tracert over ipv4 toont geen opmerkelijke verschillen.

maar je merkt het enorm aan, vooral, de webmail, die voorheen ongeveer 1 seconde nodig had om een mail te openen,
tegenover nu zo'n minuut.

unchained
30/06/11, 18:14
Ik denk dat het een vals alarm is ivm ipv6:
ik merk net in de traceroute dat 1 van de hops enorm schommelt naar mijn server toe,
terwijl diezelfde hop naar wht helemaal perfect blijft...

ondanks de geweldige timing zal het dus vast niet aan de ipv6 aanpassing liggen
(heb hem er voor de zekerheid net ook even volledig uitgegooid)




Bezig met het traceren van de route naar webmail.unchained.be [94.75.246.231] via maximaal 30 hops:
1 <1 ms <1 ms <1 ms 10.0.0.1
2 19 ms 19 ms 19 ms ip-83-134-88-1.dsl.scarlet.be [83.134.88.1]
3 237 ms 415 ms 302 ms 186.241-183-91.adsl-static.isp.belgacom.be [91.183.241.186]
4 22 ms 22 ms 22 ms 26.247-183-91.adsl-static.isp.belgacom.be [91.183.247.26]
5 29 ms 28 ms 28 ms leaseweb.bnix.net [194.53.172.101]
6 28 ms 28 ms 28 ms te9-2.sr7.evo.leaseweb.net [85.17.100.206]
7 28 ms 28 ms 28 ms aeterna.unchained.be [94.75.246.231]
De trace is voltooid.


Bezig met het traceren van de route naar webhostingtalk.nl [213.136.19.171] via maximaal 30 hops:
1 <1 ms <1 ms <1 ms 10.0.0.1
2 20 ms 19 ms 19 ms ip-83-134-88-1.dsl.scarlet.be [83.134.88.1]
3 22 ms 22 ms 22 ms 186.241-183-91.adsl-static.isp.belgacom.be [91.183.241.186]
4 22 ms 22 ms 22 ms 26.247-183-91.adsl-static.isp.belgacom.be [91.183.247.26]
5 28 ms 28 ms 28 ms xe-0-3-0-5.r02.frnkge04.de.bb.gin.ntt.net [213.198.82.189]
6 28 ms 29 ms 28 ms ae-3.r21.frnkge04.de.bb.gin.ntt.net [129.250.3.93]
7 44 ms 35 ms 35 ms as-1.r23.amstnl02.nl.bb.gin.ntt.net [129.250.3.62]
8 35 ms 36 ms 41 ms po-2.r01.amstnl02.nl.bb.gin.ntt.net [129.250.4.101]
9 31 ms 31 ms 33 ms bit-0.r01.amstnl02.nl.bb.gin.ntt.net [81.20.69.254]
10 32 ms 32 ms 37 ms webhostingtalk1.colo.bit.nl [213.136.19.171]
De trace is voltooid.

Bezig met het traceren van de route naar webmail.unchained.be [94.75.246.231] via maximaal 30 hops:
1 <1 ms <1 ms <1 ms 10.0.0.1
2 19 ms 19 ms 19 ms ip-83-134-88-1.dsl.scarlet.be [83.134.88.1]
3 211 ms 199 ms 201 ms 186.241-183-91.adsl-static.isp.belgacom.be [91.183.241.186]
4 22 ms 22 ms 22 ms 26.247-183-91.adsl-static.isp.belgacom.be [91.183.247.26]
5 29 ms 28 ms 28 ms leaseweb.bnix.net [194.53.172.101]
6 28 ms 28 ms 28 ms te9-2.sr7.evo.leaseweb.net [85.17.100.206]
7 28 ms 28 ms 27 ms aeterna.unchained.be [94.75.246.231]
De trace is voltooid.

even afwachten zal dus de boodschap zijn

unchained
30/06/11, 21:02
hmm, toch niet de oorzaak...


eth0 Link encap:Ethernet HWaddr 00:30:48:88:87:10
inet addr:94.75.246.231 Bcast:94.75.246.255 Mask:255.255.255.192
inet6 addr: fe80::230:48ff:fe88:8710/64 Scope:Link
inet6 addr: 2001:1af8:4400:a018:2::1/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:25021 errors:0 dropped:0 overruns:0 frame:0
TX packets:14625 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6516638 (6.5 MB) TX bytes:4145558 (4.1 MB)
Interrupt:16




route -6
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
2001:1af8:4400:a018::/64 :: Ue 256 0 3 eth0
fe80::/64 :: U 256 0 0 eth0
::/0 2001:1af8:4400:a018::1 UG 1 1 505 eth0
::/0 :: U 1024 0 0 eth0
::/0 :: !n -1 1 809 lo
::1/128 :: Un 0 1 1272 lo
2001:1af8:4400:a018:2::1/128 :: Un 0 1 2 lo
fe80::230:48ff:fe88:8710/128 :: Un 0 1 371 lo
ff00::/8 :: U 256 0 0 eth0
::/0 :: !n -1 1 809 lo




ip -6 route
2001:1af8:4400:a018::/64 dev eth0 proto kernel metric 256 expires 2584778sec mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295
default via 2001:1af8:4400:a018::1 dev eth0 metric 1 mtu 1500 advmss 1440 hoplimit 4294967295
default dev eth0 metric 1024 mtu 1500 advmss 1440 hoplimit 4294967295





traceroute6 ipv6.google.com
traceroute to ipv6.google.com (2a00:1450:400c:c01::93), 30 hops max, 80 byte packets
1 2001:1af8:4400:a018::1 (2001:1af8:4400:a018::1) 0.652 ms 0.718 ms 0.790 ms
2 te0-0-0-5.crs.evo.leaseweb.net (2001:1af8::11) 1.633 ms 1.651 ms 1.636 ms
3 swissix.google.com (2001:7f8:24::4a) 28.889 ms 28.897 ms 28.905 ms
4 2001:4860::1:0:10 (2001:4860::1:0:10) 22.094 ms 22.082 ms 21.858 ms
5 2001:4860::1:0:8 (2001:4860::1:0:8) 43.243 ms 21.554 ms 43.229 ms
6 2001:4860::8:0:2daf (2001:4860::8:0:2daf) 21.549 ms 21.235 ms 21.190 ms
7 2001:4860::8:0:2ac4 (2001:4860::8:0:2ac4) 32.011 ms 31.996 ms 31.980 ms
8 2001:4860::2:0:87b (2001:4860::2:0:87b) 29.662 ms 29.638 ms 29.559 ms
9 2001:4860:0:1::22f (2001:4860:0:1::22f) 32.429 ms 32.324 ms 32.338 ms
10 bru01m01-in-x93.1e100.net (2a00:1450:400c:c01::93) 28.508 ms 35.008 ms 28.611 ms


v6 op de server lijkt gewoon te werken, op thuiscomputer v6 disabled, en toch blijf ik merken dat als ik het op de server inschakel,
mijn verbinding sterk vertraagt...

iemand nog tips?

visser
30/06/11, 22:27
hmm, toch niet de oorzaak...


eth0 Link encap:Ethernet HWaddr 00:30:48:88:87:10
inet addr:94.75.246.231 Bcast:94.75.246.255 Mask:255.255.255.192
inet6 addr: fe80::230:48ff:fe88:8710/64 Scope:Link
inet6 addr: 2001:1af8:4400:a018:2::1/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:25021 errors:0 dropped:0 overruns:0 frame:0
TX packets:14625 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6516638 (6.5 MB) TX bytes:4145558 (4.1 MB)
Interrupt:16




route -6
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
2001:1af8:4400:a018::/64 :: Ue 256 0 3 eth0
fe80::/64 :: U 256 0 0 eth0
::/0 2001:1af8:4400:a018::1 UG 1 1 505 eth0
::/0 :: U 1024 0 0 eth0
::/0 :: !n -1 1 809 lo
::1/128 :: Un 0 1 1272 lo
2001:1af8:4400:a018:2::1/128 :: Un 0 1 2 lo
fe80::230:48ff:fe88:8710/128 :: Un 0 1 371 lo
ff00::/8 :: U 256 0 0 eth0
::/0 :: !n -1 1 809 lo




ip -6 route
2001:1af8:4400:a018::/64 dev eth0 proto kernel metric 256 expires 2584778sec mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295
default via 2001:1af8:4400:a018::1 dev eth0 metric 1 mtu 1500 advmss 1440 hoplimit 4294967295
default dev eth0 metric 1024 mtu 1500 advmss 1440 hoplimit 4294967295





traceroute6 ipv6.google.com
traceroute to ipv6.google.com (2a00:1450:400c:c01::93), 30 hops max, 80 byte packets
1 2001:1af8:4400:a018::1 (2001:1af8:4400:a018::1) 0.652 ms 0.718 ms 0.790 ms
2 te0-0-0-5.crs.evo.leaseweb.net (2001:1af8::11) 1.633 ms 1.651 ms 1.636 ms
3 swissix.google.com (2001:7f8:24::4a) 28.889 ms 28.897 ms 28.905 ms
4 2001:4860::1:0:10 (2001:4860::1:0:10) 22.094 ms 22.082 ms 21.858 ms
5 2001:4860::1:0:8 (2001:4860::1:0:8) 43.243 ms 21.554 ms 43.229 ms
6 2001:4860::8:0:2daf (2001:4860::8:0:2daf) 21.549 ms 21.235 ms 21.190 ms
7 2001:4860::8:0:2ac4 (2001:4860::8:0:2ac4) 32.011 ms 31.996 ms 31.980 ms
8 2001:4860::2:0:87b (2001:4860::2:0:87b) 29.662 ms 29.638 ms 29.559 ms
9 2001:4860:0:1::22f (2001:4860:0:1::22f) 32.429 ms 32.324 ms 32.338 ms
10 bru01m01-in-x93.1e100.net (2a00:1450:400c:c01::93) 28.508 ms 35.008 ms 28.611 ms


v6 op de server lijkt gewoon te werken, op thuiscomputer v6 disabled, en toch blijf ik merken dat als ik het op de server inschakel,
mijn verbinding sterk vertraagt...

iemand nog tips?

Ik snap nog niet wat je nu doet, en waar iets trager wordt.

Je zet IPv6 aan op een server ergens en je IPv4 *thuis* computer gaat daar traag van surfen ?
Maar wat heeft je thuiscomputer met die server te maken, afgezien ervan dat ze beide van jou zijn ?

Of gebruik je (via remote desktop ofzo?) die server ook om vanaf te surfen ?
Of is het benaderen van jouw server vanaf jouw (ipv4) thuiscomputer trager nadat je IPv6 aanzet op die server ?

Eén pure gok die ik kan doen is kijken naar DNS; Als je server DNS resolving anders doet op moment dat IPv6 aanstaat kan dat een hoop scenario's verklaren, vooral indien je thuiscomputer ook je server als DNS resolver gebruikt.
Zie je iets nuttigs met tcpdump/wireshark ?

unchained
30/06/11, 22:42
Ik snap nog niet wat je nu doet, en waar iets trager wordt.

Je zet IPv6 aan op een server ergens en je IPv4 *thuis* computer gaat daar traag van surfen ?
Maar wat heeft je thuiscomputer met die server te maken, afgezien ervan dat ze beide van jou zijn ?

Of gebruik je (via remote desktop ofzo?) die server ook om vanaf te surfen ?
Of is het benaderen van jouw server vanaf jouw (ipv4) thuiscomputer trager nadat je IPv6 aanzet op die server ?

Eén pure gok die ik kan doen is kijken naar DNS; Als je server DNS resolving anders doet op moment dat IPv6 aanstaat kan dat een hoop scenario's verklaren, vooral indien je thuiscomputer ook je server als DNS resolver gebruikt.
Zie je iets nuttigs met tcpdump/wireshark ?

het van thuis uit (ipv4) verbinden met mijn server gaat trager van zodra native ipv6 op de server ingesteld wordt.
bij de tunnel die ik voorheen had opgezet om dit allemaal te testen, was er geen verschil te merken.
zet ik op de server ipv6 weer uit, is de verbinding terug vlot.

dat mijn pc thuis fout geconfigureerd is zal het niet zijn: voorheen werkte hij vlot (toen de server een tunnel gebruikte)
en ik heb hier zelfs ipv6 ondertussen uit windows gegooid...

ik gebruik van hieruit enkel de dns van mijn isp, en het enige waar er vertraging op te merken valt is apache.
ftp, mail, ssh blijven allemaal vlot werken.

visser
30/06/11, 23:12
het van thuis uit (ipv4) verbinden met mijn server gaat trager van zodra native ipv6 op de server ingesteld wordt.
bij de tunnel die ik voorheen had opgezet om dit allemaal te testen, was er geen verschil te merken.
zet ik op de server ipv6 weer uit, is de verbinding terug vlot.

dat mijn pc thuis fout geconfigureerd is zal het niet zijn: voorheen werkte hij vlot (toen de server een tunnel gebruikte)
en ik heb hier zelfs ipv6 ondertussen uit windows gegooid...

ik gebruik van hieruit enkel de dns van mijn isp, en het enige waar er vertraging op te merken valt is apache.
ftp, mail, ssh blijven allemaal vlot werken.

Dan denk ik nog steeds aan DNS; Heel veel server daemons doen een reverse DNS lookup voor een binnenkomende connectie.
Als die reverse lookup voor jouw connectie trager gaat bij (native) IPv6 kan dat het verschil zijn; Waarom dat eventueel zo is kun je later uitzoeken, nu zou ik eerst controleren _of_ dit de oorzaak is.
Ik zou inloggen (met ssh) op je server, en dan met tcpdump meekijken terwijl je een http connectie doet , naar alle verkeer behalve ssh;
Hoeft niet lang te duren, maar je wilt even capturen wat je server probeert te doen (en waarschijnlijk timeout) over het netwerk op moment dat je http connectie aankomt.

Mikey
01/07/11, 00:00
En ik ga ook voor de dns, zijn je services compiled met ipv6 support, heeft je server een ipv6 dns server tot zijn beschikking. Mocht dit niet het geval zijn dan zou een kleine hickup van timeouts een logische verklaring kunnen zijn (maar; niet alle services zullen daar last van hebben).

unchained
01/07/11, 00:34
@visser: in tcpdump zie ik niet onmiddelijk iets dat de oorzaak zou zijn, ook geen enkele timeout ofzo.
@mikey: services zijn compiled met ipv6 en er is een dns server beschikbaar.

maar wel credit where it's due: visser en mikey, jullie hebben met het dns gedeelte wel de snelheid terug kunnen verbeteren.
het is nog steeds trager dan zonder ipv6, maar het is al terug doenbaar.

de ipv6 dns server stond onderaan in mijn resolv.conf ipv bovenaan.
kleine aanpassing, groot verschil :)
voor vandaag hou ik het bekeken, maar morgen ofzo nog wel even verderkijken waarom het nog steeds trager is,
en of het nog wat sneller kan.

visser
01/07/11, 00:55
@visser: in tcpdump zie ik niet onmiddelijk iets dat de oorzaak zou zijn, ook geen enkele timeout ofzo.
@mikey: services zijn compiled met ipv6 en er is een dns server beschikbaar.

maar wel credit where it's due: visser en mikey, jullie hebben met het dns gedeelte wel de snelheid terug kunnen verbeteren.
het is nog steeds trager dan zonder ipv6, maar het is al terug doenbaar.

de ipv6 dns server stond onderaan in mijn resolv.conf ipv bovenaan.
kleine aanpassing, groot verschil :)
voor vandaag hou ik het bekeken, maar morgen ofzo nog wel even verderkijken waarom het nog steeds trager is,
en of het nog wat sneller kan.

Ik verwachtte een onbereikbare DNS server (en dus een query zonder antwoord, evt query over V6, geen antwoord, dan query over V4).
Je kunt nog even een tcpdump capture maken met IPv6 enabled en dan zonder IPv6.
DNS in relatie tot het probleem staat nu al aardig vast, dan is alleen de vraag of het puur een trager antwoord is, of dat indien IPv6 enabled is er misschien meer of andere queries gedaan worden.
Met wireshark (je kunt tcpdump een file laten schrijven, en die kopieren naar een desktop om met wireshark te openen) kun je overigens makkelijker tijdsverloop zien dan met tcpdump.

Je kunt je ook afvragen of je je server uberhaupt voor elke connectie dan blijkbaar een DNS lookup wilt laten doen; Zoals je gezien hebt geeft dat vertraging als DNS niet snel werkt.
Nog steeds wil je natuurlijk wel het probleem oplossen waarom de DNS lookups in de situatie met IPv6 enabled trager waren; Want als er een andere (v4?) DNS boven stond, werd die dan eerst geprobeerd en werkte die niet ?

Anyway, nog wat uit te zoeken maar ik denk dat nu de richting duidelijk is dat wel te vinden moet zijn.

hrodenburg
01/07/11, 09:36
Je kunt ook even met "dig" je dns resolvers testen.
Als je ipv6 uitschakeld, en alles gaat goed op je server, kun je er ook voor kiezen om alleen de resolver met het ipv4 adres te gebruiken. Deze kan (zeer waarschijnlijk) nog steeds ipv6 adressen resolven. Wanneer je ipv6 op je server inschakeld, wordt dus mogelijk de ipv6 resolver gebruikt, die blijkbaar niet zo snel is ofzo.

Zoals gezegd kun je bijv. met "dig" je resolvers query'en en kun je ook zien hoe snel het gaat.
Doe bijvoorbeeld:

dig a webhostingtalk.nl @1.1.1.1 -> wel even je resolver ip adres hier invullen natuurlijk
en
dig a webhostingtalk.nl @2001:..... -> ipv6 resolver adres

unchained
01/07/11, 11:54
Als je ipv6 uitschakeld, en alles gaat goed op je server, kun je er ook voor kiezen om alleen de resolver met het ipv4 adres te gebruiken. Deze kan (zeer waarschijnlijk) nog steeds ipv6 adressen resolven.

dit lost het inderdaad op: zorgen dat er enkel ipv4 adressen in resolv.conf staan zorgt ervoor dat alles weer draait zoals voorheen.
ik heb nu ook nog een paar andere ipv6 dns servers gaan gebruiken, en die doen het blijkbaar ook een stuk beter.

zijn blijkbaar nog wat v6 dns servers die het niet zo vlot doen (dus wél resolven, maar gewoon een stuk trager dan bv die van sixxs die ik nu ingesteld heb)

visser
01/07/11, 13:05
dit lost het inderdaad op: zorgen dat er enkel ipv4 adressen in resolv.conf staan zorgt ervoor dat alles weer draait zoals voorheen.
ik heb nu ook nog een paar andere ipv6 dns servers gaan gebruiken, en die doen het blijkbaar ook een stuk beter.

zijn blijkbaar nog wat v6 dns servers die het niet zo vlot doen (dus wél resolven, maar gewoon een stuk trager dan bv die van sixxs die ik nu ingesteld heb)

Ik denk dat je uberhaupt DNS lookups niet moet doen als ze niet nodig zijn, en vooral niet als ze ook nog eens je server traag kan maken indien ze niet goed werken.
Dat is iets om naar te kijken in de instellingen van je webserver.

Verder zijn "open" DNS resolvers (resolving voor iedereen, niet alleen de 'eigen' klanten) iets wat minder gebruikelijk aan het worden is. (vanwege abuse/security issues).
'Zomaar' een DNS server kan 'zomaar' stoppen publieke resolver te zijn; sixxs heeft helemaal geen plicht om aan leaseweb IP6 adressen DNS resolving te blijven leveren.

Wat dat betreft kun je beter DNSen van je provider gebruiken (die wel de plicht heeft om ze voor klanten werkend te houden), of op je server zelf een recursive DNS te draaien.

pcman
11/07/11, 02:30
Ik weet niet welke diensten je hebt bij leaseweb.
Laatst ook bij iemand gehad die een dedicated server had bij leaseweb.
Moest ik aan de support vragen of ze de rDNS wilde instellen voor dat ipv6 adres.
Hoe dat verder bij colocatie zit durf ik zo niet te zeggen.
Tevens moest ik in mijn resolve.conf ook hun ipv6 resolvers toevoegen deze stonden er standaard niet in.
Misschien dat dit nog helpt voor je.

Met vriendelijke groet,

Michaël Jonkers

Japje
18/07/11, 11:24
Je kan er eventueel ook voor kiezen op de machine zelf een resolver te draaien. Op die manier ben je niet afhankelijk van DNS servers van je ISP/coloboer etc.