(Reverse) DNS infrastructuur optuigen voor eigen netblock.

[unezra]

Wij zijn sinds kort RIPE/NCC lid (LIR) en hebben onze eigen /22 (PA-space) toebedeeld gekregen. We hebben (nog) geen eigen routers en zijn geen ISP. Uit de /22 hebben we een /24 geknipt die door een ISP announced word en weer is opgeknipt in 4 /26's waarvan 3 op dit moment actief in gebruik.

Helaas, een van de dingen die ik dacht in januari wel een keer te kunnen fixen blijkt urgenter dan gedacht ivm de vrij agressieve policy van sommige mailservers buiten onze organisatie: reverse DNS.

Op dit moment doen we het zonder en het blijkt urgenter dan gehoopt dat snel te fixen.

Nu zit ik na te denken over hoe ik dit het best kan oplossen en vandaar dus dit topic.

Wat kenmerken:

• De in gebruik zijnde /26's zijn geografisch gescheiden over 3 lokaties, 2 datacenters, 1 kantoor.
• De /26's komen uit een /24 die door 1 ISP (uiteraard met eigen redundant infrastructuur) announced word.
• We hebben op kantoor de beschikking over een paar IP adressen via een andere ISP.
• Er zijn nog geen plannen om een 2e ISP in de arm te nemen om die een 2e /24 te laten announcen zodat we op dat gebied volledig redundant zijn en niet meer afhankelijk van 1 ISP.
• De DC's zelf en ons kantoor zijn wel op een andere manier met elkaar verbonden (L1 en L2 glas), redundancy loopt via een VPN over diezelfde ISP heen. (Het gaat daar om 2 aanbieders, 1 voor glas en 1 voor onze internet verbindingen met nog een 3e voor een losse, extra backup lijn op kantoor.)

