Het blijkt dat niet veel mensen weten wat DNSSec is, waar het voor is, waar het niet voor is en of het de moeite waard is om het thuis te implementeren. Omdat er in het Russisch weinig informatie over deze kwestie bestaat, zal ik proberen licht op deze kwesties te werpen.

Bovendien heeft het NSEC3-record een vlaggenveld dat de NSEC niet heeft. Op op dit moment Er is slechts één vlag gedefinieerd: OPT-OUT, waardoor het mogelijk is om niet de hele zone te ondertekenen (wat een zeer langdurig proces kan zijn als de omvang groot is), maar alleen die domeinnamen waarvoor er DS-records zijn.
Aan de ene kant kan OPT-OUT de ondertekeningstijd aanzienlijk verkorten, maar bij gebruik kan de toegang van een aanvaller tot het zonebestand hem in staat stellen een onbeveiligd record toe te voegen, wat in de toekomst voor problemen kan zorgen.

Werkingsmechanisme

Laten we zeggen dat we het adres test.bar.example.com willen weten:

1. Wij vragen de domeinnaam op bij de oplosser;
2. De solver stelt de DO-bit in en vraagt ​​test.bar.example.com aan bij de rootserver;
3. De oplosser weet dat de rootdomeinzone ondertekend is - hij heeft een sleutel of hash van de sleutel ervoor (het zogenaamde trust-anchor), dus vraagt ​​hij de rootserver om DNSKEY-records voor de rootzone en vergelijkt wat hij ontvangt met wat beschikbaar is;
4. De rootserver kent zo'n domeinnaam niet, en over het algemeen weet hij vooral op welke servers de com-zone zich bevindt. Hij rapporteert de adressen van deze servers aan onze solver, samen met een ondertekend DS-record voor de com-zone;
5. De solver valideert het DS-record met de ontvangen en geverifieerde ZSK-rootzonesleutel;
6. Nu weet de oplosser dat de com-zone is ondertekend, dus vraagt ​​hij de DNS-server om DNSKEY en valideert deze, waarna hij informeert naar bar.example.com. Uiteraard weet de server van de com-zone niets van zulke dingen, hij weet alleen dat de example.com-zone op ns.example.com en ns1.example.com leeft, en dit is precies wat hij reageert op de oplosser, samen met - ja, ja - een DS-record;
7. De oplosser heeft dus een vertrouwensketen opgebouwd naar example.com, waar hij de naamservers van de zone bar.example.com en zijn DS herkent;
8. Uiteindelijk ontdekt de oplosser iteratief de adressen van de DNS-servers die verantwoordelijk zijn voor bar.example.com, gaat naar hen toe en krijgt uiteindelijk wat hij wil, valideert alle informatie en geeft ons het adresrecord, waarbij de AD-bit in de antwoord.

Als het onmogelijk is om iets te valideren, retourneert de oplosser servfail.

Effecten

1. Het uitgaande verkeer naar een gezaghebbende DNS-server neemt ongeveer vier keer toe;
2. De grootte van het zonebestand na ondertekening (zonder OPT-OUT) neemt 6-7 keer toe;
3. Het vergroten van de sleutellengte leidt tot een merkbare afname van de qps van de oplosser; dit heeft in mindere mate invloed op de gezaghebbende server;
4. Integendeel, er is een toename van het aantal iteraties bij gebruik van NSEC3;
5. DNSSec resulteert in een aanzienlijke toename van de DNS-respons en daarom is het noodzakelijk dat dit allemaal gebeurt netwerkapparatuur werkte correct met DNS-pakketten groter dan 512 bytes.

Waarom is dit nodig?

Dit is een moeilijke vraag. In de eerste plaats moeten we er rekening mee houden gecreëerde effecten; ten tweede is het noodzakelijk om een ​​betrouwbare sleutelopslag te organiseren; ten derde: toezicht houden op de sleutelrotatie; ten vierde: controleer de vervaldatum van handtekeningen; ten vijfde versterkt DNSSec het effect van versterkte ddos.
Dit alles is een prijs die u moet betalen om vertrouwen te hebben in de informatie die u ontvangt van gezaghebbende DNS-servers. Nu bedenkt de gemeenschap echter wat er nog meer in DNSSec kan worden opgenomen, zodat er inkomsten mee kunnen worden gegenereerd, en sommigen stellen zelfs zeer gedurfde en interessante vragen, bijvoorbeeld Phil Regnauld, een lid van de wetenschappelijke raad van AFNIC, die vroeg “Zal DNSSEC de certificaatindustrie ten val brengen?” op een seminarie van deze raad.

DNSSEC-technologie ontworpen als uitbreiding van het DNS-systeem (Domain Name System) om te beschermen tegen gegevensvervanging. Deze bescherming helpt phishing, cache-vergiftiging en vele andere internetbedreigingen te voorkomen. Het werkingsprincipe van DNSSEC is gebaseerd op het gebruik van digitale handtekeningen en het opbouwen van een vertrouwensketen.

Hoe DNSSEC werkt

DNSSEC maakt voor elk type bronrecord een speciaal digitaal ondertekend bronrecord aan. Het belangrijkste kenmerk van een digitale handtekening is de beschikbaarheid van open, publiek beschikbare methoden om de authenticiteit van de handtekening te verifiëren. Tegelijkertijd vereist het genereren van een handtekening voor willekeurige gegevens dat de ondertekenaar over een handtekening beschikt geheime sleutel. Dienovereenkomstig is handtekeningverificatie beschikbaar voor elke deelnemer aan het systeem, maar het ondertekenen van nieuwe of gewijzigde gegevens is alleen beschikbaar voor degenen die over de geheime sleutel beschikken.

