Onderwerp: Glue record en Round Robin

Ik zit een beetje in de knoop met DNS, glue records en round-robin.

Ik heb
ns1.domain.com
ns2.domain.com
ns3.domain.com

Bij domain.com heb ik bij de registrar tevens de glue records (ipv4 & ipv6) opgegeven.
Voor een 100-tal andere domainen enkel de namen van de DNS servers.

Nu als ik een 4de DNS server in gebruik zou nemen. Dan zou ik ofwel kunnen die 100 domainen aanpassen en ns4 toevoegen (en bij domain.com dus ook).
ofwel zou ik een ns4 kunnen aanmaken zodanig dat ik bijvoorbeeld op ns1 een roundrobin doe die zowel ip van ns1 als van ns4 doorgeeft. Tot zover lukt dat zonder veel problemen. Behalve dan voor domain.com zelf. Wat geef ik dan als glue record mee? Het ip van ns1 of dat van ns4, of beide?

Round-robin DNS garandeert niet dat je bij het falen van de server achter ns1.domain.com automatisch doorgaat naar de server van ns4.domain.com.
Andersom; als ns4.domain.com faalt zal ook 50% van de queries naar ns1.domain.com falen.

Wil je dus echt gebruik maken van de extra redundantie van ns4.domain.com dan zal je deze bij alle domeinen toe moeten passen als apart domein.

Een andere optie is om een anycast IP aan ns1.domain.com te hangen, die zowel door ns1 als ns4 gebruikt worden.

Ivm failen weet ik dat het idd geen oplossing geeft.
Dus de roundrobin zoals bij een A record zou voor een NS wel degelijk moeten werken, maar wat dan met de GLUE records, daar zit ik vooral mee

Als je het niet voor redundancy gebruikt, waarvoor dan wel? Denk dat een hoop applicaties/panels/servers niet voorbereid zijn op round-robin DNS, omdat het geen enkel nut dient.

Het blijft overigens nog steeds een A-record, volgens mij wordt round-robin op andere records niet ondersteund. In het geval van nameservers zou je registrar twee GLUE records voor ns1.domain.com aan moeten maken.
Alternatief is om domain.com te delegeren aan ns1-4.otherdomain.com en in die nameservers twee A-records maken voor ns1.domain.com

De bedoeling is om extra DNS servers te kunnen bijvoegen zonder de domain-records voor alle andere domains te moeten wijzigen;
Ik heb nu al ns1..ns4, als ik er later nog 5 andere aan toevoeg, dan zit ik zowiezo qua aantal al over de max die de meeste registrars zouden aankunnen, vandaar het idee van de in round-robin te zetten.
Het is dus een soort van redundancy, maar niet op de manier dat als één van de IPs niet werkt dat deze dan niet meer zou aangesproken worden (gezien round-robin zo niet werkt).

Wat is het nut? Als er achter elk van de nameservers die je published 1 IP down is, dan bestaat de kans dat er helemaal geen nameresolution is, ondanks het feit dat de helft van je nameservers wel gewoon up is.

Ook moet je de vraag stellen of je wel goed bezig bent, als je 3 of 4 (gescheiden) nameserver hebt en er toch in zou slagen om ze allemaal op hetzelfde moment down te krijgen... :P

Enige reden die ik zou kunnen bedenken om het wel te doen, is als je die IP adressen zou kunnen laten verdelen op basis van de geogrfische locatie ipv random roundrobin, maar aangezien dit iets is wat op de nameservers van de registry moet gebeuren, denk ik niet dat dit echt mogelijk is.

Stel dat je het IP van host ns4 toevoegt als round-robin van ns1.domain.com dan betekent het falen van ns4 gelijk dat 50% van de queries aan ns1.domain.com onbeantwoord blijven, ondanks dat de host ns1 prima werkt.

Je bent jezelf nu aan het saboteren en met redundancy heeft het niks meer te maken.

Het oplossen van de limiet van 5 nameservers is anycasting, niet round-robin.

