DNS TTL en propagation

[robinsane]

Ik heb mij vandaag wat verdiept in DNS en TTL om doordacht values voor TTL te kunnen gebruiken in plaats van random.
Nu heb ik enkele vraagjes omtrent deze onderwerpen:

V 1) Voor zover ik snap kan dns caching op heel wat plaatsen gebeuren (browser,pc, router, dns cache v. provider), wordt de door mij ingestelde TTL op elk van deze plaatsen als upper limit gebruikt?
Duidelijk beantwoord, bedankt GlowMouse.

V 2) Ik vind geen duidelijke info over propagation time van dns veranderingen: welke van de volgende opties is het nu werkelijk:
* De vorige TTL maal het aantal (cache?)hops naar de authoritive nameserver.
* De vorige TTL + "de propagation time"
* "de propagation time"
Waarvan is "de propagation time" afhankelijk, ik blijf tegenkomen dat dit van minuten tot 72 uur kan gaan, maar niet waarom. Ik zou deze tijd graag kunnen inschatten, zie best practices bij "wat heb ik al gevonden".
Duidelijk uitgelegd, bedankt ndeleeuw

3)Hoe zit het een CNAME-record? Mijn initiele reactie is dezelfde (of lager) TTL als de A-record waar deze naar verwijst.
edit: bij nader inzien neem ik voor de CNAME-records misschien beter een lange TTL, omdat het domeinnaam waarnaar ze wijzen normaal onveranderd blijft.

Relevante software

Momenteel wijzen mijn NS records naar de nameservers van DigitalOcean (ns1.digitalocean.com., ns2.digitalocean.com., ns3.digitalocean.com.)
Mijn A-records en CNAME-records geef ik ook door via DigitalOcean

Wat ik al gevonden heb

Best practices om DNS aanpassen:

### Changing DNS records
1. Drop TTL to something very short (< 5 minutes)
wait the propagation time.
2. Change the DNS record
wait the propagation time.
3. Change the TTL value to be longer again
### Adding DNS records
1. Add DNS record with a very short TTL (< 5 minutes)
Check if everything is ok.
2. Set the TTL to desired value

Voordelen van lange of korte TTL

Long TTL positives:
* Faster response times.
* more robust vs DDoS attacks on authoritive nameservers.
Short TTL positives:
* operational changes are easier.
* situational positives: dns-based response vs DDoS attack / dns-based load-balancing.

TTL times in general

| TTL | time | label |
| ------ | ---- | ---------- |
| 300 | 5m | very short |
| 3600 | 1h | short |
| 86400 | 24h | long |
| 604800 | 7d | insanity |


Kleine verontschuldiging voor sloppy opmaak & alvast bedankt voor jullie tijd MedeTweakers ^.^

[ Voor 14% gewijzigd door robinsane op 01-05-2020 14:20 . Reden: formatting ]

[ik222]

Het is in die zin vrij simpel, de TTL is de tijd dat een resolver het DNS record uit zijn cache haalt zonder het opnieuw op te vragen bij de authorative servers. Dus ja als je een DNS wijziging plant is het verstandig om ruim vooraf de TTL extreem laag te zetten.

"Propagation time" is niets meer of minder dan een term voor tijd die het duurt voordat je wijziging overal is doorgekomen.

[robinsane]

ik222 schreef op woensdag 29 april 2020 @ 22:02:
Het is in die zin vrij simpel, de TTL is de tijd dat een resolver het DNS record uit zijn cache haalt zonder het opnieuw op te vragen bij de authorative servers. Dus ja als je een DNS wijziging plant is het verstandig om ruim vooraf de TTL extreem laag te zetten.

"Propagation time" is niets meer of minder dan een term voor tijd die het duurt voordat je wijziging overal is doorgekomen.

Als je het over resolver hebt, is dit dan die van je internet provider, of kan dit ook browser/pc/router omvatten?
Ik probeer te kunnen inschatten wat deze propagation time zou zijn, hangt dit bij vernieuwing van de record af van de oude TTL?

De authorative servers zijn in mijn geval die van DigitalOcean, heeft de TTL van mijn NS-records dat mijn geregistreed rootdomein naar die servers laat wijzen, enige invloed op de propagation time van mijn A-records van subdomeinen?

PS alvast bedankt om te willen helpen

[ Voor 0% gewijzigd door robinsane op 29-04-2020 23:47 . Reden: spelling ]

[GlowMouse]

robinsane schreef op woensdag 29 april 2020 @ 17:37:
1) Voor zover ik snap kan dns caching op heel wat plaatsen gebeuren (browser,pc, router, dns cache v. provider), wordt de door mij ingestelde TTL op elk van deze plaatsen als upper limit gebruikt?