Publieke sleutels worden in de domeinzone gepubliceerd in de vorm van een bronrecord van het type DNSKEY, samen met andere bronrecords. Er wordt gebruik gemaakt van een vertrouwensketen om het openbare deel van de sleutel te verifiëren. De authenticiteit van de sleutel wordt gecontroleerd met behulp van de samenvattingen (vingerafdruk, hash), die eerder in de vorm van DS-records naar de bovenliggende zone zijn verzonden. Publieke sleutelsamenvattingen van bovenliggende zones worden ook naar hun respectieve bovenliggende zones verzonden. Een dergelijke vertrouwensketen wordt opgebouwd tot in de wortelzone openbare sleutel en de samenvattingen ervan worden gepubliceerd in de officiële documenten van ICANN, de organisatie die verantwoordelijk is voor de rootzone.

DNSSEC gebruikt 2 soorten sleutels:

• ZSK (zoneondertekeningssleutel)- sleutel voor het ondertekenen van zonebronrecords;
• KSK (Key Signing-sleutel)- sleutel voor het ondertekenen van sleutels.

Voor elk sleuteltype kunt u het algoritme, de sleutellengte en de updateperiode opgeven. MET gespecificeerde parameters Er worden sleutels voor het ondertekenen van domeinen gegenereerd.

Met de huidige implementatie van DNSSEC-ondersteuning kun je alleen hetzelfde algoritme voor sleutels opgeven.

Een gebruikelijke praktijk is om grotere waarden te kiezen voor de sleutellengte en updateperiode voor KSK in vergelijking met ZSK:

• De ZSK-sleutel wordt elke keer gebruikt als er een bewerking plaatsvindt domein zone of de update ervan. Het gebruik van een korte sleutel maakt het ondertekeningsproces eenvoudiger, waardoor de belasting van de server wordt verminderd korte periode Met ZSK-updates kunt u een hoog beveiligingsniveau handhaven;
• KSK-sleutels worden alleen gebruikt om sleutels te ondertekenen en worden daarom minder vaak gebruikt dan ZSK. Daarom heeft een lange sleutel niet zoveel invloed op de prestaties. Voor een lange sleutel kunt u een lange sleutelvernieuwingsperiode opgeven zonder dat dit ten koste gaat van de veiligheid. Dankzij de lange KSK-updateperiode kunnen DS-records minder vaak naar de bovenliggende zone worden verzonden.

Om te voorkomen dat DNSSEC-sleutels in gevaar komen, wordt er gebruik gemaakt van een sleutelvernieuwingsproces. In overeenstemming met geaccepteerde praktijken (RFC7583 en RFC6781) worden sleutels geleidelijk bijgewerkt om ervoor te zorgen dat secundaire en DNS-cacheservers voldoende tijd hebben om te synchroniseren met primaire server DNS, voorkomt domeinfouten.

Het KSK-updateproces volgt het Double-DS-algoritme:

1. DS-records van de nieuwe KSK-sleutel publiceren in de bovenliggende zone. In ISPmanager wordt de volgende KSK-sleutel direct aangemaakt bij het ondertekenen van een domein of direct na het verwijderen van de oude KSK-sleutel. In dit geval heeft de gebruiker de mogelijkheid om vooraf DS-records van de nieuwe sleutel te publiceren. Voor correcte werking KSK-sleutelupdates in ISPmanager DS-records van de nieuwe sleutel moeten een maand voor het einde van de KSK-sleutelupdate in de bovenliggende zone worden gepubliceerd;
2. Vervanging van de KSK-sleutel. De actieve geldige KSK-sleutel wordt vervangen door een nieuwe KSK-sleutel. In ISPmanager vindt de vervanging 2 weken voor het einde van de KSK-sleutelupdate plaats;
3. DS-records van de oude sleutel in de bovenliggende zone verwijderen. Op dit moment genereert ISPmanager de volgende nieuwe sleutel, waardoor gebruikers tegelijkertijd de benodigde acties in de bovenliggende zone kunnen uitvoeren: DS-records van de oude sleutel verwijderen en DS-records van de volgende nieuwe sleutel toevoegen.

Dubbele DS KSK-rollover

Het ZSK-updateproces volgt het pre-publicatiealgoritme:

1. Creatie en publicatie van een nieuwe ZSK-sleutel in de domeinzone. In ISPmanager wordt dit 2 weken vóór de sleutelwijziging uitgevoerd. De nieuwe sleutel is passief en neemt niet deel aan het ondertekeningsproces van de domeinzone;
2. Vervanging van de ZSK-sleutel. De nieuwe, vooraf gepubliceerde ZSK-sleutel wordt actief. De voorheen geldige ZSK-sleutel wordt passief en neemt niet langer deel aan het ondertekeningsproces;
3. Het verwijderen van de oude passieve ZSK-sleutel. De actie wordt uitgevoerd 2 weken na het vervangen van de ZSK-sleutel.

pre-publiceer ZSK Rollover

DNSSEC-ondersteuning inschakelen

DNSSEC-ondersteuning is beschikbaar voor DNS-servers:

• Binden, vanaf versie 9.8.4;
• PowerDNS, vanaf versie 3.2.

