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 , , 16 reacties
Bron: The Register, submitter: T.T.

Eén van de uitvinders van het universeel gebruikte domain name system, Paul Mockapetris, vindt dat verbeteringen in de veiligheid van het DNS-protocol snel geimplementeerd moeten worden. Dit meldt The Register. De DoS-aanvallen op DNS-rootservers afgelopen oktober toonden de kwetsbaarheid van het DNS-systeem, maar Mockapetris denkt dat de dreiging van dergelijke aanvallen overdreven worden. Alleen als de rootservers dagenlang worden bestookt ontstaat er een probleem. Er zijn echter veel grotere beveiligingsproblemen met DNS die onvoldoende worden onderkend, vindt de wetenschapper.

Zo heeft een aanval tegen de DNS van een land veel grotere consequenties dan tegen een rootserver. Wat een nog groter probleem is, is de mogelijkheid vervalste DNS-gegevens naar een client te sturen. De DNS Security Extensions (DNSSec) staan al lang op de planning, maar zijn nog niet geratificeerd door het IETF. Met het systeem, dat in browsers ingebakken kan worden, worden veilige DNS-lookups mogelijk. Zo wordt het een stuk moeilijker voor een server zich voor te doen als een andere server. Mockapetris gelooft echter dat de politiek één van de voornaamste oorzaken is van de vertraging van de introductie van DNSSec. Exemplarisch is de discussie rond de rol van ICANN in de organisatie van internet:

dns www internet algemeenMockapetris sees the system as operating at a lower level than site certificates, which he described as a "complementary technology. I don't believe in the grand unification theory." He describes DNS Sec as a first level ID check, which is still vital to build trust on the Net. "If you don't have secure DNS, how can you trust higher level protocols?" A security model for DNS would bolster Web services and help secure IP telephony. Fraud and impersonation will run rampant without this security model, according to Mockapetris.

Lees meer over

Moderatie-faq Wijzig weergave

Reacties (16)

Waarom niet de bestaande protocollen verbeteren? Het probleem is net als met windows, je wil er vanaf maar toch blijf je het maar gebruiken omdat je geen andere keus hebt. Wanneer de bestaande protocollen verbeterd worden ipv compleet nieuwe te verzinnen, zal het verbeterde protocol zonder gedoe makkelijker ingebracht kunnen worden. Dit lijkt mij de meest makkelijke manier om nieuwe protocollen in gebruik te krijgen.
Dan blijf je dus eeuwen met de gevolgen zitten.

http://www.angelfire.com/yt/lagedor/para/d21.html

