Queries (zapytania)

Oceń tę pracę

Zapytania (queries) są wiadomościami wysyłanymi do name server’a, by wymusić na nim odpowiedź. W obrębie Internetu zapytania podróżują poprzez UDP (User Datagram Protocole) lub połączenia TCP. Odpowiedź otrzymana od name server’a może być rozwiązaniem problemu (pytania) postawionego w zapytaniu, odesłaniem do innych name server’ów w celu dalszych poszukiwań, lub też odpowiedzią sygnalizującą wystąpienie błędu.

Generalnie, użytkownik sam nie generuje zapytań, przekazuje je tylko w postaci żądań obsługi do resolver’a, który wysyła dopiero właściwie sformułowane zapytania do name server’a. W przypadku wystąpienia błędów, to również resolver zajmuje się ich obsługą.

Zapytania DNS, jak i odpowiedzi na nie udzielone przez name server’y, są przesyłane w postaci standardowego komunikatu. Komunikat posiada ustalony format zawierający nagłówek i pola zawierające informacje o zapytaniach, odpowiedziach itp. Najważniejszym polem w nagłówku jest 4-bitowe pole opcode. Rozdziela ono różne rodzaje zapytań – z 16 możliwych wartości, jakie może przyjąć, jedna jest częścią oficjalnego protokołu (standard query), dwie są przeznaczone na opcje (inverse query i status query), zaś pozostałe są dowolne.

Rodzaje zapytań

Podstawowe dwa rodzaje zapytań stosowane podczas uzyskiwania informacji:

  • STANDARD QUERIES Standardowy typ zapytania specyfikuje nazwę domeny docelowej (QNAME), rodzaj zapytania oraz klasę (QCLASS) oraz pytanie o rekordy RR, które sięzgadzają.

Używając nazwy domeny odpytywanej, oraz pól QTYPE, QCLASS name server szuka pasujących do siebie rekordów RR. W przypadku rekordów powiązanych name server może jako wynik zwrócić rekord będący wskazaniem na inny name server, posiadający informację o interesujących nas rekordach lub wyjaśniających powiązania rekordów.

Na przykład, name server, który sam nie posiada żądanej informacji, zna inne name server’y, name server zwracający nazwę domeny w postaci powiązanych rekordach może również zwrócić jako efekt rekord przypisujący nazwie domeny jej adres.

INVERSE QUERIES

Możliwe jest wykonywanie przez name server’y zapytań odwróconych, które przypisują (map) pewien konkretny zasób do domeny lub nazw domen, będących w posiadaniu takich zasobów.

Na przykład, jeżeli zwykłe zapytanie może przypisać nazwę domeny do wpisu SOA w RR, to odwrócone zapytanie może z powrotem przypisać temu wpisowi rekordu nazwę domeny.

Implementacja jest opcjonalna dla serwerów DNS, jednak wymagane jest, by każdy name server był w stanie odczytać i zrozumieć komunikat odwróconego zapytania i zwrócić odpowiedź nie będącą błędem.

Tego typu zapytania są wykorzystywane głównie do celów debugging’u jak i zarządzania bazą danych serwera DNS.

Absolutnie nie wolno stosować odwróconych zapytań do przypisywania adresów host’ów ich nazwom. Do tego celu służy specjalna domena .in-addr.arp. W zależności od zaawansowania serwera, może on odpowiadać na dwa różne sposoby – nierekursywny i rekursywny.

  • nierekursywny Najprostszy sposób, w którym name server może odpowiadać używając tylko lokalnych informacji: odpowiedź zawiera komunikat obłędzie, odpowiedź, lub odnośnik do innego serwera bliższego udzielenia odpowiedzi. Wszystkie serwery muszą mieć obowiązkowo zaimplementowany ten sposób.
  • rekursywny Pozwala name server’owi „przejąć” rolę resolver’a, i zwrócić jako rezultat błąd, albo odpowiedź, nigdy natomiast nie może zwrócić dalszego odnośnika. Jest to opcja implementacyjna, nawet name server, który ma ją zaimplementowaną może ograniczyć jej działanie do wybranych klientów a innym odmówić.

Serwis rekursywny bywa pomocny w sytuacji, gdy:

  • klientem jest prymitywny zgłoszeniodawca, którego możliwości sprowadzają się wyłącznie do użycia bezpośredniej odpowiedzi
  • żądanie obsługi musi przekroczyć barierę protokołu, lub inne granice – w takim przypadku zgłoszenie jest wysyłane do serwera, który może pośredniczyć w komunikacji
  • organizuje się sieć w której chcemy zastąpić oddzielne cache’e dla każdego z klientów na rzecz jednego