Let op: de standaardrepository van Debian 7 is PowerDNS versie 3.1. Let op: PowerDNS vóór versie 4 ondersteunt CAA-records niet volledig. Daarom kan het ondertekenen van een domein met behulp van DNSSEC op een DNS-server met PowerDNS versie 4 of eerder ertoe leiden dat CAA-records niet beschikbaar zijn.

Het inschakelen van DNSSEC-ondersteuning en het opgeven van instellingen voor het genereren van sleutels voor een domein gebeurt in sectie "Domeinen" -> "Domeinnamen" -> selecteer een domein-> knop "Instellingen"-> optie inschakelen "DNSSEC-ondersteuning". De mogelijkheid om DNSSEC-ondersteuning in te schakelen is alleen beschikbaar voor gebruikers met beheerderstoegangsniveau.

DNSSEC-sleutelinstellingen

• DNSSEC-ondersteuning- optie met DNSSEC-functionaliteit voor de domeinzone;
• Sleutelhandtekeningsleutel (KSK):
  • Algoritme- KSK-algoritme voor het genereren van sleutels:
    • Verouderde algoritmen:
      • 5 - RSA/SHA-1;
      • 7 -RSASHA1-NSEC3-SHA1;
    • Moderne algoritmen:
      • 8 - RSA/SHA-256;
      • 10 - RSA/SHA-512;
      • 12 - GOST R 34.10-2001;
    • Nieuwste algoritmen:
  • Sleutel lengte- lengte van de KSK-sleutel. Aangegeven in bits;
  • Updateperiode
• Zone-ondertekeningssleutel (ZSK):
  • Algoritme- ZSK-algoritme voor het genereren van sleutels. Moet overeenkomen met het KSK-algoritme voor het genereren van sleutels:
    • Verouderde algoritmen:
      • 5 - RSA/SHA-1;
      • 7 -RSASHA1-NSEC3-SHA1;
    • Moderne algoritmen:
      • 8 - RSA/SHA-256;
      • 10 - RSA/SHA-512;
      • 12 - GOST R 34.10-2001;
    • Nieuwste algoritmen:
      • 13 - ECDSA-curve P-256 met SHA-256;
      • 14 - ECDSA-curve P-384 met SHA-384.
  • Sleutel lengte- ZSK-sleutellengte. Aangegeven in bits;
  • Updateperiode- de periode waarna een nieuwe sleutel wordt gegenereerd. Aangegeven in maanden.

E-mailmeldingen

Om DNSSEC-beveiliging in te schakelen en te behouden, moet u DS-records in de bovenliggende zone handmatig publiceren en bijwerken. Met DNSSEC-mailmeldingen kunt u meldingen instellen over nieuwe DS-records die moeten worden gepubliceerd.

Om meldingen te ontvangen moet u de optie inschakelen "Meldingen van DNSSEC DNS-serverextensie" in sectie "Instellingen" -> "E-mailmeldingen".

DNSSEC-mailmeldingen

Schakel DNSSEC-beveiliging in voor een domein

Het algoritme om DNSSEC-bescherming voor een domein in te schakelen bestaat uit de volgende stappen:

• het controleren van de maximale TTL-waarde in de domeinzone;
• domeinzoneondertekening;
• het creëren van een keten van vertrouwen.

Het controleren van de maximale TTL-waarde in een domeinzone

Om sleutels correct te updaten, moet de maximale TTL-waarde in de domeinzone minder dan 2 weken zijn. De standaard TTL-zone is 3 uur.

De maximale TTL-waarde in de domeinzone wordt aangegeven in sectie "Domeinen" -> "Domeinnamen" -> selecteer een domein-> knop "Records"-> kolom "TTL, sec".

Een domeinzone ondertekenen

Domeinzoneondertekening wordt uitgevoerd in sectie "Domeinen" -> "Domeinnamen" -> selecteer een domein-> knop "Wijziging"-> optie inschakelen "Domein ondertekenen".

Een domeinzone ondertekenen

Na het toepassen van de wijzigingen begint het achtergrond proces domeinzoneondertekening. Tijdens het proces worden KSK en ZSK gegenereerd volgens gegeven parameters. Op het moment van ondertekening staat de domeinzone in de kolom "Staat" er wordt een handtekeningmeldingspictogram weergegeven en bewerkingen voor het domein worden geblokkeerd "Wijziging" En "Verwijderen".

Na een paar seconden moet je de pagina vernieuwen "Domeinnamen".

Na succesvolle ondertekening van de domeinzone:

• in kolom "Staat" meldingspictogram wordt weergegeven;
• banner wordt weergegeven "Er zijn ongepubliceerde DS-records";
• knop "DNSSEC" wordt actief voor het domein.

Ondertekening van domeinzones is beschikbaar voor gebruikers met het toegangsniveau 'Gebruiker' en hoger.

Het creëren van een keten van vertrouwen

Om een ​​vertrouwensketen te creëren, moet u DS-records (soms, afhankelijk van de registrar, ook KSK DNSKEY-records) overbrengen naar de bovenliggende zone. Informatie over de belangrijkste parameters van sleutels en hun DNSKEY- en DS-records wordt op de pagina weergegeven "DNSSEC-instellingen": sectie "Domeinen" -> "Domeinnamen" -> selecteer een domein-> knop "DNSSEC".

DNSSEC-instellingen

