Rekord DNS, który często się zmienia? [Zamknięte]

Jak utworzyć rekord domeny, który może się często zmieniać?

Powiedzmy, że example.orgpunkty 203.0.113.0. Dwie minuty później musi to wskazać 198.51.100.0.

Będą to normalne strony internetowe za domeną („normalne” tylko w sensie dostępu do nich za pomocą zwykłych przeglądarek internetowych), ale o bardzo krótkim okresie użytkowania. Domena wskaże adres maksymalnie przez 3-4 godziny, zanim zostanie zmieniony lub zamknięty. Nie ma potrzeby ochrony serwera DNS przed częstymi zapytaniami.

Moim podejściem byłoby ustawienie TTL na 60 sekund i po prostu zmiana zapisu, kiedy trzeba dokonać zmiany. W najgorszym przypadku spowodowałoby to, że użytkownik musiałby czekać maksymalnie 60 sekund, zanim nowy serwer będzie dostępny.

Jakoś nie ufam temu ... Niektórzy usługodawcy internetowi lub przeglądarki mogą zignorować lub zastąpić TTL, prawda? Jeśli jest to uzasadniona obawa, jakiego rozsądnego TTL można się spodziewać?

Dziękuję Ci!

Nazywa się to Fast Flux DNS Records . I zwykle w ten sposób autorzy szkodliwego oprogramowania ukrywają swoje serwery infrastruktury.

Chociaż będzie to działać w Twoim planie, nie jest to najlepszy plan. Prawdopodobnie będziesz musiał mieć zapasowy serwer lub więcej, online i prawie nic nie robić. Tylko wtedy, gdy masz problem z głównym serwerem, przełączysz się na następny.

Nawet jeśli masz TTL 1 minutę, najprawdopodobniej jeden rekord będzie ważny dłużej niż:

1. Pamięci podręczne przeglądarki

   Przeglądarki zwykle buforują rekordy DNS przez różny czas. Firefox używa 60 sekund , Chrome także 60 sekund , IE 3.x i wcześniejsze buforowane przez 24 godziny , IE 4.x i wyższe buforowane przez 30 minut.

2. Pamięć podręczna systemu operacyjnego

   Windows będzie zwykle nie honoruje TTL . TTL dla DND nie jest podobny do TTL dla pakietu IPv4. To bardziej oznaka świeżości niż obowiązkowe odświeżenie. Linux może mieć skonfigurowane nscd tak, aby ustawiał czas, jaki chce użytkownik, bez względu na DNS TTL. Może na przykład buforować wpisy przez tydzień.

3. Pamięć podręczna dostawcy usług internetowych

   Dostawcy usług internetowych mogą (i niektórzy będą) używać agresywnego buforowania w celu zmniejszenia ruchu. Mogą nie tylko zmieniać TTL, ale także buforować rekordy i zwracać je klientom, nawet nie pytając wcześniejszych serwerów DNS. Jest to bardziej rozpowszechnione w przypadku dostawców usług mobilnych, ponieważ zmieniają TTL, aby klienci mobilni nie narzekali na opóźnienia w ruchu.

Moduł równoważenia obciążenia jest przeznaczony do robienia dokładnie tego, co chcesz. Dzięki modułowi równoważenia obciążenia możesz mieć 2 lub 4 lub 10 serwerów jednocześnie w trybie online, dzieląc obciążenie. Jeśli jeden z nich przejdzie w tryb offline, usługa nie zostanie naruszona. Zmiana rekordów DNS spowoduje przestój między momentem wyłączenia serwera a zmianą DNS. Zajmie to więcej niż minutę, ponieważ musisz wykryć przestoje, zmienić rekordy i poczekać na ich rozpowszechnienie.

Więc użyj modułu równoważenia obciążenia. Jest stworzony do robienia tego, co chcesz i dokładnie wiesz, czego się spodziewać. Konfiguracja DNS szybkiego strumienia będzie mieć mieszane i niespójne wyniki.

DNS i jego działaniu może towarzyszyć więcej nieporozumień, legend, przesądów i mitologii jako dowolnego aspektu IT.

