Frage Wie viele IPs kann ein DNS A-Datensatz maximal haben?


Ich habe eine seltsame Idee - lassen Sie mehrere Personen / Organisationen die gleiche Anwendung hosten und lassen Sie alle ihre Knoten über einen einzigen Domainnamen erreichbar sein. Das ist, um beispielsweise ein wirklich verteiltes soziales Netzwerk zu haben, in dem Benutzerfreundlichkeit nicht geopfert wird (d. H. Benutzer müssen sich nicht an unterschiedliche Anbieter-URLs erinnern und dann, wenn ein Anbieter ausfällt, zu einem anderen wechseln).

Um das zu erreichen, dachte ich, dass ein DNS-Eintrag mit mehreren IPs verwendet werden kann.

Wie viele IPs kann ein einzelner DNS A-Datensatz enthalten? Diese Antwort sagt, es ist ungefähr 30, aber der Anwendungsfall dort ist anders. Für das obige Szenario wäre es mir egal, ob ein bestimmter ISP nur 30 zwischenspeichert, solange ein anderer ISP andere 30 zwischenspeichert, und so weiter.


30
2017-12-12 21:47


Ursprung


Nimmst du ungefähr Anycast? - Lie Ryan
Ich habe vor einiger Zeit gelernt, dass, wenn Sie jemals fragen müssen "Was ist die maximale Anzahl von X?" du benutzt es wahrscheinlich falsch ... - LordOfThePigs
Nicht unbedingt;) Aber im Allgemeinen ja - Bozho


Antworten:


Disclaimer: Nichts für ungut, aber das ist eine wirklich schlechte Idee. Ich empfehle niemandem, dies im wirklichen Leben zu tun.

Aber wenn Sie einem gelangweilten IT-Typen ein Labor geben, werden lustige Dinge passieren!

Für dieses Experiment habe ich einen Microsoft DNS-Server verwendet, der auf Server 2012 R2 ausgeführt wird. Wegen der Komplikationen beim Hosten einer DNS-Zone in Active Directory habe ich eine neue primäre Zone mit dem Namen testing.com erstellt nicht AD-integriert.

Mit diesem Skript:

$Count = 1
for ($x = 1; $x -lt 256; $x++)
{
    for ($y = 1; $y -lt 256; $y++)
    {
        for ($z = 1; $z -lt 256; $z++)
        {
            Write-Host "1.$x.$y.$z`t( $Count )"
            $Count++
            dnscmd . /RecordAdd testing.com testing A 1.$x.$y.$z
        }
    }
}

Ich fuhr fort, ohne Fehler 65025 Host-Datensätze für den Namen zu erstellen testing.testing.com.mit buchstäblich jeder IPv4-Adresse von 1.1.1.1 bis 1.1.255.255.

Dann wollte ich sicherstellen, dass ich 65536 (2 ^ 16 Bit) Gesamtanzahl der A-Datensätze ohne Fehler durchbrechen konnte, und ich könnte, also nehme ich an, dass ich den ganzen Weg bis zu 16581375 (1.1.1.1 bis 1.255) hätte gehen können .255.255,), aber ich wollte nicht hier sitzen und dieses Skript die ganze Nacht laufen sehen.

Too many records

Ich denke also, es gibt kein praktisches Limit für die Anzahl von A-Datensätzen, die Sie einer Zone für denselben Namen mit unterschiedlichen IP-Adressen auf Ihrem Server hinzufügen können.

Aber wird es tatsächlich Arbeit Aus der Sicht eines Kunden?

Hier ist, was ich von meinem Kunden von Wireshark erhalten habe:

two queries (Öffnen Sie das Bild in einem neuen Browser-Tab für die volle Größe.)

nslookup

TCP query