• DNSSEC-status- DNSSEC-status;
• Sleutelalgoritme- algoritme voor het genereren van KSK- en ZSK-sleutels;
• KSK-parameters:
  • Datum van sleutelupdate- datum van generatie van de huidige KSK-sleutel;
  • Updateperiode (maanden)- de periode waarna een nieuwe sleutel wordt gegenereerd. Aangegeven in maanden;
  • Sleutel lengte- lengte van de KSK-sleutel, in bits.
• DS-records- DS-records in de domeinzone. De authenticiteit van de sleutel wordt gecontroleerd met behulp van de samenvattingen (vingerafdruk, hash), die eerder in de vorm van DS-records naar de bovenliggende zone zijn verzonden.

Voor elke vermelding in de lijst met DS-vermeldingen worden de volgende gegevens weergegeven:

• Begin met opnemen- start van DS-opname;
• Label- KSK-sleutelidentificatie;
• Algoritme
• Digest-type- identificatie van het digesttype;
• Verteren- inhoud van de samenvatting.

• DNSKEY tonen- als u op de knop drukt, wordt de tabel met DNSKEY-records weergegeven. Voor elke vermelding in de lijst met DNSKEY-vermeldingen worden de volgende gegevens weergegeven:

• Begin met opnemen- begin van het DNSKEY-record;
• Vlaggen- sleuteltype-identificatie;
• Protocol- DNSSEC-protocolnummer;
• Algoritme- identificatie van het versleutelingsalgoritme;
• Openbare sleutel- open een deel van de sleutel;
• Label- KSK-sleutelidentificatie.

De overdracht van DS-records vindt op een van de volgende manieren plaats:

1. Records toevoegen via de webinterface van het domeincontrolepaneel bij de domeinnaamregistrar. U moet DS-records kopiëren vanuit ISPmanager. Als de registrarrecords in de vorm van strings worden toegevoegd, moet u de waarden van alle kolommen uit de DS-recordstabel in ISPmanager combineren en spaties ertussen invoegen.
2. Als de domeinzone zich samen met de bovenliggende zone (een zone één niveau hoger) bevindt op dezelfde server waarop ISPmanager of DNSmanager draait, dan op de pagina "DNSSEC-instellingen" knop domein beschikbaar "DS-records overbrengen naar bovenliggende zone". Door op deze knop te drukken, verzendt het paneel DS-records.
3. Als het domein dat wordt ondertekend het bovenliggende domein is van een domein dat zich op een server van derden bevindt, worden de DS-records van het onderliggende domein aangemaakt in de records van het bovenliggende domein, net als de rest. bronrecords.

Als de sleutels gecompromitteerd zijn, is het noodzakelijk om de domeinzone opnieuw te ondertekenen met nieuwe sleutels. Om dit te doen, moet u DNSSEC-beveiliging voor het domein uitschakelen:

• verwijder alle DS-records uit de bovenliggende domeinzone en wacht een paar uur;
• verwijder de handtekening van de domeinzone: sectie "Domeinen" -> "Domeinnamen" -> selecteer een domein-> knop "Wijziging"-> optie inschakelen "Handtekening verwijderen".

Het uitschakelen van domeinbeveiliging is beschikbaar voor gebruikers met het toegangsniveau 'Gebruiker' en hoger

DNSSEC-ondersteuning uitschakelen

Voordat u DNSSEC-ondersteuning uitschakelt, moet u de DS-records van alle ondertekende domeinen uit hun bovenliggende zones verwijderen. Anders zullen domeinnamen niet meer werken.

Het uitschakelen van DNSSEC-ondersteuning voor een domein doet u in sectie "Domeinen" -> "Domeinnamen"-> knop "Instellingen"-> optie uitschakelen "DNSSEC-ondersteuning". De mogelijkheid om DNSSEC-ondersteuning uit te schakelen is alleen beschikbaar voor gebruikers met beheerderstoegangsniveau.

Nadat de wijzigingen zijn bevestigd, worden alle domeinen afgemeld en worden alle sleutels verwijderd.

Beperkingen

Bij gebruik van DNSSEC nemen de pakketgroottes toe. Let op:

• Bij overschrijding van 512 bytes gebruikt DNS het TCP-protocol. Op sommige routers DNS-werk via TCP-protocol kan worden uitgeschakeld (poort 53 is gesloten);
• Wanneer de MTU-grootte wordt overschreden, worden DNS-pakketten gefilterd. MTU is de maximale grootte van een bruikbare data-eenheid van één pakket die zonder fragmentatie kan worden verzonden. Een gebruikelijke MTU-grootte is 1500 bytes.

Dit formulier is geen ondersteuningsverzoek.
Wij kunnen u niet identificeren of reageren op uw bericht.

DNS-naamomzettingssystemen, die een van de fundamenten vormen van het moderne netwerkcommunicatiesysteem, werden meer dan twintig jaar geleden ontwikkeld, toen er nog vrijwel geen aandacht werd besteed aan informatiebeveiligingskwesties. Een van de belangrijkste nadelen van het DNS-systeem is de mogelijkheid om het antwoord op een DNS-verzoek te vervalsen.

Het probleem is dat de authenticiteit van de DNS-serverreactie op geen enkele manier wordt gecontroleerd, wat betekent dat u in het geval van een hack van een DNS-server (en het omleiden ervan naar valse DNS-servers), vervalsing van DNS-records, DNS-cachevergiftiging, de gebruiker naar een willekeurig IP-adres, en de gebruiker zal er volledig op kunnen vertrouwen dat hij met een legitieme site of dienst werkt. Deze technieken worden op grote schaal gebruikt door aanvallers, die gebruikers omleiden naar sites die kwaadaardige codes bevatten of hun persoonlijke gegevens (wachtwoorden, creditcardnummers, enz.) verzamelen met behulp van zogenaamde. pharming-aanvallen.