Nawet ci z nas, którzy wiedzą, że zasadniczo kłamiemy (lub przynajmniej drastycznie upraszczamy), kiedy mówimy o „propagowaniu” zmian, nadal używają tego terminu do opisania czegoś, co - jednocześnie - jest niezwykle proste i jednoznaczne ... ale trudne do wyjaśnienia ... i nie ma nic wspólnego z propagacją jako taką , ale wszystko, co dotyczy buforowania i buforowania negatywnego, które są istotnym składnikiem działania systemu (i, prawdopodobnie, w jaki sposób pozwala uniknąć całkowitego upadku pod własnego ciężaru) - zasadniczo wywrotka, przeciwieństwo rzeczywistego „propagacji”, ciągnięcia - a nie pchania.

W przypadku wszystkich zmartwień i kłopotów związanych z krótkimi czasami TTL, zwykle działają one częściej niż nie, do tego stopnia, że ​​w twoim interesie może być po prostu ich wypróbowanie. Gdy $ {day_job}, kiedy nasze witryny migrują ze „starej” platformy na „nową” platformę, często oznacza to, że migrują w taki sposób, że nic w infrastrukturze nie jest udostępniane. Moim pierwszym krokiem w takiej migracji jest obniżenie TTL do lat 60 wystarczająco daleko przed cięciem, tak że stary TTL ma wiele wielokrotności siebie do wyczerpania, co daje mi wystarczającą pewność, że te przejściowe RR z krótkimi TTL „rozejdą się” . ” Kiedy jestem gotowy do cięcia, ponownie konfiguruję stary moduł równoważący¹, aby spiąć ruch z nowym systemem - przez Internet - tak, aby moduł równoważący nie balansował już wielu systemów wewnętrznych, ale zamiast tego jest „

Następnie przełączam DNS i obserwuję nowy balancer i stary.

Zawsze jestem mile zaskoczony, jak szybko zachodzi przemiana. Występują niemal zawsze pająki wyszukiwania i strony „sprawdzające kondycję” stron trzecich, które w niewytłumaczalny sposób nawiązują do starych zapisów.

Ale jest jeden scenariusz, który rozkłada się w przewidywalny sposób: gdy okna przeglądarki użytkownika pozostają otwarte, mają tendencję do blokowania się na już odkrytym adresie i często utrzymuje się, dopóki wszystkie okna przeglądarki nie zostaną zamknięte.

Ale w powyższej narracji znajduje się rozwiązanie problemu: „moduł równoważenia obciążenia” - konkretnie, a dokładniej, odwrotne proxy - może być systemem, na który wskazuje odsłonięty rekord DNS.

Odwrotny serwer proxy przesyła następnie żądanie na właściwy docelowy adres IP, który jest rozwiązywany za pomocą drugiej „fałszywej” nazwy hosta z krótkim TTL, co wskazuje na prawdziwy serwer zaplecza .³ Ponieważ proxy zawsze honoruje TTL DNS na tym fałszywy wpis DNS, masz pewność szybkiego i całkowitego przełączenia.

Wadą jest to, że możesz kierować ruchem przez niepotrzebną dodatkową infrastrukturę lub płacić za transport ponad wieloma granicami sieci, nadmiarowo.

Istnieją usługi, które zapewniają tego rodzaju możliwości w skali globalnej, a najbardziej znana jest CloudFront. (Najprawdopodobniej Cloudflare miałby dokładnie ten sam cel, ponieważ mały zestaw testów, które przeprowadziłem, wskazuje, że również zachowuje się poprawnie i jestem pewien, że są inne.)

Chociaż CloudFront jest sprzedawany głównie jako CDN, u podstaw jest globalna sieć odwrotnych serwerów proxy z możliwością opcjonalnego buforowania odpowiedzi. Jeśli www.example.compunkty do CloudFront i CloudFront są skonfigurowane do przekazywania tych żądań backend.example.com, a rekord DNS dla backend.example.comużywa krótkiego TTL, wówczas CloudFront zrobi właściwą rzecz, ponieważ honoruje to krótkie TTL. Gdy rekord zaplecza ulegnie zmianie, ruch będzie migrowany do czasu wyczerpania TTL.

