Wie funktioniert DNS TTL in verketteten CNAME-Konfigurationen?

Question

Ich habe eine DNS-Konfiguration, die ungefähr so ​​aussieht:

www.example.com                 600  IN   CNAME prod.myzone.l2.company.example
prod.myzone.l2.company.example      600  IN   CNAME ssl-endpoint-12345.hostcorp.example
ssl-endpoint-12345.hostcorp.example 60   IN   A     192.0.2.4

Die ersten beiden CNAME-Einträge in der Kette haben also eine TTL von 10 Minuten und der letzte A-Eintrag hat eine TTL von 1 Minute.

Der prod.myzone.l2.company.exampleCNAME führt einen regionalen Lastenausgleich zwischen mehreren Endpunkten durch und wird automatisch aktualisiert, wenn mein DNS-Anbieter feststellt, dass der aktuelle Endpunkt fehlerhaft ist. Aus diesem Grund möchte ich Änderungen am prod.myzone.l2.company.exampleCNAME so schnell wie möglich verbreiten.

Wenn ich die Gesamt-TTL reduzieren möchte, die Clients bei prod.myzone.l2.company.exampleÄnderungen sehen, reicht es dann aus, nur die TTL des prod.myzone.l2.company.exampleDatensatzes zu reduzieren, oder muss ich auch die TTL des www.example.comDatensatzes reduzieren?

Answer 1

Die TTLFor- CNAMEDatensätze funktionieren in keiner Weise anders als andere Datensätze.

Stellen wir uns einen rekursiven Resolver vor, durch den das oben genannte geht. Er füllt dann seinen Cache mit:

• www.example.com CNAMEgültig für 600s
• prod.myzone.l2.company.example CNAMEgültig für 600s
• ssl-endpoint-12345.hostcorp.example Agültig für 60er

Wenn jemand später direkt nachfragt ssl-endpoint-12345.hostcorp.example A, dann gilt die 60er TTL.

Wenn die Abfrage jedoch für eingeht www.example.com, erkennt der Resolver, dass kein ADatensatz, sondern ein CNAME vorhanden ist, und verwendet dann alle oben genannten Angaben erneut.

66 Sekunden (zum Beispiel) nach dem oben genannten www.example.comsind noch immer im Resolver-Cache, ssl-endpoint-12345.hostcorp.example Awerden es aber nicht mehr sein, sodass der Resolver eine neue DNS-Abfrage durchführen muss, um diese Daten abzurufen und zwischenzuspeichern.