Co oznacza TTL w rekordzie CNAME?


22

Ze względu na liczbę serwerów zaangażowanych w moją sieć trudno mi utrzymać je wszystkie w porządku. Niektóre z nich nie mają statycznych adresów IP, więc pomyślałem, że może być miło, jeśli utworzę domenę config.mydomain.com. W tej domenie mógłbym przechowywać rekordy A i adres IP dla każdego z serwerów. Oto jak to skonfigurowałem:

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

Każdy z tych rekordów ma TTL 60, na wypadek, gdy muszę szybko zmienić adres IP, ale niekoniecznie chcę, aby klienci łączący się co 60 sekund aktualizowali. Powiedzmy teraz, że konfiguruję domeny, aby z nich korzystać, w następujący sposób:

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

Wartości TTL dla CNAMES są wyższe, więc powiedzmy, że idę do mydomain.com. Pyta mój serwer DNS o adres IP mydomain.com, a mój serwer zwraca CNAME s2.config.mydomain.com.Następnie pyta mój serwer o adres IP s2.config.mydomain.com, a mój serwer zwraca 10.0.0.1.

Czy buforowałby CNAME s2.config.mydomain.comrekord przez 3600 sekund, a A 10.0.0.1rekord przez 60 sekund? Oznacza to, że co 60 sekund nadal będzie pytać mój serwer o adres IP?

Czy będzie buforować widok CNAME s2.config.mydomain.com, pobrać A 10.0.0.1i buforować je oba przez 3600 sekund.

Jeśli to pierwszy, prawdopodobnie będę musiał znaleźć inny sposób na zarządzanie nimi, więc mam nadzieję, że to drugi, ale nie jestem pewien. Czy znasz lepszy sposób, aby je śledzić?


Można bardziej wyraźnie określić, który masz na myśli przez „będzie to buforować”? Niestety istnieje wiele różnych implementacji resolvera, nie byłbym w ogóle zaskoczony, gdyby okazało się, że oba zachowania są prawdziwe.
Zoredache,

@zoredache Myślę, że @Ryan chce wiedzieć: resolversy dns zwykle buforują CNAME lub wynik wyszukiwania CNAME?
rdzeń rdzeniowy

@coredump, tak właśnie miałem na myśli.
Ryan Pendleton

Odpowiedzi:


10

Zgodnie z tym komunikatem na liście mailingowej ISC , CNAME i rekord, który wskazuje, są buforowane przez rozpoznawanie serwerów nazw ( rozsądne rozpoznawanie serwerów nazw ), ma to na celu umożliwienie resolverom zoptymalizowania procesu rozwiązywania / buforowania po stronie klienta.

Tak więc, jeśli CNAME TTL jest ważny, ale A, na który wskazuje, jest nieprawidłowy, powtórzy wyszukiwanie tylko do wskazanego rekordu, a nie do pierwotnej CNAME (dopóki CNAME TTL też nie będzie w górę).


Więc jeśli zrozumiem to prawo, rekord CNAME zostanie zażądany po wygaśnięciu TTL, a rekord A, na który wskazuje, zostanie również zażądany, ale po wygaśnięciu własnego TTL?
Ryan Pendleton

1
Tak. Oznacza to, że TTL działa dla rekordów CNAME tak samo, jak dla innych rekordów.
Coredump

3

Wszystkie rekordy CNAME będą buforowane przez maksymalnie 3600, 10800 i 21600 sekund.

Rekordy A są obsługiwane niezależnie i będą sprawdzane ponownie co 60 sekund.

Jednak w przypadku wygaśnięcia CNAME rekord A powinien zostać zaktualizowany w tym samym czasie.

Rekordy CNAME mają różne wyjaśnienia w RFC 1912. mojadomena.com. nie może być CNAME, ponieważ używasz rekordów SOA i NS: jest to przekazanie com. domena.

Twoje pytanie jest stare. Obecnie niektórzy dostawcy DNS nie przestrzegają RFC, pozwalając użytkownikom umieszczać CNAME w SOA (nazywają to domenami APEX). Ponownie używaj na własne ryzyko.

Wreszcie, nałożenie na ciebie wyższych wartości TTL może pomóc, gdy Twoi klienci proszą o rekord IPv6: AAAA. Przynajmniej mapowanie CNAME pozostanie w pamięci podręcznej, a tylko dwukrotnie zostanie podany tylko adres IP.

W skrócie: zwiększenie TTL w CNAME zmniejszy rozmiar odpowiedzi widzianych przez twoich klientów. Powinno to również pomóc serwerowi tłumaczącemu. Jednak liczba żądań na sekundę powinna być mniej więcej taka sama.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.