Przykłady zapytań

Dla przykładu poniżej opisano procedurę postępowania jaką wykonują SLAVE SERVER i FORWARDER by odpowiedzieć na zapytanie. (resolve name server query).

Krok 1. SLAVE SERVER otrzymuje zapytanie o nazwę host’a, na które musi odpowiedzieć.

Krok 2. SLAVE SERVER wysyła pytania do wszystkich FORWARDER’ów, które zapisane są w boot file serwera, dopóki nie dostanie odpowiedzi lub lista FORWARDER’ów zostanie wyczerpana.

Krok 3. Jeżeli FORWARDER nie posiada żądanej informacji w lokalnym cach’upyta ROOT SERVER’y umieszczone w jego plikach konfiguracyjnych. Dzieje się tak aż do uzyskania odpowiedzi lub lista ROOT SERVER’ów zostanie wyczerpana.

Krok 4. ROOT SERVER podaje FORWARDER’owi informację z jakim serwerem w jakiej domenie ten musi się skontaktować dla odpytania o szukany host.

Krok 5. FORWARDER wysyła żądanie do serwera w tej domenie. Adres serwera otrzymuje od ROOT SERVER’a, którego właśnie przepytywał.

Krok 6. Serwer dostarcza informacji o serwerach na niższych piętrach w strukturze domeny i poddomen.

Krok 7. Kroki 5. i 6. są powtarzane dopóki FORWARDER nie otrzyma żądanej informacji lub możliwości uzyskania informacji od innych host’ów zostaną wyczerpane.

Krok 8. FORWARDER zwraca rezultat poszukiwań do SLAVE SERVER’a, nawet jeśli jest niepomyślny.

image_pdf

Well Known Services Entry

Oceń tę pracę

Dobrze znane usługi (WKS) to pole określające usługi prowadzone przez poszczególne protokoły na podanym adresie. Usługi i numery portów są dostarczane w liście usług wyspecyfikowanych w pliku /etc/services.

Well Known Services Entry w kontekście DNS i sieci komputerowych odnosi się do powszechnie rozpoznawanych i standardowych usług, które mają przypisane określone numery portów i są uznawane za część standardowego zestawu protokołów internetowych. Te usługi są zwykle obsługiwane przez serwery w Internecie i mają przypisane numery portów z zakresu od 0 do 1023. Są one używane do obsługi różnych typów połączeń sieciowych i aplikacji, takich jak serwery WWW, poczta elektroniczna, transfer plików i wiele innych.

W systemie DNS, rekordy związane z Well Known Services są często implementowane jako część systemu SRV (Service Record), który umożliwia rozpoznawanie serwisów w sieci. Rekordy te wskazują na serwery, które oferują określoną usługę, a także wskazują numery portów, na których dana usługa jest dostępna. Dla takich dobrze znanych usług, jak HTTP (port 80), HTTPS (port 443), FTP (port 21), SMTP (port 25) i inne, istnieje przypisany zestaw standardowych portów, który jest wykorzystywany w różnych aplikacjach sieciowych.

Na przykład, dla usługi HTTP, serwer WWW, który obsługuje tę usługę, najczęściej jest dostępny na porcie 80. W DNS, może to być reprezentowane za pomocą rekordów A lub CNAME, wskazujących na serwery WWW:

www    IN A 192.0.2.1

Chociaż ta konfiguracja nie używa bezpośrednio rekordów SRV, sama usługa HTTP jest częścią zestawu Well Known Services. Dla bardziej złożonych usług, jak SIP (Session Initiation Protocol) czy LDAP (Lightweight Directory Access Protocol), które wymagają bardziej zaawansowanego mapowania serwisów w sieci, wykorzystuje się rekordy SRV:

_sip._tcp.example.com. IN SRV 10 60 5060 sipserver.example.com.

W tym przypadku rekord SRV wskazuje, że usługa SIP dostępna jest na porcie 5060 na serwerze sipserver.example.com z priorytetem 10 i wagą 60.

Rekordy związane z Well Known Services w DNS są kluczowe dla odpowiedniego kierowania zapytań do odpowiednich serwerów obsługujących popularne usługi w Internecie. Poprzez użycie odpowiednich portów i odpowiednią konfigurację DNS, użytkownicy i aplikacje mogą bezproblemowo łączyć się z serwisami internetowymi, takimi jak strony WWW, serwery poczty czy inne usługi oparte na TCP/IP.

Format WKS:

name ttl addr-class entry-type address protocol services