Wie Sie sehen können, gibt es bei der Verwendung von nslookup oder ping von meinem Client automatisch zwei Abfragen aus - ein UDP und ein TCP. Wie Sie bereits wissen, ist das Meiste, das ich in ein UDP-Datagramm stopfen kann, 512 Bytes. Wenn also dieses Limit überschritten wird (wie 20-30 IP-Adressen), muss stattdessen TCP verwendet werden. Aber selbst mit TCP erhalte ich nur eine sehr kleine Teilmenge von A-Datensätzen für testing.testing.com. 1000 Datensätze wurden pro TCP-Abfrage zurückgegeben. Die Liste der A-Datensätze rotiert bei jeder folgenden Abfrage genau um 1, genau wie Sie erwarten würden, dass Round-Robin-DNS funktioniert. Es würde Millionen von Abfragen benötigen, um sich durch all diese Dinge hindurchzukämpfen.

Ich kann mir nicht vorstellen, dass dies Ihnen helfen wird, Ihr massiv skalierbares, belastbares Social-Media-Netzwerk zu entwickeln, aber Ihre Antwort ist trotzdem.


Bearbeiten: In Ihrem Follow-up-Kommentar fragen Sie, warum ich das generell für eine schlechte Idee halte.

  • Angenommen, ich bin ein durchschnittlicher Internetnutzer und möchte eine Verbindung zu Ihrem Dienst herstellen. Ich tippe www.bozho.biz in meinen Webbrowser. Der DNS-Client auf meinem Computer erhält 1000 Datensätze zurück. Nun, Pech, die ersten 30 Datensätze in der Liste reagieren nicht, weil die Liste der A-Datensätze nicht auf dem neuesten Stand ist, oder vielleicht gibt es einen großen Ausfall, der einen Teil des Internets betrifft. Nehmen wir an, mein Webbrowser hat eine Zeitüberschreitung von 5 Sekunden pro IP, bevor er weitergeht und den nächsten versucht. So, jetzt sitze ich hier und schaue auf eine sich drehende Sanduhr für zweieinhalb Minuten und warte darauf, dass deine Seite geladen wird. Dafür hat niemand Zeit. Und ich gehe nur davon aus, dass mein Webbrowser oder eine andere Anwendung, mit der ich auf Ihren Dienst zugreife, sogar mehr als die ersten 4 oder 5 IP-Adressen versucht. Es wird wahrscheinlich nicht.

  • Wenn Sie automatisches Aufräumen verwenden und nicht validierte oder anonyme Aktualisierungen der DNS-Zone zulassen, in der Hoffnung, die Liste der A-Datensätze frisch zu halten, stellen Sie sich vor, wie unsicher das wäre! Selbst wenn Sie ein System entwickelt haben, bei dem die Clients ein Client-TLS-Zertifikat benötigen, das sie zuvor erhalten haben, um die Zone zu aktualisieren, wird ein kompromittierter Client irgendwo auf der Welt ein Botnetz starten und Ihren Dienst zerstören. Traditionelles DNS ist prekär unsicher, so wie es ist, ohne es zu crowd-sourcing.

  • Unmengen an Bandbreite und Verschwendung. Wenn jede DNS-Abfrage 32 Kilobyte oder mehr Bandbreite benötigt, wird das überhaupt nicht gut skalieren.

  • DNS Round-Robin ist kein Ersatz für den richtigen Lastenausgleich. Es bietet keine Möglichkeit, sich von einem ausgefallenen Knoten zu erholen oder mitten in der Sache nicht verfügbar zu sein. Werden Sie Ihre Benutzer anweisen, eine ipconfig / flushdns auszuführen, wenn der Knoten, mit dem sie verbunden waren, ausfällt? Diese Art von Problemen wurde bereits durch Dinge wie GSLB und Anycast gelöst.

  • Usw.


74
2017-12-12 23:59



Langsam .... klatsch ....., mein Herr. - mfinni
Wenn die A-Datensätze über BIND abgefragt werden (was auf den meisten DNS-Servern ausgeführt wird), werden die A-Datensätze gemischt und bestimmte A-Datensätze zurückgegeben. Diese bestimmte Anzahl ist in definiert MAX_SHUFFLE im BIND-Quellcode (der standardmäßig 32 ist). - ub3rst4r
Super, danke - Bozho
Aus Neugier, warum würdest du es nicht empfehlen? Es ist sicherlich eine sehr seltsame Sache, aber abgesehen davon, dass bösartige Knoten Anfragen unter einer "guten" Domäne bedienen und ausgefallene Knoten immer noch Anfragen erhalten, was kann sonst noch schiefgehen :-) - Bozho
Würde sich das Benutzererlebnis nicht ändern? Ist jeder Knoten ein vollständiges Replikat? Wie würden Sie sicherstellen, dass es unter der Kontrolle anderer Menschen ist? Wenn sie anders sind, dann werden die Leute heute eine Site und eine andere Site morgen bekommen. Persönlich würde mich das verrückt machen! - Brandon


