Onderwerp: Advies opzetten webhosting (zeer kleinschalig)

<knip>

Ik hoor iedereen maar praten over het feit dat je DNS servers niet in 1 netwerk moet zetten.
Ben ik het helemaal mee eens maar in heel veel situaties maakt het niets uit.

Kijk een domeinboer als Transip doet voor domeinnamen de DNS, dus netwerk gescheiden enz is wel handig
Ik heb bijv. een paar websites die ik in hetzelfde netwerk of zelfs op dezelfde server host.
Als mijn DNS offline is, dan zijn mijn websites ook voor 100 procent offline (gehele server is dan vaak het probleem).

Kijk, ga ik de mail afhandelen bij een externe dan zal die niet meer doorkomen omdat de DNS (en vaak tevens ook de webserver) server offline is.

Mijn advies: Ga je alle sites ook zelf hosten, dus hele rataplan met mail enz, dan zou ik het lekker zelf hosten (DNS), verdeeld over 2 servers. Kun je tenminste onderhoud plegen.
Ga je niet alles zelf hosten, zou ik inderdaad een VPS overwegen waarin je het 1 en ander laat syncen met elkaa (en dan vooral om eventuele externe sites waar je enkel de dns voor doet online te houden, of mail records).

Oorspronkelijk geplaatst door Vanderblom

Kijk een domeinboer als Transip doet voor domeinnamen de DNS, dus netwerk gescheiden enz is wel handig
Ik heb bijv. een paar websites die ik in hetzelfde netwerk of zelfs op dezelfde server host.
Als mijn DNS offline is, dan zijn mijn websites ook voor 100 procent offline (gehele server is dan vaak het probleem).

Het heeft niet te maken met het feit dat als je webserver down is je dns ook down mag zijn, maar met het feit dat je TTL niet verloopt en je e-mail bij de providers het later nog eens probeert te verzenden. Van zodra je geen records meer hebt die resolven failt al de rest ook dus worden e-mail direct rejected en als je dns dan terug online is moet je weer wachten tot de providers ze terug opnemen (in het geval je TTL verlopen was).

Oorspronkelijk geplaatst door The-BosS

Het heeft niet te maken met het feit dat als je webserver down is je dns ook down mag zijn, maar met het feit dat je TTL niet verloopt en je e-mail bij de providers het later nog eens probeert te verzenden. Van zodra je geen records meer hebt die resolven failt al de rest ook dus worden e-mail direct rejected en als je dns dan terug online is moet je weer wachten tot de providers ze terug opnemen (in het geval je TTL verlopen was).

Het punt dat mail (bij de afzender) gereject gaat worden is een terecht punt.
Het "wachten tot de providers ze terug opnemen" van DNS queries wanneer de NS'en een tijdje onbereikbaar geweest zijn valt nogal mee als probleem.

DNS doet negatieve caching (cachen van een server fail of record not found), maar veel korter dan de TTL gebaseerde caching van positieve antwoorden.

RFC2308 zegt dat het cachen van een server die onbereikbaar is mag, maar maximaal voor vijf minuten.
(Wanneer de server wel bereikbaar is, maar de expliciet zegt dat een record niet bestaat wordt dat antwoord ook gecached; Maar in dat geval met de minimum TTL uit de SOA als negatieve TTL. )

Een resolver die probeert iets aan je DNS te vragen terwijl die down geweest is zal dus (indien rfc compliant) hooguit vijf minuten wachten met het opnieuw proberen voor een volgende query.

Oorspronkelijk geplaatst door The-BosS

Het heeft niet te maken met het feit dat als je webserver down is je dns ook down mag zijn, maar met het feit dat je TTL niet verloopt en je e-mail bij de providers het later nog eens probeert te verzenden. Van zodra je geen records meer hebt die resolven failt al de rest ook dus worden e-mail direct rejected en als je dns dan terug online is moet je weer wachten tot de providers ze terug opnemen (in het geval je TTL verlopen was).

Je begrijpt me verkeerd. Ik ga er vanuit dat veel servers ook de DNS doet, dus dat alles op 1 server staat.
Maar wat jij aangeeft daar draait het inderdaad om.

Oorspronkelijk geplaatst door Vanderblom

