ProHoster > blog > administratie > We ontmoeten de service van Cloudflare op de adressen 1.1.1.1 en 1.0.0.1, oftewel “de openbare DNS-plank is gearriveerd!”

We ontmoeten de service van Cloudflare op de adressen 1.1.1.1 en 1.0.0.1, oftewel “de openbare DNS-plank is gearriveerd!”

We ontmoeten de service van Cloudflare op de adressen 1.1.1.1 en 1.0.0.1, oftewel “de openbare DNS-plank is gearriveerd!”

Cloudflare-bedrijf gepresenteerd openbare DNS op adressen:

  • 1.1.1.1
  • 1.0.0.1
  • 2606: 4700: 4700 :: 1111
  • 2606: 4700: 4700 :: 1001

Er wordt gezegd dat het beleid 'Privacy eerst' is, zodat gebruikers gerust kunnen zijn over de inhoud van hun verzoeken.

De service is interessant omdat deze, naast de gebruikelijke DNS, de mogelijkheid biedt om technologieën te gebruiken DNS-over-TLS и DNS-over-HTTPS, wat aanzienlijk zal voorkomen dat providers uw verzoeken langs het pad van verzoeken afluisteren - en statistieken verzamelen, monitoren en advertenties beheren. Cloudflare beweert dat de datum van de aankondiging (1 april 2018, of 04/01 in Amerikaanse notatie) niet toevallig is gekozen: op welke andere dag van het jaar zullen de “vier eenheden” worden gepresenteerd?

Omdat het publiek van Habr technisch onderlegd is, is het traditionele gedeelte "Waarom heb je DNS nodig?" Ik zal het aan het einde van het bericht plaatsen, maar hier zal ik meer praktisch nuttige dingen vermelden:

Hoe kunt u de nieuwe dienst gebruiken?

Het eenvoudigste is om de bovenstaande DNS-serveradressen op te geven in uw DNS-client (of upstream in de instellingen van de lokale DNS-server die u gebruikt). Heeft het zin om de gebruikelijke waarden te vervangen? Google-DNS (8.8.8.8, enz.), of iets minder gebruikelijk Yandex openbare DNS-servers (77.88.8.8 en anderen zoals zij) naar de servers van Cloudflare - zij zullen voor u beslissen, maar spreken voor een beginner rooster reactiesnelheid, volgens welke Cloudflare sneller is dan alle concurrenten (ik zal het verduidelijken: de metingen zijn uitgevoerd door een externe service en de snelheid voor een specifieke klant kan natuurlijk verschillen).

We ontmoeten de service van Cloudflare op de adressen 1.1.1.1 en 1.0.0.1, oftewel “de openbare DNS-plank is gearriveerd!”

Het is veel interessanter om met nieuwe modi te werken waarin het verzoek via een gecodeerde verbinding naar de server vliegt (in feite wordt het antwoord daardoor teruggestuurd), de genoemde DNS-over-TLS en DNS-over-HTTPS. Helaas worden ze niet ‘out of the box’ ondersteund (de auteurs zijn van mening dat dit ‘nog’ is), maar het is niet moeilijk om hun werk in je software (of zelfs op je hardware) te organiseren:

DNS via HTTPs (DoH)

Zoals de naam al doet vermoeden, vindt communicatie plaats via een HTTPS-kanaal, wat betekent dat

  1. de aanwezigheid van een landingspunt (eindpunt) - het bevindt zich op het adres https://cloudflare-dns.com/dns-queryEn
  2. een client die verzoeken kan verzenden en antwoorden kan ontvangen.

Verzoeken kunnen de DNS Wireformat-indeling hebben die is gedefinieerd in RFC1035 (verzonden met behulp van de POST- en GET HTTP-methoden), of in JSON-indeling (met behulp van de GET HTTP-methode). Voor mij persoonlijk leek het idee om DNS-verzoeken via HTTP-verzoeken te doen onverwacht, maar er zit een rationele korrel in: zo'n verzoek passeert veel verkeersfiltersystemen, het parseren van antwoorden is vrij eenvoudig en het genereren van verzoeken is zelfs nog eenvoudiger. Voor de beveiliging zijn de gebruikelijke bibliotheken en protocollen verantwoordelijk.

Vraag voorbeelden aan, rechtstreeks uit de documentatie:

GET-verzoek in DNS Wireformat-formaat

