Ich bin gespannt, welche tatsächlichen Auswirkungen der L-Root-Server hatDURZ heute veröffentlichenwird sein. Auf der nanog-Mailingliste,jemand sagteEs ist wichtig, die systemischen Auswirkungen von Root-Nameservern zu bewerten, die signierte Zonen veröffentlichen, selbst wenn DNSSEC nicht verwendet wird. In der Zwischenzeit besagen die von RIPE selbst veröffentlichten Informationen zu ihren Änderungen am K-Root-Server, dass eskein Problem, wenn Ihre Resolver kein DNSSEC verwenden. Kann das bitte jemand aufklären? DNSSEC scheint ein chaotisches, verworrenes Netz zu sein.
Wenn ich DNSSEC auf meinen Resolvern nicht aktiviere, muss ich mir dann wegen der bevorstehenden Änderungen an den Root-Servern Sorgen machen?
Antwort1
DuMaietwas sehen, aber das hängt bis zu einem gewissen Grad davon ab, welche DNS-Software Sie ausführen.
Insbesondere setzt BIND das „DNSSEC OK“ DO-Bit (auch bekannt als ) bei Upstream-Abfragen, selbst wenn nicht ausdrücklich nach DNSSEC-Einträgen gefragt oder eine DNSSEC-Validierung durchgeführt wird.
Unter diesen Umständen können die Root-Server zusätzliche DNSSEC-Einträge zurücksenden, dieMaiverursachen Probleme im unwahrscheinlichen Fall, dass Ihre Netzwerkausrüstung defekt ist und/oder die Firewall falsch konfiguriert ist.
Diese Probleme hängen hauptsächlich mit der Paketgröße zusammen. Einige Kits mögen keine DNS-UDP-Pakete, die länger als 512 Byte sind, entweder aufgrund fehlerhafter Firmware oder fehlerhafter empfohlener Konfigurationen des Herstellers. Siehe meineRFC 5625für weitere Einzelheiten. Beachten Sie jedoch, dass die meisten DNSSEC-bezogenen Probleme, über die ich in diesem RFC berichte, sich auf Geräte der Verbraucherklasse beziehen und nur in ungewöhnlichen Konfigurationen auftreten.
Beachten Sie, dass, wenn Ihr Kit Probleme mit großen UDP-Paketen hat, die Fallback-Option TCP ist. Einige (fehlgeleitete) Sicherheitsleute konfigurieren ihre Firewalls jedoch so, dass ausgehende DNS über TCP deaktiviert werden, was die Fallback-Option unterbricht. SieheDasIETF-Entwurf für weitere Informationen zu DNS über TCP.
Um die Konfiguration Ihres Netzwerks auf mögliche DNS-Macken zu testen, empfehle ich Ihnen übrigensexzellent NetalyzrWebsite von ICSI an der UC Berkeley.
Um es klar zu sagen: Die meisten DNS-Experten sindnichtIch erwarte erhebliche Probleme durch die Einführung von DNSSEC. Mehrere TLDs (einschließlich .org und .se) wurden bereits signiert und das Internet ist deswegen nicht zusammengebrochen.
Die DURZ ist ein gezielter Versuch, die größeren Reaktionen, die DNSSEC zwangsläufig produziert, schrittweise einzuführen, so dass die wenigen Standorte mit Netzwerkproblemen diese beheben können, bevor im Sommer die gesamte Root-Zone auf DNSSEC umgestellt wird.
Antwort2
Eine Erklärung, was bei Pseudocode schiefgehen kann, für diejenigen, die imperative Programmiersprachen bevorzugen :-)
-- Pseudocode (Syntax mehr oder weniger Ada-ähnlich), um zu zeigen, was passiert mit
-- ein DNS-Resolver, wenn die Root signiert ist und die Antworten
-- größer.
-- Hintergrundinformation:
-- https://www.dns-oarc.net/oarc/services/replysizetest
- RFC 5625
-- SSAC-Bericht Nr. 35 http://www.icann.org/committees/security/sac035.pdf
-- Stephane Bortzmeyer
-- Verwendete Variablen:
-- EDNS0: Boolesch, gibt an, ob der Resolver EDNS0-Anfragen sendet
-- EDNS0_Size: positive Ganzzahl, die von EDNS0 angegebene Puffergröße
-- DO_DNSSEC: Boolesch, das DO-Flag, das die DNSSEC-Unterstützung durch den Resolver anzeigt
-- Min_Response_Size: Integer, das Minimum (nach dem Löschen
-- unnötige RR) Größe der DNS-Antwort, die von der autoritativen
-- Server
- Clean_path_for_fragments: Boolesch, zeigt an, dass UDP-Fragmente
- kann vom autoritativen Nameserver zum Resolver gelangen
-- Clean_Path_For_EDNS0: Boolesch, gibt an, dass EDNS0 antwortet
-- (die größer als 512 Bytes sein können) können von der
-- autoritativer Nameserver für den Resolver
-- Can_TCP: Boolesch, gibt an, dass der Resolver über TCP fragen kann
-- (was einen sauberen TCP-Patch und einen autoritativen Nameserver voraussetzt)
-- die TCP akzeptieren)
-- Der Code kann für eine Anfrage mehrmals ausgeführt werden, z.
-- Beispiel, weil ein Resolver es zuerst mit UDP versucht und es dann erneut versucht
-- mit TCP.
wenn UDP dann -- Gebräuchlichstes Transportprotokoll für DNS
wenn EDNS0 dann
wenn EDNS0_Size > MTU dann
-- BIND-Standard, EDNS0_size = 4096 Bytes
wenn DO_DNSSEC dann
-- BIND-Standard, auch wenn nicht für die Validierung konfiguriert
if Min_Response_Size > MTU then -- Nicht der Fall heute mit dem root
wenn Clean_Path_for_fragments dann
OK;
anders
-- Nach einer Weile wechselt BIND zu no-EDNS0, starten Sie von vorne
Retry("Nicht empfangene Antworten können an EDNS0 liegen");
Ende wenn;
elsif Min_Response_Size > 512 dann
-- Es kommt zu keiner Fragmentierung
wenn Clean_Path_For_EDNS0 dann
OK; -- Das ist der normale und typische Fall für ein BIND
-- Resolver heute, mit der signierten Wurzel
anders
Retry("Nicht empfangene Antworten können an EDNS0 liegen");
Ende wenn;
sonst -- Wird heute nicht vorkommen, Antworten von der Wurzel sind bereits > 512
OK;
Ende wenn;
anders
-- Ohne DNSSEC werden die Antworten kürzer sein, aber einige
-- Antworten von der Wurzel sind bereits > 512
wenn Min_Response_Size > MTU dann
-- Unwahrscheinlich, ohne DNSSEC
wenn Clean_Path_for_fragments dann
OK;
anders
Retry("Nicht empfangene Antworten können an EDNS0 liegen");
Ende wenn;
elsif Min_Response_Size > 512 dann
wenn Clean_Path_For_EDNS0 dann
OK;
anders
Retry("Nicht empfangene Antworten können an EDNS0 liegen");
Ende wenn;
else -- Der heute häufigste Fall, der typische unsignierte
-- Die Antwort ist 100-200 Bytes lang
OK;
Ende wenn;
Ende wenn;
elsif EDNS0_Size >= 512 dann -- Aber niedriger als die MTU
wenn DO_DNSSEC dann
wenn Min_Response_Size > EDNS0_Size dann
-- Dies setzt voraus, dass DNS-Pakete mit gesetztem TC-Bit ankommen
-- sicher, nicht immer wahr
Wiederholen("Abschneiden");
elsif Min_Response_Size >= 512 dann
wenn Clean_Path_for_EDNS0 dann
OK;
anders
Retry("Nicht empfangene Antworten können an EDNS0 liegen");
Ende wenn;
sonst -- Kommt heute nicht mehr oft vor, einige Antworten von der Wurzel sind bereits > 512
OK; -- Nicht immer, einige Middleboxes blockieren möglicherweise EDNS0
-- Antworten, auch mit Größe 512 dann
wenn Clean_Path_For_EDNS0 dann
OK;
anders
Retry("Nicht empfangene Antworten können an EDNS0 liegen");
Ende wenn;
anders
OK;
Ende wenn;
Ende wenn;
sonst -- EDNS0 mit Größe 512 dann
Wiederholen("Abschneiden");
anders
OK;
Ende wenn;
Ende wenn;
sonst - TCP
wenn Can_TCP dann
OK; -- Aber höhere Latenz und höhere Belastung der autoritativen Nameserver
anders
Error("Fallback auf TCP fehlgeschlagen"); -- Vollständiger und totaler Fehler
Ende wenn;
Ende wenn;
Antwort3
Eine weitere Lösung zum Testen Ihres Setups, die ich viel einfacher finde als Netalyzr, istOARC-Antwortgrößentest.