Apa arti TTL pada catatan CNAME?


22

Karena berapa banyak server yang terlibat dalam jaringan saya, saya mengalami kesulitan menjaga semuanya teratur. Beberapa dari mereka tidak memiliki IP statis, jadi saya pikir mungkin lebih baik jika saya membuat domain config.mydomain.com. Di domain ini, saya bisa menyimpan catatan A dan IP untuk masing-masing server. Inilah cara saya mengaturnya:

s1.config.mydomain.com.     A   10.0.0.1    #ttl 60
s2.config.mydomain.com.     A   10.0.0.2    #ttl 60
s3.config.mydomain.com.     A   10.0.0.3    #ttl 60
# etc

Masing-masing catatan memiliki TTL 60, jika saya perlu mengubah IP dengan cepat, tapi saya tidak ingin klien yang terhubung setiap 60 detik untuk memperbarui. Sekarang katakanlah saya menyiapkan domain saya untuk menggunakannya, seperti ini:

mydomain.com.           CNAME   s2.config.mydomain.com.   #ttl 3600
mail.mydomain.com.      CNAME   s2.config.mydomain.com.   #ttl 10800
svn.mydomain.com.       CNAME   ns1.config.mydomain.com.  #ttl 21600

TTL untuk CNAMES lebih tinggi, jadi katakanlah saya pergi ke mydomain.com. Ia meminta server DNS saya untuk IP mydomain.com, dan server saya kembali CNAME s2.config.mydomain.com.Kemudian meminta server saya untuk IP s2.config.mydomain.com, dan server saya kembali 10.0.0.1.

Apakah akan CNAME s2.config.mydomain.commerekam catatan selama 3600 detik, dan A 10.0.0.1catatan selama 60 detik? Berarti setiap 60 detik masih akan meminta server saya untuk alamat IP?

Atau akankah cache tembolok CNAME s2.config.mydomain.com, dapatkan A 10.0.0.1, dan tembolok keduanya selama 3600 detik.

Jika ini yang pertama, saya mungkin harus menemukan cara lain untuk mengelolanya, jadi saya berharap itu yang kedua, tapi saya tidak yakin. Apakah Anda tahu cara yang lebih baik untuk melacak mereka?


Dapatkah Anda lebih jelas menentukan siapa Anda maksud dengan 'akan hal -cache'? Sayangnya ada banyak implementasi resolvers yang berbeda, saya tidak akan terkejut sama sekali jika Anda menemukan bahwa kedua perilaku tersebut benar.
Zoredache

@zoredache Saya pikir apa yang ingin diketahui @Ryan adalah: dns resolver biasanya men-cache CNAME atau hasil pencarian CNAME yang diselesaikan?
coredump

@coredump, ya itu yang saya maksud.
Ryan Pendleton

Jawaban:


10

Menurut pesan ini di milis ISC , CNAME, dan catatan yang ditunjukkannya di-cache dengan menyelesaikan server nama ( server nama penyelesaian waras ) ini dilakukan untuk memungkinkan resolver untuk dapat mengoptimalkan proses penyelesaian / caching di sisi klien.

Jadi, jika CNAME TTL valid tetapi A yang ditunjuknya tidak valid, itu hanya akan mengulangi tampilan ke catatan yang ditunjuk, bukan CNAME asli (sampai CNAME TTL juga naik).


Jadi, jika saya memahami hak ini, catatan CNAME akan diminta setelah TTL habis masa berlakunya, dan catatan A yang ditunjukkannya juga akan diminta, tetapi setelah TTL sendiri kedaluwarsa?
Ryan Pendleton

1
Iya nih. Itu artinya, TTL berfungsi untuk catatan CNAME sama dengan untuk catatan lainnya.
coredump

3

Semua catatan CNAME Anda akan di-cache maksimal 3600, 10800 dan 21600 detik.

Catatan A ditangani secara independen dan akan ditanyakan lagi setiap 60 detik.

Namun, jika CNAME kedaluwarsa, catatan A harus diperbarui secara bersamaan.

Catatan CNAME memiliki berbagai gotcha yang dijelaskan dalam RFC 1912. mydomain.com. tidak boleh CNAME, karena Anda memiliki catatan SOA dan NS yang digunakan: itu adalah delegasi com. domain.

Pertanyaan anda sudah tua Saat ini beberapa penyedia DNS tidak mengikuti RFC dengan membiarkan pengguna memasukkan CNAME ke dalam SOA (mereka menyebutnya domain APEX). Sekali lagi, gunakan dengan risiko Anda sendiri.

Last but not least, menempatkan nilai TTL yang lebih tinggi pada CNAME Anda dapat membantu ketika klien Anda meminta catatan IPv6: AAAA. Setidaknya pemetaan CNAME akan tetap di cache, dan hanya alamat IP yang akan diminta dua kali.

Singkatnya: menempatkan TTL lebih tinggi pada CNAME akan mengurangi ukuran tanggapan yang dilihat oleh klien Anda. Ini juga harus membantu server penyelesai. Namun jumlah permintaan per detik kira-kira harus sama.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.