wijziging mx record, hoe lang duurt het?
kj
mailserver).
Dan krijg je na de wijziging weer zo'n heerlijk 'vage opmerking':
"Het kan enige tijd duren voordat........"
Hoe lang duurt deze/zo'n aanpassing (ander MX record dus) bij xs4all (in de
regel/ong)?
Danny Terweij
"kj" <iem...@microsoft.com> schreef in bericht
news:4994a9d2$0$182$e4fe...@news.xs4all.nl...
Stel dat xs4all binnen een uur hun DNS update doen.... kan het nog wel eens
48 uur duren voordat het helemaal goed werkt. Dit heeft te maken met de TTL
tijden.
Ik zet altijd! belangrijke records die eventueel een snelle verandering moet
ondergaan op een TTL van 3600. Dat scheelt een hoop stress :)
Danny.
kj
"Danny Terweij" <spam...@p-s.nl> schreef in bericht
news:4994aa93$0$201$e4fe...@news.xs4all.nl...
Ok thx,
TTL is alleen niet aan te passen in het service center van xs4all,
helaas.............
Kuifmans
>>> Hoe lang duurt deze/zo'n aanpassing (ander MX record dus) bij
>>> xs4all (in de regel/ong)?
>>
>> Stel dat xs4all binnen een uur hun DNS update doen.... kan het nog
>> wel eens 48 uur duren voordat het helemaal goed werkt. Dit heeft te
>> maken met de TTL tijden.
>>
>> Ik zet altijd! belangrijke records die eventueel een snelle
>> verandering moet ondergaan op een TTL van 3600. Dat scheelt een hoop
>> stress :)
>
> Ok thx,
> TTL is alleen niet aan te passen in het service center van xs4all,
> helaas.............
Ga er maar van uit dat de meeste ISP's niet aan caching doen.
Als ik bij NXS of DDS een wijziging aanbreng dan "weet" in ieder geval xs4all
vrijwel meteen het juiste IP adres op te hoesten.
Mijn modem (SpeedTouch) geeft bij een nslookup dan nog wel om en om het "oude"
en "nieuwe" adres.
Voor mensen met Windows (2000/XP/Vista) die "problemen" hebben, helpt het
meestal om een ipconfig/flushdns uit te voeren.
Of beter nog, de DNS Client service (resolver cache) uit te schakelen...
--
Kuifmans
kj
Nu ik er over nadenk vind ik 2 dagen ook niet logisch en lijkt me niet
(nodig). Die 2 dagen voor een DNS wist ik en snap ik.
Maar ik verander geen DNS of domeinnaam. Het de domein (abc.nl) staat nog
gewoon bij xs4all, daar veranderd niets aan. Alleen de mail dient
anders/elders afgeleverd te worden. De mailtjes aan abc.nl gaan dus in
eerste instantie nog gewaon naar xs4all en worden vanaf daar meteen
doorgepasst naar de nieuwe mailserver, omdat ik die nwe server in de
DNS-editor van xs4all heb gezet. Toch?
Correct me if i'm wrong....
Danny Terweij
"Kuifmans" <nos...@nospam.demon.nl> schreef in bericht
news:4994cbf6$0$188$e4fe...@news.xs4all.nl...
> Als ik bij NXS of DDS een wijziging aanbreng dan "weet" in ieder geval
> xs4all vrijwel meteen het juiste IP adres op te hoesten.
> Mijn modem (SpeedTouch) geeft bij een nslookup dan nog wel om en om het
> "oude" en "nieuwe" adres.
> Voor mensen met Windows (2000/XP/Vista) die "problemen" hebben, helpt het
> meestal om een ipconfig/flushdns uit te voeren.
> Of beter nog, de DNS Client service (resolver cache) uit te schakelen...
Ja dat is dicht bij... maar verder weg in de keten zul je toch echt moeten
wachten totdat de TTL is expired.
Vooral met MX is dat een vervelend geval omdat het om email gaat dat je
graag wilt ontvangen. Stel je buurman wil je een email sturen, je hebt de MX
gewijzigd en je kan zelf het nieuwe MX IP zien. Dan zit je buurman nog
steeds met die oude cache informatie.
Echt, het kan zeker 48 uur duren voordat iedereen het nieuwe MX ziet. Ook op
client nivo dus.
Ik zelf gebruik mijn eigen DNS server lokaal op mijn linux hier en als ik
zelf een snelle wijziging wil zien dan doe ik ook een named restart en de
windows cache legen. Dan zie ik de wijziging wel. Maar de computer ernaast
ziet dat nog niet.
Ik hoop dat het een beetje duidelijk is nu.
Danny.
Danny Terweij
>
> "Danny Terweij" <spam...@p-s.nl> schreef in bericht
> news:4994aa93$0$201$e4fe...@news.xs4all.nl...
> Nu ik er over nadenk vind ik 2 dagen ook niet logisch en lijkt me niet
> (nodig). Die 2 dagen voor een DNS wist ik en snap ik.
Zie mijn andere post. Echt het duurt maximaal zo een 48 uur.
Danny.
Miquel van Smoorenburg
kj <iem...@microsoft.com> wrote:
>
>"Danny Terweij" <spam...@p-s.nl> schreef in bericht
>news:4994aa93$0$201$e4fe...@news.xs4all.nl...
>>
>> "kj" <iem...@microsoft.com> schreef in bericht
>> news:4994a9d2$0$182$e4fe...@news.xs4all.nl...
>>> Ik heb de MX record(s) van mijn Advanced Hosting pakket
>aangepast (eigen
>>> mailserver).
>>> Dan krijg je na de wijziging weer zo'n heerlijk 'vage opmerking':
>>> "Het kan enige tijd duren voordat........"
>>
>>> Hoe lang duurt deze/zo'n aanpassing (ander MX record dus)
>bij xs4all (in
>>> de regel/ong)?
>>
>> Stel dat xs4all binnen een uur hun DNS update doen.... kan
>het nog wel
>> eens 48 uur duren voordat het helemaal goed werkt. Dit
>heeft te maken met
>> de TTL tijden.
nou, dan heb je wel hele gare resolver software. de ttl
(standaard 86400, 1 dag) is de cache-tijd.
>Nu ik er over nadenk vind ik 2 dagen ook niet logisch en
>lijkt me niet
>(nodig). Die 2 dagen voor een DNS wist ik en snap ik.
>Maar ik verander geen DNS of domeinnaam. Het de domein
>(abc.nl) staat nog
>gewoon bij xs4all, daar veranderd niets aan. Alleen de mail dient
>anders/elders afgeleverd te worden. De mailtjes aan abc.nl
>gaan dus in
>eerste instantie nog gewaon naar xs4all en worden vanaf daar meteen
>doorgepasst naar de nieuwe mailserver, omdat ik die nwe server in de
>DNS-editor van xs4all heb gezet. Toch?
nee... als je de mail dienst bij xs niet hebt opgezegd,
en de mail komt binnen op de inkomende servers van xs,
dan wordt het gewoon volgens de manier waarop
je het hebt ingeteld afgeleverd.
Als er geen mail configuratier aanwezig is voor jouw
domein op de inkomende mailservers en er komt toch
mail aan, dan wordt het geweigerd.
Juiste volgorde is dus:
- dns aanpassen
- tot de ttl wachten
- mail nog 1x bij xs ophalen
- mail dienst bij xs uit laten zetten
dan gaat er geen mail verloren.
Mike.
Rob
> Echt, het kan zeker 48 uur duren voordat iedereen het nieuwe MX ziet. Ook op
> client nivo dus.
Alleen bij een defecte client.
De TTL is 86400 dus kan het maximaal 24 uur duren. Alles wat het langer
duurt wijst op een defecte resolver ergens, die dingen langer cached dan
waar hij toestemming voor krijgt.
Rob
> Ik zet altijd! belangrijke records die eventueel een snelle verandering moet
> ondergaan op een TTL van 3600. Dat scheelt een hoop stress :)
Je kunt bij XS4ALL niet zelf je TTL waarde kiezen. Is altijd 86400.
Winfried Tilanus
Hoi,
> Ga er maar van uit dat de meeste ISP's niet aan caching doen.
>
> Als ik bij NXS of DDS een wijziging aanbreng dan "weet" in ieder
> geval xs4all vrijwel meteen het juiste IP adres op te hoesten.
Ik weet van eigen DNS-wijzigingen heel zeker dat resolvers van XS4ALL
netjes cachen totdat het expired is.
Weet je zeker dat dat DNS-record in de cache van XS4ALL zit op het
moment dat je de wijziging maakt? Als het niet in de cache zit, dan
wordt het direct opgevraagd, en is de wijziging inderdaad direct
zichtbaar. Zit het wel in de cache, dan moet die eerst expiren voordat
voordat het opnieuw opgevraagd wordt.
Het is vrij onvoorspelbaar hoe lang het bij elke DNS-server gaat duren
voordat de cache expired. Het enige wat je weet is dat het nooit langer
kan duren dan de time to live (die de DNS-server mee kreeg bij de
laatste keer opvragen).
Winfried
Winfried Tilanus
> Je kunt bij XS4ALL niet zelf je TTL waarde kiezen. Is altijd 86400.
Ik zou het heel behulpzaam vinden als in het service-centrum een vinkje
komt met: "verlaag de TTL voor een periode van 48 uur naar 600". Dan
hoef ik niet bij elke DNS-wijziging unixbeheer te mailen, terwijl XS4ALL
niet permanent met korte TTL's zit...
groet,
Winfried
Rob
Tja ik kan nog zoooooooooo veel dingen noemen die heel behulpzaam zouden
zijn in de DNS editor!
- niet bij iedere wijziging helemaal terug vliegen naar het service centrum
maar netjes naar het (bijgewerkte) overzicht gaan
- support voor TXT records
- support voor SRV records
... maar ja die wensen staan al jaren open en het lijkt er niet op dat
bijwerken van dit tool een prioriteit is.
Danny Terweij
"Rob" <nom...@example.com> schreef in bericht
news:slrngpagqj....@xs7.xs4all.nl...
Nee, je vergeet dat bijvoorbeeld bij xs4all het volgende is:
Jij>xs4alldns>root dns.
2x caching dus. dus 2x 24 uur. Want ze expiren nooit op het exacte moment.
Danny.
Hans
"Danny Terweij" <spam...@p-s.nl> wrote in message
news:49955328$0$194$e4fe...@news.xs4all.nl...
Ik dacht dat ik wel wat van DNS afwist.
Maar deze reken wijze snap ik niet.
Graag uit leggen waarom het 2 x 24 uur is.
Miquel van Smoorenburg
't is nog erger:
jij > resolver > root dns > .nl dns > xs4all dns !
gelukkig doet dat allemaal volledig niets ter zake voor TTL / caching :)
Mike.
Rob
Dat zeg ik. Als ze niet op het moment expiren wat ze in de TTL krijgen
dan zijn het defecte resolvers. Kan best zijn dat jij ergens een defecte
resolver in je pad hebt, hoor. Maar dat betekent nog niet dat dat een
algemeen probleem is.
Winfried Tilanus
Hoi,
> Tja ik kan nog zoooooooooo veel dingen noemen die heel behulpzaam zouden
> zijn in de DNS editor!
>
> - niet bij iedere wijziging helemaal terug vliegen naar het service centrum
> maar netjes naar het (bijgewerkte) overzicht gaan
>
> - support voor TXT records
>
> - support voor SRV records
>
> ... maar ja die wensen staan al jaren open en het lijkt er niet op dat
> bijwerken van dit tool een prioriteit is.
Mee eens, alledrie punten die ik ook graag toegevoegd / veranderd zou zien.
Soms vraag ik me af of niet goed zou zijn om een XS4ALL-whislist te
starten (wiki, voting?), dan kunnen allemaal van dit soort dingen eens
gestructureerd bijhouden...
groet,
Winfried
Rob
Er is een experimentele diensten forum bij XS4ALL wat daar voor bedoeld is,
en waar die wensen ook wel op te vinden zijn.
Kees Nuyt
Wat zou je ervan zeggen als de code open source gemaakt werd?
Er zijn onder de xs4all klanten vast wel een paar nerds te vinden
die er graag hun tanden in zetten.
Aan xs4all de vrijheid om patches / nieuwe versies na een review
al dan niet in te zetten.
>groet,
>
>Winfried
--
) Kees
(
c[_] There are only two kind of peeps...
...those that make backups and those
that never had a hard drive fail.
-- **loki969** on /. [#555]
Danny Terweij
>> 2x caching dus. dus 2x 24 uur. Want ze expiren nooit op het exacte
>> moment.
> Dat zeg ik. Als ze niet op het moment expiren wat ze in de TTL krijgen
> dan zijn het defecte resolvers. Kan best zijn dat jij ergens een defecte
> resolver in je pad hebt, hoor. Maar dat betekent nog niet dat dat een
> algemeen probleem is.
Heb je wel eens naar de ttl counters gekeken bij het dig resultaat?
ns2.google.com. 2d14h59m30s IN A 216.239.34.10
ns3.google.com. 2d15h5m29s IN A 216.239.36.10
ns4.google.com. 2d15h9m4s IN A 216.239.38.10
ns1.google.com. 2d14h51m46s IN A 216.239.32.10
;; Total query time: 6 msec
;; FROM: xs6.xs4all.nl to SERVER: 127.0.0.1
;; WHEN: Fri Feb 13 23:20:06 2009
;; MSG SIZE sent: 28 rcvd: 326
en
ns4.google.com. 1d14h57m18s IN A 216.239.38.10
ns1.google.com. 1d14h57m18s IN A 216.239.32.10
ns3.google.com. 1d14h57m18s IN A 216.239.36.10
ns2.google.com. 1d14h57m18s IN A 216.239.34.10
;; Total query time: 15 msec
;; FROM: xs3.xs4all.nl to SERVER: 127.0.0.1
;; WHEN: Fri Feb 13 23:21:00 2009
;; MSG SIZE sent: 28 rcvd: 326
Om maar een voorbeeld te geven, elke resolver op het internet staat anders.
Dus de expire tijd als de TTL op 86400 staat kan max 48 uur duren wat
betekend dat bij een DNS wijziging het dus wel even kan duren voordat het is
doorgevoerd.
En bij MX omdat het email betreft en je eigenlijk niks wil missen moet je
minimaal 48 uur van te voren dubbele mailservers hebben draaien, dan de MX
wijzigen en na 48 uur kun je de oude server offline doen. Dan weet je zeker
dat je geen email mist, dat er geen email bounced, dat er geen email
vertraging plaats vind.
Dus niks met defecte resolvers. resolvers halen pas nieuwe gegevens op nadat
de TTL op de resolver is expired. Als die resolver opnieuw gegevens vraagd
aan zijn resolver en die heeft nog de oude info dan krijgt die eerste
resolver eerst nog de oude info.
Ik heb het zat meegemaakt in de praktijk en het is echt zo :-S.
Danny.
Mark Huizer
>
> Dus niks met defecte resolvers. resolvers halen pas nieuwe gegevens op nadat
> de TTL op de resolver is expired. Als die resolver opnieuw gegevens vraagd
> aan zijn resolver en die heeft nog de oude info dan krijgt die eerste
> resolver eerst nog de oude info.
En dat is dan op zich wel een niet zo nette resolver, zoals jij het
presenteert.
Je zal zien bij de xs4all nameservers dat de TTL aftelt van de entries
in de cache. Als een andere cache het daaraan vraagt, krijgen ze dus een
lagere TTL mee.
>
> Ik heb het zat meegemaakt in de praktijk en het is echt zo :-S.
Klopt, er zijn genoeg verschillende stukken DNS software die
verschillend met dingen omgaan, en er zijn er ook die TTL's negeren, of
een minimale tijd gebruiken.
Net als met alles op het Internet :-) ben ruimdenkend in wat je verwacht
van anderen
Mark
Rob
Dat zijn dig's voor NS records. En niet van XS4ALL ook.
We hadden het over MX records van XS4ALL klanten, is niet?
Ik beweer dat de TTL daarvan op 86400 staat en jij komt aan met een
voorbeeld van een andere server die een langere TTL hanteert, en dan
ook nog voor een recordtype waarvan de data vrijwel nooit verandert.
www.google.nl. 7200 IN CNAME www.google.com.
www.google.com. 7200 IN CNAME www.l.google.com.
www.l.google.com. 278 IN A 74.125.79.104
www.l.google.com. 278 IN A 74.125.79.147
www.l.google.com. 278 IN A 74.125.79.99
www.l.google.com. 278 IN A 74.125.79.103
Kijk dir zijn heel andere waarden.
> Om maar een voorbeeld te geven, elke resolver op het internet staat anders.
> Dus de expire tijd als de TTL op 86400 staat kan max 48 uur duren wat
NEE NEE NEE.
Waar haal je die onzin toch vandaan?
Als de TTL op 86400 staat kan het maximaal 24 uur duren. NIET 48.
> betekend dat bij een DNS wijziging het dus wel even kan duren voordat het is
> doorgevoerd.
> En bij MX omdat het email betreft en je eigenlijk niks wil missen moet je
> minimaal 48 uur van te voren dubbele mailservers hebben draaien, dan de MX
1 milliseconde is genoeg. 48 uur is nergens voor nodig.
> wijzigen en na 48 uur kun je de oude server offline doen. Dan weet je zeker
> dat je geen email mist, dat er geen email bounced, dat er geen email
> vertraging plaats vind.
Als de oude server echt offline gaat kun je dat ook meteen doen, je zult
dan in de praktijk geen mail missen maar het kan 24 uur duren voor je
het ontvangt. De meeste servers zullen niet binnen 24 uur mail weggooien
als de server niet reageert.
Blijft de server wel bestaan maar pakt ie geen mail meer voor dat domein
aan, dan is het een andere zaak. Dan moet je 24 uur wachten met die actie
uit te voeren.
Vooruit, wellicht nog wat extra voor reserve.
Maar dat "verdubbel het maar vanwege de caching resolvers" dat is uit
de lucht gegrepen.
> Dus niks met defecte resolvers. resolvers halen pas nieuwe gegevens op nadat
> de TTL op de resolver is expired. Als die resolver opnieuw gegevens vraagd
> aan zijn resolver en die heeft nog de oude info dan krijgt die eerste
> resolver eerst nog de oude info.
Maar dat alles maximaal gedurende de TTL.
Er is nergens iets wat er voor zorgt dat een TTL van 86400 leidt tot
48 uur oude info.
> Ik heb het zat meegemaakt in de praktijk en het is echt zo :-S.
Je ziet spoken of je hebt verrotte DNS software geinstalleerd.
Wim J
Ja, ik heb ook een wens: ik wil graag meer dan 10 email adressen
per pop box.
Dan kan ik 1 mail box blijven gebruiken en toch heel makkelijk
tijdelijke email adressen aanmaken.
Wim
Jurjen Oskam
> Om maar een voorbeeld te geven, elke resolver op het internet staat anders.
> Dus de expire tijd als de TTL op 86400 staat kan max 48 uur duren wat
> betekend dat bij een DNS wijziging het dus wel even kan duren voordat het is
> doorgevoerd.
Nee, nee, nee. Een record dat een TTL van 86400 heeft wordt echt maar
maximaal 86400 seconden (24 uur) gecached, aangenomen dat je geen buggy
DNS server hebt.
Hoe lang een enkel record wordt gecached heeft niets te maken met hoeveel
authoritative DNS servers betrokken zijn geweest bij het opzoeken van dat
record.
Het kan wel al snel erg onoverzichtelijk worden als een domain van nameservers
wisselt, zeker als er glueless delegaties om de hoek komen kijken. Als je iets
dergelijks niet zorgvuldig planned en uitvoert, kan je inderdaad te maken
krijgen met problemen die dagen kunnen aanhouden. Zelfs in dit geval blijft
het echter zo dat een record nooit langer dan de bijbehorende TTL gecached
wordt.
--
Jurjen Oskam
Savage's Law of Expediency:
You want it bad, you'll get it bad.
Arlé Mooldijk
Wim J <nos...@pc004.local> typed:
> Ja, ik heb ook een wens: ik wil graag meer dan 10 email adressen
> per pop box.
> Dan kan ik 1 mail box blijven gebruiken en toch heel makkelijk
> tijdelijke email adressen aanmaken.
Je hebt er 11, namelijk de mailbox zelf en daarnaast 10 andere adressen
(aliassen). Totaal dus 55 mailadressen bij een abonnement omdat je 5
mailboxen hebt.
Er was bSMTP of Batched SMTP waarbij je een subdomein had, iets van
naam.xs4all.nl en dan kon je daar min of meer onbeperkt adressen aanmaken,
maar ik zie dit niet meer terug bij de producten. Als je ex-demon gebruiker
bent dan is dat er nog wel voor de systeemnaam.demon.nl adressen. Ideaal
voor het aanmaken van een apart mailadres voor iedere site of ieder bedrijf
waar je je aanmeldt voor een account, kun je gelijk zien wie je adres heeft
verkocht als het misbruikt wordt.
Een andere optie is een eigen domein waar je min-of-meer onbeperkt
e-mailadressen kunt aanmaken, voordeel is dan wel dat je
provider-onafhankelijk bent en kunt overstappen met behoud van mailadressen.
--
Mvg,
Arlé
Wim J
> In news:49969d11$0$191$e4fe...@news.xs4all.nl,
> Wim J <nos...@pc004.local> typed:
>
>> Ja, ik heb ook een wens: ik wil graag meer dan 10 email adressen
>> per pop box.
>> Dan kan ik 1 mail box blijven gebruiken en toch heel makkelijk
>> tijdelijke email adressen aanmaken.
>
> Je hebt er 11, namelijk de mailbox zelf en daarnaast 10 andere adressen
> (aliassen). Totaal dus 55 mailadressen bij een abonnement omdat je 5
> mailboxen hebt.
>
Weet ik. Maar het is zo lekker als al
je mail in 1 box komt. En ik kan me niet voorstellen dat deze optie
voor xs4all veel extra kosten met zich meebrengt.
> Er was bSMTP of Batched SMTP waarbij je een subdomein had, iets van
> naam.xs4all.nl en dan kon je daar min of meer onbeperkt adressen aanmaken,
> maar ik zie dit niet meer terug bij de producten. Als je ex-demon gebruiker
> bent dan is dat er nog wel voor de systeemnaam.demon.nl adressen. Ideaal
> voor het aanmaken van een apart mailadres voor iedere site of ieder bedrijf
> waar je je aanmeldt voor een account, kun je gelijk zien wie je adres heeft
> verkocht als het misbruikt wordt.
>
> Een andere optie is een eigen domein waar je min-of-meer onbeperkt
> e-mailadressen kunt aanmaken, voordeel is dan wel dat je
> provider-onafhankelijk bent en kunt overstappen met behoud van mailadressen.
>
> --
> Mvg,
> Arlé
>
>
Al deze opties ken ik. Maar desondanks zou ik meer adressen
per email box willen hebben. Meest simpel voor mij, en
xs4all hoeft alleen maar 1 constante aan te passen :).
Wim
Hans
Dat is niet waar.
Zelf in jouw fout voorbeeld kun je zien dat dit niet waar kan zijn.
In jouw voorbeeld staan krome tijden " 1d14h57m18s" dat komt omdat dit de
tijd is dat deze entry nog geldig is.
Al zou een resolver informatie van resolver krijgen, wat je dan wel zelf zo
heb geconfigureerd.
Dan nog zal de TTL van de in de cache van de resolver van de resolver server
een TTL hebben die gelijk aan die van de authoritieve server.
En niet dus jouw geclaimed 2 x model.
>
> Ik heb het zat meegemaakt in de praktijk en het is echt zo :-S.
Ik niet.
Maar wel goed kijken en de informatie juist beoordelen.
Wat de meesten wel vergeten is de tijd tussen dat je weiziging gemaakt hebt
in een de DNS editor en voordat deze wijzing werkelijk actief is geworden in
DNS.
En als we het over TTL hebben wordt de eerst vertraging dus niet mee
gerekend.
Vooral bij het verhuizen van de domaien wordt nog al eens vergeten dat de
TLD DNS servers maar 2 x per dag worden herladen.
En dat er in de domain delegatie vaakt een TTL zit van 3 dagen.
kj
"Miquel van Smoorenburg" <mik...@xs4all.nederland.invalid> schreef in
bericht news:499535a9$0$190$e4fe...@news.xs4all.nl...
Ok, de mail (MX) lijkt in orde. Nu heb ik afgelopen vrijdag middag ook de
andere records aangepast. Voor een/het domein naam zelf. A-record voor een
.nl domein. Daar merk ik nog helemaal niets van, bijna 48urr later
nu.........
Miquel van Smoorenburg
kj <iem...@microsoft.com> wrote:
>Ok, de mail (MX) lijkt in orde. Nu heb ik afgelopen vrijdag middag ook de
>andere records aangepast. Voor een/het domein naam zelf. A-record voor een
>.nl domein. Daar merk ik nog helemaal niets van, bijna 48urr later
>nu.........
Als je niet vertelt om welk domein het gaat en welk A record
dan valt daar niets over te zeggen.
Mike.
Robert Scheer
> komt met: "verlaag de TTL voor een periode van 48 uur naar 600". Dan
Het heeft niet zoveel zin om de TTL gelijk met de wijziging te verlagen.
Dat had je minimaal $OUDE_TTL seconden eerder moeten doen.
Groetjes,
Robert
Rob
Ja maar dat kun je dus niet. Vandaar dat die feature wel leuk zou zijn.