Jeśli mam hosty example.com
i leaf.intermediate.example.com
rekordy DNS dla example.com
, ale nie mam żadnych rekordów dla intermediate.example.com
siebie, czy to powoduje problem w niektórych sytuacjach, czy z jakiegoś powodu jest to zły styl lub etykieta? Mam skonfigurowane serwery sieciowe i wszystko wydaje się działać dobrze, ale chciałem tylko sprawdzić, czy czegoś brakuje.
27
Odpowiedzi:
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.com
zwrotyNXDOMAIN
, to jakikolwiek rekurencyjny serwer nazw natychmiast odpowieNXDOMAIN
na nie,leaf.intermediate.example.com
ponieważ 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):
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, skorzystajmywww.teh.k12.ca.us
.Oczywiście, jeśli zapytasz o tę nazwę, a nawet
teh.k12.ca.us
możesz odzyskaćA
rekordy. Nic rozstrzygającego dla naszego celu (w środku jest nawet CNAME, ale nas to nie obchodzi):Zapytajmy teraz o
k12.ca.us
(nie pytam o autorytatywny serwer nazw, ale to w rzeczywistości nie zmienia wyniku):Czego uczymy się z tej odpowiedzi?
Po pierwsze, jest to sukces, ponieważ status to
NOERROR
. Gdyby to było coś innego, a konkretnieNXDOMAIN
wtedyteh.k12.ca.us
, i niewww.teh.k12.ca.us
mogłoby istnieć.Po drugie, sekcja ODPOWIEDŹ jest pusta. Brak
A
danych dlak12.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 oznaczaNOERROR
+ 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.com
mówiąc , plik strefy może być taki i jest całkowicie poprawny i działa:W przypadku takiego pliku strefy, zapytanie do tego serwera nazw spowoduje dokładnie zachowanie opisane powyżej: zapytanie dla
intermediate.example.com
zwróciNOERROR
z 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ścialeaf.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:
in-addr.arp
lubip6.arpa
, a konkretnie w ostatniej. Będziesz mieć rekordy podobne1.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 etykietySRV
rekordach, na przykład_nicname._tcp.fr. 12h IN SRV 0 0 43 whois.nic.fr.
, domena może mieć wiele_proto._tcp.example.com
i_proto._udp.example.com
SRV
rekordy, ponieważ z założenia muszą mieć ten formularz, ale jednocześnie_tcp.example.com
i_udp.example.com
pozostaną puste Non-Terminals, ponieważ nigdy nie są używane jako rekordywhatever._domainkey.example.com
, ale oczywiście_domainkey.example.com
sam z siebie nigdy nie będzie używany, więc pozostanie pusty, nie-terminalowy. To jest taka sama dlaTLSA
zapisów w DANE (np_25._tcp.somehost.example.com. TLSA 3 1 1 BASE64==
) lubURI
zapisy (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 toQNAME
protokół poniżej):Serwer nazw znajduje strefę
example.com
jako najbliższego przodka QNAME, więc możemy przejść do kroku 3.Mamy teraz to:
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.com
nazwę, 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:
Nie w naszym przypadku, pomijamy to.
Cokolwiek QTYPE zdecydujemy (
A
,AAAA
,NS
, itd.) Nie mamy dla RRintermediate.example.com
, ponieważ nie pojawiają się w zonefile. Więc kopia tutaj jest pusta. Teraz kończymy w kroku 6:Nie dotyczy nas tutaj, dlatego kończymy sukcesem.
To dokładnie tłumaczy obserwowane zachowanie: takie zapytania będą zwracane,
NOERROR
ale też nie będą mieć danych.Teraz możesz zadać sobie pytanie: „ale jeśli użyję jakiejkolwiek nazwy, tak jak
another.example.com
w powyższym algorytmie, powinienem otrzymać tę samą odpowiedź (bez błędu)”, ale obserwacje byłybyNXDOMAIN
w takim przypadku zgłaszane .Czemu?
Ponieważ cały algorytm, jak wyjaśniono, zaczyna się od tego:
Oznacza to, że powyższy plik strefy jest przekształcany w to drzewo:
Tak więc, postępując zgodnie z algorytmem, z góry rzeczywiście można znaleźć ścieżkę:
com > example > intermediate
(ponieważ ścieżkacom > example > intermediate > leaf
istnieje) Aleanother.example.com
pocom > example
, gdy nie znajdzieszanother
etykiety w drzewie, jako węzeł potomnyexample
. Dlatego wchodzimy w część wyboru c z góry:Etykieta
*
nie istnieje, a my nie zastosowaliśmy się do niejCNAME
, dlatego jesteśmy w przypadku:set an authoritative name error in the response and exit
akaNXDOMAIN
.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:
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
NXDOMAIN
naprawdę oznaczaNXDOMAIN
, że jest, jeśli odpowiedźNXDOMAIN
naintermediate.example.com
, wtedyleaf.intermediate.example.com
nie 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/127Ludzie musieli wtedy zastosować dla nich określone środki zaradcze: nie jest to agresywne buforowanie,
NXDOMAIN
ponieważ dla tych dostawców, jeśli dostaniesz sięNXDOMAIN
do jakiegoś węzła, może to oznaczać, że dostaniesz coś innego niżNXDOMAIN
inny 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:
źródło
Możliwe, że źle zrozumiałem odpowiedź Khaleda, ale brak pośrednich zapisów w żadnym wypadku nie powinien stanowić problemu z rozdzielczością podtonowanej nazwy. Zauważ, że ten wynik wyjściowy nie pochodzi ani nie jest skierowany do wiarygodnego serwera DNS
teaparty.net
ani żadnej jego podstrefy:Rzeczywiście, powinieneś być w stanie zrobić to
dig
sam i uzyskać tę odpowiedź -teaparty.net
to prawdziwa domena, pod moją kontrolą i naprawdę zawiera tenA
zapis. Możesz sprawdzić, czy nie ma żadnych rekordów dla żadnej z tych stref pomiędzyvery
iteaparty.net
, i że nie ma to wpływu na rozdzielczość powyższej nazwy hosta.źródło
teaparty.net
rekordy w jednym pliku strefy, więc puste rekordy są syntetyzowane dla domen pośrednich. Czy ktoś może wyjaśnić, co by się stało, gdybyparents.teaparty.net
delegacjavery.deep.host.with.no.immediate
była zapisana w pliku strefy delegowanej?teaparty.net
jest subdomeną delegowanąnet
; gdyby jedyny rekord A w jego pliku strefyvery.deep...
nie miałby znaczenia.Jeśli bezpośrednio przeszukujesz autorytatywny serwer DNS, otrzymasz odpowiedzi bez problemów.
Jednak nie otrzymasz poprawnej odpowiedzi, jeśli wysyłasz zapytanie za pośrednictwem innego serwera DNS, który nie ma prawidłowej pamięci podręcznej. Zapytanie o
intermediate.example.com
spowodujeNXDOMAIN
błąd.źródło
NXDOMAIN
, powinno skutkowaćNOERROR
kodem i pustą sekcją odpowiedzi.intermediate.example.com
jeśli nie jest do niczego używany. Więc nawet jeśli zwraca błąd (nie robi), jaką to robi różnicę?NXDOMAIN
, dostanieszNOERROR
. To jest odpowiedź dla węzła, który istnieje w hierarchii DNS, ale nie ma żadnych żądanych rekordów typu.NS
rekordy, ale poprosisz oA
rekordy, otrzymaszNOERROR
pustą odpowiedź.NXDOMAIN
dlaintermediate.example.com
to oznacza, że nie ma nic „poniżej”, a następnieleaf.intermediate.example.com
nie może istnieć. Niektóre agresywne rekurencyjne przeliczniki mogą nawet buforować to i odejmować rzeczy samodzielnie.Aby bezpośrednio odpowiedzieć na pytanie, nie, nie musisz dodawać rekordów dla nazw pośrednich, których tak naprawdę nie używasz, ale to nie znaczy, że te nazwy nie istnieją.
Jeśli chodzi o to, czy te nazwy istnieją, czy nie, jest to właściwie osobne pytanie, na które mam nadzieję udzielić krótkiej i raczej intuicyjnej odpowiedzi.
Wszystko sprowadza się do tego, że DNS jest strukturą drzewa, gdzie każda etykieta w nazwie domeny jest węzłem drzewa. Np
www.example.com.
ma etykietywww
,example
,com
i `` (węzeł główny), które są węzły drzewa, które tworzą ścieżkę aż do korzenia.To, co może sprawić, że ta podstawowa natura DNS będzie nieoczywista, to fakt, że prawie zawsze podczas zarządzania danymi DNS nie ma drzewa do zobaczenia i na ogół nie pracujemy bezpośrednio z samymi węzłami drzewa, zamiast tego zwykle mamy spłaszczoną listę tego, co rekord dane, które powinny istnieć w różnych nazwach domen (w rzeczywistości ścieżki drzewa, jak wyżej).
Co się dzieje, gdy jest używana ta spłaszczona lista jest to, że oprogramowanie serwera DNS konstruuje drzewo oparte na istniejących rekordów, a jeśli istnieją luki między węzłami, które rekordy (np Istnieją zapisy dla
foo.bar.example.com.
aexample.com.
jednak niebar.example.com.
) są one po prostu uważane pusty drzewo węzły Oznacza to, że są to nazwy domen / węzły, które faktycznie istnieją, drzewo nie jest zepsute, te węzły po prostu nie są z nimi powiązane.W związku z tym, jeśli zapytasz jeden z tych pustych węzłów, otrzymasz
NODATA
odpowiedź (NOERROR
status +SOA
w sekcji uprawnień), mówiąc, że żądany typ rekordu nie istniał w tym węźle. Jeśli zamiast tego zapytasz o nazwę, która tak naprawdę nie istnieje, otrzymaszNXDOMAIN
odpowiedź, że żądana nazwa domeny nie istnieje w drzewie.Teraz, jeśli chcesz drobiazgowych szczegółów, przeczytaj bardzo dokładną odpowiedź Patricka Mevzka.
źródło