Um die Frage zu beantworten, wie es gesagt wurde ("Wie viele IPs kann eine einzelne DNS A-Aufzeichnung halten?") Ist die Antwort sehr einfach: eine einzige A Datensatz enthält genau eine Adresse. Es kann jedoch mehrere geben A Datensätze für denselben Namen.


18
2017-12-13 01:04





Jede IPv4-Adresse belegt 16 Byte in der Antwort. Jede IPv6-Adresse belegt in der Antwort 28 Byte.

Es wird dringend empfohlen, sicherzustellen, dass die Antwort in 512 Bytes passt. Das würde ungefähr 25 IPv4-Adressen und 14 IPv6-Adressen ermöglichen (in Anbetracht dessen, dass Sie auch einige andere Informationen in dem Paket benötigen). Das genaue Limit hängt von der Länge Ihres Domain-Namens ab.

Wenn Sie sowohl 25 IPv4-Adressen als auch 14 IPv6-Adressen haben, rechnen Sie damit, dass die Clients in separaten Abfragen IPv4- und IPv6-Adressen anfordern. Sollte der Kunde in einer einzigen Abfrage nach beiden Adresstypen fragen (was selten vorkommt), müssten Sie tiefer gehen.

Wenn die Antwortgröße 512 Bytes überschreitet, kann es immer noch über UDP funktionieren, wenn Client und Server EDNS unterstützen. Ohne EDNS würde der Client eine abgeschnittene Antwort erhalten, und er müsste es erneut über TCP versuchen. Dies erhöht die Kommunikation von 1 bis 4 Roundtrips. Aber noch schlimmer, manchmal gibt es Fehlkonfigurationen, die verhindern, dass DNS über TCP funktioniert.

Selbst wenn Sie mehr als 14 Adressen in die Antwort pressen könnten, ohne Probleme auf der DNS-Schicht zu verursachen, ist es unwahrscheinlich, dass sie sehr nützlich sind. Das Zeitlimit, das vom Client verwendet wird, bevor er auf eine Adresse verzichtet und mit dem nächsten fortfährt, ist oft signifikant.

Ein einziges Mal auf diese Zeitüberschreitung zu warten, kann zu einer schlechten Benutzererfahrung führen. Wenn der Client 14 Adressen durchlaufen muss, bevor er eine Antwort erhält, muss der Benutzer 13 Zeitüberschreitungen warten.


10
2017-12-12 23:57