Je provider raadpleegt de bevoegde DNS server, krijgt een up-to-date resultaat, en volgt dus de maximale TTL. Als iemand anders met dezelfde provider een domeinnaam opvraagt met een TTL van een uur, en vijf minuten later vraag jij dezelfde naam op, krijg je een resultaat met een TTL van 55 minuten. De cache van Windows volgt de TTL (met een maximum van een dag), dus na 55 minuten wordt de entry uit de providercache en de Windowscache geleegd. Een extra tussenlaag van een DNS server op een router brengt hierin - mits goed geïmplementeerd - geen verandering. Je browsercache trekt zich niets van de TTL aan en wordt na een minuut geleegd.

[ Voor 12% gewijzigd door GlowMouse op 30-04-2020 01:08 ]

[robinsane]

GlowMouse schreef op donderdag 30 april 2020 @ 01:07:
[...]

Je provider raadpleegt de bevoegde DNS server, krijgt een up-to-date resultaat, en volgt dus de maximale TTL. Als iemand anders met dezelfde provider een domeinnaam opvraagt met een TTL van een uur, en vijf minuten later vraag jij dezelfde naam op, krijg je een resultaat met een TTL van 55 minuten. De cache van Windows volgt de TTL (met een maximum van een dag), dus na 55 minuten wordt de entry uit de providercache en de Windowscache geleegd. Een extra tussenlaag van een DNS server op een router brengt hierin - mits goed geïmplementeerd - geen verandering. Je browsercache trekt zich niets van de TTL aan en wordt na een minuut geleegd.

Bedankt! Heel duidelijk uitgelegd! De upper limit van windows is ook een zeer handig weetje.

[lordgandalf]

De propogatie tijd voor een nieuw record is nagenoeg 0ms en voor oude records die gewijzigd worden geld de TTL. CNAME heeft een eigen TTL en met een nieuwe CNAME record is het 0ms en met aanpassingen is het de TTL tijd. Je TTL zou zoveel mogelijk gelijk moeten zijn maar op sommige plekken kan het minder verstandig zijn. Lagere TTL is meer verkeer. Een standaard TTL is vaak tussen de 8 en 24 uur. Er worden vaak hoge TTl values gekozen omdat dan niet elek 5 minuten een dns server bij een andere server nieuwe info hoeft op te halen want dat is wat de TTL betekend. Hoevaak moet er nieuwe info worden opgehaald = TTL = Propogatie

[ Voor 80% gewijzigd door lordgandalf op 01-05-2020 11:11 ]

[robinsane]

lordgandalf schreef op vrijdag 1 mei 2020 @ 11:05:
De propogatie tijd voor een nieuw record is nagenoeg 0ms en voor oude records die gewijzigd worden geld de TTL. CNAME heeft een eigen TTL en met een nieuwe CNAME record is het 0ms en met aanpassingen is het de TTL tijd. Je TTL zou zoveel mogelijk gelijk moeten zijn maar op sommige plekken kan het minder verstandig zijn. Lagere TTL is meer verkeer. Een standaard TTL is vaak tussen de 8 en 24 uur. Er worden vaak hoge TTl values gekozen omdat dan niet elek 5 minuten een dns server bij een andere server nieuwe info hoeft op te halen want dat is wat de TTL betekend. Hoevaak moet er nieuwe info worden opgehaald = TTL = Propogatie

Heel duidelijke uitleg, bedankt ndeleeuw!

Dus als ik een TTL instelde van 8 uur op een A-record, en ik wil deze naar een ander ip laten wijzen. Dan verander ik de TTL naar 60 sec. Kan ik dan 8 uur later naar een ander ip wijzen + de TTL terug op 8 uur zetten en met zekerheid zeggen dat dit alles in 60 seconden (tenzij ergens onderweg mininimum limit van paar minuten) is gepropageerd?

Waarom zou mijn TTL zoveel mogelijk gelijk moeten zijn? Omwille van het gemak? En bedoel je dan enkel A records? Mijn huidig plan was algemene TTL kiezen voor A-records en het dubbele daarvan voor CNAME aangezien CNAME mooi naar een andere record kan blijven wijzen moesten er toch ip veranderingen doorkomen.

[lordgandalf]

