Zapis nazw domenowych w ASCII

Z punktu widzenia DNS każda nazwa domenowa kończy jako prosty zapis w ASCII, nawet jeśli użytkownik widzi domenę z polskimi znakami lub innym alfabetem. System nazw działa w oparciu o ograniczony zestaw znaków (litery, cyfry, myślnik), a domeny IDN są tylko „ładną” warstwą dla ludzi – pod spodem i tak zamieniają się na techniczną postać zrozumiałą dla serwerów.

Dlaczego domeny w DNS są zapisane w ASCII?

Podstawowy powód jest po prostu techniczny i wynika z faktu, że system DNS projektowano w czasach, gdy Internet opierał się na prostym zestawie znaków ASCII. Żeby system nazw był maksymalnie stabilny, przyjęto ścisłe zasady tego, co wolno umieścić w domenie.

Czyli klasyczny model to tzw. LDH (letters–digits–hyphen):

• litery: a–z (zapisywane bez rozróżniania wielkości liter),
• cyfry: 0–9,
• myślnik: -.

Do tego dochodzą ograniczenia techniczne:

• pojedyncza etykieta (część między kropkami, np. example w example.com)
  – maksymalnie 63 znaki,
• pełna nazwa FQDN (z kropkami) – maksymalnie 255 znaków,
• myślnik nie może być na początku ani na końcu etykiety,
• wewnątrz etykiety nie można stosować innych znaków specjalnych (@, /, #, spacji itd.).

Dzięki temu wszystkie serwery DNS i oprogramowanie sieciowe mogą operować na jednym, prostym formacie, niezależnie od języka, w którym zapisano nazwę widoczną dla użytkownika.

Jak działa zapis domen IDN w ASCII (punycode, prefiks xn--)?

Domeny IDN pozwalają na użycie Unicode (np. polskich znaków, cyrylicy, alfabetów azjatyckich), ale wygląd to jedno, a zapis w DNS to drugie. Żeby pogodzić obie rzeczy, stosuje się mechanizm IDNA (Internationalizing Domain Names in Applications).

Działa to w uproszczeniu tak:

1. Przeglądarka / aplikacja przyjmuje nazwę w Unicode, np. domena-ż.pl.
2. Każdą etykietę (tutaj: domena-ż i pl) przetwarza oddzielnie:
   • normalizuje zapis (m.in. do małych liter),
   • jeśli w etykiecie są tylko podstawowe znaki ASCII – zostawia ją bez zmian,
   • jeśli pojawia się choć jeden znak spoza LDH – stosuje kodowanie punycode i dodaje prefiks xn--.
3. Do DNS trafia już tylko forma ASCII, np.:
   • domena-ż.pl → xn--domena-abc.pl (przykładowa postać, sama idea jest istotna).
4. W drugą stronę (DNS → użytkownik) aplikacja po napotkaniu etykiety zaczynającej się od xn-- dekoduje ją z powrotem do Unicode i decyduje, co wyświetlić: wersję „ładną” czy surowy punycode (np. ze względów bezpieczeństwa).

Kluczowy wniosek z tego w zasadzie jest taki, że DNS widzi wyłącznie ASCII, a cały „międzynarodowy” charakter domen IDN jest obsługiwany po stronie aplikacji dzięki punycode i prefiksowi xn--.

Praktyczne konsekwencje zapisu domen w ASCII

Po pierwsze, nie każdy znak widoczny w domenie jest faktycznie zapisany w DNS. Jeśli rejestr oferuje domeny IDN z polskimi znakami, pod spodem takie nazwy są trzymane jako xn--…. W panelu lub WHOIS możesz więc zobaczyć tę techniczną postać – to normalne, to właśnie ASCII kompatybilne z DNS.

Po drugie, obowiązują te same ograniczenia długości i zestawu znaków, co w klasycznym DNS:

• nawet po zakodowaniu w punycode etykieta nie może przekroczyć 63 znaków,
• rejestr może odrzucić nazwę, która po konwersji do ASCII nie mieści się w tych ramach,
• wciąż nie wolno używać spacji, ukośników ani innych znaków specjalnych poza kropkami (jako separatorami).

Po trzecie, zapis w ASCII ma znaczenie dla bezpieczeństwa. Unicode pozwala tworzyć domeny wizualnie podobne (homoglify) z różnych alfabetów, dlatego przeglądarki i rejestry stosują dodatkowe zasady:

• blokują mieszanie kilku skryptów (np. łacina + cyrylica) w jednej etykiecie,
• w niektórych sytuacjach zamiast ładnej wersji Unicode pokażą użytkownikowi surowy punycode (xn--…),
• wdrażają polityki, które ograniczają możliwość podszywania się pod znane marki.

W praktyce warto traktować zapis ASCII jako warstwę transportową i kontrolną: dzięki niemu domeny – także IDN – działają na całym świecie w spójny sposób, a zasady LDH i limity długości wymuszają porządek i przewidywalność w systemie DNS.