Jeder DNS sollte heutzutage EDNS unterstützen. Die 512-Byte-Grenze für DNS-Antworten ist aufgrund von DNSSEC nicht mehr praktikabel. - Barmar
@Barmar Aber wenn Sie es eingeschaltet haben, besteht ein ziemlich signifikantes Risiko, dass Ihr Server bei Amplifikationsangriffen verwendet wird. Als ich das letzte Mal nachprüfte, stellte ich fest, dass das Ausschalten der Bindung das einzige war, was man tun konnte, um Amplifikationsangriffe zu mildern. Bis EDNS um ein Cookie-Feld erweitert wird und die Unterstützung dafür weit verbreitet ist, wird empfohlen, die Unterstützung für Antworten mit mehr als 512 Byte zu deaktivieren. - kasperd
Ich bin nicht wirklich in der Art von Suchergebnissen für die Deaktivierung EDNS eine Best Practice. Zitate bitte? Amplifikationsangriffe, die rekursive Server nutzen, werden unabhängig davon, ob EDNS aktiviert ist oder nicht, durchgeführt, wenn Ihr Netzwerk die Überprüfung der Quelladresse nicht durchführt. Selbst wenn es sich um einen autoritativen Server handelt, wird dies erst relevant, wenn Sie es einmal getan haben konfiguriert es um so viele Daten in einer einzigen Antwort zurückzugeben, zu diesem Zeitpunkt wird es Ihnen nicht helfen, sie zu deaktivieren. - Andrew B
@AndrewB Ich kann mich nicht erinnern, wo ich diese Empfehlung gelesen habe. Ich habe viele verschiedene Empfehlungen gelesen, wie Amplifikationsattacken vermieden werden können, und alle sind lutschen. Es ist schade, dass EDNS kein Cookie eingeführt hat, was eine effiziente Lösung für die Amplifikationsangriffe mit DNS gewesen wäre. Was ich in meiner Antwort empfehle, ist zu vermeiden, dass so viele Datensätze in eine Abfrage eingefügt werden, dass Sie auf andere angewiesen sind, um EDNS zu aktivieren, damit Antworten effizient sind. - kasperd
@AndrewB Wenn ich A-Datensätze mit mehr als 512 Byte in eine Zone lege und sicherstelle, dass sie auf einem autoritativen DNS-Server gehostet wird, auf dem EDNS aktiviert ist, kann dies ein Problem für Benutzer rekursiver Resolver sein, die keine so großen Antworten zulassen. Und deshalb empfehle ich, die Anzahl der A-Datensätze niedriger zu halten. Außerdem habe ich erklärt, warum der wahrgenommene Nutzen dieser vielen A-Datensätze nicht so relevant ist. - kasperd


Was Sie beschreiben, ist keine besonders neue Idee. Wie andere Antworten bereits berichtet haben, ist die Anzahl der A-Datensätze, die Sie in einer Antwort haben können, begrenzt, aber das sagt nichts darüber aus, wie viele A-Datensätze es insgesamt gibt.

Sie könnten zum Beispiel einen DNS-Server implementieren, der jede Anfrage nach einem A-Eintrag mit einer zufälligen IP beantwortet. Oft genug abgefragt, würde dies 4294967296 eindeutige A-Datensätze ergeben: einen für jede IPv4-Adresse.

Wie gesagt, das ist keine neue Idee. In der Tat ist es teilweise wie Akamai funktioniert (und wahrscheinlich viele andere CDNs). Der A-Eintrag, den Sie für jede Akamai-Domain erhalten, wird von ihren schwarzmagischen DNS-Servern bestimmt. Ich wette, dass die Antwort, die Sie erhalten, von dynamischer Lastverteilung und geographischen Bedenken abhängt.

Zum Beispiel wählte ich a338.g.akamaitech.net. Wenn ich mir das jetzt auf meinem Computer anschaue, der einen DHCP zugewiesenen Nameserver von Comcast benutzt:

$ host a338.g.akamaitech.net
a338.g.akamaitech.net has address 23.3.98.65
a338.g.akamaitech.net has address 23.3.98.89

Was ist, wenn ich Google DNS frage?

$ host a338.g.akamaitech.net 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases: 

a338.g.akamaitech.net has address 23.3.96.152
a338.g.akamaitech.net has address 23.3.96.120

Ich wette, wenn Sie es versuchen, ich wette, Sie werden eine andere Antwort bekommen. Wie viele Edge-Server bedient Akamai mit einer bestimmten Ressource? Mehr als zwei, wette ich.


5
2017-12-13 13:21



Vielen Dank. Ja, ich weiß, dass CDNs auf diese Weise funktionieren, aber meiner Meinung nach haben sie nur eine begrenzte Anzahl von Datensätzen pro Subdomain (2 in Ihrem Beispiel). Meine andere aktuelle Frage betrifft CDNs und ihre DNS-Implementierung :-) - Bozho


Andere haben es als ein Detail erwähnt, aber von einem praktischen Standpunkt aus ist das harte Limit die UDP-Paketgrößenbeschränkung von 512 Bytes. Obwohl es möglich ist, zu TCP zu wechseln, wenn die Trunkierung erkannt wird, werden viele / die meisten Clients es nicht tun (und sollten es auch nicht tun; es würde den meisten Anwendungen schlechte Benutzererfahrung geben und ich würde nur Zonentransfers oder andere erwarten spezielle Lookups zur Unterstützung von TCP). Sie sehen also eine Grenze von etwa 30 Adressen für IPv4 (A-Datensätze) und etwas weniger für IPv6 (AAAA), da sie größer sind. Die Länge des Domain-Namens schneidet darin ein und begrenzt die Anzahl weiter.