$ curl -v "https://cloudflare-dns.com/dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB" | hexdump
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7f968700a400)
GET /dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/2
Host: cloudflare-dns.com
User-Agent: curl/7.54.0
Accept: */*

* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
HTTP/2 200
date: Fri, 23 Mar 2018 05:14:02 GMT
content-type: application/dns-udpwireformat
content-length: 49
cache-control: max-age=0
set-cookie: __cfduid=dd1fb65f0185fadf50bbb6cd14ecbc5b01521782042; expires=Sat, 23-Mar-19 05:14:02 GMT; path=/; domain=.cloudflare.com; HttpOnly
server: cloudflare-nginx
cf-ray: 3ffe69838a418c4c-SFO-DOG

{ [49 bytes data]
100    49  100    49    0     0    493      0 --:--:-- --:--:-- --:--:--   494
* Connection #0 to host cloudflare-dns.com left intact
0000000 ab cd 81 80 00 01 00 01 00 00 00 00 03 77 77 77
0000010 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00
0000020 01 c0 0c 00 01 00 01 00 00 0a 8b 00 04 5d b8 d8
0000030 22
0000031

POST-verzoek in DNS Wireformat-formaat

$ echo -n 'q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB' | base64 -D | curl -H 'Content-Type: application/dns-udpwireformat' --data-binary @- https://cloudflare-dns.com/dns-query -o - | hexdump

{ [49 bytes data]
100    49  100    49    0     0    493      0 --:--:-- --:--:-- --:--:--   494
* Connection #0 to host cloudflare-dns.com left intact
0000000 ab cd 81 80 00 01 00 01 00 00 00 00 03 77 77 77
0000010 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00
0000020 01 c0 0c 00 01 00 01 00 00 0a 8b 00 04 5d b8 d8
0000030 22
0000031

Hetzelfde, maar met JSON

$ curl 'https://cloudflare-dns.com/dns-query?ct=application/dns-json&name=example.com&type=AAAA'

{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": true,
  "CD": false,
  "Question": [
    {
      "name": "example.com.",
      "type": 1
    }
  ],
  "Answer": [
    {
      "name": "example.com.",
      "type": 1,
      "TTL": 1069,
      "data": "93.184.216.34"
    }
  ]
}

Het is duidelijk dat een zeldzame (als er tenminste één) thuisrouter op deze manier met DNS kan werken, maar dit betekent niet dat er morgen geen ondersteuning zal verschijnen - en interessant genoeg kunnen we hier het werken met DNS behoorlijk implementeren in onze applicatie (zoals al Mozilla gaan maken, alleen op Cloudflare-servers).

DNS via TLS

Standaard worden DNS-query's zonder encryptie verzonden. DNS over TLS is een manier om ze via een beveiligde verbinding te verzenden. Cloudflare ondersteunt DNS via TLS op standaardpoort 853 zoals voorgeschreven RFC7858. Dit maakt gebruik van een certificaat dat is uitgegeven voor de cloudflare-dns.com-host, TLS 1.2 en TLS 1.3 worden ondersteund.

Een verbinding tot stand brengen en werken volgens het protocol gaat ongeveer als volgt:

  • Voordat een DNS-verbinding tot stand wordt gebracht, slaat de client een base64-gecodeerde SHA256-hash op van het TLS-certificaat van cloudflare-dns.com (genaamd SPKI)
  • DNS-client brengt een TCP-verbinding tot stand met cloudflare-dns.com:853
  • DNS-client initieert TLS-handshake
  • Tijdens het TLS-handshakeproces presenteert de cloudflare-dns.com-host zijn TLS-certificaat.
  • Zodra een TLS-verbinding tot stand is gebracht, kan de DNS-client DNS-verzoeken via een beveiligd kanaal verzenden, waardoor wordt voorkomen dat verzoeken en antwoorden worden afgeluisterd en vervalst.
  • Alle DNS-query's die via een TLS-verbinding worden verzonden, moeten voldoen aan de DNS verzenden via TCP.

Een voorbeeld van een verzoek via DNS over TLS:

$ kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com  example.com
;; DEBUG: Querying for owner(example.com.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP)
;; DEBUG: TLS, imported 170 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, C=US,ST=CA,L=San Francisco,O=Cloudflare, Inc.,CN=*.cloudflare-dns.com
;; DEBUG:      SHA-256 PIN: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
;; DEBUG:  #2, C=US,O=DigiCert Inc,CN=DigiCert ECC Secure Server CA
;; DEBUG:      SHA-256 PIN: PZXN3lRAy+8tBKk2Ox6F7jIlnzr2Yzmwqc3JnyfXoCw=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted.
;; TLS session (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 58548
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1536 B; ext-rcode: NOERROR
;; PADDING: 408 B

;; QUESTION SECTION:
;; example.com.             IN  A

;; ANSWER SECTION:
example.com.            2347    IN  A   93.184.216.34

;; Received 468 B
;; Time 2018-03-31 15:20:57 PDT
;; From 1.1.1.1@853(TCP) in 12.6 ms

Deze optie lijkt het beste te werken voor lokale DNS-servers die voorzien in de behoeften van een lokaal netwerk of een enkele gebruiker. Toegegeven, met de steun van de standaard is het niet erg goed, maar laten we hopen!

Twee woorden waarin wordt uitgelegd waar het gesprek over gaat

De afkorting DNS staat voor Domain Name Service (dus het zeggen van “DNS-service” is enigszins overbodig, de afkorting bevat al het woord “service”) en wordt gebruikt om een ​​eenvoudige taak op te lossen: begrijpen welk IP-adres een bepaalde hostnaam heeft. Elke keer dat iemand op een link klikt of een adres invoert in de adresbalk van de browser (bijvoorbeeld zoiets als "https://habrahabr.ru/post/346430/"), probeert de menselijke computer erachter te komen welke server een verzoek moet sturen om de inhoud van de pagina op te halen. In het geval van habrahabr.ru zal het antwoord van DNS een indicatie bevatten van het IP-adres van de webserver: 178.248.237.68, en dan zal de browser al proberen contact te maken met de server met het opgegeven IP-adres.

Op zijn beurt bepaalt de DNS-server, na ontvangst van het verzoek “wat is het IP-adres van de host genaamd habrahabr.ru?”, of hij iets weet over de opgegeven host. Als dat niet het geval is, doet het een verzoek aan andere DNS-servers in de wereld en probeert het stap voor stap het antwoord op de gestelde vraag te achterhalen. Als gevolg hiervan worden de gevonden gegevens bij het vinden van het definitieve antwoord naar de client gestuurd die nog steeds op hen wacht, en worden ze opgeslagen in de cache van de DNS-server zelf, waardoor u een soortgelijke vraag de volgende keer veel sneller kunt beantwoorden.

Een veelvoorkomend probleem is dat de DNS-querygegevens in de eerste plaats transparant worden verzonden (waardoor iedereen met toegang tot de verkeersstroom de mogelijkheid heeft om de DNS-query's en de antwoorden die zij ontvangen te isoleren en deze vervolgens voor hun eigen doeleinden te parseren; dit geeft de mogelijkheid om advertenties nauwkeurig te targeten voor een DNS-client, wat behoorlijk veel is!). Ten tweede hebben sommige ISP's (we zullen niet met de vingers wijzen, maar niet de kleinste) de neiging om advertenties weer te geven in plaats van een of andere opgevraagde pagina (wat vrij eenvoudig is geïmplementeerd: in plaats van het opgegeven IP-adres voor een zoekopdracht door habranabr.ru hostnaam, een willekeurige persoon. Zo wordt het adres van de webserver van de provider geretourneerd, waar de pagina met de advertentie wordt weergegeven). Ten derde zijn er aanbieders van internettoegang die een mechanisme implementeren om te voldoen aan de vereisten voor het blokkeren van individuele sites door de juiste DNS-antwoorden over de IP-adressen van geblokkeerde webbronnen te vervangen door het IP-adres van hun server met daarop stubpagina's (als gevolg daarvan wordt de toegang tot dergelijke sites merkbaar ingewikkelder), of naar het adres van uw proxyserver die de filtering uitvoert.

Dit zou waarschijnlijk een foto van de site moeten zijn. http://1.1.1.1/, gebruikt om de verbinding met de dienst te beschrijven. De auteurs lijken behoorlijk veel vertrouwen te hebben in de kwaliteit van hun DNS (het is echter moeilijk om iets anders van Cloudflare te verwachten):

We ontmoeten de service van Cloudflare op de adressen 1.1.1.1 en 1.0.0.1, oftewel “de openbare DNS-plank is gearriveerd!”

Je kunt Cloudflare, de maker van de dienst, volledig begrijpen: ze verdienen hun brood met het onderhouden en ontwikkelen van een van de populairste CDN-netwerken ter wereld (waartoe niet alleen de distributie van inhoud behoort, maar ook het hosten van DNS-zones), en dankzij de wens van degenen, die niet goed op de hoogte is, leer die wie ze niet kennen, op dat waar te gaan in het mondiale netwerk heeft vaak last van het blokkeren van de adressen van hun servers laten we niet zeggen wie - dus het hebben van een DNS die niet wordt beïnvloed door "geschreeuw, fluitjes en krabbels" voor het bedrijf betekent minder schade aan hun bedrijf. En technische voordelen (een kleinigheid, maar leuk: vooral voor klanten van de gratis DNS Cloudflare zal het updaten van de DNS-records van bronnen die op de DNS-servers van het bedrijf worden gehost onmiddellijk plaatsvinden) maken het gebruik van de in het bericht beschreven service nog interessanter.

Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. Inloggen, Alsjeblieft.

Maak jij gebruik van de nieuwe dienst?

  • Ja, door dit simpelweg op te geven in het besturingssysteem en/of op de router

  • Ja, en ik zal nieuwe protocollen gebruiken (DNS over HTTPs en DNS over TLS)

  • Nee, ik heb voldoende huidige servers (dit is een openbare provider: Google, Yandex, etc.)

  • Nee, ik weet niet eens wat ik nu gebruik

  • Ik gebruik mijn recursieve DNS met een SSL-tunnel ernaartoe

693 gebruikers hebben gestemd. 191 gebruiker onthield zich van stemming.

Bron: www.habr.com

Voeg een reactie