TL; DR: tak, muszą istnieć pośrednie subdomeny, przynajmniej w razie zapytania, zgodnie z definicją DNS; mogą jednak nie istnieć w pliku strefy.
Możliwe zamieszanie w celu wyeliminowania w pierwszej kolejności; Definicja „pustego terminala”
Być może mylisz dwie rzeczy, podobnie jak inne odpowiedzi. Mianowicie, co dzieje się podczas zapytania o nazwy w porównaniu do sposobu konfiguracji serwera nazw i zawartości pliku strefy.
DNS jest hierarchiczny. Aby istniał jakikolwiek węzeł liścia, MUSZĄ istnieć wszystkie elementy prowadzące do niego, w tym sensie, że jeśli są one pytane, odpowiedzialny autorytatywny serwer nazw powinien odpowiedzieć za nie bez błędu.
Jak wyjaśniono w RFC 8020 (który jest tylko powtórzeniem tego, co zawsze było regułą, ale tylko niektórzy dostawcy DNS potrzebowali przypomnienia), jeśli w przypadku dowolnego zapytania, autorytatywna nazwa serwera odpowiedzi NXDOMAIN (to znaczy: ten rekord zasobu nie istnieje), oznacza to, że żadna etykieta „poniżej” tego zasobu również nie istnieje.
W twoim przykładzie, jeśli zapytanie o intermediate.example.comzwroty NXDOMAIN, to jakikolwiek rekurencyjny serwer nazw natychmiast odpowie NXDOMAINna nie, leaf.intermediate.example.componieważ ten rekord nie może istnieć, jeśli wszystkie etykiety w nim nie istnieją jako rekordy.
Zostało to już stwierdzone w RFC 4592 o znakach wieloznacznych (które nie są tutaj powiązane):
Przestrzeń nazw domen to struktura drzewiasta. Węzły w drzewie albo
posiadają co najmniej jeden zestaw RRSet i / lub mają potomków, którzy łącznie posiadają
co najmniej jeden zestaw RRSet. Węzeł może istnieć bez RRSets tylko wtedy, gdy ma
potomków, którzy to robią; ten węzeł jest pustym nieterminalnym.
Węzeł bez potomków jest węzłem liścia. Puste węzły liści nie istnieją.
Praktyczny przykład z nazwami domen .US
Weźmy przykład roboczy z TLD z wieloma historycznymi etykietami, to znaczy .US. Wybierając dowolny przykład online, skorzystajmy www.teh.k12.ca.us.
Oczywiście, jeśli zapytasz o tę nazwę, a nawet teh.k12.ca.usmożesz odzyskać Arekordy. Nic rozstrzygającego dla naszego celu (w środku jest nawet CNAME, ale nas to nie obchodzi):
$ dig www.teh.k12.ca.us A +short
CA02205882.schoolwires.net.
107.21.20.201
35.172.15.22
$ dig teh.k12.ca.us A +short
162.242.146.30
184.72.49.125
54.204.24.19
54.214.44.86
Zapytajmy teraz o k12.ca.us(nie pytam o autorytatywny serwer nazw, ale to w rzeczywistości nie zmienia wyniku):
$ dig k12.ca.us A
; <<>> DiG 9.11.5-P1-1ubuntu2.5-Ubuntu <<>> k12.ca.us A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59101
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1480
;; QUESTION SECTION:
;k12.ca.us. IN A
;; AUTHORITY SECTION:
us. 3587 IN SOA a.cctld.us. hostmaster.neustar.biz. 2024847624 900 900 604800 86400
;; Query time: 115 msec
;; SERVER: 127.0.0.10#53(127.0.0.10)
;; WHEN: mer. juil. 03 01:13:20 EST 2019
;; MSG SIZE rcvd: 104
Czego uczymy się z tej odpowiedzi?
Po pierwsze, jest to sukces, ponieważ status to NOERROR. Gdyby to było coś innego, a konkretnie NXDOMAINwtedy teh.k12.ca.us, i nie www.teh.k12.ca.usmogłoby istnieć.
Po drugie, sekcja ODPOWIEDŹ jest pusta. Brak Adanych dla k12.ca.us. To nie jest błąd, ten typ ( A) nie istnieje dla tego rekordu, ale może istnieją inne typy rekordów dla tego rekordu lub ten rekord jest ENT, czyli „Empty Non Terminal”: jest pusty, ale nie jest liściem, są rzeczy „poniżej” (patrz definicja w RFC 7719 ), jak już wiemy (ale zwykle rozdzielczość jest z góry na dół, więc osiągniemy ten krok, zanim przejdziemy o jeden poziom poniżej, a nie odwrotnie, jak robimy tutaj dla demonstracji cel, powód).
Właśnie dlatego w skrócie mówimy, że kod stanu to NODATA: to nie jest prawdziwy kod statusu, to po prostu oznacza NOERROR+ pustą sekcję ODPOWIEDŹ, co oznacza, że nie ma danych dla tego konkretnego typu rekordu, ale mogą istnieć dla innych.
Możesz powtórzyć ten sam eksperyment dla tego samego wyniku, jeśli zapytasz następną etykietą „w górę”, czyli nazwą ca.us.
Wyniki zapytań a zawartość pliku strefy
A skąd się bierze zamieszanie? Uważam, że może to wynikać z fałszywego pomysłu, że jakakolwiek kropka w nazwie DNS oznacza, że istnieje delegacja. To nieprawda. Inaczej example.commówiąc , plik strefy może być taki i jest całkowicie poprawny i działa:
example.com. IN SOA ....
example.com. IN NS ....
example.com. IN NS ....
leaf.intermediate.example.com IN A 192.0.2.37
W przypadku takiego pliku strefy, zapytanie do tego serwera nazw spowoduje dokładnie zachowanie opisane powyżej: zapytanie dla intermediate.example.comzwróci NOERRORz pustą odpowiedzią. Nie musisz go tworzyć specjalnie w pliku strefy (jeśli nie potrzebujesz go z innych powodów), autorytatywny serwer nazw zajmie się syntezą odpowiedzi „pośrednich”, ponieważ widzi, że potrzebuje tej pustej nieterminalnej (i dowolnej inne „pomiędzy”, jeśli były inne etykiety), ponieważ widzi nazwę liścia leaf.intermediate.example.com.
Zauważ, że jest to powszechny przypadek w niektórych obszarach, ale możesz go nie zobaczyć, ponieważ dotyczy on większej liczby rekordów „infrastruktury”, na które ludzie nie są narażeni:
- w strefach odwróconych, takich jak
in-addr.arplub ip6.arpa, a konkretnie w ostatniej. Będziesz mieć rekordy podobne 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.1.d.e.1.6.8.0.0.0.0.0.0.2.6.2.ip6.arpa. 1h IN PTR text-lb.eqiad.wikimedia.org.i oczywiście nie ma delegacji w każdej kropce ani rekordów zasobów dołączonych do każdej etykiety
- w
SRVrekordach, na przykład _nicname._tcp.fr. 12h IN SRV 0 0 43 whois.nic.fr., domena może mieć wiele _proto._tcp.example.comi _proto._udp.example.com SRVrekordy, ponieważ z założenia muszą mieć ten formularz, ale jednocześnie _tcp.example.comi _udp.example.compozostaną puste Non-Terminals, ponieważ nigdy nie są używane jako rekordy
- w rzeczywistości istnieje wiele innych przypadków specyficznej konstrukcji nazw opartych na „etykietach podkreślenia” dla różnych protokołów, takich jak DKIM. DKIM upoważnia cię do posiadania takich rekordów DNS
whatever._domainkey.example.com, ale oczywiście _domainkey.example.comsam z siebie nigdy nie będzie używany, więc pozostanie pusty, nie-terminalowy. To jest taka sama dla TLSAzapisów w DANE (np _25._tcp.somehost.example.com. TLSA 3 1 1 BASE64==) lub URIzapisy (np _ftp._tcp IN URI 10 1 "ftp://ftp1.example.com/public")
Zachowanie serwera nazw i generowanie odpowiedzi pośrednich
Dlaczego serwer nazw automatycznie syntetyzuje takie odpowiedzi pośrednie? Przyczyną tego jest algorytm rozpoznawania rdzenia dla DNS, opisany szczegółowo w RFC 1034 sekcja 4.3.2 , weźmy go i podsumujmy w naszym przypadku, gdy pytamy o powyższy autorytatywny serwer nazw dla tej nazwy intermediate.example.com(jest to QNAMEprotokół poniżej):
- Wyszukaj dostępne strefy dla strefy, która jest najbliższym przodkiem QNAME. Jeśli taka strefa zostanie znaleziona, przejdź do kroku 3, w przeciwnym razie do kroku 4.
Serwer nazw znajduje strefę example.comjako najbliższego przodka QNAME, więc możemy przejść do kroku 3.
Mamy teraz to:
- Rozpocznij dopasowywanie w dół, etykieta po etykiecie, w strefie. [..]
za. Jeśli cała QNAME jest dopasowana, znaleźliśmy węzeł. [..]
b. Jeśli dopasowanie usunie nas z wiarygodnych danych, mamy skierowanie. Dzieje się tak, gdy napotykamy węzeł z NS RR oznaczającymi nacięcia wzdłuż dna strefy. [..]
do. Jeśli przy jakiejś etykiecie dopasowanie jest niemożliwe (tzn. Odpowiednia etykieta nie istnieje), sprawdź, czy istnieje etykieta „*”. [..]
Możemy wyeliminować przypadki b i c, ponieważ nasz plik strefy nie ma delegacji (stąd nigdy nie będzie odwołania do innych serwerów nazw, nie ma przypadku b) ani symboli wieloznacznych (więc nie ma przypadku c).
Mamy tu do czynienia tylko ze sprawą a.
Zaczynamy dopasowywać w strefie etykietę po etykiecie. Więc nawet jeśli mamy długą sub.sub.sub.sub.sub.sub.sub.sub.example.comnazwę, w pewnym momencie dochodzimy do przypadku: nie znaleźliśmy skierowania ani symbolu wieloznacznego, ale skończyliśmy na ostatecznej nazwie, dla której chcieliśmy uzyskać wynik.
Następnie stosujemy resztę treści sprawy a:
Jeśli dane w węźle to CNAME
Nie w naszym przypadku, pomijamy to.
W przeciwnym razie skopiuj wszystkie RR zgodne z QTYPE do sekcji odpowiedzi i przejdź do kroku 6.
Cokolwiek QTYPE zdecydujemy ( A, AAAA, NS, itd.) Nie mamy dla RR intermediate.example.com, ponieważ nie pojawiają się w zonefile. Więc kopia tutaj jest pusta. Teraz kończymy w kroku 6:
Używając tylko danych lokalnych, spróbuj dodać inne RR, które mogą być przydatne w dodatkowej sekcji zapytania. Wyjście.
Nie dotyczy nas tutaj, dlatego kończymy sukcesem.
To dokładnie tłumaczy obserwowane zachowanie: takie zapytania będą zwracane, NOERRORale też nie będą mieć danych.
Teraz możesz zadać sobie pytanie: „ale jeśli użyję jakiejkolwiek nazwy, tak jak another.example.comw powyższym algorytmie, powinienem otrzymać tę samą odpowiedź (bez błędu)”, ale obserwacje byłyby NXDOMAINw takim przypadku zgłaszane .
Czemu?
Ponieważ cały algorytm, jak wyjaśniono, zaczyna się od tego:
Poniższy algorytm zakłada, że RR są zorganizowane w kilka struktur drzewa, po jednej dla każdej strefy, a drugi dla pamięci podręcznej
Oznacza to, że powyższy plik strefy jest przekształcany w to drzewo:
+-----+
| com | (just to show the delegation, does not exist in this nameserver)
+-----+
|
|
|
+---------+
| example | SOA, NS records
+---------+
|
|
|
+--------------+
| intermediate | no records
+--------------+
|
|
|
+------+
| leaf | A record
+------+
Tak więc, postępując zgodnie z algorytmem, z góry rzeczywiście można znaleźć ścieżkę: com > example > intermediate(ponieważ ścieżka com > example > intermediate > leafistnieje) Ale another.example.compo com > example, gdy nie znajdziesz anotheretykiety w drzewie, jako węzeł potomny example. Dlatego wchodzimy w część wyboru c z góry:
Jeśli etykieta „*” nie istnieje, sprawdź, czy szukana nazwa to pierwotna nazwa QNAME w zapytaniu, czy nazwa, której używaliśmy ze względu na CNAME. Jeśli nazwa jest oryginalna, ustaw autorytatywny błąd nazwy w odpowiedzi i zakończ. W przeciwnym razie po prostu wyjdź.
Etykieta *nie istnieje, a my nie zastosowaliśmy się do niej CNAME, dlatego jesteśmy w przypadku: set an authoritative name error in the response and exitaka NXDOMAIN.
Zauważ, że wszystkie powyższe w przeszłości powodowały zamieszanie. Jest to gromadzone w niektórych RFC. Zobacz na przykład to nieoczekiwane miejsce (radość z tego, że specyfikacje DNS są tak nieprzeniknione) definiujące symbole wieloznaczne: RFC 4592 „Rola symboli wieloznacznych w systemie nazw domen”, a zwłaszcza jego sekcja 2.2 „Reguły istnienia”, również częściowo cytowana na początku moja odpowiedź, ale tutaj jest bardziej kompletna:
Puste nieterminale [RFC2136, sekcja 7.16] to nazwy domen, które nie posiadają żadnych rekordów zasobów, ale mają takie poddomeny. W sekcji 2.2.1
„_tcp.host1.przykład”. jest przykładem pustej nieterminalnej nazwy.
Puste nieterminale są wprowadzane przez ten tekst w sekcji 3.1 RFC 1034:
# The domain name space is a tree structure. Each node and leaf on
# the tree corresponds to a resource set (which may be empty). The
# domain system makes no distinctions between the uses of the
# interior nodes and leaves, and this memo uses the term "node" to
# refer to both.
Nawiasy w nawiasach „które mogą być puste” wskazują, że puste
nieterminale są jawnie rozpoznawane i że puste nieterminale
„istnieją”.
Pedantyczne czytanie powyższego akapitu może prowadzić do
interpretacji, że istnieją wszystkie możliwe domeny - do sugerowanego
limitu 255 oktetów dla nazwy domeny [RFC1035]. Na przykład
www.example. może mieć RR A, i, o ile to praktycznie
dotyczy, jest liściem drzewa domen. Ale definicję można
rozumieć jako oznaczającą ten pod. Przykład. istnieje również, choć bez danych. Według rozszerzenia istnieją wszystkie możliwe domeny, od katalogu głównego do dołu.
Ponieważ RFC 1034 definiuje również „autorytatywny błąd nazwy wskazujący, że nazwa nie istnieje” w sekcji 4.3.1, więc najwyraźniej nie jest to intencja oryginalnej definicji, uzasadniając potrzebę zaktualizowanej definicji w następnej sekcji.
A następnie definicją w następnej sekcji jest akapit, który zacytowałem na początku.
Należy zauważyć, że w dokumencie RFC 8020 (na NXDOMAINnaprawdę oznacza NXDOMAIN, że jest, jeśli odpowiedź NXDOMAINna intermediate.example.com, wtedy leaf.intermediate.example.comnie może istnieć) została upoważniona w części z powodu różnych dostawców DNS nie zastosował tę interpretację i który stworzył spustoszenie, lub były tylko błędy, patrz na przykład ten jeden naprawiony w 2013 r. w jednym autorytatywnym kodzie serwera nazw opensource: https://github.com/PowerDNS/pdns/issues/127
Ludzie musieli wtedy zastosować dla nich określone środki zaradcze: nie jest to agresywne buforowanie, NXDOMAINponieważ dla tych dostawców, jeśli dostaniesz się NXDOMAINdo jakiegoś węzła, może to oznaczać, że dostaniesz coś innego niż NXDOMAINinny węzeł poniżej.
A to uniemożliwiało uzyskanie minimalizacji QNAME (RFC 7816) ( więcej szczegółów na stronie: https://indico.dns-oarc.net/event/21/contribution/298/attachments/267/487/qname-min.pdf ) , podczas gdy chciałem zwiększyć prywatność. Istnienie pustych nieterminali w przypadku DNSSEC również w przeszłości powodowało problemy związane z obsługą nieistnienia (patrz https://indico.dns-oarc.net/event/25/contribution/403/attachments/378/647 /AFNIC_OARC_Dallas.pdf, jeśli jest zainteresowany, ale naprawdę potrzebujesz dobrego zrozumienia DNSSEC wcześniej).
Poniższe dwa komunikaty podają przykład problemów, które jeden dostawca musiał być w stanie poprawnie egzekwować w przypadku tej reguły na pustych terminalach innych niż terminale, daje pewne spojrzenie na problemy i dlaczego tam jesteśmy: