Journalistiek

Onpartijdig, onafhankelijk nieuws, uitsluitend in dienst van het branchebelang.

DNSSEC en nameservers: Luisteren op TCP

  • Door
  • Randy ten Have
  • geplaatst op
  • 30 augustus 2010 08:03 uur

Nu DNSSEC op steeds meer domeinen wordt ingevoerd ontstaat er straks bij een gesignde zone en domeinnaam een ander probleem: DNS-queries worden langer dan normaal en passen niet meer in een UDP-pakket. Nameservers zullen daarom moeten overschakelen op het TCP-protocol.

Registrars die domeinen bij het Franse AFNIC geregistreerd hebben kennen het probleem misschien al wel van de controles die uitgevoerd worden op de nameservers. Wanneer deze niet luisteren op TCP dan zal de registratie van een .fr-domein niet slagen. Het lijkt een beetje vreemd dat een registry toegang tot TCP wil hebben omdat dit protocol normaal gesproken alleen gebruikt wordt voor (interne) AXFR-transfers maar ook zonder DNSSEC kunnen er problemen ontstaan door UDP-pakketten die te groot worden, bijvoorbeeld een SPF-record met een  grote lijst geautoriseerde mailservers.

Met de komst van DNDSEC zullen pakketten mogelijk over de grens van 512 bytes heen gaan, waardoor DNS-servers over zullen schakelen naar TCP om de informatie af te leveren. Veel firewalls en DNS-servers blokkeren dit protocol of droppen pakketten groter dan 512 bytes. Nu ook in Nederland en België de eerste stappen voor DNSSEC zijn gezet, is het belangrijk om alvast te kijken hoe je eigen DNS-server en firewalls ingesteld staan.  Er is een manier om te testen of je huidige DNS-resolver DNSSEC aankan. Namelijk door de instructies te volgen op DNS-OARC.

Frank, 30 augustus 2010 1:20 pm

Beetje vreemd verhaal. UDP kan pakketten gebruiken die tot 65535 bytes groot zijn (zie RFC 768). Dat in de praktijk de omvang meestal wordt beperkt tot 512 bytes verandert daar niets aan. Bij het ontwikkelen van een nameservertooltje in 2005 ben ik al servers tegengekomen die - zonder dat dat iets met DNDSEC te maken had - in één pakket veel meer dan 512 bytes terugstuurden. Dat je daar rekening mee moet houden, is ook aangegeven in verschillende DNS RFCs.

Randy ten Have, 30 augustus 2010 8:35 pm

Niet helemaal. We gebruiken een MTU van 1500. UDP pakketten zijn dan beperkt tot maximaal 1452 bytes. MTU van 1500 minus >= 20 bytes voor de IP-header minus 8 bytes voor de UDP header. (Uit m'n hoofd even. De CCNA boeken liggen alweer een aantal jaren in een doos op zolder...

Marco, 1 september 2010 11:02 am

De 512 bytes grens is een waarde die is vastgelegd in het oorspronkeljike DNS protocol (RFC1035, par. 2.3.4). Met de komst van de EDNS0 uitbreiding (RFC2671) kunnen DNS antwoorden over UDP echter veel groter zijn dan de oorspronkelijke 512 bytes. Omdat er nog een aantal resolvers zijn die geen EDNS0 ondersteuning hebben, danwel achter een firewall staan die hier niets van begrijpt, zal in een aantal gevallen echter nog worden overgeschakeld op TCP (zoals is vastgelegd in het DNS protocol. Voor .nl is het aantal TCP queries met een factor 34 toegenomen met de introductie van DNSSEC (maar het maakt nog steeds een zeer klein deel van het totaal aantal queries uit).
Desondanks is het raadzaam om op authoritative name servers (die grote antwoorden kunnen genereren), resolvers en tussenliggende firewalls TCP toe te staan.

Feedback!
Fill out my online form.
Laatste reacties

Bedankt voor het succes van ISPam.nl
Koen Stegeman, Editor-in-Chief & founder Hostingjournalist.com: Jammer Arnout, maar je hebt een mooie bijdrage aan de hosting industrie geleverd, en dat jaren lang....

Bedankt voor het succes van ISPam.nl
Dillard Blom: Jammer dat een 'instituut' verdwijnt, en daarmee een bron van informatie over actuele zaken (en opin...

Bedankt voor het succes van ISPam.nl
L.: Uit automatisme kijk ik toch nog steeds elke dag naar ispam.nl, toch de hoop dat er nog een berichtj...

Bedankt voor het succes van ISPam.nl
Toni Donkers: Arnout bedankt! ik ga het missen dat is een feit!

Bedankt voor het succes van ISPam.nl
Marcel Stegeman: Ik zie het nu pas. Inderdaad jammer maar ik kijk nu al uit naar het volgende project.