Waarom hebben we DNSSEC-technologie nodig?

DNS-beveiligingsextensies (DNSSEC)– een technologie die is ontworpen om de veiligheid van de DNS-service te verbeteren door het gebruik van cryptografische handtekeningen waarmee iemand op unieke wijze de authenticiteit kan verifiëren van de informatie die wordt ontvangen van de DNS-server. Die. Alle vragen en antwoorden van een DNSSEC-compatibele DNS-server moeten digitaal ondertekend zijn, waarvan de authenticiteit door de client kan worden geverifieerd met behulp van een openbare sleutel. Deze digitale handtekeningen worden aangemaakt wanneer een zone wordt ondertekend (er wordt DNSSEC op toegepast).

Vereenvoudigd werkt het DNSSEC-verificatiemechanisme als volgt: de client stuurt een verzoek naar de DNS-server, de server retourneert een DNS-antwoord met een digitale handtekening. Omdat de client beschikt over de openbare sleutel van de certificeringsinstantie die de DNS-records heeft ondertekend, kan de handtekening (hashwaarde) ontsleutelen en het DNS-antwoord verifiëren. Om dit te doen, moeten zowel de client als de DNS-server worden geconfigureerd om hetzelfde vertrouwensanker te gebruiken. Vertrouwen anker– een vooraf geconfigureerde openbare sleutel die is gekoppeld aan een specifieke DNS-zone. Als de DNS-server meerdere zones ondersteunt, kunnen meerdere trust anchors worden gebruikt.

Het is belangrijk op te merken dat het hoofddoel van DNSSEC het beschermen is tegen vervalsing en wijziging van DNS-verzoeken en -antwoorden. Maar de gegevens zelf die via het netwerk worden verzonden, zijn niet gecodeerd (hoewel de vertrouwelijkheid van de verzonden DNS-gegevens kan worden gewaarborgd met behulp van codering, maar dit is optioneel en niet het hoofddoel van DNSSEC).

De belangrijkste componenten van DNSSEC zijn gedefinieerd in volgende normen RFC:

• RFC4033
• RFC4034
• RFC4035

DNSSEC op Windows-systemen

Ondersteuning voor DNSSEC-technologie verscheen in Windows-server 2008 R2 en Windows 7. Vanwege de complexiteit en niet voor de hand liggend van de instellingen werd het echter niet veel gebruikt. DNSSEC kreeg zijn verdere ontwikkeling in Windows Server 2012, waarin de functionaliteit van DNSSEC aanzienlijk werd uitgebreid en configuratie via een grafische interface mogelijk maakte.

In dit artikel beschrijven we de basisinstallatie en configuratie van DNSSEC op basis van een DNS-server met Windows Server 2012, waarbij een ondertekende zone en vertrouwenspunten worden aangemaakt.

DNSSEC installeren en configureren in Windows Server 2012

Laten we creëren nieuwe DNS zone dnssec.contoso.com en voeg er één A-record van de SRV12-server aan toe met het adres 192.168.1.14.

Opmerking. In Windows 8/2012 is het beter om in plaats van het hulpprogramma nslookup informatie van de DNS-server te verkrijgen, de Powershell-cmdlet Resolve-DnsName te gebruiken.

Resolve-DnsName srv12.dnssec.contoso.com –Server SRV12-SUB-CA –DnssecOk

Omdat de zone is niet ondertekend, het verzoek retourneert geen RRSIG-records.

Laten we de interne DNS-zone dnssec.contoso.com ondertekenen met een digitaal certificaat. Om dit te doen, klikt u in de DNS-console op klik met de rechtermuisknop per zone en selecteer DNSSEC->Onderteken de zone.

In de Zone Signing Wizard die verschijnt, laat u alle standaardinstellingen staan ​​(Gebruik standaardinstellingen om de zone te ondertekenen) -> Volgende -> Volgende -> Voltooien.

Nadat de wizard is voltooid, worden de volgende nieuwe bronrecords automatisch aangemaakt in de ondertekende zone:

• RRSIG (Resource Read Signature) - handtekening van bronrecord
• DNSKEY (een openbare sleutel) – slaat het openbare deel van de sleutel en zijn identificatiegegevens op
• DS (Delegation Signer) – bevat een hash van de domeinnaam van de erfgenaam en de KSK-sleutel
• NSEC (Next Secure) en NSEC3 (Next Secure 3) – gebruikt voor betrouwbare bescherming van spoofing-aanvallen

Zodra de zone is ondertekend, wordt de openbare sleutel opgeslagen in het bestand %windir%\system32\dns\keyset-dnssec.

We importeren de openbare sleutel van de zone (hetzelfde vertrouwensanker) in DNS door naar de sectie Vertrouwenspunt in de DNS-console te gaan, import -> DNSKEY te selecteren en het pad naar de sleutelset-dnssec op te geven.

Opmerking. Deze sleutel moet worden gedistribueerd naar alle DNS-servers die zullen deelnemen aan het proces van veilige caching van ondertekende zonegegevens.

Als gevolg van het importeren van de sleutel verschijnen er twee sleutels van het type DNSKEY in de sectie Trust Points -> dnssec (de ene sleutel is actief, de andere is stand-by).

