Universiteit Twente implementeert DNSSEC op compleet vernieuwde DNS -infrastructuur
Voor studenten is dit de ideale manier om hands-on ervaring op te doen
Deze maand heeft de Universiteit Twente de implementatie van DNSSEC afgerond. Daarmee is onder andere het hoofddomein utwente.nl ondertekend en zijn alle resolvers van validatie voorzien. Waar de DNS-infrastructuur voorheen bestond uit twee autoritatieve servers, is die nu vervangen door vijf fysieke en twee gevirtualiseerde systemen, alle gebruikmakend van Bind op Ubuntu Linux. Daarmee worden ongeveer 825 eigen domeinnamen beheerd en bij elkaar zo'n 30 duizend apparaten bediend.
Dit project was onderdeel van de Campus Challenge, een competitie georganiseerd door SURFnet en SIDN. De implementatie van DNSSEC was daar een onderdeel van. Omdat een installatie op basis van Infoblox niet bleek aan te sluiten bij hun manier van werken, heeft de UT ervoor gekozen hun nieuwe DNS-infrastructuur helemaal zelf op te bouwen. Hoewel dat wel een paar maanden vertraging opleverde ten opzichte van de originele planning, was dit uiteindelijk voor zowel beheerders als twee betrokken afstudeerders een veel interessanter en leerzamer traject.
DNSSEC is het afgelopen jaar op grote schaal uitgerold op de campus van de Universiteit Twente. Deze implementatie was onderdeel van de Campus Challenge, een competitie georganiseerd door SURFnet en SIDN met als doel om onderwijs- en onderzoeksinstellingen te stimuleren om hun IT-infrastructuur te verbeteren. Daarmee maakt deze Challenge onderdeel uit van het veelomvattender GigaPort3-innovatieprogramma.
Drie lagen
Waar de UT in eerste instantie twee identieke DNS-servers had, is de architectuur in de nieuwe omgeving opgedeeld in drie lagen: Twee verborgen nameservers beheren dezelfde zones als de twee oude servers. De eerste is een gevirtualiseerde machine die fungeert als een afgesloten master waarop het beheer van de zones en de monitoring plaatsvindt. De tweede is een slave die enerzijds voor de ondertekening zorgt en anderzijds als master fungeert voor drie autoritatieve nameservers. Deze drie zorgen vervolgens voor de distributie van de zone-informatie. Om de inrichting robuuster te maken, zal een daarvan buiten het universiteitsnetwerk worden geplaatst. Op die manier is de DNS-informatie toch beschikbaar als de UT of SURFnet niet bereikbaar mocht zijn.
Daarnaast zijn er nog twee recursieve caching nameservers die als resolvers door de UT-gemeenschap worden gebruikt. Daarop staan ook de zones voor intern gebruik. Deze systemen bedienen ongeveer 3300 medewerkers en een kleine 10 duizend studenten. Met name vorig collegejaar zagen de beheerders een sterke toename van het aantal gebruikte IP-adressen omdat studenten steeds vaker hun eigen apparatuur inzetten (BYOD, Bring Your Own Device). Alles bij elkaar bedienen deze twee nameservers op dit moment naar schatting zo'n 30 duizend apparaten.
Dedicated server-systemen
De twee resolvers en twee van de drie autoritatieve nameservers draaien op dedicated hardware. Daarvoor zijn vier HP DL360p Gen8 systemen aangeschaft. De verborgen master waarop de ondertekening plaatsvindt is eenzelfde systeem, maar dan voorzien van twaalf processorkernen en 32 Gbyte aan geheugen. De derde autoritatieve nameserver is een virtuele machine die nu nog op een bestaande server draait maar straks makkelijk bij een externe partner kan worden ondergebracht. Beschikbaarheid is de reden dat we vier van de vijf publieke nameservers als fysieke systemen hebben uitgevoerd,
aldus beheerder Johan Moelaert. Op die manier voorkom je dat problemen met de server-virtualisatie roet in het eten kunnen gooien, of dat er iets mis gaat met de gevirtualiseerde netwerkaansluitingen. Het systeem dat onze domeinen ondertekent hadden we in principe wel kunnen virtualiseren, maar dat is niet voordehandliggend omdat dat een echt werkpaard is. We hebben daarvan echter nog geen performance-statistieken beschikbaar omdat we de grote zones nu nog niet ondertekenen. Dat is de volgende stap.
Voor deze fase hebben we het testdomein ut-test.nl geregistreerd, en daar weer een subdomein onder geplaatst. Op die manier hebben we zowel parent- als child-domein in eigen huis, zodat we het ondertekenen en de key roll-over helemaal zelf kunnen beheren, onafhankelijk van de .nl-zone. Normaal gesproken staat de TTL hier op één dag. Voor het subdomein onder de test-zone hebben we dat nu naar twee uur teruggebracht, anders zitten we twee dagen te wachten voordat een roll-over helemaal afgerond is.
Complex
De complexiteit die DNSSEC en DANE aan de DNS-infrastructuur toevoegen is volgens Moelaert geen enkel probleem. DNS en DHCP worden hier door de techneuten al veel langer gebruikt om mee te experimenteren — die zaten zeker niet in de administratieve hoek — dus dat hebben we goed in de vingers. Bovendien doen we ook al langer certificaten, digitale handtekeningen en Secure Shell; daar zit ook een volledige chain-of-trust aan vast. Naar DANE [een extra keten om certificaten te authenticeren] hebben we nog niet gekeken.
Volgens Moelaert is de titel 'DNSSEC Mastery: Securing the Domain Name System with BIND', geschreven door Michael W. Lucas, een aanrader. Op dit moment is dit het enige boek beschikbaar dat specifiek over DNSSEC gaat. Als je met DNSSEC op Bind aan de slag gaat, is dit echt een must-read. De auteur gebruikt weliswaar OpenBSD in plaats van Linux, maar hij weet heel goed waarover hij praat. Voor ons was het bijvoorbeeld aanleiding om het verkeer tussen de servers te beveiligen met TSIG en om SSHFP records in onze zone files op te nemen. Dat deden we nog niet en staat in dit boek heel goed beschreven.
Bind 9.9 op Ubuntu Linux
We gebruikten hier al Bind,
vertelt Moelaert. Voor deze upgrade hebben we een nieuwe stack gemaakt van Bind op Ubuntu Linux versie 12.4. De Bind-versie die nu standaard met die distributie wordt meegeleverd is 9.8, maar daarin ontbreekt een essentieel vlaggetje (inline-signing) voor DNSSEC key management. Vandaar dat we Bind versie 9.9 via een aparte repository hebben binnengehaald in onze Ubuntu distributie.
Een veelgenoemd nadeel van Bind is dat je wel elke keer opnieuw de zone in zijn geheel moet inlezen als daar iets in veranderd is. Voor de UT is dat geen probleem, ook omdat de zones daar veel minder groot zijn dan bij een commerciële DNS-operator. De reload wordt automatisch uitgevoerd door het script. Bovendien zijn de gegenereerde zone files gewoon leesbaar. Dat maakt het heel makkelijk om fouten op te sporen.
Geen appliances
Voordat we besloten toch weer onze eigen Bind-gebaseerde DNS-infrastructuur op te bouwen, zijn we in eerste instantie begonnen met een inventarisatie van geschikte IPAM-producten,
zo vertelt hoofd netwerkbeheer Jan Markslag. Daarvan zijn toen NetDB en Infoblox geselecteerd voor nader onderzoek. NetDB is een open source pakket ontwikkeld door Stanford University, maar er blijkt geen support beschikbaar te zijn. Infoblox is marktleider op het gebied van IPAM appliances. Het onderzoek naar deze omgeving hebben we als onderdeel van de Campus Challenge laten uitvoeren door twee HBO-afstudeerders van Saxion. Infoblox heeft daarvoor een appliance beschikbaar gesteld.
De conclusie was dat Infoblox een goed en stabiel product is, maar dat hun benadering niet past bij onze manier van werken. We gebruiken hier een eigen systeem dat we al in de jaren '90 hebben gebouwd. Daarin zijn alle gebruikers vastgelegd, en die zijn weer gekoppeld aan IP-adressen. Dat doen we gewoon aan de hand van het UT-account en de identity-management-omgeving. SURFnet eist ook van ons dat wij bij incidenten direct de gebruiker achter een bepaald IP-adres kunnen traceren. In ons huidige systeem hebben we dat allemaal prima voor elkaar. Bovendien hebben we ook nog een CMDB waarin aanvullende informatie voor de systemen is opgeslagen. Het gesloten karakter van Infoblox blijkt het echter heel lastig te maken om externe systemen en databases aan te koppelen.
Een groot voordeel van de Infoblox appliance is dat DNSSEC al volledig wordt ondersteund. Na een migratie is het niet veel meer dan een vinkje aanzetten en de DNSSEC-implementatie is klaar.
Eigen systeem
Als je begint met een spreadsheet en je wilt van daaruit gaan automatiseren, dan is Infoblox een prima keuze,
vervolgt Markslag. Maar als je al je relaties al hebt en je neemt een host als uitgangspunt — waarbij een host ook meerdere interfaces kan hebben, en een interface meerdere MAC-adressen, en een MAC-adres weer meerdere IP-adressen — dan leer je al gauw dat je zo'n hiërarchie niet in Infoblox kunt vastleggen. Daarin kunnen alleen namen en nummers worden gekoppeld.
Dat voldoet prima als je Infoblox puur en alleen voor DNS wilt gebruiken, maar wij hebben zelf ons eigen order call systeem gebouwd, zoals we dat voor wel meer toepassingen doen. En die aanpak past — in ieder geval voorlopig — niet in hun denkwijze. De contacten met Infoblox zijn echter prima; we proberen ze nog steeds te overtuigen van onze manier van werken en vastleggen van gegevens.
PowerDNS
We hebben ook nog even naar PowerDNS gekeken,
vult Moelaert aan, maar daarmee hadden we hetzelfde probleem als met Infoblox: PowerDNS gebruikt de onderliggende MySQL database als interface met de buitenwereld, en dat maakt het lastig om ons huidige systeem aan te koppelen. Wat we nu doen is elke keer een compleet nieuwe zone file genereren, en als die anders is dan de huidige dan wordt die vervangen. Verplaatst je dat naar MySQL, dan moet je dat ineens op record-niveau gaan doen. Dat is veel complexer.
Dan kun je inderdaad net zo goed zelf iets bouwen met Bind op Linux, dezelfde software die Infoblox zelf ook in zijn appliances gebruikt. Binnenkort gaan we een hele nieuwe applicatie maken voor ons order call systeem. Dat vanwege de uitbreiding met IPv6. We zullen dan bij SURFnet ook informeren of er nog meer partijen zijn die mee willen doen.
Technische universiteit
Hoewel Moelaert het prototype van de ouderwetse Unix-beheerder is — zijn liefde voor Bind dateert nog uit de tijd dat hij trainingen gaf voor versie 4 — is er op de UT minder dan voorheen interactie tussen de academici en studenten enerzijds en de beheerders anderzijds. We zijn als IT-afdeling nu meer dan vroeger met operationeel beheer bezig,
beaamt Markslag. Maar die traditionele academische cultuur is zeker nog niet verdwenen. De Campus Challenge is daar een goed voorbeeld van. Aan de ene kant zijn de studenten veranderd; de meesten willen alleen maar dat alles naar behoren werkt. Aan de andere kant is Linux enorm in opkomst. We zijn en blijven natuurlijk een technische universiteit.
Dat is ook waarom we voorop willen lopen met de implementatie van nieuwe technologieën als DNSSEC. Maar we zijn ook al heel lang met IPv6 bezig; zo zijn alle vijf nieuwe resolvers dual-stacked. Daarnaast hebben we security hoog in het vaandel staan, al is dat op een universiteit natuurlijk anders geregeld dan bij een bank. Wij hebben hier een open omgeving; de UT is de enige Nederlandse universiteit met een campus. Er staan hier ongeveer 2500 studentenwoningen, alle voorzien van hoogwaardige netwerkvoorzieningen, zowel vast als draadloos.
Hands-on ervaring
De implementatie van DNSSEC bij de UT is een paar maanden uitgelopen ten opzichte van de planning. Dat werd veroorzaakt door de zoektocht naar de beste oplossing en de computersystemen die met vertraging werden besteld en uitgeleverd. We vinden het leuk om niet direct commerciële producten in te zetten,
zegt Markslag, maar eerst samen met studenten en onderzoekers zelf wat te ontwikkelen. Vandaar dat we Infoblox door twee studenten hebben laten evalueren. Toen we daaruit de conclusie trokken dat die appliance niet aansloot bij onze manier van werken, had dat natuurlijk wel consequenties voor het DNSSEC-onderdeel van de Campus Challenge.
Waar we in eerste instantie dachten alleen een vinkje aan te hoeven zetten in de webinterface van de appliance, moesten we nu een complete Bind-installatie opzetten. Dat is veel complexer. Daardoor hebben we hier meer tijd in moeten investeren en waren we uiteindelijk ook een paar maanden later klaar dan gedacht. Deze onvoorziene wending heeft de upgrade wel veel interessanter gemaakt. We hebben hier zelf veel van geleerd, maar ook voor studenten is dit een ideale manier om hands-on ervaring op te doen in hun opleiding.
Migratie en ondertekening
De implementatie van de nieuwe DNS-infrastructuur bij de UT is zojuist afgerond. We hebben de afgelopen maanden proefgedraaid met de resolvers en de laatste tests uitgevoerd,
aldus Moelaert. Inmiddels zijn de validerende resolvers volledig operationeel.
Inmiddels hebben we ook de interne en externe domeinen naar de nieuwe omgeving gemigreerd. Het hoofddomein utwente.nl is ondertekend en het sleutelmateriaal geupload. We zijn zelf registrar, dus dat konden we direct doen via de EPP webinterface. Daar wordt de key dan omgezet in een DS record en ondertekend door SIDN [elke twee uur]. Vervolgens duurt het nog zeker een dag voordat de oude records overal uit de caching resolvers zijn verdwenen. Ruim genomen is zo'n transitie in twee dagen rond.
De komende tijd gaan we naar de rest van de onderliggende domeinen kijken. De afgelopen maanden hebben we al een hoop oude configuraties opgeruimd. Alles bij elkaar hebben we nu ongeveer 825 domeinen in ons systeem zitten, maar het leeuwendeel daarvan is alleen voor intern gebruik.
Validatiefouten
De IT-beheerders hebben nog wel zorgen over de validatiefouten die door de nieuwe resolvers gegenereerd zullen worden. In de meeste gevallen zal dat geen probleem zijn en kunnen we prima uitleggen wat er aan de hand is,
aldus Moelaert.
We gaan in ieder geval geen niet-validerende nameserver aanbieden, want dan gaat iedereen die gebruiken omdat dat geen gezeur oplevert. We moeten het probleem met de validatiefouten oplossen, niet omzeilen. En als mensen echt willen, zijn er in de buitenwereld voldoende publieke nameservers beschikbaar, al valideren sommige daarvan inmiddels ook.
Service desk
Andere validerende organisaties zoals T-Mobile, SURFnet en het CWI geven hun logs van de gedetecteerde validatiefouten elke dag door aan SIDN. De registry gebruikt deze informatie om het aantal fouten actief naar beneden te brengen. SURFnet doet dat zelf ook voor zijn eigen klanten.
Op dit moment is het nog te vroeg om validatiefouten door te zetten,
vertelt Moelaert. Bind gebruikt een aparte logfile voor DNSSEC, waarin ook alle foutmeldingen terecht komen. Dat is wel een ander formaat dan wat door Unbound wordt afgeleverd. We hebben SIDN al toegezegd dat we hier graag aan mee willen werken; we moeten alleen nog uitzoeken hoe we dat het beste implementeren. Daarover overleggen we nog met hun technisch adviseurs.
De focus ligt nu op de instructie van onze service desk. Zij moeten weten hoe ze met DNSSEC-problemen om moeten gaan. Om mensen te kunnen helpen, moeten zij kunnen uitzoeken wat er precies aan de hand is. Gaat het om een verkeerd gespelde naam, een verkeerd top-level domein, of is het inderdaad een validatiefout? We werken nu aan een tool — een query of een webpagina — om de service-medewerkers daarbij te ondersteunen. Maar misschien moeten we die pagina wel voor iedereen beschikbaar maken. Dan kunnen gebruikers zelf kijken wat er aan de hand is.