W praktyce przestało się tego używać, ponieważ mało serwerów używa tego wpisu, ponieważ nie ma takiego obowiązku. Poszczególne pola mają wartości zdefiniowane podobnie jak dla BIND File Entries, z wyjątkiem pól:

address

To pole specyfikuje adres IP dla każdego systemu. Dozwolone jest tylko jedno WKS dla każdego adresu IP.

hardware

Pole zawiera informację u stosowanym protokole, jaki będzie użyty dla usługi (np. UDP lub TCP)

Przykład: Wpis pola HINFO posiadającego dwie pozycje.

; name ttl addr-class entry-type address             protocol services                        IN HINFO         128.32.0.4        UDP who route                        IN HINFO         128.32.0.78      TCP (echo talk                                                                         discard sftp                                                                         netstat host                                                                         time link pop                                                                         finger domain auth)Usługi ujęte w nawiasy () są traktowane jako jedna usługa i mogą zajmować więcej niż jedną linijkę.

image_pdf

Mail Exchanger Entry

5/5 - (1 vote)

Mail Exchanger (MX) to jeden z kluczowych rekordów w systemie DNS, który określa, które serwery pocztowe są odpowiedzialne za odbieranie poczty elektronicznej dla danej domeny. Rekord MX wskazuje adresy serwerów pocztowych, do których powinny być kierowane wiadomości e-mail, gdy użytkownicy wysyłają pocztę do domeny.

Rekord MX zawiera dwie istotne informacje: adres serwera pocztowego oraz priorytet, który pozwala określić, który serwer powinien zostać użyty w pierwszej kolejności, gdy wiele serwerów obsługuje tę samą domenę. Priorytet jest liczbą całkowitą, gdzie mniejsza wartość oznacza wyższy priorytet. Na przykład, jeśli domena posiada dwa serwery pocztowe, jeden z priorytetem 10, a drugi z priorytetem 20, serwer o priorytecie 10 będzie używany jako pierwszy. Jeśli ten serwer jest niedostępny, wiadomości będą kierowane do serwera o wyższym priorytecie (priorytet 20).

Wpis rekordu MX w pliku strefy DNS może wyglądać następująco:

@    IN MX 10 mail.example.com.

W tym przypadku, rekord MX wskazuje, że serwer pocztowy mail.example.com ma priorytet 10 i jest odpowiedzialny za obsługę poczty przychodzącej dla domeny example.com.

Rekordy MX mogą również wskazywać na zewnętrzne serwery pocztowe, co jest powszechne w przypadku korzystania z usług pocztowych dostawców zewnętrznych, takich jak Google (Gmail) czy Microsoft (Outlook). Dzięki temu użytkownicy mogą korzystać z profesjonalnych usług hostingowych, nie zarządzając własnymi serwerami pocztowymi. Na przykład, rekordy MX dla domeny mogą wyglądać tak:

@    IN MX 10 mail1.provider.com.
@    IN MX 20 mail2.provider.com.

W takim przypadku, gdy mail1.provider.com jest niedostępny, poczta będzie kierowana do mail2.provider.com.

Rekordy MX odgrywają kluczową rolę w zapewnieniu prawidłowego funkcjonowania komunikacji e-mail. Są one niezbędne do określenia, gdzie powinny trafiać wiadomości e-mail wysyłane na adresy w danej domenie. Odpowiednia konfiguracja tych rekordów jest niezbędna, aby zapewnić niezawodną i wydajną obsługę poczty elektronicznej.

Pole to określa, który z komputerów w domenie lokalnej będzie pełnił funkcję gateway’a (tzn. komputera wiedzącego jak rozsyłać nadchodzącą pocztę do komputerów nie wpiętych bezpośrednio do sieci lokalnej i wysyłać ich pocztę poza obszar domeny).
Format MX:

system ttl addr-class entry-type pref-value gateway

Poszczególne pola mają wartości zdefiniowane podobnie jak dla BIND File Entries, z wyjątkiem pól:

system

Pole specyfikuje nazwę systemu, do którego poczta ma być wysłana.

pref-value

Pole, w którym zapisywana jest kolejność, według której mailer wybiera drogę wysłania poczty (jeżeli jest określonych kilka różnych).

gateway

Pole zawiera informację o nazwie gateway’a.

Przykład:
Wpis pola MX posiadającego dwie pozycje.

; system ttl addr-class entry-type pref-value gateway
munari.oz.au.                IN         MX       0          ceisimo.cs.au.
*.folks.dec.com.            IN         MX       0          relay.cs.net.