In Windows Server 2012 is het mogelijk om automatisch Trust Anchors-sleutels te repliceren over alle domeincontrollers in het forest dat een bepaald domein bedient. DNS-zone. Om dit te doen, gaat u naar de eigenschappen van de gewenste zone (dnssec) op het tabblad Vertrouwen anker schakel de optie in Schakel de distributie van vertrouwensankers in voor deze zone en sla de wijzigingen op.

Laten we proberen deze zone opnieuw bij de client te ondervragen.

Zoals we kunnen zien, bevat het antwoord van de DNS-server informatie over het RRSIG-record en de digitale handtekening.

WIndows-clients configureren om DNSSEC te gebruiken

Om Windows-clients te dwingen alleen "beveiligde" (DNSSEC)-query's te gebruiken, d.w.z. accepteren DNS-gegevens alleen als hun digitale handtekening correct is, is het nodig om het GPO te gebruiken om het NRPT-beleid (Name Resolution Policy Table) in te schakelen.

Voor dit doel in GPO-sectie Computerconfiguratie -> Beleid -> Windows-instellingen -> Naamresolutiebeleid op het tabblad DNSSEC opties inschakelen:

• Schakel DNSSEC in deze regel in
• Vereisen dat DNS-clients controleren of naam- en adresgegevens zijn gevalideerd door de DNS-server

Het enige dat overblijft is het beleid toewijzen aan de gewenste OE. Zorg er na het toepassen van het beleid voor dat de client is geconfigureerd om “beveiligde” DNS te gebruiken:

Get-DnsClientNrptPolicy

Betekenis DNSSecValidationRequired=Waar, d.w.z. Verplichte validatie van DNS-antwoorden is vereist op de client.

Als het antwoord dat wordt ontvangen van de DNS-server niet is ondertekend of is ondertekend met het verkeerde certificaat, retourneert de opdracht een fout Onbeveiligd DNS-pakket.

DNSSEC voor externe zones

Om ervoor te zorgen dat de DNS-server een verplichte DNSSEC-controle voor externe zones vereist, moet u naar de eigenschappen op het tabblad gaan Geavanceerd optie inschakelen Schakel DNSSEC-validatie in voor reacties op afstand.

U kunt vertrouwensankers in de rootzone handmatig importeren (hierboven beschreven) of met behulp van de opdracht:

Dnscmd /RetrieveRootTrustAnchors

Advies. Om DNSSEC correct te laten werken, is het noodzakelijk om een ​​aantal wijzigingen aan firewalls door te voeren:

1. Open poort 53-poort van TCP- en UDP-protocollen in beide richtingen
2. Omdat de gegevensgrootte in het DNSSec-pakket groter is dan 512 bytes, het is noodzakelijk om DNS-pakketten groter dan 512 bytes door UDP en TCP te laten passeren

De Domain Name and IP Address Management Corporation, ICANN, waarschuwt voor mogelijke verstoringen in het wereldwijde netwerk als gevolg van een update van de encryptiesleutel voor verzoeken om resolutieservers een naam te geven die het DNSSEC-protocol gebruiken, aldus een persbericht van ICANN.

DNSSEC-coderingssleutels worden voor het eerst bijgewerkt sinds het systeem op 15 juli 2010 werd gelanceerd, toen de rootzone, ook wel een “punt” genoemd, werd ondertekend, dat wil zeggen de zone boven topniveaudomeinen zoals . com., .ru., .org. en andere (in browserinterfaces wordt de laatste punt meestal weggelaten). De beslissing om de "Key Signing Key" of KSK voor de rootzone opnieuw uit te geven, werd verschillende keren uitgesteld; het oorspronkelijke plan was dat de rootzone om veiligheidsredenen elke vijf jaar opnieuw zou worden ondertekend - de eerste sleutelvervanging was gepland 2015. De zorg van ICANN is dat niet alle DNSSEC-compatibele DSN-servers zullen overstappen op het gebruik van de nieuwe encryptiesleutel: servers die ooit zijn geconfigureerd hebben mogelijk al die tijd correct gewerkt, maar hun eigenaren hebben misschien niet aan de mogelijkheid gedacht om de KSK te updaten.

Een eenvoudige DNSSEC-configuratieservice voor domeineigenaren uit het Russische segment, dat wil zeggen in de ru-, “рф”- en su-zones, wordt aangeboden door slechts drie registrars, die ook hun eigen DNS-servers bezitten: nic.ru, reg.ru en webnamen.ru. Tot nu toe is het protocol niet bijzonder populair: van de 5,6 miljoen Russische domeinen was het aantal domeinen met DNSSEC-ondersteuning volgens statistieken van het “Coördinatiecentrum” dat de Russische zones reguleert, in september 2018 niet hoger dan 3.000, ook al omvatten ze de grootste en meest populaire bronnen Runet. Tegelijkertijd ondersteunt de populairste dienst onder Russische domeineigenaren, Yandex Connect, DNSSEC niet, hoewel Yandex.DNS wel ondersteuning biedt voor een veilig protocol voor thuisgebruikers. In de mondiale domeinruimte zijn er ordes van grootte meer domeinen die DNSSEC gebruiken: volgens statdns, van de 135 miljoen domeinen in één zone alleen com-domein er zijn bijna een miljoen namen met DNSSEC.

