Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 50 reacties
Bron: CircleID, submitter: KoeKk

De heren van CircleID hebben een interview met Duane Wessels online gezet, waarin het onderzoek van de Cooperative Association for Internet Data Analysis naar het gebruik van de dertien DNS-rootservers besproken wordt. De conclusie van dit onderzoek was dat 98 procent van de aanvragen bij DNS-rootservers onnodig is. Wessels doet al sinds 1994 onderzoeken met betrekking tot het internet en is sinds 2000 directeur van het onderzoeksbureau The Measurement Factory. De opdracht voor het onderzoek kwam van een onderdeel van de ICANN: het Root Server System Advisory Committee.

Het onderzoek is gebaseerd op de 152 miljoen aanvragen die op vier oktober door de F rootserver in Palo Alto, Californië, zijn verwerkt. Daaruit volgde dat 98 procent van de aanvragen onnodig is, de meeste aanvragen worden herhaald met als tussenpozen de in de DNS-standaard gespecificeerde tijden, dus waarschijnlijk ontvangt de aanvrager het antwoord niet. Een ander deel van de aanvragen bestaat uit niet bestaande top-level-domeinnamen, zoals '.corp' en '.localhost'. Gewone internetgebruikers en de meeste bedrijven merken niets van al deze zinloze aanvragen, zij hebben haast nooit te maken met de DNS-rootservers en deze hebben genoeg capaciteit om al deze aanvragen te verwerken.

Dat aanvragers geen antwoord krijgen, komt vaak door te ijverige firewalls en packetfilters. DNS-namen worden vaak opgevraagd om in een logbestand een naam weer te geven in plaats van een IP-adres. Deze DNS-aanvragen zijn niet cruciaal, dus de aanvrager zal deze zinloze aanvragen niet snel opmerken. De oplossing van dit probleem is het goed configureren van firewalls en packetfilters. Op dit moment hebben de meeste bedrijven daar geen boodschap aan, de DNS-aanvragen kosten niks en het opnieuw configureren van de firewall wel, daarnaast willen veel bedrijven niet toegeven dat hun apparatuur verkeerd staat afgesteld. Over spam als oorzaak van het probleem heeft Wessels het volgende te zeggen:

It's entirely possible that spam emails generate an increased load for the root name servers. However, I don't think that simply sending spam increases load. Rather, it's more likely that anti-spam tools do. I can think of two specific examples:

1. Many anti-spam tools verify "From" addresses and perhaps other fields. If the From address has an invalid hostname, such as "spam.my.domain," the root servers will see more requests, because the top level domain does not exist.

2. Anti-spam tools also make various checks on the IP address of the connecting client -- for example, the various "realtime blackhole lists" and basic in-addr.arpa checks. These may be causing an increase in root server load, not simply because of the amount of spam, but also because these tools silently ignore failures.

Lees meer over

Moderatie-faq Wijzig weergave

Reacties (50)

Euhmm is het niet zo dat er op *elk* netwerk continue niet-essentiŽle data maar onderhoudsdata heen en weer wordt gezonden?

Vervolgens krijgt de anti-spamsoftware er van langs.

Het lijkt er op alsof ICANN een beetje in zijn maag zit met alle rootserver aanvragen. Toch lijken 152 miljoen aanvragen op een hele dag niet zo heel erg gek veel. Dat is in ieder geval veel minder dan ťťn aanvraag per internetter per dag :*)

Wat wil ICANN hiermee? Zijn ze bang voor een sterke stijging van het aantal aanvragen door anti-spamsoftware, willen ze ISP's of anderen proberen te overreden om hun spullen beter af te stellen? Komt dit uit nog een andere hoek?

Echt duidelijk is het allemaal niet, het zal er wel weer op neerkomen dat de ICANN de schuld kan afschuiven als er weer problemen met de rootservers komen.
Gewone internetgebruikers en de meeste bedrijven merken niets van al deze zinloze aanvragen, zij hebben haast nooit te maken met de DNS-rootservers en deze hebben genoeg capaciteit om al deze aanvragen te verwerken.
Dus eigenlijk helemaal niet erg dus. Tevens zijn er veel bedrijven, ISP's en mensen die zelf een DNS caching hebben, wat weer aanvragen kan schelen. Hoe meer er slim gecached wordt, hoe minder een Ddos op deze DNS servers voor invloed heeft op de korte termijn. Ik merk het dan alleen als ik nieuwe sites wil opvragen, die dus niet in m'n cache zitten.
niet erg?

98% betekend dat je er eigenlijk 1 pc had neer kunnen zetten ipv 50, das nogal een verschil denk ik

misschien merk je er nu persoonlijk niets van maar als je denkt aan de DDoS'n die ze gehad hebben, dan zou het toch fijn zijn als ze meer capaciteit vrij hebben
Met 1 PC ben je niet redundant -> 1 goeie DDOS aanval en het net ligt plat. Ze zullen die 13 die er nu zijn heus niet de deur uit doen.

Ik ben het met NiGeLaToR eens dat mensen meer gebruik moeten maken van de DNS server die hun ISP aanbied (ook al heb je een lokale DNS draaien, je kunt die DNS als forwarder gebruiken).
Dan voorkom je dat verkeer dat niet verder hoeft, ook niet verder gaat.
Staat gewoon in de tekst

