Qual è la differenza tra `dig` e` host` quando si esegue una query su un server dei nomi specifico?

Stavo usando questo comando per verificare se avessi impostato correttamente le cose con un provider DNS:

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

Per quanto posso dire, questo chiede ns1.example-nameserver.comdi cercare hostname.example.come riporta la risposta. Stavo ricevendo una risposta non trovata dall'host, quindi ho pensato di aver sbagliato. Tuttavia, senza specificare il loro server dei nomi (permettendo così al server dei nomi del mio ISP di cercarlo) ho ottenuto la risposta corretta ( hostnameè un CNAMEse è importante). Non riuscivo a capire questo, quindi ho cercato in giro e ho trovato il digcomando:

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

Per quanto ne so, fa lo stesso del hostcomando: chiede a un server dei nomi specifico di cercare un host. Concludo pertanto che devono farlo in qualche modo in modo diverso e che i server dei nomi nella cache devono utilizzare lo stesso metodo di dig.

La mia conclusione è giusta o sbagliata, se è giusta:

Qual è la differenza tra questi due metodi di ricerca?

Se è sbagliato:

Quali sono i miei equivoci su DNS e i comandi hoste digche mi hanno portato a questa conclusione?

Esempio di output:

$ 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
fonte

entrambi i comandi dovrebbero funzionare allo stesso modo in questo caso. Puoi mostrare l'output completo di ciascun comando?

— Renan,

Notare come entrambi dige hostriferire NXDOMAIN. Con digpuoi vederlo nell'intestazione (quinta riga non vuota dell'output) e con hostè più ovvio. NXDOMAINsignifica che il dominio non esiste. Tuttavia un CNAMEviene restituito nella sezione risposta! Credo che sia un bug nel server DNS!

— Celada,

Quindi, in questo caso, fanno dige hostsia inviare l'esatto stesso pacchetto di query, ottenere esattamente lo stesso pacchetto di risposta (a parte eventuali timestamp), ma interpretano in modo diverso? Fa il hostsalvataggio non appena vede NXDOMAIN?

— Jhabbott,

FWIW Ho l'esatto problema opposto su un sottodominio specifico. L'utilizzo dell'host su questo sottodominio specifico fornisce il record previsto che mostra che questo sottodominio specifico si risolve in un nome host canonico previsto. Tuttavia, quando si utilizza dig su questo particolare sottodominio, ricevo una risposta che il record non esiste. Inoltre, la navigazione verso questo sottodominio con un browser non funziona. Ho provato più volte, verificando errori di ortografia, ecc. I comandi NON funzionano chiaramente allo stesso modo.

— user12345,

Risposte:

host, dige nslookuptutti condividono la maggior parte delle stesse funzionalità. Nel caso tu stia chiedendo (fare una particolare domanda DNS ad un particolare server dei nomi), dige host(e in effetti nslookup) si comportano esattamente allo stesso modo.

Per la risoluzione dei problemi DNS, digè preferibile perché il suo formato di output è più "grezzo": nel suo output mostra direttamente il contenuto di tutti e 4 i campi nella risposta DNS: domanda, risposta, autorità e sezioni aggiuntive (più i flag nell'intestazione) e ha anche più opzioni. hostd'altra parte, ha un formato di output più intuitivo.

Se non hai bisogno di un'opzione che uno dei comandi ha e gli altri no, o di un'informazione che uno di loro produce e gli altri no, allora si tratta di una questione di preferenza.

— Celada
fonte

Se fanno la stessa cosa sul lato della rete (la query effettiva) come posso ottenere l'host non trovato durante l'utilizzo hostma la risposta corretta quando utilizzo dig? Anche se il server è configurato utilizzando una determinata impostazione (per scelta o per incidente) per causare ciò, deve essere in grado di differenziare le richieste.

— Jhabbott,

No! I due comandi che dai nella tua domanda sono equivalenti e dovrebbero produrre la stessa risposta! Sei sicuro che digti abbia dato una risposta effettiva e non un record nella sezione aggiuntiva o di autorità? Come suggerisce Renan , potrebbe essere utile mostrare l'output.

— Celada,

Ok, ho aggiunto alcuni esempi di output. Ottengo lo stesso risultato a casa e al lavoro. Quando non specifico un server dei nomi da usare e il mio ISP gestisce la query, hostfunziona bene. Per favore provalo tu stesso e fammi sapere i risultati.

— Jhabbott,

Sto solo rivedendo questo aspetto - l'ISP alla fine mi ha detto che il loro server era configurato per non rispondere alle richieste dirette dei client, ma solo ad altri nameserver che chiedevano trasferimenti di informazioni - la digquery in un modo diverso, come farebbe un nameserver?

— Jhabbott,

scavare può fare sia domande regolari (tutti i tipi tranne AXFR) che trasferimenti di zona (tipo AXFR) ma gli operatori DNS di solito limitano i trasferimenti di zona agli schiavi autorizzati, quindi molto probabilmente vorrai usare domande regolari

— Celada

Se si utilizza un nome host non FQDN, i risultati possono essere diversi perché hostutilizzeranno i domini di ricerca in resolv.conf, mentre digper impostazione predefinita non lo è.

Devi usare l' +searchopzione se vuoi digusare resolv.conf(o aggiungerla a ~/.digrc).

Per esempio:

$ 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
fonte