TTL rekordu frontowego wskazującego na CloudFront i to, czy przeglądarki i programy buforujące honorują go, są nieistotne, ponieważ zmiany miejsca docelowego zaplecza nie wymagają zmian w www.example.comrekordzie ... więc pojęcie, że „Internet” ma, jeśli chodzi o właściwy cel, www.example.comjest spójny, niezależnie od tego, gdzie znajduje się system zaplecza.

Dla mnie to całkowicie rozwiązuje problem, zwalniając przeglądarkę z potrzeby „śledzenia” zmian adresu IP serwera źródłowego.

tl; dr: kieruje żądania do systemu, który służy jako serwer proxy dla prawdziwego serwera WWW, tak że tylko konfiguracja serwera proxy musi uwzględniać zmianę adresu IP serwera źródłowego - nie DNS skierowany do przeglądarki.

Zwróć uwagę, że CloudFront minimalizuje również opóźnienie dzięki pewnej magii DNS, którą narzuca na stronę frontową, co powoduje www.example.comrozwiązywanie najbardziej optymalnej lokalizacji krawędzi CloudFront na podstawie lokalizacji zapytania www.example.com, więc ruch jest niepotrzebnie okrężny. od przeglądarki do krawędzi do początku ... ale ta część jest przezroczysta i automatyczna i nie wchodzi w zakres pytania.

Oczywiście buforowanie zawartości może być również przydatne, ponieważ zmniejsza obciążenie serwera lub transportu źródłowego - skonfigurowałem strony internetowe na CloudFront, gdzie serwer źródłowy był w obwodzie ADSL, a ADSL jest z natury ograniczony do przepustowości łącza nadawczego. Serwer źródłowy, z którym łączy się CloudFront w celu pobrania zawartości, nie musi być serwerem w ekosystemie AWS.

¹ Mówię o równoważeniu jako o pojedynczej jednostce, gdy w rzeczywistości ma wiele węzłów. Gdy moduł równoważący jest modułem ELB, maszyna stojąca za modułem równoważącym działa jako atrapa serwera aplikacji i faktycznie łączy się z modułem równoważącym nowej platformy, ponieważ ELB nie może tego zrobić samodzielnie.

² Jedyną wiedzą nowego modułu równoważącego na temat starej jest to, że musi on ufać X-Forwarded-For starego modułu równoważącego i że nie powinien wykonywać żadnych ograniczeń opartych na IP na źródłowych adresach starego modułu równoważącego.

³ Gdy serwerem proxy jest jeden lub więcej serwerów, które kontrolujesz, możesz pominąć korzystanie z DNS po stronie zaplecza i po prostu użyć adresów IP w konfiguracji serwera proxy, ale omówiony scenariusz hostowany / rozproszony potrzebuje następnie drugiej warstwy DNS .

Kiedy zmieniam rekordy DNS, często stary adres IP będzie używany przez miesiące. Powiedziawszy to, TTL wynoszący zaledwie kilka sekund jest tym, czego Amazon używa na przykład do stworzenia awaryjnej usługi.

Zamiast zmieniać DNS, możesz postawić przed nim serwer proxy / moduł równoważenia obciążenia.

Możesz zajrzeć za pomocą Dynamicznego DNS. Jest to zaprojektowane specjalnie dla scenariusza wspomnianego przez @glglgl w powyższym komentarzu. Uważam, że używają niskiego TTL, który, jak wskazano wcześniej, może nie być w 100% skuteczny, ponieważ klienci mogą go zignorować. Ale działa „całkiem dobrze”.

Nawet jeśli często nie zmieniasz adresu IP, ważne jest, aby utrzymać TTL na rozsądnym poziomie. Wiele lat temu firma, w której pracowałem dla zmienionych dostawców usług internetowych, która spowodowała zmianę naszych adresów IP. Niestety ustawiliśmy TTL na coś absurdalnego jak miesiąc, więc stare rekordy DNS były przechowywane przez długi czas.