Zmiana adresu IP

Zmiana adresu IP to parametr monitoringu stron internetowych, który porównuje adresy IPv4 zwrócone dla domeny w bieżącym zapytaniu DNS z adresami zapamiętanymi przy poprzednim pomiarze. Możliwe wyniki to: adresy bez zmian, inny zbiór adresów niż poprzednio, pierwszy pomiar, który tylko zapisuje punkt odniesienia, albo brak odpowiedzi, przy którym porównania nie da się wykonać. Adres IPv4 hosta przechowuje rekord A z 32-bitowym adresem internetowym, a host z kilkoma adresami ma kilka rekordów A ^[2].

Jak działa

Pomiar zestawia dwie migawki. Pierwsza odpowiedź dla domeny staje się wzorcem, a każdą kolejną porównuje się z nim jako zbiór adresów. Kolejność rekordów nie powinna mieć znaczenia: RFC 1794 zauważa, że protokół DNS nie gwarantuje kolejności, a wczesne mechanizmy równoważenia obciążenia celowo rotowały rekordy adresowe metodą round-robin ^[3]. Po wykryciu różnicy nowy zbiór zwykle zastępuje wzorzec, żeby ta sama zmiana nie była zgłaszana w każdym kolejnym pomiarze.

RYS. 1.1Porównanie skanu N-1 i skanu N

Na wynik wpływa czas życia rekordu. TTL to limit czasu, przez który rekord może leżeć w pamięci podręcznej; ustala go administrator strefy ^[1]. RFC 1034 zaleca, by przed zapowiedzianą zmianą obniżyć TTL, a po zmianie przywrócić dawną wartość, co ogranicza niespójność w okresie przejścia ^[1]. Dwa kolejne pomiary mogą więc przez pewien czas widzieć raz stary, raz nowy adres, zależnie od tego, co pamięta pytany resolver.

Sama różnica adresów nie mówi, co się stało. Tę samą obserwację daje dostawca CDN, zaplanowana przeprowadzka serwera i przejęcie konta DNS, dlatego pomiar jest punktem wyjścia do rozróżnienia, a nie rozstrzygnięciem.

RYS. 1.2Rozróżnienie zmiany adresu

Standardy i specyfikacje

• RFC 1034 i RFC 1035 definiują pole TTL i rekord A: 32-bitowy adres w danych rekordu, wiele rekordów A dla hosta z wieloma adresami oraz czas przechowywania w pamięci podręcznej ^{[1] [2]}.
• RFC 1794 (1995, dokument informacyjny) opisuje równoważenie obciążenia przez DNS. Odpowiedź zawiera wiele adresów, a w opisanym wdrożeniu adresy losowo przestawiano co 300 sekund. W takiej zmiennej strefie TTL rekordów musi być bardzo niski ^[3].
• RFC 4786 definiuje anycast jako udostępnianie tego samego adresu usługi w wielu odrębnych lokalizacjach, tak że pakiety trafiają do jednej z nich ^[4].
• NIST SP 800-128 definiuje konfigurację bazową (ang. baseline configuration) jako zestaw specyfikacji przejrzany i uzgodniony w danym momencie, który można zmieniać tylko przez procedury kontroli zmian ^[8]. Monitorowanie konfiguracji ma wykrywać, kiedy stan faktyczny odbiega od zatwierdzonego wzorca, czyli nieautoryzowaną zmianę ^[8].

Zagrożenia i skutki

Przejęcie DNS. Dyrektywa CISA ED 19-01 z 22 stycznia 2019 r. opisywała kampanię, w której napastnik po zdobyciu danych logowania zmieniał rekordy A, MX lub NS i kierował ruch na własną infrastrukturę ^[7]. Dyrektywa nakazywała sprawdzić, czy publiczne rekordy DNS wskazują zamierzone miejsca; CISA zamknęła ją 8 stycznia 2026 r. ^[7]. Szerzej o przejęciu domeny pisze artykuł Rozwiązywanie DNS.

Migracja poza kontrolą zmian. NIST SP 800-128 wśród przyczyn nieautoryzowanych zmian wymienia zmiany przypadkowe, działania osób, które nie znają procesu kontroli zmian albo uważają, że ich nie dotyczy, oraz opóźnienie między wprowadzeniem zmiany a aktualizacją wzorca ^[8]. Nieautoryzowana zmiana może świadczyć o ataku albo o tym, że procedury nie są przestrzegane, dlatego NIST zaleca analizować jej przyczynę ^[8]. Przeniesienie strony na inny serwer bez wiedzy osób, które ją utrzymują, wygląda z zewnątrz tak samo jak zmiana wprowadzona przez napastnika.

Fałszywe alarmy przy CDN. Dla rekordu obsługiwanego przez proxy Cloudflare zapytanie DNS zwraca adresy anycast Cloudflare zamiast adresu serwera źródłowego ^[5]. Zakresy tych adresów są wspólne dla wszystkich hostów za proxy ^[6]. TTL takich rekordów wynosi 300 sekund i nie da się go zmienić; krótki czas ma sprawić, że zmiana przypisanego adresu anycast szybko zacznie obowiązywać ^[5]. Inny adres w odpowiedzi nie oznacza wtedy zmiany serwera ani hostingu. Podobnie przy równoważeniu obciążenia przez DNS: jeśli zawartość puli rekordów zmienia się co kilka minut ^[3], porównanie pełnych zbiorów zgłosi zmianę przy każdej takiej rotacji.

Zmiana niewidoczna. Proxy działa też w drugą stronę i ukrywa przeprowadzkę: odwiedzający dostaje adres Cloudflare zamiast prawdziwego adresu serwera źródłowego ^[6]. Migracja serwera za CDN nie zmienia więc odpowiedzi DNS, a porównanie rekordów A jej nie wykryje.

Przykłady

Obserwacja	Wynik porównania	Typowa przyczyna
Te same adresy w innej kolejności	bez zmian	rotacja round-robin [3]
Jeden adres zastąpiony innym, TTL wcześniej obniżony	zmiana	zapowiedziana migracja serwera [1]
Adresy z zakresów CDN zamiast adresu serwera	zmiana	włączenie proxy, adresy anycast [5] [6]
Inny adres CDN przy niezmienionej konfiguracji	zmiana	dostawca zmienił przydział adresu anycast [5]
Nowy adres i zmienione rekordy NS lub MX	zmiana	przejęcie konta DNS [7]
Nowy adres, którego nikt nie zatwierdził	zmiana	migracja poza procesem kontroli zmian [8]
Migracja serwera schowanego za proxy	bez zmian	adres źródłowy ukryty za CDN [6]
Brak odpowiedzi albo nazwa nie istnieje	nie da się porównać	awaria DNS, wygaśnięcie domeny — patrz Rozwiązywanie DNS