Goed even een samenvatting:
Er zijn '13'
rootservers op deze aardbodem, elke van deze 'servers' wordt met een letter aangeduid.
De reden waarom er maar '13' servers zijn is omdat
UDP pakketjes maar 512 bytes aan info kunnen meenemen.
Rootservers verwijzen overigens alleen naar de servers die verdere lookup doen. Dus, in een niet gechachde situatie, gebeurt het volgende:
* Jij doet een request aan je nameserver voor
www.tweakers.net
* Je nameserver doet een request aan een root server waar hij
.net domeinen kan opzoeken.
* Je nameserver maakt contact met een .net nameserver.
* Je krijgt het IP adres van
www.tweakers.net
(enigzins versimpeld, zie ook
DNS)
Nu is het zo dat als de ene server niet reageert er een andere server gebruikt zal worden. Je hebt niets voor niets meestal een primaire en secundaire DNS server (of meer) ingesteld.
Een en ander wordt gecached, dus je nameserver zal niet elke keer een rootserver opzoeken etc.
Een rootserver zijn meer servers. Dit gebeurt door
anycast. Dat zorgt ervoor dat je een server krijgt die bij je in 'de buurt' staat. Hierdoor kan het effect van zo'n DoSS attack plaatselijk blijven.
Dit is niet om Icann te bashen maar het geeft wel weer aan hoe kwetsbaar de rootservers nog steeds zijn. Namelijk deze aanval was bijna net zo groot als die in 2002 de techniek is 4 jaar verder dus het is gewoon wachten op een grotere aanval.
De vraag is heb je er iets van gemerkt? Ik denk het niet. Daarnaast is er onder andere doormiddel van anycast een hoop aangedaan om de redundancy te verhogen.
Verder blijfs DNS natuurlijk een technologie bedacht in de jaren 80 (1983 om precies te zijn). Hoewel het enorm schaalbaar blijkt te zijn vind ik het niet gek dat je nu tegen bepaalde problemen aanloopt. In 1983 was niet te voorzien dat het internet zo groot zou worden, en DNS zo belangrijk.
omdat hier nogal wat onjuistheden in staan toch maar even een reactie.
UDP kan veel meer aan dan 512 bytes aan data. Sowieso heeft het length field al een waarde van 16 bits dit is dus al 8KB als max waarde. Ik laad regelmatig met TFTP (UDP) files van meer dan 20 MB op een router dus wat deze vergelijking er mee te maken heeft geen idee.
ok het komt dus doordat het hints file niet meer dan 512 bytes kan worden en dan niet meer betrouwbaar verstuurd kan worden. Lijkt me eerder een beperking van het DNS protocol dan van het UDP protocol
Als je naar
www.tweakers.net wil ga je eerst in je cache kijken of je hem kent. Ken je hem niet ga je naar je provider. Kent die hem ook niet dan gaat hij pas vragen aan de root servers wie er authorative is voor het .net TLD
De kans dat je provider het niet weet is erg klein omdat er nogal veel mensen gebruik maken van die DNS.
Je primaire en secondaire DNS hebben niks te maken met de rootservers. Dit zijn namelijk gewoon de DNS servers van je provider die uiteindelijk toch bij de root DNS servers uitkomen.
Uit je WIKI artikel ook
In practice, most of this information doesn't change very often and gets cached, and necessary DNS lookups to the root nameservers are relatively rare
Er word wel aan gewerkt geloof ik om de machine die de ROOT servers uit mogen vragen te beperken. Er is voor mij namelijk geen enkele reden om de ROOT servers te benaderen.
omdat hier nogal wat onjuistheden in staan toch maar even een reactie.
Ik laad regelmatig met TFTP (UDP) files van meer dan 20 MB op een router dus wat deze vergelijking er mee te maken heeft geen idee.
UDP pakketjes kunnen groter zijn dan 512 bytes, maar dan loop je tegen problemen aan. Zie bijvoorbeeld
hier:
When configuring the UDP packet size to be larger than 512 bytes, remember UDP packets must travel through devices other than UDP hosts, such as routers, and these devices may not support UDP packets larger than 512 bytes. It is recommended that you establish the maximum UDP packet length support for all devices, and the path's MTU, if possible, and configure your UDP hosts according to this maximum.
De maximale size van een UDP pakketje is overigens 64 kilobyte. Ik weet wel zeker dat jouw TFTP server meerdere pakketjes gebruikt voor een bestand van 20 Mb. Zie de
RFC 1350 en
2347, het is 512 bytes tot 8192 bytes per datagram.
www.tweakers.net" target="_blank">Als je naar
[url="http://www.tweakers.net"]www.tweakers.net</a> wil ga je eerst in je cache kijken of je hem kent.[/q]
Ik zei ook in
een niet gecachede situatie.
Je primaire en secondaire DNS hebben niks te maken met de rootservers.
Dat zeg ik ook niet, ik zeg als de ene server niet reageert wordt de adnere geprobeerd. Zoals je zelf ook een primaire en secundaire DNS server hebt.
Wat PolarBear zegt klopt wel degelijk hoor.
UDP is een onbetrouwbaar, connectieloos protocol, dat eigenlijk alleen vastlegt hoe een UDP pakket eruit moet zien. Het tweede "transportprotocol" TCP is wél een betrouwbaar protocol, met allerlei voorzieningen om het netwerk niet te overbelasten.
Waarom gebruikt DNS dan UDP? Omdat TCP een ongewenste overhead (3-way handshake, ACKs) heeft en omdat het UDP protocol redelijk betrouwbaar is voor erg kleine pakketjes (< 512 bytes).
Dat jij 20MB files m.b.v. TFTP op een router kunt plaatsen heeft hier werkelijk niets mee te maken. Ten eerste gebruikt het TFTP-protocol UDP op zo'n manier dat het quasi als een TCP-protocol wordt gebruikt - mét de bijbehorende overhead. Verder is het zo dat de effectieve grootte van zowel een UDP als een TCP pakket in de praktijk ook (vooral) zal afhangen de maximale framegrootte van de verschillende fysieke data links die worden gebruikt (zo kan een gemiddeld ethernet-frame maar 1518 bytes bevatten).
Het blijft moeilijk
UDP-packets zijn beperkt tot de maximale packet size van IP-packets (65535 bytes) minus de IP header lengte (20 bytes, uitgaande van een IP-packet zonder options). De maximale datasize van een UDP-packet komt uit op 65535 - 20 - 8 (UDP header) = 65507 bytes.
Dat er 13 rootservers zijn heeft te maken met dat vroeger het DNS-protocol bepaalde limieten (512 byte, geloof ik) stelde aan de maximale packet data size. DNS heeft tegenwoordig de mogelijkheid om grotere packets te gebruiken, maar die mogelijkheid moet wel door de client aangegeven worden. Het is dus niet een limiet die inherent is aan het gebruik van UDP: 't is alleen vervelend om grotere packets te sturen, vanwege fragmentation.
Ethernet framing heeft er ook niks mee te maken: de kracht van het TCP/IP-model is juist dat de hogere lagen zo min mogelijk zouden moeten weten van de lagere lagen. Een IP-packet van 65535 byte dat verstuurd wordt over een ethernet interface, zal dan ook netjes in stukjes gehakt (gefragmenteerd) worden om aan de andere kant weer in elkaar gezet te worden. Enige nadeel is dat dat uit elkaar halen en in elkaar zetten een performance bitch is.
Overigens is bovenstaande berekening (2 v/d 13, dus 15.38%, daarvan 90% enz) te kort door de bocht, aangezien er, zoals gezegd, een aantal andere servers zijn die anycast gebruiken, en mogelijk veel meer queries per seconde afhandelen dan de 2 servers waar het in de berekening over ging..
When configuring the UDP packet size to be larger than 512 bytes, remember UDP packets must travel through devices other than UDP hosts, such as routers, and these devices may not support UDP packets larger than 512 bytes. It is recommended that you establish the maximum UDP packet length support for all devices, and the path's MTU, if possible, and configure your UDP hosts according to this maximum.
een router zal het een rotzorg zijn hoe groot de UDP pakketten zijn. Een router routeert op basis van IP informatie. Welk protocol je hier in stopt maakt niks uit. Je moet wel zorgen dat je IP MTU goed staat natuurlijk
De maximale size van een UDP pakketje is overigens 64 kilobyte. Ik weet wel zeker dat jouw TFTP server meerdere pakketjes gebruikt voor een bestand van 20 Mb. Zie de RFC 1350 en 2347, het is 512 bytes tot 8192 bytes per datagram.
ja tuurlijk stuur ik veel meer pakketjes. Ik wil enkel aangeven dat het nergens de beperking van UDP is om grotere files dan van een 512 bytes te sturen.
In jouw voorbeeld sloeg je voor het gemak de DNS van je provider over. Die is zweer belangrijk omdat die een veel grotere cache heeft dan jij thuis. De kans dat die hem niet heeft staan is er klein
De ddos-aanval was nagenoeg zo sterk als die van 2002, maar omdat de machines sindsdien veel krachtiger zijn en omdat er na die aanval nieuwe veiligheidsmaatregelen zijn geïmplementeerd, gingen er geen servers plat, aldus Ben Petro van provider en tld-operator Neustar. Wel begaf een aantal servers het bijna, zo reageerden de G- en de L-machines tijdelijk niet op negentig procent van de aanvragen. Neustar spreekt in dit kader van een 'brownout' in plaats van een 'blackout'. Volgens Petro was de aanval gericht op dochterbedrijf UltraDNS, dat het .org-tld beheert. Ditmaal hadden internetters er weinig tot geen last van, of het moet Icann-cto John Crain zijn, die toegeeft dat hij er behoorlijk door uit de slaap werd gehouden. Dergelijke aanvallen gebeuren via botnets - met behulp van trojans gekaapte pc's die zich overal kunnen bevinden - en zijn derhalve lastig te traceren. Het meeste verkeer zou evenwel afkomstig zijn geweest uit Zuid-Korea.
11:53
10:17
Door 
![[show]](http://tweakimg.net/g/if/comments/button_down.gif "Reactie uitklappen")