In de V.S. is de standaardafstand tussen spoorrails 4 voet en 8½ duim - 143,51 cm.
Dat lijkt een weinig voor de hand liggende maat.
Waarom hebben ze dan voor een dergelijke spoorbreedte gekozen?
Omdat dat de spoorbreedte was die ze in Engeland hanteerden en de Amerikaanse spoorwegen zijn aangelegd door mensen die uit Engeland afkomstig waren.
Waarom gebruikten de Engelsen die maat?
Omdat de allereerste spoorlijnen werden aangelegd door dezelfde mensen die daarvóór de eerste trambanen hadden aangelegd en zij gebruikten die onderlinge afstand.
En hoe kwamen zij er dan weer aan?
Degenen die de trambanen aanlegden, gebruikten daarvoor hetzelfde gereedschap als voor het maken van koetsen en karren en die hadden deze spoorbreedte.
Goed, maar waarom hadden die dan zo'n rare afstand tussen de wielen?
Tja, als ze een andere breedte hadden genomen, hadden op de oude lange-afstandswegen in Engeland hun wielen het begeven, omdat dit de breedte is van de karresporen.
Wie hebben die oude, uitgesleten wegen dan aangelegd?
De eerste lange-afstandswegen in Europa, dus ook die in Engeland, zijn aangelegd onder de Romeinse keizers voor en door hun legioensoldaten. Die wegen zijn sindsdien altijd in gebruik gebleven.
En die karresporen?
De eerste sporen moeten gevormd zijn door de strijdwagens van de Romeinen. Daarna moest iedereen daar noodgedwongen rekening mee houden, omdat anders de wielen van de kar afliepen. Omdat de strijdwagens gebouwd werden door of voor Romeinen, werd altijd de keizerlijke standaardmaat toegepast wat betreft de spoorbreedte.
De in Amerika geldende standaardafstand tussen spoorrails van 4 voet en 8½ duim is dus rechtstreeks afgeleid van de oorspronkelijke specificatie voor strijdwagens van het Romeinse keizerrijk.
Specificaties hebben, net als bureaucratieën, het eeuwige leven.
De strijdwagens van het keizerrijk Rome werden namelijk net breed genoeg gemaakt om ruimte te bieden aan het achtereind van twee strijdrossen.
Hiermee hebben we dan eindelijk het antwoord op de oorspronkelijke vraag.
Als we nu kijken naar een Space Shuttle op zijn lanceerplatform, dan zien we twee grote aanjaagraketten ter weerszijden van de grote brandstoftank. Zo'n aanjaagraket wordt een 'solid rocket booster' genoemd, afgekort SRB. SRB's worden gemaakt in de fabriek van Thiokol in Utah.
De ontwerpers van de SRB hadden 'm graag wat forser uitgevoerd willen zien, maar SRB's moeten per trein van de fabriek naar het lanceerplatform vervoerd worden. De spoorlijn die van de fabriek komt loopt door een tunnel in de bergen. De SRB moest door die tunnel kunnen.
De tunnel is net iets breder dan het spoor en het spoor is ongeveer zo breed als de derrières van een span paarden.
Dus, het belangrijkste gegeven voor het ontwerp van wat we kunnen omschrijven als het meest geavanceerde transportsysteem ter wereld werd al meer dan tweeduizend jaar geleden bepaald en wel door de breedte van een paardekont!
Leuk verhaal, maar niet helemaal van toepassing. Een spoor kan je niet zomaar van breedte veranderen, want dan rijdt er geen enkele trein meer op. Bij elektronica en software is het vele malen makkelijker om twee mogelijkheden te ondersteunen, of toch op z'n minst voor te bereiden.
Mijn mailserver doet ook zowel QMTP als SMTP. QMTP een stuk efficienter, maar alleen mn backup MX en degene waar ik backup MX voor ben die het spreekt, verder is het zo goed als waardeloos omdat alleen qmail het protocol snapt.

Gewoon 2 standaarden accepteren dus, net zoals mn mailserver. Uiteindelijk is de betere standaard (QMTP) degene die overwint: als ik strax naar @home ga kan ik niets meer binnenkrijgen op poort 25 en kan mn backup MX mn server alleen nog maar bereiken via poort 209 met QMTP.
Reactie op : iceblink/Jan de Groot

Wat jij waarschijnlijk niet snapt in het verhaal van Ortep (en hij heeft het toch echt heel duidelijk beschreven) is het volgende: het is niet eenvoudig om bestaande dingen (bijvoorbeeld software) aan te passen. Denk eens aan eventuele gevolgen (die Ortep ook weer keurig beschrijft) van een eventuele aanpassing. Je moet veel verder denken dan het kleine wereldje om jou (of in dit geval fabrikant van software/hardware) heen.

In het kort dus: lees de post van Ortep nog eens en probeer voor jezelf eens te bedenken wat er allemaal fout kan gaan als je bijvoorbeeld in de electronica van een router een aanpassing maakt, welke zaken mogelijk allemaal aangepast zouden moeten worden door de wijziging (denk bijv. aan software).
De breedte van de SRB's is bepaald door de keuze van fabrikant. Als men een andere fabrikant had gekozen had hij niet door de tunnel gehoeven... Je kan alles zo doorredeneren zoals jij doet in je verhaaltje, maar dan sla je wel wat keuzes over. Zo had er ook gekozen kunnen worden voor een andere vorm van transport, of voor assemblage op locatie.
Je kan alles zo doorredeneren zoals jij doet in je verhaaltje, maar dan sla je wel wat keuzes over
Het ging hier om een voorbeeld van hoe lang een bepaalde keuze kan doorwerken. Ja, de fabrikant van de booster is gekozen. Dat had een andere kunnen zijn. Maar dan nog is het zo dat op dit moment de maat van de booster mede bepaald wordt door een Romeins paard van 2000 jaar geleden.