In UPgrade-opmerkingen verklaarden alle drie de Russische registrars die DNSSEC ondersteunen dat ze klaar zijn om KSK te veranderen huidige moment ze werken met de oude sleutel erin actieve modus, en met een nieuwe sleutel, waarvan het publieke deel op 11 september 2017 door ICANN in passieve modus werd gepubliceerd. Op bevel van ICANN staan ​​registrars klaar om de status van sleutels te wijzigen en verwachten ze geen fouten. Grootste houders eigen servers toestemming van domeinnamen die niet afkomstig zijn van de registrars Rostelecom, Megafon, Beeline en MTS, verklaarden in opmerkingen aan RBC dat zij ook bereid waren de sleutel te wijzigen. Het is echter onmogelijk te voorspellen of de KSK-wijziging zal leiden tot storingen voor eigenaren van kleinere DNS-servers, bijvoorbeeld voor providers in kleine steden, hoewel ICANN actief samenwerkt met technische beheerders providers, telecomoperatoren en andere bedrijven die rechtstreeks met de internetinfrastructuur werken.

De dienst DNS of Domain Name System werd vrijwel gelijktijdig met de introductie van domeinen in de jaren tachtig ontwikkeld. Wanneer u via de DNS-service toegang krijgt tot een domeinnaam (bijvoorbeeld een website), vindt de internetprovider het IP-adres (bijvoorbeeld 87.236.16.85) dat overeenkomt met de domeinnaam. Domeineigenaren geven zogenaamde “resource records” aan (bijvoorbeeld *A 87.236.16.85) op hun eigen DNS-servers (bijvoorbeeld ns1.beget.com). Andere DNS-servers kopiëren deze records in de loop van de tijd en maken er een cache van om niet elke keer contact op te nemen met de oorspronkelijke server. Vóór de introductie van DNSSEC vertrouwden DNS-servers onvoorwaardelijk elkaars informatie, waardoor ze kwetsbaar werden voor aanvallen van aanvallers om “de cache te vergiftigen”, dat wil zeggen om een ​​“vertrouwende” DNS-server te voorzien van een record dat het IP-adres vervangt door het adres van de aanvaller. . Bezoekers van grote bronnen, online banken, sociale netwerken, zoekdiensten en andere sites kunnen dus worden omgeleid naar een nepbron.

Om DNS-cachevergiftiging en andere bedreigingen te helpen elimineren, zijn “DNS Security Extensions” of DNS Security Extensions, of DNSSEC, ontwikkeld. De implementatie van het uitgebreide protocol werd vertraagd vanwege het beslag op de rekenkracht van servers en de hoge belasting van netwerken. Vereenvoudigd DNSSEC–bis-protocol met achterwaarts compatibel met het DNS-systeem werd een cascade geïntroduceerd van minder rekenintensief elektronische certificaten van de rootzone tot individuele domeinen die DNS-servers bij elk verzoek direct konden controleren op authenticiteit. De KSK van de rootzone vereist periodieke updates: de 1024-bits sleutel KSK-2010, gemaakt in 2010, werd in 2017 gecompliceerd tot de 2048-bits KSK-2017 als reactie op een toename van de rekenkracht van de wereld, wat voldoende zou kunnen zijn om het cijfer te selecteren.

We weten allemaal dat DNS een protocol is dat oplossingen biedt domeinnaam s naar IP-adressen, maar hoe weten we de authenticiteit van het geretourneerde IP-adres? Het is mogelijk dat een aanvaller met een DNS-antwoord knoeit of de DNS-cache vergiftigt en gebruikers naar een kwaadwillende site leidt met de legitieme domeinnaam in de adresbalk. DNS Security Extensions (DNSSEC) is een specificatie die tot doel heeft de gegevensintegriteit van DNS-antwoorden te behouden. DNSSEC ondertekent alle DNS-bronrecords (A, MX, CNAME etc.) van een zone met behulp van PKI (Public Key Infrastructure). Nu maakt DNSSEC DNS-resolvers mogelijk (zoals Google Openbare DNS) kan de authenticiteit van een DNS-antwoord (dat een IP-adres bevat) verifiëren met behulp van het openbare DNSKEY-record.

DNSSEC-bronrecords

Een Resource Record (RR) bevat specifieke informatie over het domein. Enkele veel voorkomende zijn een record dat het IP-adres van het domein bevat, een AAAA-record dat de IPv6-informatie bevat, en een MX-record dat mailservers van een domein bevat. U kunt een volledige lijst met DNS RR's vinden.

Op dezelfde manier vereist ook DNSSEC verschillende RR's.

• DNSKEY Bevat de openbare sleutel die de oplossers gebruiken om te verifiëren.
• RRSIG Bestaat voor elke RR en bevat de digitale handtekening van een record.
• DS- Delegation Signer – dit record bestaat op de naamservers van de TLD. Dus als example.com uw domeinnaam was, is de TLD "com" en zijn de naamservers a.gtld-servers.net. , b.gtld-servers.net .up naar m.gtld-servers.net Het doel van dit record is om de authenticiteit van de DNSKEY zelf te verifiëren.

Omgeving instellen

Domeinnaam: voorbeeld.com

Ik heb hiervoor een echt .COM-domein gebruikt, maar heb dit vervangen door voorbeeld.com voor dit artikel.

Hoofdnaamserver:
IP-adres: 1.1.1.1
Hostnaam: master.voorbeeld.com
Besturingssysteem: Debian7

Slave-naamserver:
IP-adres: 2.2.2.2
Hostnaam: slaaf.voorbeeld.com
Besturingssysteem: CentOS

Bestandslocaties en namen

