Wijzigingen in DNS-gedrag


Wijzigingen in .com/.net/.edu-naamsservers in voorbereiding op DNSSEC

Op 1 maart 2010 voerde Verisign twee wijzigingen door die van invloed zijn op het gedrag van de gezaghebbende naamservers voor de zones .com, .net en .edu ([a-m].gtld-servers.net). De wijzigingen zijn een vereiste voor de implementatie van DNSSEC in deze drie zones. De twee wijzigingen zijn
Nieuw verwijzingsgedrag en Aanhechting niet langer gepromoot als gezaghebbende status.

Nieuw verwijzingsgedrag 

Wanneer de gezaghebbende naamservers voor .com en .net in het verleden werde gevraagd om een bestaande A- of AAAA-record die als aanhechtingspunt diende (een adresrecord op of onder NS-records op een delegatiepunt), reageerden zij met de glue-record (aanhechtingsrecord) in de antwoordsectie. Het antwoord werd echter niet als gezaghebbend gemarkeerd, d.w.z., de AA-bit werd niet ingesteld. Hoewel dit gedrag voldeed aan de DNS-standaarden, reageerden gezaghebbende servers niet op deze manier. Wanneer nieuwe gezaghebbende servers om een naam op of onder een delegatiepunt werden gevraagd, reageerden deze met een verwijzing naar de gedelegeerde zone. Dit gedrag werd ook ondersteund door de DNS-standaarden.

De [a-m].gtld-servers.net-servers zijn nu overgegaan naar het laatstgenoemde verwijzingsgedrag: query's naar glue-records resulteren in doorverwijzingen in plaats van niet-bindende antwoorden.

Deze wijziging is van invloed op de omzetting van bepaalde domeinen onder .com en .net die van elkaar afhankelijk zijn. Zo werkte de volgende configuratie van onderling afhankelijke example.com- en example.net-zones prima in het verleden:

example.com. NS ns1.example.net.
example.com. NS ns2.example.net.

example.net. NS ns1.example.com.
example.net. NS ns2.example.com.

Deze twee domeinen werden in een 'cyclus' geconfigureerd: alle servers van example.com bevinden zich in het domein example.net, en alle servers van example.net bevinden zich in het domein example.com. Een dergelijke cyclische configuratie werd normaal omgezet, omdat [a-m].gtld-servers.net voor zowel de .com- als de .net-zones gezaghebbend waren, en omdat servers glue-query's retourneerden als niet-bindende antwoorden, zoals hierboven beschreven.