naar het gebruik van de dertien DNS-rootservers besproken wordt
uit

a) de tekst

b) host -t NS .
en dat levert je A t/m M.ROOT-SERVERS.NET op
Ja, maar ieder van die lettertjes staat wel een hele serverende boerderij aan computertjes achter.
hoe kom je aan die 13?
Wat dacht je van DNS peering? Zijn verschillende ISP's dit dit doen. Bij een mismatch zal er pas een request naar een andere (interne) DNS server gaan.
"Tevens zijn er veel bedrijven, ISP's en mensen die zelf een DNS caching hebben"

Elke DNS-server houdt een cache bij, een DNS-server gaat enkel een aanvraag doen bij een DNS-server van een hoger nivieau als hij zelf de naam niet in zijn cache heeft of als deze niet meer klopt.

Dus ieder bedrijf, ISP, ... die een DNS draait hebben die cache, het is zelfs zo dat indien de 13 root DNS-servers er uit zouden liggen het nog dagen duurt eer wij dat zouden gaan merken.
Jamaar met dat caching krijg je toch ook weer problemen dat als ik een site opvraag en mijn DNS van mijn provider (bij deze @sloom) niet is geupdate maar netjes alles heeft gecached en er is net een wijziging doorgevoerd ik dus kan fluiten naar deze vernieuwde DNS!

Het beste is denk ik als ze voor het eventueel vertalen van een IPadres naar een hostname (voor logging en firewalls etc) een aantal alternatieve DNSsen moeten gaan gebruiken ipv de standaard DNS-servers waarop het internet is gebasseerd
Ja, maar zo'n cache expired ook weer. Meestal wordt deze tijd op 1 dag gezet, dus is er nog niet veel aan de hand. Dat betekent gewoon dat je even geduld moet hebben voordat mensen je nieuwe verwijzing kunnen vinden.. en dat moet toch wel.
Dit is de normale werkwijze zoals helmet al zegt.
Als jij bvb een domeinnaam registreert en de dns servers invult dan zal dit domein ook niet onmiddelijk bekend zijn bij andere providers/domeinnaam registranten.
Het heeft ook een doorlooptijd nodig voordat het in de andere DNS records wordt opgenomen.

Geduld is een mooie deugd :z
Als ik hier wat over te zeggen had dan zou ik alle verkeerde aanvragen loggen (natuurlijk beperkt en eventueel random) om zo bedrijven te blocken die de boel lopen te verstieren. Imo is dit gewoon iets dat je als systeembeheerder moet weten te voorkomen/configuren.

