Domena i rekordy DNS dla aplikacji
Skierujesz domenę lub subdomenę na serwer aplikacji i sprawdzisz rekordy DNS z kilku perspektyw, od publicznych resolverów po lokalny plik hosts.
1. Krótka teoria
Domena główna, na przykład example.com, może mieć subdomenę app.example.com przeznaczoną dla aplikacji. Rekord A wiąże nazwę z adresem IPv4, a AAAA z IPv6. Rekord CNAME tworzy alias do innej nazwy DNS; nie jest zamiennikiem rekordu adresowego w każdej sytuacji. Warto publikować tylko rekordy dla protokołów faktycznie skonfigurowanych na serwerze. Nazwa użyta w DNS powinna odpowiadać server_name app.example.com w Nginxie. TTL określa, jak długo odpowiedź może być przechowywana w cache. Po zmianie część resolverów może nadal zwracać starszą wartość aż do wygaśnięcia cache; ten proces potocznie nazywa się propagacją DNS. dig, host i getent hosts pokazują wynik z różnych perspektyw. Zapytania do resolverów takich jak 1.1.1.1 i 8.8.8.8 pomagają porównać publiczny stan. Lokalny wpis w /etc/hosts może chwilowo mapować domenę do IP na jednym komputerze, lecz nie publikuje niczego w DNS. Poprawny DNS wskazuje host, ale nie uruchamia Nginxa, nie otwiera portu i nie gwarantuje odpowiedzi aplikacji.
2. Przykłady komend
dig A app.example.com
Pyta domyślny resolver o rekord IPv4 subdomeny.
$ dig A app.example.com
dig AAAA app.example.com
Sprawdza, czy dla subdomeny opublikowano rekord IPv6.
$ dig AAAA app.example.com
dig @1.1.1.1 app.example.com A +short
Pyta wybrany publiczny resolver o krótki wynik rekordu A.
$ dig @1.1.1.1 app.example.com A +short
203.0.113.10
dig @8.8.8.8 app.example.com A +short
Pozwala porównać odpowiedź z innym publicznym resolverem.
$ dig @8.8.8.8 app.example.com A +short
203.0.113.10
host app.example.com
Pokazuje prostą informację o adresach przypisanych do nazwy.
$ host app.example.com
getent hosts app.example.com
Sprawdza rozwiązanie nazwy używane przez lokalny system, także z uwzględnieniem hosts.
$ getent hosts app.example.com3. Zadanie praktyczne
app.example.com zaplanuj rekord A wskazujący adres IPv4 serwera. Jeśli serwer nie obsługuje poprawnie IPv6, nie dodawaj rekordu AAAA. Zapisz wartość TTL i skonfiguruj zgodny server_name w przykładowym bloku Nginxa. Sprawdź wynik przez dig, host i getent hosts, a następnie porównaj odpowiedzi resolverów 1.1.1.1 oraz 8.8.8.8. Jeżeli nie zarządzasz prawdziwą domeną, wykonaj ćwiczenie jako plan i opcjonalnie użyj lokalnego wpisu hosts wyłącznie w laboratorium.
4. Typowe błędy
- Skierowanie rekordu A na nieaktualny lub prywatny adres IPv4 serwera.
- Dodanie rekordu AAAA mimo braku działającej konfiguracji IPv6.
- Niezgodność domeny w DNS z wartością server_name w Nginxie.
- Oczekiwanie natychmiastowej zmiany mimo aktywnego cache i wcześniejszego TTL.
- Traktowanie wpisu w /etc/hosts jako publicznej konfiguracji DNS.
- Użycie CNAME bez zrozumienia, że wskazuje nazwę, a nie bezpośrednio adres IP.
- Wnioskowanie z poprawnego DNS, że aplikacja i port HTTP muszą działać.
5. Podsumowanie
Rekord A kieruje nazwę na IPv4, AAAA na IPv6, a CNAME tworzy alias do innej nazwy. Domena w DNS musi być zgodna z server_name Nginxa. TTL i cache DNS wyjaśniają, dlaczego różne resolvery mogą przez pewien czas zwracać inne odpowiedzi. dig, host i getent hosts pozwalają porównać stan publiczny z lokalnym rozwiązywaniem nazw.