De namen en locaties van configuratie- en zonebestanden van BIND verschillen afhankelijk van de gebruikte Linux-distributie.

Debian/Ubuntu

Servicenaam:
binden9
Hoofdconfiguratiebestand:
/etc/bind/named.conf.options
Bestand met zonenamen:
/etc/bind/named.conf.local
Standaardzonebestandslocatie:
/var/cache/bind/

CentOS/Fedora

Servicenaam:
genoemd
Hoofdconfiguratie- en zonenamenbestand:
/etc/named.conf
Standaardzonebestandslocatie:
/var/naam/

Deze kunnen veranderen als je bind-chroot gebruikt. Voor deze tutorial heb ik Debian voor de Master NS en CentOS voor de Slave NS gebruikt, dus verander het volgens je distributie.

DNSSEC-masterconfiguratie

Schakel DNSSEC in door de volgende configuratie-instructies toe te voegen aan options( )

nano /etc/bind/named.conf.options

Dnssec-enable ja; dnssec-validatie ja; dnssec-lookaside auto;

Het is mogelijk dat deze in sommige distributies al zijn toegevoegd. Navigeer naar de locatie van uw zonebestanden.

Cd /var/cache/bind

Maak een Zone Signing Key (ZSK) met de volgende opdracht.

Dnssec-keygen -a NSEC3RSASHA1 -b 2048 -n ZONE voorbeeld.com

De eerste tool is eenvoudig, terwijl de tweede je een visuele weergave van dingen geeft. Hier is een screenshot van de eerste tool.

Let op de regels die ik heb gemarkeerd. De eerste vermeldt de Sleutellabel waarde (62910) van het DS-record terwijl de tweede sleutel id(40400) van het DNSKEY-record dat de ZSK (Zone Signing Key) bevat.

Zonerecords wijzigen

Elke keer dat u de zone bewerkt door records toe te voegen of te verwijderen, moet deze worden ondertekend om deze te laten werken. We zullen hier dus een script voor maken, zodat we niet elke keer lange commando's hoeven te typen.

Root@master# nano /usr/sbin/zonesigner.sh #!/bin/sh PDIR=`pwd` ZONEDIR="/var/cache/bind" #locatie van uw zonebestanden ZONE=$1 ZONEFILE=$2 DNSSERVICE="bind9 " #Op CentOS/Fedora vervang je dit door "named" cd $ZONEDIR SERIAL=`/usr/sbin/named-checkzone $ZONE $ZONEFILE | egrep -ho "(10)"` sed -i "s/"$SERIAL"/"$(($SERIAL+1))"/" $ZONEFILE /usr/sbin/dnssec-signzone -A -3 $(head -c 1000 /dev/random | cut -b 1-16) -N verhoging -o $1 -t $2 service $DNSSERVICE cd opnieuw laden $PDIR

Sla het bestand op en maak het uitvoerbaar.

Root@master# chmod +x /usr/sbin/zonesigner.sh

Wanneer u records wilt toevoegen of verwijderen, bewerkt u de example.com.zone en NIET het .signed-bestand. Dit bestand zorgt ook voor het verhogen van de seriële waarde, dus u hoeft dit niet elke keer te doen als u het bestand bewerkt. Voer na het bewerken het script uit door de domeinnaam en de zonebestandsnaam als parameters door te geven.

Root@master# zonesigner.sh voorbeeld.com voorbeeld.com.zone

U hoeft niets te doen op de slave-naamserver, aangezien het verhoogde serienummer de zone zal garanderen als deze wordt overgedragen en bijgewerkt.

Het beveiligen van de DNSSEC-installatie tegen Zone Walking

Zone Walking is een techniek die wordt gebruikt om alle bronrecords van een zone te vinden door de NSEC(Next-Secure)-record. NSEC3 werd vrijgegeven, die deze informatie "hashte" met behulp van een salt. Denk aan de opdracht dnssec-signzone waarin we een optie -3 specificeerden, gevolgd door een andere uitgebreide opdracht om een ​​willekeurige reeks te genereren. Dit is het zout dat kan worden gevonden met behulp van de volgende opzoekquery.

# dig NSEC3PARAM voorbeeld.com. @master.voorbeeld.com. +kort 1 0 10 7CBAA916230368F2

Dit alles maakt het wandelgebied lastig maar niet onmogelijk. Een vastberaden hacker die regenboogtabellen gebruikt, kan de hash breken, maar dat zal lang duren. Om dit te voorkomen kunnen we deze salt met regelmatige tussenpozen opnieuw berekenen, wat de poging van een hacker nutteloos maakt omdat er een nieuwe salt voor hem/haar ligt. kan de hasj met het oude zout vinden. Maak een cronjob om dit voor u te doen met behulp van de zonesigner.sh script dat we eerder hebben gemaakt. Als u de cronjob als root uitvoert, hoeft u zich geen zorgen te maken over het eigendom van het bestand. Of zorg er anders voor dat de gebruiker onder wie u de cron plaatst schrijfrechten voor de zonemap En leesrechten op de privésleutels(Kvoorbeeld.com.*.privé).

Root@master:~# crontab -e 0 0 */3 * * /usr/sbin/zonesigner.sh voorbeeld.com voorbeeld.com.zone

Hierdoor wordt de zone elke 3 dagen ondertekend en als resultaat wordt er nieuw zout gegenereerd. U ontvangt ook een e-mail met de uitvoer van de opdracht dnssec-signzone.