Dat er voldoende capaciteit is staat hier los van, het gaat hier om 'onkunde' en het lijkt mij dat dat op een of andere wijze moet worden bestreden.
Ik snap zoiso al niet waarom nameservers voor ieder TLD bijna dagelijks opnieuw een aanvraag doen bij de rootservers... De servers voor de TLD's veranderen ook niet zo vaak... zou ook maandelijks kunnen worden geupdate, zoals dat met je lijst met TLD-servers gebeurt.
Lijkt me niet echt fijn. Verander je met je TLD van server, moet je een maand wachten met het opnieuw overal on-line zijn :(
En dit probleem doet zich al vaker voor bij de trage providers.

Heb al vaker mee gemaakt dat @home, UPC ofzo erg traag is met updaten van hun DNS terwijl Demon super snel is.
Klopt inderdaad. Heb hier namelijk wel problemen mee gehad met mijn UPC verbinding. Na het opzetten van een nieuw TLD moest in inbellen naar Wanadoo Free om te kunnen uploaden naar mijn eigen domein omdat UPC heel traag was met updaten, het kostte geloof ik twee dagen of zo.
Ten eerste registreert u zelf vast geen TLD.

Dat een nieuw domein bij uw provider dan niet werkt is logisch, waarschijnlijk omdat u uw providers nameserver hebt vervuild door te vroeg requests te sturen. Stel u stuurt een request als het domein nog niet 100% actief is (ofwel, het domein staat nog niet in de tld's zonefile), dan onthoudt uw providers nameserver dat als een miss, en laat u dan weer 1 tot 3 dagen wachten voordat-ie het opnieuw probeert. Om dit te voorkomen kan u heel eenvoudig checken, bijv, uw domein is fiets.com:

host -t ns com.

en kies een van die servers, bijv. A.GTLD-SERVERS.NET. daarna:

host -t ns fiets.com. A.GTLD-SERVERS.NET.

Als daar geen resultaat uit komt, dan nog wachten. Werkt het wel, kijk dan vervolgens of het bij die NS ook nog werkt, stel die ns is dan ns1.provideur.nl:

host -t any fiets.com. ns1.provideur.nl.

Werkt dit alles, dan kan u via uw eigen provider het domein gewoon direct gebruiken, tenzij u dus alvorens het actief worden dns-requests daarvoor de deur uit heeft gedaan.
Ten eerste registreert u zelf vast geen TLD.
Pardon?

Welzeker heb ik een paar maal een TLD geregistreerd, en mijn voorbeeld is een praktijkvoorbeeld.

Bedankt voor de tip in ieder geval.
Heeft iemand uberhaupt het artikel gelezen en begrepen?
Our results showed that 50% of the root server traffic comes from only 220 IP addresses.
en
The short answer is that we suspect firewalls and packet filters.
...
From this, it seems most likely that these agents are just not receiving any DNS replies.
Het is niet Apache's schuld, spam heeft er (bijna) niets mee te maken enzovoort enzovoort. 220 individuen genereren de helft van al het verkeer, en een groot deel van de andere helft zijn clueloze zone-alarm gebruikers die niet door hebben wat ze fout doen. (Of erger: domme Ms-Proxy of FW1-gebruikers die niet door hebben wat ze fout doen.)
220 individuen genereren de helft van al het verkeer, en een groot deel van de andere helft zijn clueloze zone-alarm gebruikers die niet door hebben wat ze fout doen.
Vrij logisch, dat maar een beperkt aantal IP adressen de rootservers raadplegen: denk jij dat jouw IP adres bij de rootserver terecht komt op het moment dat jij een aanvraag doet? Nee dus: jouw aanvraag komt bij de DNS van jouw provider. Die vraagt het (in het meest gunstige geval) voor jou op bij de root servers. Dus het aantal IP adressen dat werkelijk verbinding maakt met de rootservers is behoorlijk beperkt...
zou er maar niet zo zeker van zijn dat alle jouw aanvragen niet bij de root servers terecht komen. Omdat de sjello DNS er vaak uitligt draai ik mijn eigen caching DNS (djbdns).
Hieronder waar mijn servertje de boel weghaalt. 192.168.0 en 192.168.1 zijn mn localnet en bncnet domeinen en worden ook absoluut niet doorgestuurd maar geresolved op localhost. De @ is voor de rest, daar staan keurig de 13 root servers in.

jan@c111031:/service/dnscachex/root$ ls servers/*
0.168.192.in-addr.arpa @ localnet
1.168.192.in-addr.arpa bncnet

jan@c111031:/service/dnscachex/root$ cat servers/@
198.41.0.4
128.9.0.107
192.33.4.12
128.8.10.90
192.203.230.10
192.5.5.241
192.112.36.4
128.63.2.53
192.36.148.17
198.41.0.10
193.0.14.129
198.32.64.12
202.12.27.33
Als je nu als zone 168.192.in-addr.arpa in je lokale dns zou poten dan verveel je de root servers niet met queries voor de reversed addressen in 192.168.0.0/16 die je niet gebruikt. Hetzelfde geld voor 10.0.0.0/8 en 172.16.0.0/12
Spam message kunnen inderdaad requests extra opleveren, ook door sommige content die er in staat die meegelinkt is. Ongewilt levert dit wel een hoop extra requests op denk ik, vooral als mensen hun autoview message optie niet uitzetten.
Maar wat willen de heren met dit onderzoek bereiken? Interactie van de gebruikers en bedrijven? Kun je wel vergeten ben ik bang. Alleen een structurele wijziging kan dit oplossen, want de mensen zelf willen er geen tijd en moeite in steken omdat "ze zeggen: "het werkt toch?".
Het geeft aan dat spam een doorn in het oog is, niet alleen bij de internetters maar ook bij de rootservers.
Een reden des te meer om wat tegen spam te doen......
Wat sterk bemoeilijkt word door de locale regeltjes en wetten. Als je het in de US goed regelt scheelt het misschien iets, maar dan nog blijven er requests komen uit andere landen etc. Andersom geld dat ook voor de overigen servers, eigenlijk zou de grond waarop die gebouwen staan als ICANN-ambassade met diplomatieke status als een erkend land moeten worden veranderd wil je echt wat druk kunnen uitoefenen op de bad requests. Wat dus nooit gaat gebeuren, dus moeten er strakkere gedragsregels komen en moeten zaken als requests etc beter in protocollen worden gestopt om bepaalde requests te voorkomen. Probleem met die gedragsregels is weer dat niet iedereen zich er aan gaat houden omdat buiten de ICANN iedereen min of meer vrij lijkt om te doen en laten wat ze willen. Dus is de cirkel weer rond en schiet je wederom niets op. Tenzij je de cirkel breekt met een fundamentele verandering. Welke dat is? Ik denk dat ze daar bij de ICANN ook nog even wat vergaderingen voor nodig hebben :)
Niemand zou de DNS root servers moeten query'en. De DNS servers van ISPs en dergelijke worden meermaals per dag geŁpdate adhv de root servers, zodat jij gewoon rustig de server van je ISP kan gebruiken. Het zou zeer nuttig zijn moest er gewoon gesteld worden dat alleen ISP's queries naar de root servers mochten maken!
Je zou gelijk hebben wanneer alle doemeinextensies landenextensies zouden zijn.

Je vergeet dat er ook nog de .com de .net etc zijn.
Deze aanvragen worden door de rootservers afgehandeld.
Ik gebruik ook DNS caching op mijne router.
Dat gaat sowieso rapper, iedereen zou dit moeten doen

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True