DNS management software

by admin6721

DNS-beheersoftware is computersoftware die Domain Name System (DNS) -serverclusters bestuurt. DNS-gegevens worden doorgaans op meerdere fysieke servers geïmplementeerd. De belangrijkste doelen van DNS-beheersoftware zijn:

  • om menselijke fouten te verminderen bij het bewerken van complexe en repetitieve DNS-gegevens
  • om de inspanning te verminderen die nodig is om DNS-gegevens te bewerken
  • om DNS-gegevens te valideren voordat ze op de DNS-servers worden gepubliceerd
  • om de distributie van DNS-gegevens te automatiseren

Achtergrond

In 1995 bestonden er slechts 70.000 domeinen. De manier om ze te registreren was per e-mail en de manier om ze te publiceren was BIND. Medio 1997 bedroeg het aantal domeinen 1,3 miljoen. Naarmate het aantal domeinen en internethosts omhoog schoot, nam ook de hoeveelheid DNS-gegevens en de tijd die nodig was om deze te beheren toe. Sysadmins reageerde door Perl- of Shell-scripts te schrijven die hielpen bij het automatiseren van DNS-wijzigingen. Deze scripts waren meestal in-house tools. Het dichtst bij algemeen beschikbare DNS-beheersoftware was de BIND-module in webmin, die webtools bood voor het bewerken van BIND-zonebestanden.

Eind jaren negentig overweldigde de enorme hoeveelheid DNS-gegevens de beschikbare tools om deze te beheren. De kosten voor het beheer van de gegevens veroorzaakten de geboorte van DNS-beheersoftware. De kosten kunnen het beste worden toegelicht door middel van illustratie. In 1998 hadden drie van de grootste webhostingbedrijven (HostPro, Interland en Vservers) elk ongeveer 100.000 DNS-zones. DNS-wijzigingen zijn aangebracht door te telnetten naar een BIND-master en zonebestanden te bewerken met een teksteditor. Een staf van verschillende DNS-beheerders heeft deze taak de hele dag, elke dag uitgevoerd. Hun wijzigingen worden pas van kracht na een BIND-herlaadbeurt. Omdat schijven traag waren, duurde het enkele uren voordat BIND een volledige herlaadbeurt had uitgevoerd. Als een DNS-beheerder een typefout maakte in een zonebestand, zou BIND dat bestand niet parseren en sterven. Vaak na urenlange verwerking. Wie merkte dat BIND niet actief was, zou de logboeken moeten lezen, het zonebestand met de fout moeten zoeken, het bestand handmatig moeten bekijken, de fout moeten oplossen en dan proberen BIND opnieuw te starten. Als de wijzigingen eenmaal zijn doorgevoerd, kunnen ze via zoneoverdrachten worden doorgegeven aan de DNS-slaven. Het kostte vaak meer dan 24 uur om wijzigingen door te voeren.

DNS en databases

Terwijl ze worstelden met de uitdagingen van het bewerken van zonebestanden, merkten meer dan een paar systeembeheerders op dat SQL een geweldige plek is om DNS-gegevens op te slaan. Door de Single Source of Truth van tekstbestanden naar SQL te verplaatsen, konden DNS-gegevens worden gevalideerd en beperkt voordat ze in de database werden geaccepteerd. Exportscripts kunnen de SQL converteren naar zonebestanden. Rsync kan named-xfer vervangen voor distributie, waardoor de beveiliging toeneemt en de propagatietijd wordt verkort. Bij grote hostingproviders werd het modieus om DNS-gegevens op te slaan in SQL en een aangepaste interface te bouwen voor het beheer ervan. mysqlBind is zo’n DNS-manager. Het biedt een webinterface voor gegevensinvoer en exporteert de gegevens naar BIND-zonebestanden.

In 2000 bracht Daniel J Bernstein Djbdns uit. Een van de nieuwe kenmerken was dat tinydns, de meegeleverde gezaghebbende DNS-server, DNS rechtstreeks vanuit een CDB-database bediende. De cdb moest worden samengesteld uit een gewoon tekstbestand waarvan het formaat was ontworpen om te worden bewerkt door scripts. Tinydns werd al snel de op één na populairste DNS-server en er werden een aantal DNS-managers voor vrijgegeven, waaronder: VegaDNS, SuaveDNS en NicTool.

In 2005 werd PowerDNS uitgebracht. Een van de functies was de mogelijkheid om DNS-gegevens rechtstreeks vanuit de SQL-database te leveren, waarbij de exportstap volledig werd omzeild. PowerDNS heeft ook een aantal DNS-managers voortgebracht die webinterfaces bieden voor de SQL-gegevensopslag.

DDNS

Met behulp van het RFC2136 DDNS-updateprotocol is het mogelijk om DNS-zones te wijzigen zonder toegang te krijgen tot de zonebestanden. Beheerhulpmiddelen waarvan bekend is dat ze op die manier werken, zijn Admin4 en NicTool via het nsupdate-exportmechanisme.

Dienstverleners

DNS-serviceproviders implementeren vaak verschillende soorten DNS-servers in hun netwerken. Daarnaast kunnen er verschillende antwoorden worden gegeven aan DNS-clients op basis van de geografische locatie van de clients, zoals bepaald door hun IP-adres (GeoIP). De meest praktische manier om een ​​dergelijke kritieke internetinfrastructuur te beheren, was vertrouwen op databases en complexe DNS-beheersoftware om homogeniteit te garanderen en single-point of deployment-fouten te voorkomen.

BIND zone bestandsformaat

Het BIND-zonebestandsformaat is een veel gebruikte industriestandaard die is gedocumenteerd in RFC 1035. Verschillende andere DNS-servers, waaronder PowerDNS, NSD, Knot DNS en Microsoft DNS Server hebben de mogelijkheid om BIND-zonebestanden te lezen en van hen te bedienen.

Homogeniteit van DNS-software

Primaire redenen voor DNS-providers (met name root-operators) om verschillende DNS-servers te gebruiken, is codediversiteit en applicatieprestaties. Door codediversiteit is het minder waarschijnlijk dat een prestatie- of beveiligingsbug in één DNS-server kan worden misbruikt om een Denial of Service-aanval op een organisatie uit te lokken. Om deze reden worden NSD en Knot DNS vaak gebruikt door root- en TLD-operators. DNS-beheersoftware kan het publiceren van DNS-gegevens naar verschillende DNS-servers aanzienlijk vereenvoudigen.

Bekijk ook:
DNS management software vegelijking
DNS software