W pierwszej linijce host ceisimo.cs.au. jest gateway’em poczty dla munari.oz.au., natomiast w drugiej linijce zastosowano gwiazdkę jako wildcard, pozwalającą na to, by niezależnie od nazwy komputera w domenie .folks.dec.com cała poczta będzie przesyłana przez gateway relay.cs.net.

image_pdf

Host Information Entry

Oceń tę pracę

Wpis informacji na temat host’a (HINFO) pozwala na opisanie informacji o komputerze. Wpis składa się z różnych pozycji takich jak specyfikacja sprzętowa, system operacyjny. Należy pamiętać, że tylko jedna spacja oddziela opis hardware’u od systemu, więc jeżeli odstęp ma być częścią nazwy należy ująć ją w cudzysłów. W zapisie nie może być więcej niż jedna pozycja określająca każdy host w domenie.

Format HINFO:

host ttl addr-class entry-type hardware opsys

Poszczególne pola mają wartości zdefiniowane podobnie jak dla BIND File Entries, z wyjątkiem pól:

host

To pole specyfikuje nazwę host’a. Jeżeli host jest w bieżącej domenie, wystarczy podać tylko nazwę komputera. Jeżeli komputer znajduje się w innej domenie, należy podać pełną nazwę BIND’ową (tzn. zakończoną kropką (.). Np. utah.states.dec.com.

hardware

Tutaj umieszczana jest informacja o typie procesora.

opsys

Tutaj umieszczana jest nazwa systemu operacyjnego, pod którym pracuje dany komputer.Patrz przykład.

Przykład:
wpis pola HINFO posiadającego jedną pozycję.

; host                ttl addr-class entry-type hardware opsys

alpha.twins.pk.edu.pl IN  HINFO „DEC Alpha 3400” „Digital Unix v3.2”

image_pdf

Adress Entry

Oceń tę pracę

Address Entry w kontekście systemów DNS (Domain Name System) jest wpisem w bazie danych, który przypisuje adres IP do nazwy hosta. Jest to jedna z podstawowych funkcji DNS, umożliwiająca rozwiązywanie nazw domenowych na adresy IP, dzięki czemu urządzenia w sieci mogą się wzajemnie odnajdywać i komunikować.

W kontekście konfiguracji DNS, najczęściej spotykanym rodzajem „Address Entry” jest A Record (Address Record). A Record to wpis, który mapuje nazwę domeny na adres IPv4. Na przykład, wpis A w DNS mógłby wyglądać tak:
example.com. IN A 192.0.2.1

Taki wpis oznacza, że domena „example.com” wskazuje na adres IP „192.0.2.1”. Jest to podstawowa forma rozwiązywania nazw w DNS, wykorzystywana do komunikacji z serwerami, stronami internetowymi, czy innymi urządzeniami w sieci.

AAAA Record (znany również jako „IPv6 address entry”) jest analogicznym wpisem w DNS, ale dla adresów IPv6. Format wpisu wygląda podobnie, ale adres jest w formacie IPv6, który jest dłuższy i składa się z ośmiu grup czteroznakowych liczb szesnastkowych, np.
example.com. IN AAAA 2001:0db8:85a3:0000:0000:8a2e:0370:7334

Z kolei w kontekście WINS (Windows Internet Name Service), Address Entry odnosi się do mapowania nazw NetBIOS na adresy IP w sieci lokalnej, co jest szczególnie użyteczne w środowiskach opartych na starszych technologiach Windows.

Warto dodać, że zarządzanie tymi wpisami odbywa się przez interfejsy administracyjne DNS, które pozwalają na dodawanie, edytowanie i usuwanie odpowiednich „address entries” w bazach danych, co umożliwia dynamiczne zmiany w rozwiązywaniu nazw w sieci.

Wpis adresowy A wylicza wszystkie adresy poszczególnych komputerów.
Format A:

name ttl addr-class entry-type adress

Poszczególne pola mają wartości zdefiniowane podobnie jak dla BIND File Entries, z wyjątkiem pola:

adress

Tutaj umieszczany jest adres IP dla każdego komputera. Może być tylko jedna pozycja typu A dla każdego podanego adresu.

Przykład:
Wpis dwóch pól A:

; name                          ttl addr-class entry-type adress
miami.cities.dec.com                 IN          A                     128.11.22.44
                                                 IN          A                     128.11.22.33

Pole ttl zostało opuszczone, zatem przyjmowana jest wartość określona w SOA. Z powyższego przykładu wynika, iż komputer miami.cities.dec.com ma dwa adresy IP.

image_pdf