Nu heb ik een aantal vragen en overwegingen (onder andere gevoed door: https://www.ripe.net/mana...--objects-for-reverse-dns )

• Kunnen we ondanks dat het om 1 ISP gaat, de 3 locaties als geografisch gescheiden beschouwen. (Zoals RIPE/NCC aan raad.)
• Ik denk aan 2, 3 of 4 nameservers, 1 op iedere lokatie en nog 1 bij een VPS provider. Neig naar de primary en secondary op de datacenter locaties te zetten, tertiary dan op kantoor en de 4e op de VPS bij die ISP. Alleen welke ik dan master moet maken en welke slave, daar ben ik nog niet over uit. (Liefst heb ik de master op onze eigen infra, mogelijk zelfs als losse master die niet van buitenaf te benaderen is en enkel de slaves te exposen.)
• Qua software twijfel ik tussen PowerDNS met PowerAdmin als web front-end en MySQL of MariaDB als database en good ol' BIND9. Over PowerDNS hoor ik heel goede geluiden, MySQL replicatie moet ook goed lukken. BIND9 ben ik zelf veel vertrouwder mee en kan ik ook goed zonder web GUI beheren. (Ik sta open voor andere suggesties maar wil wel iets hebben dat relatief eenvoudig op te zetten en te beheren is.)
• Ik twijfel ergens nog over Microsoft DNS. Qua licenties (datacenter licenties) kan dat volgens mij prima maar we willen juist meer en meer Open Source Software inzetten in de organisatie. Voordeel is wel dat we het intern al gebruiken. :-)
• In eerste instantie gaat het alleen om reverse DNS, later willen we dit mogelijk gaan uitbreiden naar forwards en recursors. Of ik dat op dezelfde nameservers ga doen of niet weet ik niet. Ook daar graag jullie mening. (Ik kan me voorstellen dat er goede redenen zijn dat volledig los te willen trekken of in ieder geval op aparte vm's te draaien.)

Volgens mij zijn dat wel zo even mijn overwegingen. Als ik nog dingen vergeten ben pas ik uiteraard het topic aan en beantwoord ik de vragen zo goed en zo kwaad als het kan.

Ik ben benieuwd naar jullie visie/mening/input op dit gebied en hoop snel een keuze te kunnen maken zodat we in ieder geval weer PTR records hebben. (We kunnen het eventueel namelijk uitbesteden aan een ISP, maar het hele grote nadeel daarvan is dat zij wijzigingen enkel per email kunnen doen. Er is geen front-end beschikbaar. Als het moet dan moet het, al zou het maar tijdelijk zijn maar heel gelukkig word ik niet van een oplossing waar ik zelf maar beperkt invloed op heb.)

Mods: Ik hoop dat ik dit topic in het juiste subforum heb geplaatst. Zo niet, mijn excuses en graag een schop naar het juiste subforum. (Weet ik het meteen voor een volgende keer, ik denk dat ik nog wel vaker vergelijkbare topics zal openen.)

[Equator]

Ik maak in ieder geval even een alias aan in Professional Networking & Servers. Daarnaast kijk ik lekker mee, want wij zitten met een vergelijkbaar probleem. Ook een /22 en geen een uitbesteede reverse DNS.

Kunnen we ondanks dat het om 1 ISP gaat, de 3 locaties als geografisch gescheiden beschouwen. (Zoals RIPE/NCC aan raad.)

De vraag is - en deze kan ik dus ook niet beantwoorden - wil je de reverse DNS voor je /22 aanbieden op je eigen IP adressen uit deze reeks, of doe je dat elders. Of is dat überhaupt verplicht?

[unezra]

Equator schreef op donderdag 7 december 2017 @ 12:26:
Ik maak in ieder geval even een alias aan in Professional Networking & Servers. Daarnaast kijk ik lekker mee, want wij zitten met een vergelijkbaar probleem. Ook een /22 en geen reverse DNS.

Top! Ik twijfelde echt even heel hard waar dit topic het beste thuis hoort omdat we met onze /22 en LIR-schap ook een beetje ISP spelen ook al zijn we dat niet. (We bieden geen internet diensten aan anderen.)

[...]
De vraag is - en deze kan ik dus ook niet beantwoorden - wil je de reverse DNS voor je /22 aanbieden op je eigen IP adressen uit deze reeks, of doe je dat elders. Of is dat überhaupt verplicht?

Daar twijfel ik dus ook over. RIPE/NCC is daar niet helemaal duidelijk over.

RIPE/NCC zegt dit:

• Make sure you set up at least two name servers that are authoritative for the zone
• Ensure that the servers are at least in different subnets, but preferably in different networks that are geographically distributed
• The resolvable names of these name servers should be in the NS resource records of the zone
• The SOA resource record (RR) should have the same content, both serial number and other data, on all the name servers
• The SOA should contain a valid "RNAME" (the contact address)
• The timing parameters should be reasonable

Die laatste is *erg* vaag. Er staat niet bij wat "reasonable" is. Maar het gaat hier om de eerste 2.

Wat wij willen is rdns aanbieden op IP's uit die /22. Dat zou raar zijn als het 1 enkele /22 is. Maar die /22 hebben we opgeknipt in 1 /24 die dan weer is opgeknipt in 4 /26's waarbij iedere /26 op een aparte locatie leeft. Het enige is dat je niets kleiners dan een /24 kunt announcen, waardoor die /26's wat dat betreft wel uit hetzelfde block komen.

Ik denk dat te kunnen oplossen door te zorgen dat er altijd 1 van de 3 locaties online is, met eventueel een last-resort op een externe VPS en/of via een andere ISP. (Die we toch al hebben liggen zodat we op kantoor als last-resort DNS kunnen dienen. Daar ligt een redelijk rappe VVDSL lijn dus die moet dat als nood wel aan kunnen. De extra, losse, ISP levert 500/50 waar dat ook geen probleem zou moeten zijn.)

Helemaal buiten onze infra kan, maar dan moeten we 2 VPS hosters in de arm nemen. Diegene waar we nu zitten met een paar vm's (specifiek voor taken die we buiten onze infra willen of moeten hebben), kan niet garanderen dat een 2e VPS op andere infra, laat staan een andere locatie komt te draaien.

Overigens is de impact me echt tegen gevallen. Ik dacht dat het hooguit een paar tienden punt op de spamfilters zou opleveren en daarmee wilde ik dit issue ergens in januari, februari gaan slechten. Helaas heb ik nu al 2, 3 gevallen gezien waar 'ie keihard op de MTA van een ontvanger word geweigerd, nog voor het spamfilter. "Geen PTR, doei!" Daarom heeft dit een "iets" hogere prioriteit gekregen. (Maar ik wil het wel goed doen, liever een paar dagen langer met een goed ontwerp dan nu snel snel en met een shitoplossing zitten.)

[CyBeR]

Van dat lijstje van RIPE/NCC zijn de eerste twee best practices (1 ns werkt maar als die stuk is heb je geen rdns), de volgende twee zijn gewoon standaard DNS dingen, de volgende is voornamelijk theoretisch want niemand gebruikt de SOA RNAME en de laatste houdt in dat je niet dom moet doen en de TTL op acht jaar zetten.

Reverse DNS is niet speciaal. Je kunt daar gewoon je huidige DNS servers voor gebruiken en een .in-addr.arpa zone toevoegen. Heb je geen DNS servers en wil je dat niet? Gebruik iets als Route53.

[ Voor 23% gewijzigd door CyBeR op 07-12-2017 12:51 ]

[Equator]

Ensure that the servers are at least in different subnets, but preferably in different networks that are geographically distributed

Wat ze hier zeggen is dat ze liever hebben dat het op aparte netwerken staat, en geografisch gescheiden. Ik denk dat je - zolang jij geen redundante aansluiting hebt op een dubbele ISP - dit niet zelf kan invullen.

Je kan het opdelen natuurlijk, maar dan ga je veel IP space weggooien ben ik bang.

CyBeR schreef op donderdag 7 december 2017 @ 12:50:
Reverse DNS is niet speciaal. Je kunt daar gewoon je huidige DNS servers voor gebruiken en een .in-addr.arpa zone toevoegen. Heb je geen DNS servers en wil je dat niet? Gebruik iets als Route53.

Maar als je een dienst aanbiedt aan klanten met deze IP adressen, dan wil je wel een bepaalde beschikbaarheid realiseren. Route53 ga ik ook eens naar kijken. Ah, ik vond het al bekend voorkomen, is de DNS dienst van AWS.. Dank

[ Voor 38% gewijzigd door Equator op 07-12-2017 12:56 ]

[unezra]

Oh, ik zie trouwens dat ik er per ongeluk niet een discussietopic maar een vraagtopic van heb gemaakt. Sorry.

CyBeR schreef op donderdag 7 december 2017 @ 12:50:
Van dat lijstje van RIPE/NCC zijn de eerste twee best practices (1 ns werkt maar als die stuk is heb je geen rdns), de volgende twee zijn gewoon standaard DNS dingen, de volgende is voornamelijk theoretisch want niemand gebruikt de SOA RNAME en de laatste houdt in dat je niet dom moet doen en de TTL op acht jaar zetten.

Ik wil het sowieso met 2 of 3 nameservers gaan doen, op iedere locatie 1. De geografische scheiding is er, alleen blijft het wel binnen dezelfde /22, meer specifiek, zelfs binnen 1 /24 die enkel door de announcende ISP word opgeknipt in /26's.

Reverse DNS is niet speciaal. Je kunt daar gewoon je huidige DNS servers voor gebruiken en een .in-addr.arpa zone toevoegen. Heb je geen DNS servers en wil je dat niet? Gebruik iets als Route53.

Onze huidige extern benaderbare DNS servers draaien geheel buiten onze infra. Dat werkt voorlopig eigenlijk prima. Alleen kan die partij geen rdns voor ons doen. (Wel een VPS leveren waarop we dat zelf doen.)

Op termijn willen we dat misschien zelf gaan doen maar vooralsnog hebben we daar geen goede redenen voor gehad. (Externe DNS werkt prima en is lekker onderhoudsvrij. Plus, sleutelen we aan onze eigen infra, werkt DNS nog wel. Handig als je even wat records naar tijdelijke adressen wilt zetten.)

Equator schreef op donderdag 7 december 2017 @ 12:53:
[...]
Wat ze hier zeggen is dat ze liever hebben dat het op aparte netwerken staat, en geagrafisch gescheiden. Ik denk dat je - zolang jij geen redundante aansluiting hebt op een dubbele ISP - dit niet zelf kan invullen.

Je kan het opdelen natuurlijk, maar dan ga je veel IP space weggooien ben ik bang.

De bedoeling is dat op termijn wel te doen als de behoefte aan een volledig 2e ISP groot genoeg word. Heel misschien dat we tegen die tijd zelf ook BGP gaan praten en routers hebben, al betekend dat ook een afhankelijkheid van eigen kennis en hardware die we nu nog niet hebben en niet willen.

De /22 is best ruim voor wat we van plan zijn, een extra /24 gebruiken kan op termijn geen kwaad en levert op andere gebieden buiten DNS ook een prettige extra redundancy op.

Zolang het draait bij 1 ISP is dat de SPOF, aan de andere kant kunnen we daar buiten nog wel iets doen met een 3e en 4e nameserver (VPS, extra verbinding op kantoor) en heeft die ISP zelf de boel ook redundant uitgevoerd. Het enige dat niet redundant is, is die ISP zelf en hun aansluiting op onze eigen infra. (Per locatie hebben we 1 uplink. Know risk. Word aan gewerkt maar ik heb daar in 2018 nog geen budget voor.)

[CyBeR]

Equator schreef op donderdag 7 december 2017 @ 12:53:
[...]

Maar als je een dienst aanbiedt aan klanten met deze IP adressen, dan wil je wel een bepaalde beschikbaarheid realiseren.

Zeker, maar ik ga er van uit dat als je al DNS-diensten aanbiedt op eigen infrastructuur, dat je daar al over nagedacht hebt.

Route53 ga ik ook eens naar kijken. Dank

Ik gebruik R53 voor een specifiek doeleinde wat met m'n eigen DNS servers minder makkelijk te realiseren is (discrimineren op basis van geografische locatie), en dat werkt best prima. Is geloof ik ook zo ongeveer de enige AWS-dienst met een 100% beschikbaarheid SLA.

unezra schreef op donderdag 7 december 2017 @ 13:00:

Ik wil het sowieso met 2 of 3 nameservers gaan doen, op iedere locatie 1. De geografische scheiding is er, alleen blijft het wel binnen dezelfde /22, meer specifiek, zelfs binnen 1 /24 die enkel door de announcende ISP word opgeknipt in /26's.

Mja, dat maakt niet uit. Ten eerste, omdat dat verschillnde subnets zijn. Het enige waar dat om gaat is dat ze je vertellen dat 't verstandig is om gescheiden netwerken te gebruiken zodat een netwerkprobleem niet je beide nameservers offline wipt. Daar heb je in voorzien.

Onze huidige extern benaderbare DNS servers draaien geheel buiten onze infra. Dat werkt voorlopig eigenlijk prima. Alleen kan die partij geen rdns voor ons doen. (Wel een VPS leveren waarop we dat zelf doen.)

Waarom? Reverse DNS is gewoon een normale DNS zone onder in-addr.arpa (IPv4) of ip6.arpa (IPv6). Dat kunnen ze prima, hoogstens kunnen ze 't om onduidelijke redenen niet willen.

[ Voor 42% gewijzigd door CyBeR op 07-12-2017 13:04 ]

[Equator]

unezra schreef op donderdag 7 december 2017 @ 13:00:
Oh, ik zie trouwens dat ik er per ongeluk niet een discussietopic maar een vraagtopic van heb gemaakt. Sorry.

Opgelost

[KoeKk]

Ik heb iets vergelijkbaars, maar werk bij een (kleine) ISP

Wij draaien onze forward en reverse zones op dezelfde servers. Recursive servers natuurlijk apart.

Wij hebben onze 'dns1' in ons eigen AS draaien, en de 'dns2' als een VPS bij een 100% gescheiden ISP waar wij verder geen andere diensten bij afnemen. Je wilt vooral dat je tweede DNS server niets in de connectiviteit deelt, dus niet in je eigen AS, of het upstream pad naar het internet, dus niet bij de ISP die ook je connectiviteit levert. Als je wat kleiner bent is dat verreweg de simpelste oplossing die het meeste redundantie bied, en het voldoet letterlijk aan het advies van RIPE: 2+ servers, geografisch, subnet en netwerk technisch gescheiden.

Wij gebruiken zelf Microsoft DNS (Wij zijn een Microsoft shop), met een zelfbouw powershellscript welke de zone's op de primary aanmaakt als secondary zones op de secondary servers. De inhoud van je zones synced gewoon via het standaard DNS update systeem. Anders zou ik overigens ook kijken naar PowerDNS of ISC Bind, dat is naar mij gevoel een beetje de standaard oplossing .

Voor verdere zaken:
Waarom adverteer je ISP alleen die /24 en niet direct je hele /21? Het wordt in principe aangeraden om al te IP adressen te adverteren zodat je de ranges die je niet adverteert minder simpel gekaapt kunnen worden (In de RIPE db moet je dat aangeven).

[CyBeR]

KoeKk schreef op donderdag 7 december 2017 @ 13:26:
Ik heb iets vergelijkbaars, maar werk bij een (kleine) ISP

Als je wat kleiner bent is dat verreweg de simpelste oplossing die het meeste redundantie bied, en het voldoet letterlijk aan het advies van RIPE: 2+ servers, geografisch, subnet en netwerk technisch gescheiden.

Precies wat ik ook doe, met het verschil dat ik een fysieke server heb ipv een vps. Maar idd bij een compleet ongerelateerde ISP, in een andere stad zelfs.

[unezra]

CyBeR schreef op donderdag 7 december 2017 @ 13:01:
[...]
Zeker, maar ik ga er van uit dat als je al DNS-diensten aanbiedt op eigen infrastructuur, dat je daar al over nagedacht hebt.

In ons geval bieden we geen DNS diensten aan klanten aan. Dus ja, er is wel over nagedacht maar je denkt wel anders over zulke zaken na als het enkel je interne klanten zijn, dan als je daadwerkelijk ISP bent.

[...]
Ik gebruik R53 voor een specifiek doeleinde wat met m'n eigen DNS servers minder makkelijk te realiseren is (discrimineren op basis van geografische locatie), en dat werkt best prima. Is geloof ik ook zo ongeveer de enige AWS-dienst met een 100% beschikbaarheid SLA.

Hmmm. Kan interessant zijn. Gok dat daar wel een prijskaartje aan zit?

[...]
Mja, dat maakt niet uit. Ten eerste, omdat dat verschillnde subnets zijn. Het enige waar dat om gaat is dat ze je vertellen dat 't verstandig is om gescheiden netwerken te gebruiken zodat een netwerkprobleem niet je beide nameservers offline wipt. Daar heb je in voorzien.

Ok! Dus de constructie zoals ik die in mijn hoofd heb zou, met de mitsen en maren die ik al heb aangegeven, in principe OK moeten zijn?
As in, tuurlijk werkt het maar de vraag is of het een ongelooflijk domme setup zou zijn, of dat dit met de middelen die ik heb eigenlijk een heel nette oplossing is.

[...]
Waarom? Reverse DNS is gewoon een normale DNS zone onder in-addr.arpa (IPv4) of ip6.arpa (IPv6). Dat kunnen ze prima, hoogstens kunnen ze 't om onduidelijke redenen niet willen.

Onze VPS boer levert het niet. Heb dat wel nagevraagd, maar het is geen dienst die ze willen leveren op het moment. (Ze doen ook alleen VPSen, colocatie en domeinen. DNS doen ze er bij. (Handig als je een domein af neemt zeg maar.)

rdns kan wel door onze ISP worden gedaan maar het grote nadeel is dat ik er zelf geen toegang toe heb en dat werkt helemaal niet fijn.

KoeKk schreef op donderdag 7 december 2017 @ 13:26:
Ik heb iets vergelijkbaars, maar werk bij een (kleine) ISP

Wij draaien onze forward en reverse zones op dezelfde servers. Recursive servers natuurlijk apart.

Check. Doe je daar ook je interne DNS op met split-horizon, of heb je daar aparte servers voor die al dan niet met de rest communiceren / zone transfers doen?

Wij hebben onze 'dns1' in ons eigen AS draaien, en de 'dns2' als een VPS bij een 100% gescheiden ISP waar wij verder geen andere diensten bij afnemen. Je wilt vooral dat je tweede DNS server niets in de connectiviteit deelt, dus niet in je eigen AS, of het upstream pad naar het internet, dus niet bij de ISP die ook je connectiviteit levert. Als je wat kleiner bent is dat verreweg de simpelste oplossing die het meeste redundantie bied, en het voldoet letterlijk aan het advies van RIPE: 2+ servers, geografisch, subnet en netwerk technisch gescheiden.

Check.
Eventueel de VPS als 3e of 4e? Of juist primair op site A, secondary op de VPS en de 3e en 4e eventueel weer geografisch op een andere locatie, maar wel binnen je eigen netwerk? (Ik twijfel ook of ik secondary niet op onze eigen infra, maar op kantoor en ontsloten via de fallback ISP ga draaien. Kan alleen niet inschatten / vinden in hoeverre de requests round-robin gaan of dat je primary als eerste benaderd word en pas bij uitval naar de 2e. Kun jij daar iets over zeggen?

Wij gebruiken zelf Microsoft DNS (Wij zijn een Microsoft shop), met een zelfbouw powershellscript welke de zone's op de primary aanmaakt als secondary zones op de secondary servers. De inhoud van je zones synced gewoon via het standaard DNS update systeem. Anders zou ik overigens ook kijken naar PowerDNS of ISC Bind, dat is naar mij gevoel een beetje de standaard oplossing .

Yep. Wij zijn nogal mixed. Intern doen we veel met Microsoft maar ook meer en meer met OSS. We kunnen op 2 plekken zonder pardon Microsoft DNS inzetten, maar daar buiten kost het geld omdat we daar geen datacenter licenties hebben. Dat, plus dat we meer en meer met OSS willen doen, zorgt dat ik neig naar PowerDNS of ISC BIND.

PowerDNS schijnt heel goed, veilig en snel te zijn, heeft een mooie bruikbare web GUI voor dagelijks beheer, etc. BIND ben ik zelf bekender mee en ik type graag zonefiles. (Als we voor BIND gaan weet ik ook niet of ik d'r wel een GUI tegenaan wil gooien of gewoon zonefiles blijf kloppen.)

Voor verdere zaken:
Waarom adverteer je ISP alleen die /24 en niet direct je hele /21? Het wordt in principe aangeraden om al te IP adressen te adverteren zodat je de ranges die je niet adverteert minder simpel gekaapt kunnen worden (In de RIPE db moet je dat aangeven).

Omdat we heel bewust die overige /24's later willen gaan gebruiken. We zouden het kunnen laten announcen door onze ISP en later daar weg halen maar het leek mij een beetje raar dat te doen als we nu al weten dat we die /24's echt door andere ISP's willen laten opvangen. (Of/en zelf ooit BGP willen gaan babbelen, al was het maar ter experiment. Dan is een losse /24 speciaal daarvoor wel heel erg fijn.)

Ik moet zeggen dat ik niet wist van het risico van gekaapt worden dus daar ga ik zeker alsnog eens over nadenken. Wel announcen, niet actief gebruiken. Het is ook niet meer dan een enkele change op hun infra.

(Het is overigens een /22, groter krijg je niet op dit moment. Je krijgt 1x een /22 IPv4 PA en klaar... Alleen IPv6 kun je meer en grote blokken PA krijgen. PI leveren ze helemaal niet meer.)

CyBeR schreef op donderdag 7 december 2017 @ 13:28:
[...]
Precies wat ik ook doe, met het verschil dat ik een fysieke server heb ipv een vps. Maar idd bij een compleet ongerelateerde ISP, in een andere stad zelfs.

Wij hebben zo'n beetje alles virtueel draaien. Wel op eigen infra. Voor ons is het dus ook een logische keuze een VPS bij een VPS hoster te hebben voor taken die we niet binnen onze eigen infra willen doen. Er draait bijvoorbeeld een monitoring server (proxy) die extern onze infra in de gaten houd. Dat kun je niet goed intern doen omdat je echt wil dat de checks van buitenaf komen. Die proxy moet ook nog een actieve monitoring server worden die ook los van zijn master kan acteren.

Dus een extra nameserver op een VPS (dat word dan wel een losse) ligt redelijk voor de hand.

[CyBeR]

unezra schreef op donderdag 7 december 2017 @ 14:03:
[...]

Hmmm. Kan interessant zijn. Gok dat daar wel een prijskaartje aan zit?

Alles bij AWS is Pas as you Go, dus ook Route53. Een hosted zone kost 50 ct per maand. Je betaalt ook voor queries maar je moet flink bezig zijn wil dat in de papieren gaan lopen.

De afgelopen maand heb ik Amazon voor Route53 $1.29 betaald, voor 1 hosted zone in productie (en 1 om te testen), dus 29ct voor iets meer dan een half miljoen queries.

[KoeKk]

Check. Doe je daar ook je interne DNS op met split-horizon, of heb je daar aparte servers voor die al dan niet met de rest communiceren / zone transfers doen?

Ik wil maar 1 blik op de wereld , dus geen split-horizon of andere (IMO) meuk. Het ene deel van onze hosting gaat via NAT naar binnen, het andere deel heeft een frontend/backend netwerk.
We gebruiken een aparte DNS zone voor RFC1918 IP's, denk aan <host>.<ad-domein>.bedrijf.nl en dan <host>.bedrijf.nl voor de publieke IP's.
Dan kan je makkelijk verbinding maken met backend of frontend IP's door gewoon een andere FQDN te gebruiken, en heb je altijd een consistent beeld van de servers.

Check.
Eventueel de VPS als 3e of 4e? Of juist primair op site A, secondary op de VPS en de 3e en 4e eventueel weer geografisch op een andere locatie, maar wel binnen je eigen netwerk? (Ik twijfel ook of ik secondary niet op onze eigen infra, maar op kantoor en ontsloten via de fallback ISP ga draaien. Kan alleen niet inschatten / vinden in hoeverre de requests round-robin gaan of dat je primary als eerste benaderd word en pas bij uitval naar de 2e. Kun jij daar iets over zeggen?

Ik zou het zelf simpel houden, dus de primary op je belangrijkste locatie, en je secondary op je VPS. Ik zou zelf geen 3e of 4e doen, maar het kan natuurlijk wel. Ik zou niet beide op je eigen infra draaien, als er een keer iets goed mis gaat dan kan het zo maar overal uitvallen. Even afhankelijk hoe erg dit dan is met je reverse, want je mailserver doet het dan sowieso ook niet.
Qua load balancing: hangt van de resolver af... , sommige pakken de eerste die ze zien (dus je primary), anderen pakken er random eentje uit de lijst van NS records. Zie hier voor wat meer info: https://serverfault.com/q...rvers-improve-performance

Omdat we heel bewust die overige /24's later willen gaan gebruiken. We zouden het kunnen laten announcen door onze ISP en later daar weg halen maar het leek mij een beetje raar dat te doen als we nu al weten dat we die /24's echt door andere ISP's willen laten opvangen. (Of/en zelf ooit BGP willen gaan babbelen, al was het maar ter experiment. Dan is een losse /24 speciaal daarvoor wel heel erg fijn.)

Ik moet zeggen dat ik niet wist van het risico van gekaapt worden dus daar ga ik zeker alsnog eens over nadenken. Wel announcen, niet actief gebruiken. Het is ook niet meer dan een enkele change op hun infra.

Het belangrijkste is dat je in de RIPE DB aangeeft welke AS-en jouw range mogen adverteren. Verder wordt het aangeraden om gewoon al je IP's te adverteren, ik weet ook niet wat ik met een /32 hoeveelheid aan IPv6 adressen moet, maar ik adverteer hem wel volledig., op aanraden van mijn upstream ISP.
Daarnaast: als je in de toekomst meerdere ISP's gaat gebruiken: probeer zelf BGP te gaan draaien, dan kan je direct je hele range multihome online brengen in plaats van je subnetjes over verschillende ISP's te verdelen .

[unezra]

Topic gaat sneller dan verwacht. Denk dat ik een aardig eind uit mijn overwegingen ben gekomen al.
Fijn! (Ik ben nog niet aan het bouwen geslagen, heel bewust eerst deze overwegingen voordat ik een vm ga optuigen.)

KoeKk schreef op donderdag 7 december 2017 @ 14:45:
[...]

Ik wil maar 1 blik op de wereld , dus geen split-horizon of andere (IMO) meuk. Het ene deel van onze hosting gaat via NAT naar binnen, het andere deel heeft een frontend/backend netwerk.
We gebruiken een aparte DNS zone voor RFC1918 IP's, denk aan <host>.<ad-domein>.bedrijf.nl en dan <host>.bedrijf.nl voor de publieke IP's.
Dan kan je makkelijk verbinding maken met backend of frontend IP's door gewoon een andere FQDN te gebruiken, en heb je altijd een consistent beeld van de servers.

Hmm, daar is inderdaad ook wat voor te zeggen ja.
Op de eoa manier ben ik split-horizon nog gewend vanuit mijn tijd bij een kleine ISP (10+ jaar geleden), maar met lokale subdomeinen heb je dat natuurlijk niet meer echt nodig. Goeie. Ik zat echt nog te puzzelen op hoe ik dat moest gaan doen, maar wellicht dat ik het helemaal achterwege kan laten. (En dan is het ook geen eis meer dat het kan. Scheelt meteen weer configuratiewerk.)

[...]
Ik zou het zelf simpel houden, dus de primary op je belangrijkste locatie, en je secondary op je VPS. Ik zou zelf geen 3e of 4e doen, maar het kan natuurlijk wel. Ik zou niet beide op je eigen infra draaien, als er een keer iets goed mis gaat dan kan het zo maar overal uitvallen. Even afhankelijk hoe erg dit dan is met je reverse, want je mailserver doet het dan sowieso ook niet.
Qua load balancing: hangt van de resolver af... , sommige pakken de eerste die ze zien (dus je primary), anderen pakken er random eentje uit de lijst van NS records. Zie hier voor wat meer info: https://serverfault.com/q...rvers-improve-performance

Check.
Ofwel, op zowel primary als secondary zorgen voor voldoende performance (bandbreedte, queries per seconde) om daar geen vertragende factor in te hebben omdat het altijd kan zijn dat iemand round-robin gaat doen. Hooguit de primary wat meer in de gaten houden omdat die netto ws net iets meer voor zijn kiezen gaat krijgen.

[...]
Het belangrijkste is dat je in de RIPE DB aangeeft welke AS-en jouw range mogen adverteren. Verder wordt het aangeraden om gewoon al je IP's te adverteren, ik weet ook niet wat ik met een /32 hoeveelheid aan IPv6 adressen moet, maar ik adverteer hem wel volledig., op aanraden van mijn upstream ISP.
Daarnaast: als je in de toekomst meerdere ISP's gaat gebruiken: probeer zelf BGP te gaan draaien, dan kan je direct je hele range multihome online brengen in plaats van je subnetjes over verschillende ISP's te verdelen .

Juist. Goed, dan ga ik dat eens op de TODO zetten. Dat zijn 2 changes, die kunnen we nog wel handlen. (1 om het aan te zetten en op termijn 1 om het weer af te zetten bij die ene ISP.) 100% zeker dat ik heel graag ooit zelf met eigen routers wil gaan werken. Misschien niet volledig in productie, maar hoe dan ook in test en voor de ervaring. Lijkt me ontzettend leerzaam. (En zolang het in test is, kan dat ook best met een afgeschreven server en een software router d'r in. Die hebben we altijd wel liggen.)

Los van dit allemaal:
Zijn er nog specifiek dingen te roepen over de nameservers (master/slave, etc) en of er dwingende redenen zijn om voor PowerDNS danwel BIND9 te gaan? (Of dat het niet slecht is om puur te kiezen op basis van vertouwdheid, waarmee BIND9 voor mij meer voor de hand ligt.)

[KoeKk]

Ik denk niet dat je snel een performance issue gaat hebben op je DNS, dan heb je het echt over zo belachelijk veel queries, hebben we het meer over TLD authoratieve servers, niet over de reverse DNS van een paar /24's

Voor die RIPE DB aanpassing: die zal er hoogst waarschijnlijk al staan, anders zou je al praktisch niet bereikbaar moeten zijn (Of je ISP is een van de oude tier 1's zoals KPN, Verizon, Sprint enzovoorts). Kan je checken in de RIPE DB als je het route object van je IP range opzoekt, de 'Origin' zou het AS van je ISP moeten zijn.

Voor welke DNS software: kijk voorruit, hoe lang is het leuk om zone's te kloppen, wanneer zou je dit aan klanten/collega's willen overlaten (en dan eventueel via een web interface?) wil je het gaan automatiseren?Dat heeft grote invloed op de juiste keuze

[unezra]

KoeKk schreef op donderdag 7 december 2017 @ 15:35:
Ik denk niet dat je snel een performance issue gaat hebben op je DNS, dan heb je het echt over zo belachelijk veel queries, hebben we het meer over TLD authoratieve servers, niet over de reverse DNS van een paar /24's

True. Dat moet met een VPSje met 1 of 2 cores en 2G geheugen ook nog wel prima te doen zijn natuurlijk. Zo spannend is DNS niet.

Voor die RIPE DB aanpassing: die zal er hoogst waarschijnlijk al staan, anders zou je al praktisch niet bereikbaar moeten zijn (Of je ISP is een van de oude tier 1's zoals KPN, Verizon, Sprint enzovoorts). Kan je checken in de RIPE DB als je het route object van je IP range opzoekt, de 'Origin' zou het AS van je ISP moeten zijn.

Volgens mij staat daar enkel iets voor de /24 omdat zij enkel die /24 announcen. De rest van het block hangt nog in de lucht. Het is (uiteraard) wel van ons, maar er hangt geen partij aan die het mag announcen.

Voor welke DNS software: kijk voorruit, hoe lang is het leuk om zone's te kloppen, wanneer zou je dit aan klanten/collega's willen overlaten (en dan eventueel via een web interface?) wil je het gaan automatiseren?Dat heeft grote invloed op de juiste keuze

Daar heb je een punt.
Dus dan zou het BIND9 met webinterface of PowerDNS met webinterface moeten zijn.

PowerDNS is misschien wel vooral koudwatervrees. Ik ben er totaal niet mee bekend en het dan meteen in productie gaan draaien is best eng.

Sowieso vind ik dat nog wel een interessante discussie op zich: PowerDNS of BIND9.
BIND9 is oud en vertrouwd, PowerDNS is the new kid on the block waar heel slimme mensen aan werken en dat ontzettend goede papieren lijkt te hebben. Maar het is wel een new kid, ziet er toch allemaal totaal anders uit en werkt anders dan good ol' BIND9.

[ Voor 9% gewijzigd door unezra op 07-12-2017 17:34 ]

[CyBeR]

Zo nieuw is PowerDNS niet meer hoor. Ik draai dat al minimaal 10 jaar.

Het is een wat flexibelere optie dan BIND.

[ Voor 20% gewijzigd door CyBeR op 07-12-2017 17:39 ]

[unezra]

@CyBeR Sure maar in vergelijking met BIND is het the new kid.
Bind stamt volgens Wikipedia ergens uit begin jaren 80.

Ik zie dat PowerDNS in 2002 open source werd maar begonnen is als commercieel product.

[paulhekje]

Ga je gelijk IPv6 regelen en IPSEC?
Daar is dit een goed moment voor.

Als men Windows DNS gewend is, is het een optie de primary intern op Windows te draaien, en de extern bereikbare secondary op andere DNS-serversoftware. (cross-vendor kan met IPSEC wel issues geven)

[Out.of.Control]

ITYM: DNSSEC

[paulhekje]

inderdaad DNSSEC

[unezra]

paulhekje schreef op vrijdag 8 december 2017 @ 15:54:
Ga je gelijk IPv6 regelen en IPSEC?
Daar is dit een goed moment voor.

DNSSEC weet ik nog niet maar is interessant meteen te regelen.
IPv6 wil ik pas oppakken als we daadwerkelijk iets met IPv6 gaan doen. Dat nu er meteen in prutsen is denk ik vrij nutteloos.

Als men Windows DNS gewend is, is het een optie de primary intern op Windows te draaien, en de extern bereikbare secondary op andere DNS-serversoftware. (cross-vendor kan met IPSEC wel issues geven)

Ok. Dat is iets om over na te denken.

Helaas verder tot mijn grote frustratie nog niets met de uitvoering kunnen doen. Vrijdag/Zaterdag/Zondag bezig geweest met deel 2 van een migratie en nu geveld door een griepje. (Eigenlijk zondag al maar soms kun je gewoon even niet ziek zijn.) Kortom, ik hoop dat ik maandag echt weer verder kan met dit issue en dan (als mijn hoofd wat helderder is dan nu) een zinvolle beslissing kan nemen.

Wel gisteren bedacht dat we tóch split-horizon nodig gaan hebben. We maken gebruik van plaatjes in onze Outlook signatures, maar dat zijn links naar een externe website. (Draait op onze eigen infra.) So far so good. Maar nu blijkt dat als die plaatjes om wat voor reden dan ook niet te vinden zijn, Outlook extreem traag word. Het gaat zitten wachten op een timeout en dat kan minuten duren. (Dat merk je vooral wanneer je een nieuwe email wilt schrijven en wanneer je die vervolgens wil verzenden.) Outlook freezed "not responding" en is daarmee onwerkbaar traag. We hebben het nu opgelost door het onderliggende issue beet te pakken: Zorgen dat die URL intern weer bereikbaar is. (Was routeringsfoutje, dus hoe dan ook een legitiem issue. Outlook maakte het enkel wat urgenter om op te lossen.)

Dit is wel iets waarvoor ik split-horizon DNS zou willen gebruiken. Nadeel is nu namelijk dat het verkeer dus ook buitenom gaat. Via onze primaire site, het internet op, naar de 2e site en daar richting webserver. Dat verkeer zouden we het liefst intern willen houden, maar dat kan alleen als de nameserver daadwerkelijk een ander antwoord geeft als het request van binnenaf komt.

Nu kun je nog zeggen dat dit juist wel handig is. Het gaat om weinig verkeer en we merken het zo sneller als die specifieke webserver het niet doet. Maar toch twijfel ik of ik het wel netjes vind.

Daar ga ik dus nog even over nadenken. Het is vooral netheid. Want an-sich is het zo weinig verkeer buitenom dat het nauwelijks relevant is en kan het prima. Dus ik moet nadenken of ik het probleem groot genoeg vind om op te lossen of dat ik het lekker zo laat omdat het in de regel eigenlijk zelden tot problemen gaat leiden.

[unezra]

Gisteren nog even over na zitten denken:

Zijn er harde en zinvolle argumenten om níet voor BIND te kiezen?

[Out.of.Control]

Nadeel van BIND vind ik dat recursive en authoritative in één daemon zitten. Dat is natuurlijk met allerlei configuratie-instellingen wel op te lossen, maar ik vind het helderder om dat gescheiden te houden.
Ik ben zelf wel gecharmeerd van Unbound en NSD, maar dat is (in mijn geval) meer voor de hobby dan voor productie.

[paulhekje]

recursive en authorative in één daemon als mogelijkheid is m.i. juist een plus t.o.v. Windows DNS. Je heb zo minder servers nodig.
Afhankelijk van waar het request vandaan komt kun je regelen wat er te resolven is.
Zo kan een eigen DMZ-server bijvoorbeeld via de BIND DNS-server wel de interne DNS-record resolven, en een extern request alleen je publieke records.

[Out.of.Control]

paulhekje schreef op vrijdag 15 december 2017 @ 10:06:
recursive en authorative in één daemon als mogelijkheid is m.i. juist een plus t.o.v. Windows DNS. Je heb zo minder servers nodig.

Dat je recursive en authoritative splitst over aparte daemons betekent niet dat je automatisch aparte servers nodig hebt.

Afhankelijk van waar het request vandaan komt kun je regelen wat er te resolven is.
Zo kan een eigen DMZ-server bijvoorbeeld via de BIND DNS-server wel de interne DNS-record resolven, en een extern request alleen je publieke records.

Nu heb je het over split-horizon voor authoritative DNS, dat is weer een andere discussie.