Ik hoor iedereen maar praten over het feit dat je DNS servers niet in 1 netwerk moet zetten.
Ben ik het helemaal mee eens maar in heel veel situaties maakt het niets uit.

Kijk een domeinboer als Transip doet voor domeinnamen de DNS, dus netwerk gescheiden enz is wel handig
Ik heb bijv. een paar websites die ik in hetzelfde netwerk of zelfs op dezelfde server host.
Als mijn DNS offline is, dan zijn mijn websites ook voor 100 procent offline (gehele server is dan vaak het probleem).

Kijk, ga ik de mail afhandelen bij een externe dan zal die niet meer doorkomen omdat de DNS (en vaak tevens ook de webserver) server offline is.

Mijn advies: Ga je alle sites ook zelf hosten, dus hele rataplan met mail enz, dan zou ik het lekker zelf hosten (DNS), verdeeld over 2 servers. Kun je tenminste onderhoud plegen.
Ga je niet alles zelf hosten, zou ik inderdaad een VPS overwegen waarin je het 1 en ander laat syncen met elkaa (en dan vooral om eventuele externe sites waar je enkel de dns voor doet online te houden, of mail records).

Ik snap je verhaal niet, het is dus ok dat als je server 5 min niet bereikbaar is door een kleine netwerkstoring dat een resolver die je records niet heeft (omdat ie bv net gerestart is) geen antwoord krijgt en de mail bedoeld voor je server gewoon weggooit of bounced?