dat is een mogelijkheid of je changed het wacht 8 uur en dan is het actief.
En meestal word er een ttl als de basis gekozen en daar wil je dan zoveel mogelijk op blijven. Afwijken is mogelijk maar hoe meer je afwijkende configs hebt des te meer updates er verstuurd worden stel je hebt om een ttl van 8 uur en een van 4 uur dan stuur je om de 8 uur de volledige update uit en dan elke 4 uur een update van bijv CNAMES. en dat betekend dus meer verkeer. Als verkeer je niet boeit dan kun je het gewoon doen maar vaak word aanbevolen om je ttl op 1 waarde te zetten. Bij onze omgeving is dit zeker niet de waarheid dus het is mogelijk. is het aan te bevelen niet echt.

[robinsane]

@lordgandalf

Nu ben ik toch wat in de war door "updates versturen".
Bedoel je meer verkeer door vaker raadplegen van de autoritive nameservers?

Dan vermindert het verkeer toch nog steeds als ik CNAME TTL 8 uur maak en al de rest op 4u laat?
Wat je dan bedoelt is waarschijnlijk zorgen dat de laagste TTL allemaal dezelfde waarde heeft?

[ Voor 0% gewijzigd door robinsane op 02-05-2020 11:17 . Reden: spelling ]

[lordgandalf]

9 van de 10 keer vraag je een dns naam niet direct op bij je dns server maar via een andere server. Als je een record hebt met een ttl van 8 uur en je wijzigt het na 3 uur dan moet je nog de 5 uur wachten voordat je dns aanpassing doorgevoerd is. Een lagere ttl vereist meer checks van een caching dns server of het record nog klopt dus als je een ttl van 5 min hebt word er door dns servers elke 5 minuten gechecked hey is dit record nog ok en de server zegt jep etc etc dan word er dus vaker een verzoek gestuurd dan als je een ttl hebt van meerdere uren.

[Jazzy]

Ik heb in mijn werk met redelijk veel DNS-changes te maken met betrekking tot Office 365 en migraties. Microsoft adviseert voor de DNS records die client acess of mail flow managen een TTL van 1 uur en ik heb eigenlijk nooit de behoefte gehad om een kortere TTL te gebruiken.

Wel pas een incidentje met een "DNS beheerder" die niet helemaal goed snapte wat er van hem verwacht werd. Had voor de cutover de TTL naar 1 uur gezet, vervolgens de wijzigingen niet correct doorgevoerd en direct daarna de TTL op 24 uur gezet omdat dit blijkbaar de default was in de webportal van de domeinboer. Uiteindelijk viel de impact mee, maar ik vraag me toch af of je voor DNS-records die toegang tot een dienst managen inderdaad niet gewoon die standaard van 1 uur aan moet houden.

[robinsane]

lordgandalf schreef op maandag 4 mei 2020 @ 11:59:
9 van de 10 keer vraag je een dns naam niet direct op bij je dns server maar via een andere server. Als je een record hebt met een ttl van 8 uur en je wijzigt het na 3 uur dan moet je nog de 5 uur wachten voordat je dns aanpassing doorgevoerd is. Een lagere ttl vereist meer checks van een caching dns server of het record nog klopt dus als je een ttl van 5 min hebt word er door dns servers elke 5 minuten gechecked hey is dit record nog ok en de server zegt jep etc etc dan word er dus vaker een verzoek gestuurd dan als je een ttl hebt van meerdere uren.

Dat snapte ik allemaal, wel weer zeer mooi uitgelegd.
Ik had denk ik je zin verkeerd begrepen: afwijkende configs dacht ik ook dat je verschillen naar boven bedoelde en dat snapte ik niet helemaal.

[robinsane]

Jazzy schreef op maandag 4 mei 2020 @ 12:07:
Ik heb in mijn werk met redelijk veel DNS-changes te maken met betrekking tot Office 365 en migraties. Microsoft adviseert voor de DNS records die client acess of mail flow managen een TTL van 1 uur en ik heb eigenlijk nooit de behoefte gehad om een kortere TTL te gebruiken.

Wel pas een incidentje met een "DNS beheerder" die niet helemaal goed snapte wat er van hem verwacht werd. Had voor de cutover de TTL naar 1 uur gezet, vervolgens de wijzigingen niet correct doorgevoerd en direct daarna de TTL op 24 uur gezet omdat dit blijkbaar de default was in de webportal van de domeinboer. Uiteindelijk viel de impact mee, maar ik vraag me toch af of je voor DNS-records die toegang tot een dienst managen inderdaad niet gewoon die standaard van 1 uur aan moet houden.

Zolang er proper wordt omgegaan met eventuele veranderingen lijkt een iets langere TTL toch mooi voor response times. Op het internet verschillen de meningen zeer hard, maar consensus lijkt inderdaad toch tussen 1 en 24 uur voor een A-record.

[ Voor 0% gewijzigd door robinsane op 04-05-2020 16:20 . Reden: spelling ]