Het is gewoonweg niet eenvoudig om bestaande dingen aan te passen. Het is vaak eenvoudiger om maar gewoon opnieuw te beginnen. Daar draaide het verhaaltje om. Het was nl een reactie op EPJ met :
Wanneer de bestaande protocollen verbeterd worden ipv compleet nieuwe te verzinnen, zal het verbeterde protocol zonder gedoe makkelijker ingebracht kunnen worden.
Wat jij dus zegt is exact hetzelfde als de moraal van mijn (gestolen) verhaal: Totaal andere keuzes maken. Dan kan je schoon beginnen. Anders blijf je eindeloos je erfenis meeslepen.
Mja.. het huidige protocol is ook wel erg verouderd en in sommige gevallen overbodig. We houden er alleen nog met zn allen krampachtig aan vast. SMTP is bijvoorbeeld ook een zwaar verouderd en inefficient protocol, er zijn alternatieven maar niemand gebruikt ze. En met IPv6 wordt ook vrolijk gebruikt voor allerlei speeldoeleinden maar een serieuze omschakeling laat ook nog wel een paar jaar op zich wachten. Zonde.
Ja, maar het is niet eenvoudig om dat allemaal zomaar te implementeren. Veel applicaties, maar ook belangrijke delen van de internetinfrastructuur moeten aangepast worden om over te stappen naar DNSSec en IPv6. Routers zijn daar niet het kleinste deel van. Maak een gebruiker maar eens wijs dat ie van elke applicatie een nieuwe versie moet hebben,voor die datum, omdat ie anders gewoon niet op het internet kan (en dus de nieuwere versie niet kan ophalen). Daarbovenop de miljardeninvesteringen voor ISP's ed... neen het zal niet voor morgen zijn...
Daarbovenop de miljardeninvesteringen voor ISP's ed...
pardon? ik zie (en ik ben toevallig degene die bij een ISP over DNS gaat) niet waarom wij miljarden zouden moeten investeren voor de implementatie van DNSSec. We kunnen het in principe zo gaan gebruiken. (als ik persoonlijk het nut d'r van in zou zien tenminste, wat ik op dit moment nog niet doe)

Ook voor IPv6 valt de investering wel mee, de meeste van onze switches, routers, inbelbanken e.d. kunnen het al aan in principe, of we moeten d'r even een nieuw IOS in trappen.

aan de client-side kan het probleem groter worden, boel klanten die welliswaar goedkope routers hebben, maar dat goedkope heeft z'n prijs: je kan niet mee groeien met internet als internet spontaan IPv6 gaat gebruiken. Nou is dat met een tunnel wel weer op te lossen, maar ik zie de meeste dat nog niet zelfstandig voor elkaar krijgen.

overal zie ik nog weinig problemen met de implementatie van IPv6 of met DNSSec als internet zichzelf kon reguleren zoals het nagenoeg altijd heeft gedaan. Dat gezeik van de politiek in ieder land moet maar eens afgelopen zijn, internet providers en pro's kunnen het prima zelf.
DNSsec kan ook normale DNS aan :)
Zodat je app. niet geupdate moet worden, wel handig

Ps. Leuk om te weten
Nederland is koploper op dit gebied. Hebben ook al 2 DNSsec servers staan. Die je mag gebruiken :)
Ja leuk dat IPV6, maar met de huidige stand van zaken rond NAT en ook nog in het achterhoofd houdend dat routers en switches die het IPv6 protocol ondersteunen schaars en zeer zeker duur zijn. Is het dus zeer goed te begrijpen dat de feitelijke invoering van het IPv6 protcol op zich laat wachten.

Wat betreft SMTP, das een kwestie van op "macrosoft" wachten als die SMTP onmogelijk maakt in outlook express is het snel over met dat feest :P
Daar heb je idd gelijk in. De meeste protocollen van tegenwoordig stammen nog uit de tijd dat Planet de enige provider was in NL :P...
Das niet erug aktueel ja.. En IPv6 loopt wel los hoor, ik denk niet dat we er veel van zullen merken, 't zit immers al in XP....
De meeste bedrijven die inbellen gebruiken Windows 2000 en geen XP.
als die dns lookup net zo werkt als reverse lookup gaan een heleboel sites dikke problemen krijgen. Want de meeste sites worden gehost op andere DNS servers en daardoor is reverse lookup dus altijd negatief. Daarom staat reverse lookup op de meeste DNS servers ook uit. Hopelijk is dit een beter protocol om de boel dicht te timmeren.
"Met het systeem (DNSSec) , dat in browsers ingebakken kan worden, worden veilige DNS-lookups mogelijk"
Volgens mij is DNS-lookup een OS functie , en hoort niet in de browser thuis!

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