dig @192.161.119.112 chucks-tees.com
; <<>> DiG 9.9.9-P1 <<>> @192.161.119.112 chucks-tees.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32737
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;chucks-tees.com. IN A
;; ANSWER SECTION:
chucks-tees.com. 172800 IN A 192.161.119.112
;; AUTHORITY SECTION:
chucks-tees.com. 172800 IN NS ns1.chucks-tees.com.
chucks-tees.com. 172800 IN NS ns2.chucks-tees.com.
;; ADDITIONAL SECTION:
ns1.chucks-tees.com. 172800 IN A 192.161.119.112
ns2.chucks-tees.com. 172800 IN A 192.161.119.112
;; Query time: 1 msec
;; SERVER: 192.161.119.112#53(192.161.119.112)
;; WHEN: Sun Feb 12 12:04:34 EST 2017
;; MSG SIZE rcvd: 128
nslookup chucks-tees.com
Server: 209.159.189.8
Address: 209.159.189.8#53
Non-authoritative answer:
Name: chucks-tees.com
Address: 192.161.119.112
Когда я пытаюсь получить доступ, он работает только локально.
Если я добавлю DNS для поиска, то есть Windows DNS, чтобы указать сервер, он работает
Теперь мне кажется, что это должно работать, на данный момент я жду, чтобы увидеть, будет ли он распространяться, но не уверен, правильно ли это работает, чтобы отвечать на внешние запросы.
192.161.119.112
отвечает только по TCP, а не по UDP.
DNS в основном используется через UDP (но также и TCP в определенных сценариях), поэтому это будет серьезной проблемой.
Может быть, есть какой-то брандмауэр, который вызывает это? Убедитесь, что доступны и 53 / udp, и 53 / tcp.