Verschiedene Aspekte des Betriebs von DNS wurden bereits mehrfach vom Autor in einer Reihe von im Blog veröffentlichten Artikeln angesprochen. Dabei lag der Hauptfokus immer auf der Verbesserung der Sicherheit dieses entscheidenden Dienstes für das gesamte Internet.
Bis vor kurzem, trotz der offensichtlichen Verwundbarkeit des DNS-Traffics, der bis heute größtenteils unverschlüsselt übertragen wird, war der Prozess , trotz der vorhandenen Technologien wie DNSSEC/DANE, DNScrypt, DNS-over-TLS und DNS-over-HTTPS, ins Stocken geraten. Während serverseitige Lösungen, einige davon bereits seit einiger Zeit bekannt und verfügbar sind, die Unterstützung durch Client-Software jedoch häufig zu wünschen übrig lässt.
Glücklicherweise ändert sich die Situation. Insbesondere haben die Entwickler des beliebten Browsers Firefox , dass sie planen, standardmäßig den Modus (DoH) in naher Zukunft. Dies sollte helfen, den DNS-Verkehr der WWW-Nutzer vor den oben genannten Bedrohungen zu schützen, könnte jedoch potenziell neue Herausforderungen mit sich bringen.
1. Probleme mit DNS-over-HTTPS
Auf den ersten Blick scheint die beginnende massenhafte Einführung von DNS-over-HTTPS in Internet-Software nur positive Reaktionen hervorzurufen. Doch wie so oft liegt der Teufel im Detail.
Ein zentrales Problem, das die breite Anwendung von DoH einschränkt, ist die ausschließliche Ausrichtung auf Web-Traffic. Tatsächlich ist das Protokoll HTTP und seine aktuelle Version HTTP/2, auf dem DoH basiert, das Fundament des WWW. Doch das Internet beschränkt sich nicht nur auf das Web. Es gibt eine Vielzahl beliebter Dienste wie E-Mail, verschiedene Messenger, Dateitransfersysteme, Multimedia-Streaming und mehr, die kein HTTP verwenden. Somit erweist sich DoH, trotz der weit verbreiteten Wahrnehmung als Allheilmittel, als unpraktisch ohne zusätzliche (und unnötige) Anstrengungen für alles andere als Browsing-Technologien. Erwähnenswert ist, dass DNS-over-TLS als viel würdigere Alternative erscheint, da es den Standard-DNS-Traffic in das sichere Standardprotokoll TLS einkapselt.
Ein weiteres Problem, das potenziell viel gravierender ist als das erste, ist der tatsächliche Verzicht auf die ursprünglich eingebaute Dezentralisierung von DNS zugunsten der Verwendung eines einzelnen, in den Browsereinstellungen angegebenen DoH-Servers. Insbesondere bietet Mozilla einen Service von Cloudflare an. Ein ähnlicher Service wurde auch von anderen namhaften Unternehmen im Internet, darunter Google, ins Leben gerufen. Das bedeutet, dass die Implementierung von DNS-over-HTTPS in der derzeit vorgeschlagenen Form nur die Abhängigkeit der Endnutzer von den größten Anbietern erhöht. Es ist kein Geheimnis, dass die Informationen, die durch die Analyse von DNS-Anfragen gesammelt werden können, zusätzlich dazu beitragen, noch mehr Daten über den Benutzer zu erfassen sowie deren Genauigkeit und Aktualität zu verbessern.
In diesem Zusammenhang war und bleibt der Autor ein Befürworter der massenhaften Einführung von nicht DNS-over-HTTPS, sondern DNS-over-TLS in Verbindung mit DNSSEC/DANE als universelles, sicheres und nicht zentralisierungsförderndes Mittel zur Gewährleistung der Sicherheit von DNS-Traffic. Leider ist es aus verständlichen Gründen nicht zu erwarten, dass eine schnelle Einführung von alternativen DoH in Client-Software erfolgt, und bisher bleibt dies den Enthusiasten sicherer Technologien vorbehalten.
Aber da wir jetzt DoH erhalten, warum nicht nutzen, indem wir uns von potenzieller Überwachung durch Unternehmen auf deren Servern abwenden und stattdessen unseren eigenen DNS-over-HTTPS-Server betreiben?
2. Protokoll DNS-over-HTTPS
Wenn man sich den Standard anschaut, der das Protokoll DNS-over-HTTPS beschreibt, sieht man, dass es im Wesentlichen eine Web-API ist, die es ermöglicht, das Standard-DNS-Paket in das HTTP/2-Protokoll zu kapseln. Dies geschieht durch spezielle HTTP-Header und die Umwandlung des binären Formats der übermittelten DNS-Daten (siehe und folgende Dokumente) in ein Format, das die Übertragung und den Empfang sowie die Arbeit mit den notwendigen Metadaten ermöglicht.
Es wird standardmäßig nur HTTP/2 und eine gesicherte TLS-Verbindung unterstützt.
DNS-Anfragen können über die Standardmethoden GET und POST gesendet werden. Im ersten Fall wird die Anfrage in eine base64URL-codierte Zeichenkette umgewandelt, während im zweiten Fall dies über den Binärkörper der POST-Anfrage erfolgt. Dabei wird ein spezieller MIME-Typ für die DNS-Anfrage und -Antwort verwendet. application/dns-message.
root@eprove:~ # curl -H 'accept: application/dns-message' 'https://my.domaint/dns-query?dns=q80BAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE' -v
* Verbindung zu 2001:100:200:300::400:443 wird versucht...
* TCP_NODELAY gesetzt
* Verbunden mit eprove.net (2001:100:200:300::400) Port 443 (#0)
* ALPN, bietet h2 an
* ALPN, bietet http/1.1 an
* Zertifikat-Überprüfungsorte erfolgreich festgelegt:
* CAfile: /usr/local/share/certs/ca-root-nss.crt
CApath: keine
* TLSv1.3 (OUT), TLS-Handshake, Client hello (1):
* TLSv1.3 (IN), TLS-Handshake, Server hello (2):
* TLSv1.3 (IN), TLS-Handshake, Verschlüsselte Erweiterungen (8):
* TLSv1.3 (IN), TLS-Handshake, Zertifikat (11):
* TLSv1.3 (IN), TLS-Handshake, CERT Überprüfung (15):
* TLSv1.3 (IN), TLS-Handshake, Fertig (20):
* TLSv1.3 (OUT), TLS Wechsel des Chiffrierverfahrens, Chiffrier-Spezifikation ändern (1):
* TLSv1.3 (OUT), TLS-Handshake, Fertig (20):
* SSL-Verbindung unter Verwendung von TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, Server akzeptierte Verwendung von h2
* Serverzertifikat:
* Betreff: CN=my.domain
* Startdatum: 22. Jul 2019 00:07:13 GMT
* Ablaufdatum: 20. Okt 2019 00:07:13 GMT
* subjectAltName: Host "my.domain" stimmte mit dem Zertifikat "my.domain" überein
* Aussteller: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL-Zertifikat überprüft.
* Verwendet HTTP2, Server unterstützt Mehrfachnutzung
* Verbindungsstatus geändert (HTTP/2 bestätigt)
* Kopiere HTTP/2-Daten im Stream-Puffer in den Verbindungs-Puffer nach dem Upgrade: len=0
* Verwende Stream-ID: 1 (einfacher Handle 0x801441000)
> GET /dns-query?dns=q80BAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE HTTP/2
> Host: eprove.net
> User-Agent: curl/7.65.3
> accept: application/dns-message
>
* TLSv1.3 (IN), TLS-Handshake, neues Session-Ticket (4):
* Verbindungsstatus geändert (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 200
< server: h2o/2.3.0-beta2
< content-type: application/dns-message
< cache-control: max-age=86274
< date: Do, 12. Sep 2019 13:07:25 GMT
< strict-transport-security: max-age=15768000; includeSubDomains; preload
< content-length: 45
<
Warnung: Binärausgabe kann Ihr Terminal durcheinanderbringen. Verwenden Sie "--output -", um curl anzuweisen, es dennoch in Ihrem Terminal auszugeben, oder verwenden Sie "--output ", um in eine Datei zu speichern.
* Schreiben des Körpers fehlgeschlagen (0 != 45)
* Stream-Pause gestoppt!
* Verbindung #0 zum Host eprove.net bleibt unberührtBeachten Sie auch den Titel cache-control: in der Antwort des Webservers. Im Parameter max-age befindet sich der TTL-Wert für den zurückgegebenen DNS-Eintrag (oder der Minimalwert, falls eine Gruppe zurückgegeben wird).
Basierend auf dem Vorhergehenden besteht die Funktionsweise eines DoH-Servers aus mehreren Schritten.
- Erhalten Sie die HTTP-Anfrage. Wenn es sich um eine GET-Anfrage handelt, dekodieren Sie das Paket aus der base64URL-Codierung.
- Senden Sie dieses Paket an den DNS-Server.
- Erhalten Sie die Antwort vom DNS-Server
- Finden Sie den minimalen TTL-Wert in den erhaltenen Einträgen.
- Geben Sie dem Client die Antwort per HTTP zurück.
3. Ihr eigener DNS-over-HTTPS-Server
Der einfachste, schnellste und effizienteste Weg, um Ihren eigenen DNS-over-HTTPS-Server zu starten, ist die Verwendung eines HTTP/2-Webservers , über den der Autor bereits kurz geschrieben hat (siehe „«).
). Ein Vorteil dieser Wahl ist, dass der gesamte Code des eigenen DoH-Servers vollständig mit dem im H2O integrierten Interpreter implementiert werden kann. Neben den Standardbibliotheken wird eine Bibliothek (mrbgem) benötigt, um mit dem DNS-Server zu kommunizieren, die glücklicherweise bereits in der aktuellen Entwicklerversion H2O 2.3.0-beta2 in den Ports von FreeBSD. Es ist jedoch nicht schwierig, sie auch in jede frühere Version hinzuzufügen, indem man das Repository klont. in das Verzeichnis /deps vor der Kompilierung.
root@beta:~ # uname -v
FreeBSD 12.0-RELEASE-p10 GENERIC
root@beta:~ # cd /usr/ports/www/h2o
root@beta:/usr/ports/www/h2o # make extract
=== > Lizenz MIT BSD2CLAUSE vom Benutzer akzeptiert
=== > h2o-2.2.6 benötigt Datei: /usr/local/sbin/pkg - gefunden
=== > Alle benötigten Dist-Dateien für den Bau von h2o-2.2.6 werden abgerufen
=== > Entpacken für h2o-2.2.6.
=> SHA256 Prüfziffer OK für h2o-h2o-v2.2.6_GH0.tar.gz.
=== > h2o-2.2.6 benötigt Datei: /usr/local/bin/ruby26 - gefunden
root@beta:/usr/ports/www/h2o # cd work/h2o-2.2.6/deps/
root@beta:/usr/ports/www/h2o/work/h2o-2.2.6/deps # git clone https://github.com/iij/mruby-socket.git
Klone in «mruby-socket»…
remote: Objekte zählen: 385, erledigt.
remote: Insgesamt 385 (Delta 0), 0 wiederverwendet (Delta 0), pack-reused 385
Erhalte Objekte: 100% (385/385), 98.02 KiB | 647.00 KiB/s, fertig.
Änderungen bestimmen: 100% (208/208), fertig.
root@beta:/usr/ports/www/h2o/work/h2o-2.2.6/deps # ll
total 181
drwxr-xr-x 9 root wheel 18 12 Aug. 16:09 brotli/
drwxr-xr-x 2 root wheel 4 12 Aug. 16:09 cloexec/
drwxr-xr-x 2 root wheel 5 12 Aug. 16:09 golombset/
drwxr-xr-x 4 root wheel 35 12 Aug. 16:09 klib/
drwxr-xr-x 2 root wheel 5 12 Aug. 16:09 libgkc/
drwxr-xr-x 4 root wheel 26 12 Aug. 16:09 libyrmcds/
drwxr-xr-x 13 root wheel 32 12 Aug. 16:09 mruby/
drwxr-xr-x 5 root wheel 11 12 Aug. 16:09 mruby-digest/
drwxr-xr-x 5 root wheel 10 12 Aug. 16:09 mruby-dir/
drwxr-xr-x 5 root wheel 10 12 Aug. 16:09 mruby-env/
drwxr-xr-x 4 root wheel 9 12 Aug. 16:09 mruby-errno/
drwxr-xr-x 5 root wheel 14 12 Aug. 16:09 mruby-file-stat/
drwxr-xr-x 5 root wheel 10 12 Aug. 16:09 mruby-iijson/
drwxr-xr-x 5 root wheel 11 12 Aug. 16:09 mruby-input-stream/
drwxr-xr-x 6 root wheel 11 12 Aug. 16:09 mruby-io/
drwxr-xr-x 5 root wheel 10 12 Aug. 16:09 mruby-onig-regexp/
drwxr-xr-x 4 root wheel 10 12 Aug. 16:09 mruby-pack/
drwxr-xr-x 5 root wheel 10 12 Aug. 16:09 mruby-require/
drwxr-xr-x 6 root wheel 10 12 Sept. 16:10 mruby-socket/
drwxr-xr-x 2 root wheel 9 12 Aug. 16:09 neverbleed/
drwxr-xr-x 2 root wheel 13 12 Aug. 16:09 picohttpparser/
drwxr-xr-x 2 root wheel 4 12 Aug. 16:09 picotest/
drwxr-xr-x 9 root wheel 16 12 Aug. 16:09 picotls/
drwxr-xr-x 4 root wheel 8 12 Aug. 16:09 ssl-conservatory/
drwxr-xr-x 8 root wheel 18 12 Aug. 16:09 yaml/
drwxr-xr-x 2 root wheel 8 12 Aug. 16:09 yoml/
root@beta:/usr/ports/www/h2o/work/h2o-2.2.6/deps # cd ../../..
root@beta:/usr/ports/www/h2o # make install clean
...Die Konfiguration des Webservers ist insgesamt standardmäßig.
root@beta:/usr/ports/www/h2o # cd /usr/local/etc/h2o/
root@beta:/usr/local/etc/h2o # cat h2o.conf
# Diese Beispielkonfiguration vermittelt Ihnen ein Gefühl dafür, wie h2o verwendet werden kann
# und bietet eine hochsichere Konfiguration für TLS und HTTP-Header
# siehe https://h2o.examp1e.net/ für ausführliche Dokumentation
# und h2o --help für Befehlszeilenoptionen und Einstellungen
# v.20180207 (c)2018 von Max Kostikov http://kostikov.co E-Mail: max@kostikov.co
user: www
pid-file: /var/run/h2o.pid
access-log:
path: /var/log/h2o/h2o-access.log
format: "%h %v %l %u %t "%r" %s %b "%{Referer}i" "%{User-agent}i""
error-log: /var/log/h2o/h2o-error.log
expires: off
compress: on
file.dirlisting: off
file.send-compressed: on
file.index: [ 'index.html', 'index.php' ]
listen:
port: 80
listen:
port: 443
ssl:
cipher-suite: ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
cipher-preference: server
dh-file: /etc/ssl/dhparams.pem
certificate-file: /usr/local/etc/letsencrypt/live/eprove.net/fullchain.pem
key-file: /usr/local/etc/letsencrypt/live/my.domain/privkey.pem
hosts:
"*.my.domain":
paths: &go_tls
"/":
redirect:
status: 301
url: https://my.domain/
"my.domain:80":
paths: *go_tls
"my.domain:443":
header.add: "Strict-Transport-Security: max-age=15768000; includeSubDomains; preload"
paths:
"/dns-query":
mruby.handler-file: /usr/local/etc/h2o/h2odoh.rbDie einzige Ausnahme bildet der URL-Handler /dns-query für den unser DNS-over-HTTPS-Server verantwortlich ist, der in mruby geschrieben wurde und über die Handler-Option aufgerufen wird. mruby.handler-file.
root@beta:/usr/local/etc/h2o # cat h2odoh.rb
# H2O HTTP/2 Webserver als DNS-over-HTTP-Dienst
# v.20190908 (c)2018-2019 Max Kostikov https://kostikov.co E-Mail: max@kostikov.co
proc {|env|
if env['HTTP_ACCEPT'] == "application/dns-message"
case env['REQUEST_METHOD']
when "GET"
req = env['QUERY_STRING'].gsub(/^dns=/,'')
# base64URL dekodieren
req = req.tr("-_", "+/")
if !req.end_with?("=") && req.length % 4 != 0
req = req.ljust((req.length + 3) & ~3, "=")
end
req = req.unpack1("m")
when "POST"
req = env['rack.input'].read
else
req = ""
end
if req.empty?
[400, { 'content-type' => 'text/plain' }, [ "Ungültige Anfrage" ]]
else
# --- Anfrage an den DNS-Server
sock = UDPSocket.new
sock.connect("localhost", 53)
sock.send(req, 0)
str = sock.recv(4096)
sock.close
# --- niedrigsten TTL in der Antwort finden
nans = str[6, 2].unpack1('n') # Anzahl der Antworten
if nans > 0 # kein DNS-Fehler
shift = 12
ttl = 0
while nans > 0
# Verarbeitung der Domänennamenkompression
if str[shift].unpack1("C") < 192
shift = str.index("x00", shift) + 5
if ttl == 0 # Frageabschnitt überspringen
next
end
end
shift += 6
curttl = str[shift, 4].unpack1('N')
shift += str[shift + 4, 2].unpack1('n') + 6 # Antwortdaten-Größe
if ttl == 0 or ttl > curttl
ttl = curttl
end
nans -= 1
end
cc = 'max-age=' + ttl.to_s
else
cc = 'no-cache'
end
[200, { 'content-type' => 'application/dns-message', 'content-length' => str.size, 'cache-control' => cc }, [ str ] ]
end
else
[415, { 'content-type' => 'text/plain' }, [ "Nicht unterstützter Medientyp" ]]
end
}Bitte beachten Sie, dass für die Verarbeitung von DNS-Paketen der lokale Caching-Server verantwortlich ist, in diesem Fall , der standardmäßig in FreeBSD enthalten ist. Aus Sicht der Sicherheit ist dies die optimale Lösung. Nichts hindert Sie jedoch daran, localhost die Adresse eines anderen DNS-Servers zu verwenden, den Sie planen einzusetzen.
root@beta:/usr/local/etc/h2o # local-unbound version
usage: local-unbound [options]
start unbound daemon DNS resolver.
-h diese Hilfe
-c datei Konfigurationsdatei anstelle von /var/unbound/unbound.conf lesen
Dateiformat wie in unbound.conf(5) beschrieben.
-d nicht im Hintergrund ausführen.
-p keine PID-Datei erstellen.
-v detailliert (mehrfach zur Erhöhung der Detailtiefe)
Version 1.8.1
verlinkte Bibliotheken: mini-event intern (verwendet select), OpenSSL 1.1.1a-freebsd 20. Nov 2018
verlinkte Module: dns64 respip validator iterator
BSD-lizenziert, siehe LIZENZ im Quellpaket für Details.
Fehler melden an unbound-bugs@nlnetlabs.nl
root@eprove:/usr/local/etc/h2o # sockstat -46 | grep unbound
unbound local-unbo 69749 3 udp6 ::1:53 *:*
unbound local-unbo 69749 4 tcp6 ::1:53 *:*
unbound local-unbo 69749 5 udp4 127.0.0.1:53 *:*
unbound local-unbo 69749 6 tcp4 127.0.0.1:53 *:*Jetzt bleibt es, H2O neu zu starten und zu sehen, was dabei herausgekommen ist.
root@beta:/usr/local/etc/h2o # service h2o restart
H2O wird gestoppt.
Warten auf PIDs: 69871.
H2O wird gestartet.
start_server (pid:70532) startet jetzt...4. Testen
Lassen Sie uns also die Ergebnisse überprüfen, indem wir eine weitere Testanfrage senden und den Netzwerkverkehr mit dem Tool beobachten. tcpdump.
root@beta/usr/local/etc/h2o # curl -H 'accept: application/dns-message' 'https://my.domain/dns-query?dns=q80BAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE'
Warnung: Binärausgabe kann Ihr Terminal durcheinanderbringen. Verwenden Sie "--output -", um curl zu sagen,
Warnung: dass es dennoch an Ihr Terminal ausgegeben werden soll, oder ziehen Sie "--output
Warnung: <DATEI>" in Betracht, um in eine Datei zu speichern.
...
root@beta:~ # tcpdump -n -i lo0 udp port 53 -xx -XX -vv
tcpdump: hört auf lo0, Link-Typ NULL (BSD Loopback), Erfassungsgröße 262144 Bytes
16:32:40.420831 IP (tos 0x0, ttl 64, id 37575, offset 0, flags [none], proto UDP (17), length 57, fehlerhafte Prüfziffer 0 (->e9ea)!)
127.0.0.1.21070 > 127.0.0.1.53: [schadhafter UDP-Prüfziffer 0xfe38 -> 0x33e3!] 43981+ A? example.com. (29)
0x0000: 0200 0000 4500 0039 92c7 0000 4011 0000 ....E..9....@...
0x0010: 7f00 0001 7f00 0001 524e 0035 0025 fe38 ........RN.5.%.8
0x0020: abcd 0100 0001 0000 0000 0000 0765 7861 .............exa
0x0030: 6d70 6c65 0363 6f6d 0000 0100 01 mple.com.....
16:32:40.796507 IP (tos 0x0, ttl 64, id 37590, offset 0, flags [none], proto UDP (17), length 73, fehlerhafte Prüfziffer 0 (->e9cb)!)
127.0.0.1.53 > 127.0.0.1.21070: [schadhafter UDP-Prüfziffer 0xfe48 -> 0x43fa!] 43981 q: A? example.com. 1/0/0 example.com. A 93.184.216.34 (45)
0x0000: 0200 0000 4500 0049 92d6 0000 4011 0000 ....E..I....@...
0x0010: 7f00 0001 7f00 0001 0035 524e 0035 fe48 .........5RN.5.H
0x0020: abcd 8180 0001 0001 0000 0000 0765 7861 .............exa
0x0030: 6d70 6c65 0363 6f6d 0000 0100 01c0 0c00 mple.com........
0x0040: 0100 0100 0151 8000 045d b8d8 22 .....Q...].."
^C
2 Pakete erfasst
23 Pakete wurden durch den Filter empfangen
0 Pakete wurden vom Kernel verworfenDie Ausgabe zeigt, wie die Anfrage zur Adressauflösung example.com vom DNS-Server empfangen und erfolgreich bearbeitet wurde.
Jetzt müssen wir unseren Server im Firefox-Browser aktivieren. Dazu sind einige Anpassungen auf der Konfigurationsseite erforderlich. about:config.
Zunächst ist dies die Adresse unserer API, über die der Browser Informationen im DNS abfragen wird. network.trr.uri. Es wird auch empfohlen, die IP-Adresse der Domain aus dieser URL für eine sichere Auflösung über den Browser selbst anzugeben, ohne auf DNS zurückzugreifen. network.trr.bootstrapAddress. Und schließlich der Parameter network.trr.mode , der die Verwendung von DoH aktiviert. Wenn Sie den Wert auf „3“ setzen, verwendet der Browser ausschließlich DNS-over-HTTPS zur Namensauflösung, während der sicherere und zuverlässigere Wert „2“ DoH priorisiert und die standardmäßige DNS-Abfrage als Backup lässt.
5. PROFIT!
War dieser Artikel hilfreich? Dann scheuen Sie sich bitte nicht, uns finanziell über das Spendenformular (unten) zu unterstützen.
Quelle: habr.com