En hoe pak ik die anycast dan aan?

In overleg met je transit provider(s) en Google: http://www.google.nl/search?q=anycast+dns

Oorspronkelijk geplaatst door EricV

In overleg met je transit provider(s) en Google: http://www.google.nl/search?q=anycast+dns

Voor veel partijen een ietwat theoretisch advies hier.

Je moet dus zelf op twee locaties zitten (ok, kan)

Het kost je minimaal een /24 , die dan alleen maar voor anycast-compatible diensten gebruikt kan worden. (diensten zonder state. Niet zo goed voor tcp met langer durende sessies). (kan ook, voor sommigen)

Er zijn niet zo veel partijen voor wie anycast voor extern-bereikbare authoritive DNSen daardoor handig is.

Anycast binnen je eigen netwerk kan ook, en kost je niet zoveel adressen.
(Die minimaal /24 is omdat transits en peers gewoonlijk (en terecht) geen langere prefixen accepteren. Sterker, op een aantal plekken zullen de root-dns server prefixen al een uitzondering zijn binnen de prefix lengte filters).

hmm gezien we dit alles met VPSen doen, zal het vrees ik dan niet zo haalbaar zijn :-(

Oorspronkelijk geplaatst door visser

Het kost je minimaal een /24 , die dan alleen maar voor anycast-compatible diensten gebruikt kan worden. (diensten zonder state. Niet zo goed voor tcp met langer durende sessies). (kan ook, voor sommigen)

Voor meer info over Anycast en TCP zie oa http://www.nanog.org/meetings/nanog3...att.levine.pdf

Oorspronkelijk geplaatst door dirkb

hmm gezien we dit alles met VPSen doen, zal het vrees ik dan niet zo haalbaar zijn :-(

Er zijn partijen waarbij je deze dienst kant-en-klaar kan inhuren, maar een goede referentie heb ik niet voor je. Misschien iemand anders?

Oorspronkelijk geplaatst door EricV

Voor meer info over Anycast en TCP zie oa http://www.nanog.org/meetings/nanog3...att.levine.pdf

Die kende ik. Ok, ik schreef wat kort door de bocht.
Die presentatie zegt een paar dingen:
"Het werkt voor ons" "Niet zo veel TCP sessies duren lang"
"Meet (en laat het ons weten)."

Voor de OP (of anderen die het overwegen) is interessant hoe stabiel diens colo/transit boeren zijn, en dat *alle* diensten die in de anycast prefix zitten feitelijk stateless, kortdurende state, of synchronisatie moeten doen.
En natuurlijk dat alle diensten in de anycast prefix op alle bron-locaties aanwezig moeten zijn en moeten werken.
Aangenomen *dat* je die /24 of groter ervoor hebt.

Anycast is een heel fraaie hack, die ik graag op passende plekken aanraad.
Maar wie niet alle ins en outs ervan snapt, moet er vooral niet aan beginnen.

De OP zit volgens mij niet in de positie dat Anycast een optimale oplossing voor zijn authoritieve DNS server probleem is.

Oorspronkelijk geplaatst door EricV

Er zijn partijen waarbij je deze dienst kant-en-klaar kan inhuren, maar een goede referentie heb ik niet voor je. Misschien iemand anders?

We willen het juist allemaal zelf gaan beheren en niet meer uitbesteden...
Heb net ook van onze registrar gehoord dat ze het aantal DNS servers per domain niet hoger dan 4 kunnen/willen zetten omdat voor sommige TLDs (vraag mij dan wel af welke) het niet mogelijk is om er meer dan 4 te hebben :-(

In dat geval zou ik 4 servers in verschillende netwerken/datacentra neerzetten, of bijvoorbeeld een server huren op verschillende continenten. De kan dat ze dan alle 4 een storing hebben is verwaarloosbaar.
Bij de meeste registrars kan je nameservers toepassen middels een template, dus wijzigingen zijn eenvoudig globaal door te voeren.