2
2017-12-14 01:47



Sie sind ziemlich richtig, dass es viele fehlerhafte Clients und Resolver gibt, die DNS-Antworten nicht richtig verarbeiten, die nicht in ein einzelnes UDP-Datagramm passen, aber bitte die Idee, dass nur Zonenübertragungen oder ungewöhnliche Anforderungen größere Antwortgrößen benötigen. In Ihrer Antwort verwenden Sie eindeutig keine DNSSEC-Validierung, aber viele Leute sind (und DNSSEC ist auch nicht der einzige Grund, warum größere Antworten benötigt werden, aber es ist ein sehr wichtiger.) - Michael McNally
@MichaelMcNally: DNSSEC ist nicht beabsichtigt (zumindest nicht von Implementierern, basierend auf Threads in den glibc-Mailinglisten, an denen ich beteiligt war), die an Endpunkten (Anwendungen, die DNS-Lookups durchführen) verwendet werden, aber auf dem lokalen rekursiven Nameserver Nachschlagevorgänge im Auftrag von Anwendungen. Selbst mit einem DNSSEC-Setup ist daher kein Grund zu erwarten, dass Anwendungen DNS über TCP sprechen. UDP funktioniert einwandfrei. - R..


Andere haben darauf hingewiesen, dass es eine schreckliche Idee für den realen Gebrauch ist.

In der realen Welt gibt es nichtkonforme Clients und Resolver, die Probleme mit Antworten haben, die nicht in ein einzelnes UDP-Datagramm passen, und es gibt Firewalls, die bestimmte, aber nicht protokollkonforme Ideen zu Beschränkungen der DNS-Nachrichtengröße erzwingen.

Und selbst wenn Sie sich darauf verlassen könnten, dass Ihre riesige Reaktion in jedem Fall durchkommt (was Sie mit Nachdruck nicht tun können), gibt es einen weiteren Grund, warum dies eine sehr schlechte Idee ist. Je größer Ihre DNS-Antwortgröße ist, desto verlockender ist sie als Nutzlast für Reflection-Angriffe, da Sie einen enormen Verstärkungsfaktor bereitstellen. Bei dieser Art von Denial-of-Service-Angriffen, die im DNS üblich sind, wird eine UDP-Abfrage an einen offenen rekursiven Resolver gesendet. Die Quelladresse von UDP-Abfragen wird normalerweise leicht gefälscht, und der Angreifer setzt die Abfragequelle auf die IP des beabsichtigten Ziels. Zwei wünschenswerte (für den Angreifer) Effekte werden erreicht: erstens - ein relativ geringer Sendungsaufwand ihrerseits (von einer kleinen gefälschten Abfrage) führt zu einem vergleichsweise großen Strom von unerwünschtem Verkehr, der am Ziel ankommt (dies ist der Verstärkungsfaktor). und zweitens - die eigentliche Quelle des Angriffs ist vor dem Ziel verborgen; Das Ziel kennt nur die Adressen der rekursiven Resolver, die als Reflektoren verwendet werden.


0
2017-12-15 06:02





Interessanter Punkt der historischen Trivia zu diesem Thema. In den 90er Jahren erweiterte AOL seine DNS-Einträge so, dass eine MX-Abfrage> 512 Byte zurückgab. Diese Verletzung RFC, brach viele SMTP-Server (qmail ist eine beliebte zu der Zeit), und verursacht Sysadmins eine Menge Kopfschmerzen. Die Fehlerbehebung benötigt entweder patchenoder statische Routen hinzufügen.

Ich weiß nicht, was die aktuelle Situation ist, aber vor ein paar Jahren, als ich zum letzten Mal qmail berührte, waren die Patches immer noch vorhanden.

http://www.gossamer-threads.com/lists/qmail/users/30503


0
2017-12-17 13:25