Jaka jest różnica między `dig` i` host` podczas zapytania do określonego serwera nazw?

Korzystałem z tego polecenia, aby sprawdzić, czy poprawnie skonfiguruję ustawienia u dostawcy DNS:

host hostname.example.com ns1.example-nameserver.com

O ile mi wiadomo, prosi o to, ns1.example-nameserver.comaby spojrzeć w górę hostname.example.comi podać odpowiedź. Otrzymałem odpowiedź „nie znaleziono gospodarza”, więc pomyślałem, że zrobiłem to źle. Jednakże, bez określania ich nazwa-serwera (dzięki czemu nazwa-serwera mojego ISP to sprawdzić) Mam poprawną odpowiedź ( hostnameto CNAMEjeśli ma to znaczenie). Nie mogłem tego pojąć, więc rozejrzałem się i znalazłem digpolecenie:

dig @ns1.example-nameserver.com hostname.example.com

O ile mogę to stwierdzić, robi to samo co hostpolecenie - prosi określony serwer nazw, aby szukał hosta. W związku z tym dochodzę do wniosku, że muszą to zrobić inaczej, a buforowanie serwerów nazw musi korzystać z tej samej metody co dig.

Mój wniosek jest słuszny lub zły, jeśli jest słuszny:

Jaka jest różnica między tymi dwiema metodami wyszukiwania?

Jeśli jest źle:

Jakie są moje nieporozumienia dotyczące DNS i poleceń hostoraz dig, które doprowadziły mnie do tego wniosku?

Przykładowe dane wyjściowe:

$ host cardiff.tzmchapters.org ns1.livedns.co.uk
Using domain server:
Name: ns1.livedns.co.uk
Address: 213.171.192.250#53
Aliases: 

Host cardiff.tzmchapters.org not found: 3(NXDOMAIN)

$ dig @ns1.livedns.co.uk cardiff.tzmchapters.org

; <<>> DiG 9.8.3-P1 <<>> @ns1.livedns.co.uk cardiff.tzmchapters.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23620
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;cardiff.tzmchapters.org.   IN  A

;; ANSWER SECTION:
cardiff.tzmchapters.org. 3600   IN  CNAME   ghs.google.com.

;; AUTHORITY SECTION:
google.com.     3600    IN  SOA ns1.livedns.co.uk. admin.google.com. 1354213742 10800 3600 604800 3600

;; Query time: 27 msec
;; SERVER: 213.171.192.250#53(213.171.192.250)
;; WHEN: Mon Apr 22 23:47:05 2013
;; MSG SIZE  rcvd: 128

— jhabbott
źródło

oba polecenia powinny w tym przypadku działać tak samo. Czy możesz pokazać pełny wynik każdego polecenia?

— Renan

Zwróć uwagę na oba sposoby digi hostzgłoś NXDOMAIN. Ze digmożna go zobaczyć w nagłówku (5 niepusty wiersz wyjścia) i hostjest to bardziej oczywiste. NXDOMAINoznacza, że domena nie istnieje. Jednak CNAMEw sekcji odpowiedzi zwracane jest a ! Wierzę, że to błąd w serwerze DNS!

— Celada,

Więc w tym przypadku, czy digi hostjak wysłać dokładnie ten sam pakiet kwerendy uzyskać dokładnie ten sam pakiet odpowiedzi (oprócz ewentualnych znaczników czasu), ale interpretuje to inaczej? Czy hostratuje się, gdy tylko zobaczy NXDOMAIN?

— jhabbott

FWIW Mam dokładnie odwrotny problem w określonej subdomenie. Użycie hosta w tej konkretnej subdomenie zapewnia oczekiwany rekord pokazujący, że ta konkretna subdomena rozwiązuje oczekiwaną kanoniczną nazwę hosta. Jednak podczas korzystania z dig w tej konkretnej subdomenie - otrzymuję odpowiedź, że rekord nie istnieje. Ponadto nawigacja do tej subdomeny za pomocą przeglądarki nie działa. Próbowałem wiele razy, sprawdzając błędy ortograficzne itp. Polecenia najwyraźniej NIE działają w ten sam sposób.

— user12345,

Odpowiedzi:

host, digi nslookupwszystkie mają tę samą funkcjonalność. W przypadku, gdy pytasz (zadajesz konkretne pytanie DNS do konkretnego serwera nazw) digi host(i rzeczywiście nslookup) zachowujesz się dokładnie tak samo.

W przypadku rozwiązywania problemów z DNS digjest preferowany, ponieważ jego format wyjściowy jest bardziej „surowy”: w danych wyjściowych bezpośrednio pokazuje zawartość wszystkich 4 pól w odpowiedzi DNS: pytanie, odpowiedź, uprawnienia i dodatkowe sekcje (plus flagi w nagłówku) , a także ma więcej opcji. hostz drugiej strony ma bardziej przyjazny format wyjściowy.

Jeśli nie potrzebujesz opcji, którą ma jedno z poleceń, a inne nie, lub informacji, którą jedno z nich wysyła, a inne nie, to sprowadza się to do preferencji.

— Celada
źródło

Jeśli robią to samo po stronie sieci (rzeczywiste zapytanie), jak mogę uzyskać, że host nie zostanie znaleziony podczas używania, hostale poprawna odpowiedź podczas używania dig? Nawet jeśli serwer jest skonfigurowany przy użyciu określonego ustawienia (z wyboru lub przez przypadek), aby to spowodować, musi być w stanie rozróżnić żądania.

— jhabbott

Nie! Dwa polecenia podane w pytaniu są równoważne i powinny dać tę samą odpowiedź! Czy na pewno digdałeś ci prawdziwą odpowiedź, a nie zapis w dodatkowej lub autorytatywnej sekcji? Jak sugeruje Renan , pomocne może być pokazanie wyników.

— Celada

Ok, dodałem przykładowe dane wyjściowe. Ten sam rezultat mam w domu i w pracy. Kiedy nie określam serwera nazw, który ma być używany, a mój dostawca usług internetowych obsługuje zapytanie, hostdziała dobrze. Spróbuj sam i daj mi znać wyniki.

— jhabbott

Wystarczy przejrzeć to - ISP ostatecznie powiedział mi, że ich serwer został skonfigurowany tak, aby nie odpowiadać na bezpośrednie zapytania klientów, tylko na inne serwery nazw proszące o przesyłanie informacji - czy digzapytanie jest w inny sposób, jak zrobiłby to serwer nazw?

— jhabbott,

dig może wykonywać zarówno regularne pytania (wszystkie typy z wyjątkiem AXFR), jak i transfery stref (typ AXFR), ale operatorzy DNS zwykle ograniczają transfery stref do autoryzowanych urządzeń podrzędnych, więc najprawdopodobniej chcesz użyć zwykłych pytań

— Celada

Jeśli używasz nazwy hosta innej niż FQDN, wyniki mogą być inne, ponieważ hostbędą używać domen wyszukiwania w resolv.conf, digale domyślnie nie.

Musisz użyć tej +searchopcji, jeśli chcesz digużyć resolv.conf(lub dodać do ~/.digrc).

Na przykład:

$ host foo
foo.myfqdn.com has address 10.1.2.3

$ dig +short foo
# (no result)

$ dig +short +search foo
10.1.2.3

— wisbucky
źródło