En mocht je een foutje maken in de zone op je enige nameserver (met 2 ip's in dezelfde range) dan is het ook prima dat resolvers cachen dat je website/email/etc niet bestaat? Dat je dan voor enkele uren onbereikbaar bent is het waard om geen 2 dns servers in 2 netwerken/datacenters te draaien?

Oorspronkelijk geplaatst door vDong

[..]

En mocht je een foutje maken in de zone op je enige nameserver (met 2 ip's in dezelfde range) dan is het ook prima dat resolvers cachen dat je website/email/etc niet bestaat? Dat je dan voor enkele uren onbereikbaar bent is het waard om geen 2 dns servers in 2 netwerken/datacenters te draaien?

Je lijkt hier te zeggen dat een outage, door negatieve caching tot enkele uren extra onbereikbaarheid kan leiden ?

Zo werkt negatieve caching niet. Zie mijn posting in deze thread.

Overigens, als je "foutje in de zonefile" als oorzaak neemt, daar helpen meerdere DNSen in meerdere datacenters natuurlijk niet tegen, want die zonefile met fout wordt evenzeer over alle DNSen gerepliceerd als een goede zonefile

Oorspronkelijk geplaatst door visser

Je lijkt hier te zeggen dat een outage, door negatieve caching tot enkele uren extra onbereikbaarheid kan leiden ?

Zo werkt negatieve caching niet. Zie mijn posting in deze thread.

Nee hoor, ik zeg alleen dat in die 5 min downtime alle mail retour gaat ipv even gequeued op de uitgaande smtp.

Overigens, als je "foutje in de zonefile" als oorzaak neemt, daar helpen meerdere DNSen in meerdere datacenters natuurlijk niet tegen, want die zonefile met fout wordt evenzeer over alle DNSen gerepliceerd als een goede zonefile

Een secondairy zal echt weigeren om een zonefile te updaten als de master geen SOA record heeft (en dus geen idee heeft of de slave up to date is)
Behalve als je zonefiles rsynced (niet echt gebruikelijk) kan die situatie niet bestaan.
Als je geen idee hebt waarom een compleet domein niet meer werkt omdat je een foutje in de zone file maakt, zal je waarschijnlijk geen gebruik maken van bind (en dan ben je een van de gelukkigen)

Oorspronkelijk geplaatst door vDong

[..]

Een secondairy zal echt weigeren om een zonefile te updaten als de master geen SOA record heeft (en dus geen idee heeft of de slave up to date is)
Behalve als je zonefiles rsynced (niet echt gebruikelijk) kan die situatie niet bestaan.
Als je geen idee hebt waarom een compleet domein niet meer werkt omdat je een foutje in de zone file maakt, zal je waarschijnlijk geen gebruik maken van bind (en dan ben je een van de gelukkigen)

Het worden een beetje byzantijnse scenario's, op welke manier een foutje in de zonefile nog wel of nog geen zichtbaar effect heeft bij een bepaalde server setup.
Als de master ook zichtbaar is, heeft in dit scenario nog steeds 1/n (de helft, bij twee NS'en ,of 1/3 bij drie) van de bezoekers er zichtbaar last van.
Maar ik moet zeggen dat ik een foutscenario op basis van een syntactische fout in de zonefile die niet gecontroleerd/gevonden wordt op de (hidden ?) master en dan wel op de slaves een beetje vergezocht vindt.
Aangezien je aanneemt dat er geen rsync gebruikt wordt, zullen de slaves, als ze een tijdlang geen valide zonetransfer van de master kunnen doen ook stoppen met het geven van antwoorden. Kortom, je hebt alleen een wat langere tijd om je fout te ontdekken en herstellen hier, maar moet dat ontdekken blijkbaar zonder hulp van tools of checks doen, want je hebt 'm wel op de master gezet.
Om het dan te ontdekken moet je of zelf 'gewoon' een brainwave krijgen, of dan ontdekken dat je (bedoelde) wijziging nog niet op de slaves doorkomt, en dat de oorzaak die syntax fout is.

Een fout in de zonefile waar qua syntax/zonetransfer niks mis mee is, maar wel het domein of hosts erin onbereikbaar maakt lijkt me een iets meer aannamelijker model.

Maar hoe dan ook, de aanbeveling van gescheiden netwerken en gescheiden DC's heeft het voorkomen van Single Point of Failure's in de technische infrastructuur als achtergrond, en helpt niet tegen fouten hoger in de keten zoals de inhoud van zonefiles.
(tenminste, wanneer je alle DNS'en voedt vanuit een enkele bron.)

Laatste antwoord, omdat we wel erg afdwalen

Oorspronkelijk geplaatst door visser

Het worden een beetje byzantijnse scenario's, op welke manier een foutje in de zonefile nog wel of nog geen zichtbaar effect heeft bij een bepaalde server setup.
Als de master ook zichtbaar is, heeft in dit scenario nog steeds 1/n (de helft, bij twee NS'en ,of 1/3 bij drie) van de bezoekers er zichtbaar last van.

Onterecht, is niet hoe resolver libraries werken, als ze 1 negatief en 1(of meer keer) een ip adres terug krijgen gebruiken ze die.
<knip>

Aangezien je aanneemt dat er geen rsync gebruikt wordt, zullen de slaves, als ze een tijdlang geen valide zonetransfer van de master kunnen doen ook stoppen met het geven van antwoorden.

Incorrect, de slave blijft gewoon antwoord geven, ook als de master nooit meer terugkeert.

Oorspronkelijk geplaatst door vDong

Laatste antwoord, omdat we wel erg afdwalen

't gaat wel richting violent agreement inderdaad...

Maar toch enig disagreement:

Oorspronkelijk geplaatst door vDong

Onterecht, is niet hoe resolver libraries werken, als ze 1 negatief en 1(of meer keer) een ip adres terug krijgen gebruiken ze die.
<knip>

Niet wat ik bedoelde : bij een authoritief antwoord (ook fout) gaat een resolver niet verder vragen. Een dode server leidt wel tot door zoeken.

Oorspronkelijk geplaatst door vDong

Incorrect, de slave blijft gewoon antwoord geven, ook als de master nooit meer terugkeert.

Je ging blijkbaar uit van een AXFR model (geen rsync, en master/slave terminologie), en in de SOA staat hoe lang een slave mag antwoorden zonder refresh/check met de master.
(refresh - retry - expiry). Na het verlopen van de expiry stopt de slave met antwoorden voor die zone.
De aanbevolen expiry time is typisch wel erg lang (weken), maar ook dat is te kort voor een master die _nooit_ terugkomt.

Werkt elke DNS server met een eigen bron van zoneinformatie (die eventueel via rsync, of gedeelde db, of wat dan ook centraal geupdate wordt) is de term slave niet van toepassing.

Ik zou een VPS nemen met een controlpanel als Plesk, Direct Admin of Cpanel. Je hebt dan shell acces maar geen beheer aan hard-software.
Webhosters zijn webhosters en software ontwikkelaars zijn... juist software ontwikkelaars.