Waarom deze configuratie werkt, kan als volgt geïllustreerd worden. Kijk eens naar de stappen die een iteratieve omzetter (het gedeelte van een recursieve naamserver dat query's verzendt) volgt om gegevens op 'www.example.com' om te zetten:

  • De iteratieve omzetter zoekt op een gezaghebbende .com-naamserver naar 'www.example.com' en ontvangt een verwijzing naar 'example.com' waarbij alleen naamservers in 'example.net' worden vermeld.
  • Hoewel de verwijzing A-records bevat voor 'ns1.example.net' en 'ns2.example.net' in de aanvullende sectie van het DNS-bericht, worden deze records door moderne iteratieve omzetters genegeerd ter bescherming tegen cache-poisoning.
  • De iteratieve omzetter verwijdert de A-records voor 'ns1.example.net' en 'ns2.example.net' en heeft nu de namen, maar geen adressen voor example.com-naamservers. De query moet tijdelijk worden onderbroken zodat 'www.example.com' het adres van een van de example.com-naamservers kan opzoeken. Laten we ervan uitgaan dat de omzetter besluit 'ns1.example.net' om te zetten.
  • De iteratieve omzetter zoekt uiteindelijk op een gezaghebbende .net-naamserver naar de A-records voor 'ns1.example.net'. Volgens het huidige verwijzingsgedrag van [a-m].gtld-servers.net, retourneert de .net-server een niet-bindend antwoord voor de A-record voor 'ns1.example.net'. De iteratieve omzetter gebruikt dit adres om contact te leggen met deze example.com-naamserver en 'www.example.com' om te zetten.

Vanaf 1 maart 2010 retourneert de .net-server niet langer de A-record voor 'ns1.example.net', maar een verwijzing naar 'example.net'. Alle 'example.net'-naamservers bevonden zich echter in het domein example.com. De enige reden waarom de iteratieve omzetter nu probeert 'ns1.example.net' om te zetten, is om de oorspronkelijke query, 'www.example.com', om te zetten, die zich dus ook bevindt in het domein example.com. Omzetting is dus niet langer mogelijk, omdat alle domeinen van elkaar afhankelijk zijn.

Verisign heeft twee lijsten samengesteld met .com- en .net-domeinen waarop deze wijziging van invloed kan zijn:

Lijst 1: Domeinen die deel uitmaken van cycli

Domeinen in deze lijst zijn onderling afhankelijk zoals hierboven is beschreven. Zo zouden volgens het bovenstaande scenario zowel 'example.com' als 'example.net' op lijst 1 staan.

Lijst 2: Domeinen die geheel afhankelijk zijn van domeinen in cycli

Domeinen maken niet actief deel uit van een cyclus zoals de domeinen in lijst 1. Alle domeinen gebruiken in plaats daarvan alleen naamservers van domeinen die deel uitmaken van een cyclus. Met andere woorden, alle naamservers van een domein in lijst 2 komen uit een of meer domeinen in lijst 1. Als het domein 'foo.com' dus naamservers 'ns1.example.com' en 'ns2.example.com' had, zou 'foo.com' volgens het bovenstaande voorbeeld in lijst 2 komen.

Als een domein in een van de twee lijsten staat, betekent de wijziging van 1 maart dat ten minste een van de naamservers moet worden gewijzigd om de cyclus te doorbreken (voor domeinen in lijst 1) of om de afhankelijkheid tussen een domein en een cyclus op te heffen (voor domeinen in lijst 2).

Terug naar boven

Aanhechting niet langer gepromoot als gezaghebbende status 

In het .com/.net-registersysteem kan een domein in een administratieve wachtstand worden geplaatst. Een domein in wachtstand wordt niet gepubliceerd: de NS-records die het domein overdragen, worden verwijderd uit de zone .com- of .net. Registratiehouders plaatsen een domein bijvoorbeeld soms in wachtstand als het binnenkort zal verlopen en de inschrijver nog niet op verzoeken om verlenging heeft gereageerd. Een andere reden kan zijn dat het domein voor schadelijke activiteiten wordt gebruikt.

Wanneer een domein vóór de wijziging in wachtstand werd gezet, werden de NS-records uit de zone verwijderd, maar niet de A- en AAAA-records van naamservers in dat domein. Stel dat het domein example.com in het register stond samen met de naamserver ns.example.com. (Belangrijk: Voor het hier beschreven gedrag is het niet belangrijk of de example.com-zone zelf 'ns.example.com' daadwerkelijk als een van de gezaghebbende naamservers gebruikt. Wat van belang is, is dat 'ns.example.com' in het example.com-domein staat, d.w.z. eronder in de DNS-naamruimte.)

Als het example.com-domein voorheen in wachtstand werd gezet, werden de NS-records die het overdroegen, uit de .com-zone verwijderd. De A- en AAAA-records voor 'ns.example.com' bleven in de zone staan. Aangezien deze records zich niet langer onder een delegatiepunt bevonden, werden deze in feite bevorderd tot gezaghebbende gegevens.

Vanaf 1 maart 2010 geldt dat wanneer een domein in wachtstand gaat, de NS-records die het domein overdragen, uit de zone worden verwijderd, en de A- en AAAA-records voor naamservers onder het domein niet langer naar gezaghebbende status worden bevorderd. Deze A- en AAAA-records worden niet daadwerkelijk verwijderd: hoewel ze niet worden geretourneerd bij een rechtstreekse query, verschijnen ze wel in de aanvullende sectie met verwijzingen die aan deze records refereren.

Als 'example.com' in het bovenstaande voorbeeld in wachtstand wordt gezet, worden de NS-records uit de zone verwijderd. Maar als het example.net-domein 'ns.example.com' gebruikt als naamserver, staan de A- en AAAA-records voor 'ns.example.com' wel in de aanvullende sectie van een verwijzingsantwoord naar 'example.net' .

Hebt u vragen over deze wijzigingen, neem dan contact op met de Verisign-klantenservice voor registers.

Terug naar boven


WILT U MEER INFORMATIE?

  • +1-703-948-3200