dig -4IPv6 주소가 반환되는 이유는 무엇입니까 ?
% dig -v
DiG 9.16.5
%
% dig -4 @8.8.8.8 TXT o-o.myaddr.l.google.com | grep TXT
; <<>> DiG 9.16.5 <<>> -4 @8.8.8.8 TXT o-o.myaddr.l.google.com
;o-o.myaddr.l.google.com. IN TXT
o-o.myaddr.l.google.com. 54 IN TXT "2a0a:b640:1:5a::a07d"
걱정하지 마세요. 저는 VPN을 사용하고 있습니다.
이것은 Google 네임서버의 버그입니까? (그렇다면 어떻게 신고하나요?)
흥미롭게도 다음을 추가하면 출력이 달라집니다 -c IN.
% diff <(dig -4 -c IN @8.8.8.8 TXT o-o.myaddr.l.google.com) <(dig -4 @8.8.8.8 TXT o-o.myaddr.l.google.com)
2c2
< ; <<>> DiG 9.16.5 <<>> -4 -c IN @8.8.8.8 TXT o-o.myaddr.l.google.com
---
> ; <<>> DiG 9.16.5 <<>> -4 @8.8.8.8 TXT o-o.myaddr.l.google.com
6,7c6,7
< ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35377
< ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
---
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27019
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 3
11c11
< ; COOKIE: ffdced2ffd1d8fb9ca1b1c3c5f53070accd8e6ece4fb266f (good)
---
> ; COOKIE: 8042de852de231e1242187435f53070bdddc4b80f19c7711 (good)
13c13
< ;TXT. IN A
---
> ;o-o.myaddr.l.google.com. IN TXT
15,25c15,16
< ;; AUTHORITY SECTION:
< . 7956 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2020090401 1800 900 604800 86400
<
< ;; Query time: 66 msec
< ;; SERVER: 8.8.8.8#53(8.8.8.8)
< ;; WHEN: Sat Sep 05 10:33:31 +07 2020
< ;; MSG SIZE rcvd: 135
<
< ;; Got answer:
< ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16524
< ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
---
> ;; ANSWER SECTION:
> o-o.myaddr.l.google.com. 28 IN TXT "2a0a:b640:1:5a::a07d"
27,31c18,26
< ;; OPT PSEUDOSECTION:
< ; EDNS: version: 0, flags:; udp: 4096
< ; COOKIE: ffdced2ffd1d8fb9e51dd6995f53070b3d32c82e71242836 (good)
< ;; QUESTION SECTION:
< ;o-o.myaddr.l.google.com. IN A
---
> ;; AUTHORITY SECTION:
> google.com. 121655 IN NS ns1.google.com.
> google.com. 121655 IN NS ns4.google.com.
> google.com. 121655 IN NS ns3.google.com.
> google.com. 121655 IN NS ns2.google.com.
>
> ;; ADDITIONAL SECTION:
> ns1.google.com. 340694 IN A 216.239.32.10
> ns1.google.com. 340694 IN AAAA 2001:4860:4802:32::a
33c28
< ;; Query time: 76 msec
---
> ;; Query time: 73 msec
36c31
< ;; MSG SIZE rcvd: 80
---
> ;; MSG SIZE rcvd: 229
답변1
이는 당신이 일을 잘하지 못했다는 것을 의미합니다. ☺
신고 -c IN효과는 제대로 하지 않았기 때문이다. IN어쨌든 이것이 기본 클래스이므로 두 쿼리 모두 명확합니다 . 그러나 실패한 것은 도메인 이름 TXT.이 아니라 조회 도메인 이름이라는 점에 유의하십시오 o-o.myaddr.l.google.com.. 혼란스러워서 dig리소스 레코드 유형 매개변수가 도메인 이름이라고 생각하게 되었습니다.
매개변수로 처리하는 것은 순서가 명확하게 명시된 매뉴얼을 읽지 않는 사람들을 위한 버팀목이라는 점에 유의하십시오. ☺ (Knot DNS는 매뉴얼상 순서가 조금 다르지만, 자신의 주장을 잘못된 방식으로 제시하는 사람들을 다루려고 노력합니다.)type domain-namedigdomain-name type classkdigdomain-name class type
또한 매뉴얼에서는 (최상위) 도메인 이름을 사용 -t하고 모호함을 피하도록 명시적으로 권장합니다.-q
이것은 -4실제로 이것과 아무 관련이 없습니다. 이는 IPv4를 DNS 서버와 통신하게 만듭니다. 하지만 DNS 서버가 잘못되었습니다.
이것은 @8.8.8.8중요한 요소입니다.
쿼리는 Google에 대해 직접 실행되어야 합니다.콘텐츠DNS 서버. (작성 당시) IPv4 세계에서는 다음과 같습니다.
%dnsqrnsl.google.com. | awk '/답변:/ {print $5}' |
216.239.34.10
216.239.32.10
216.239.36.10
216.239.38.10
%
TXT도메인 이름이 쿼리되면 이러한 콘텐츠 DNS 서버는 원래 IP 주소와 EDNS0 정보를 리소스 레코드 집합으로 반환합니다.
당신은 Google을 위해 이 일을 하고 있습니다.공개 결의 프록시대신 DNS 서버가 사용됩니다. EDNS0 정보와 원래 IP 주소를 얻고 있습니다.사용되는 특정 프록시 서버의 백엔드(8.8.8.8은 애니캐스트임) 머신의 자체 IP 주소 대신. Google의 공개 프록시 DNS 서버가 Google의 콘텐츠 DNS 서버에 접속하므로 IP 주소와 EDNS0 정보입니다.저것리소스 레코드 세트의 콘텐츠는 DNS 서버에서 반환되고 Google 프록시로 반환된 다음 프록시에서 사용자에게 반환됩니다.
사실 TTL은 Google의 60초가 아닌 54초입니다.콘텐츠여기서는 DNS 서버의 사용이 큰 단서가 되지만 실제로는 그렇지 않습니다.당신의IPv6 주소.
dig대부분의 docos에서 사용 및 제공되는 약어가 host일반적으로 거래를 Google의 콘텐츠 DNS 서버로 명시적으로 지시하지 않고도 작동하는 이유는 해당 거래가 다음을 통과하기 때문입니다.현지의프록시 DNS 서버 확인자신의 컴퓨터에서, 백엔드 쿼리는 물론 다음에서 파생됩니다.당신의 기계IP 주소. 로컬 확인 프록시 DNS 서버를 보유하는 것은 Unix 및 Linux 세계의 표준이었으며 현재도 그렇습니다. 이것은 (서버가 아닌) Microsoft Windows가 아닙니다.
하지만: 사용하다다른 사람의자신의 프록시 DNS 서버에서 전달하거나 에서 다른 사람의 서버를 구성하거나 /etc/resolv.conf(여기서와 같이) 쿼리를 8.8.8.8/1.1.1.1/9.9.9.9 등에 명시적으로 지정하여 프록시 DNS 서버를 확인하면 정보를 얻을 수 있습니다. 다른 사람의 프록시 DNS 서버 백엔드에 대해.
%DNSCACHEIP=1.1.1.1 dnsqr txt oo.myaddr.l.google.com 16oo.myaddr.l.google.com: 105바이트, 1+1+0+0 레코드, 응답, 오류 없음 쿼리: 16oo.myaddr.l.google.com 답변: oo.myaddr.l.google.com 36 TXT \0342400:cb00:63:1024::a29e:2192 % %DNSCACHEIP=1.0.0.1 dnsqr txt oo.myaddr.l.google.com 16oo.myaddr.l.google.com: 105바이트, 1+1+0+0 레코드, 응답, 오류 없음 쿼리: 16oo.myaddr.l.google.com 답변: oo.myaddr.l.google.com 12 TXT \0342400:cb00:63:1024::a29e:2192 % %DNSCACHEIP=9.9.9.9 dnsqr txt oo.myaddr.l.google.com 16oo.myaddr.l.google.com: 71바이트, 1+1+0+0 레코드, 응답, 오류 없음 쿼리: 16oo.myaddr.l.google.com 답변: oo.myaddr.l.google.com 60 TXT \0212620:171:fa:f0::7 %
CloudFlare가 실행하는 확인 프록시 DNS 서버의 백엔드에 CloudFlare가 할당한 IPv6 주소가 있다는 것은 놀라운 일이 아닙니다. ☺
그들 중 일부는 실제로 IP 주소를 소유했거나 Anycast가 이동함에 따라 여러 개의 백엔드 IP 주소를 가지고 있습니다. (나는 그 중 일부 사이에서 잠시 멈췄습니다.)
%DNSCACHEIP=8.8.8.8 dnsqr txt oo.myaddr.l.google.com 16oo.myaddr.l.google.com: 114바이트, 1+2+0+0 레코드, 응답, 오류 없음 쿼리: 16oo.myaddr.l.google.com 답변: oo.myaddr.l.google.com 59 TXT \01574.125.181.14 답변: oo.myaddr.l.google.com 59 TXT "edns0-client-subnet\040에헴! %DNSCACHEIP=8.8.8.8 dnsqr txt oo.myaddr.l.google.com 16oo.myaddr.l.google.com: 124바이트, 1+2+0+0 레코드, 응답, 오류 없음 쿼리: 16oo.myaddr.l.google.com 답변: oo.myaddr.l.google.com 59 TXT \0272a00:1450:400c:c01::106 답변: oo.myaddr.l.google.com 59 TXT "edns0-client-subnet\040에헴! %DNSCACHEIP=8.8.8.8 dnsqr txt oo.myaddr.l.google.com 16oo.myaddr.l.google.com: 124바이트, 1+2+0+0 레코드, 응답, 오류 없음 쿼리: 16oo.myaddr.l.google.com 답변: oo.myaddr.l.google.com 59 TXT \0272a00:1450:400c:c01::107 답변: oo.myaddr.l.google.com 59 TXT "edns0-client-subnet\040에헴! % %DNSCACHEIP=9.9.9.10 dnsqr txt oo.myaddr.l.google.com 16oo.myaddr.l.google.com: 71바이트, 1+1+0+0 레코드, 응답, 오류 없음 쿼리: 16oo.myaddr.l.google.com 답변: oo.myaddr.l.google.com 60 TXT \0212620:171:fa:f0::3 %DNSCACHEIP=9.9.9.10 dnsqr txt oo.myaddr.l.google.com 16oo.myaddr.l.google.com: 66바이트, 1+1+0+0 레코드, 응답, 오류 없음 쿼리: 16oo.myaddr.l.google.com 답변: oo.myaddr.l.google.com 31 TXT \01474.63.26.248 %DNSCACHEIP=9.9.9.10 dnsqr txt oo.myaddr.l.google.com 16oo.myaddr.l.google.com: 66바이트, 1+1+0+0 레코드, 응답, 오류 없음 쿼리: 16oo.myaddr.l.google.com 답변: oo.myaddr.l.google.com 60 TXT \01474.63.26.250 %
dnsqrTXT다음은 리소스 레코드를 덤프하는 약간 순진한 방법입니다. 이러한 8진수 이스케이프는 단지 길이 바이트입니다. 아마 이 문제를 고쳐야 할 것 같아요. ☺
추가 읽기
- 조나단 드보인 폴라드(2000)."콘텐츠" 및 "프록시" DNS 서버. 자주 주어지는 답변입니다.
- 조나단 데보인 폴라드(2003).프록시 DNS 서비스를 받을 수 있는 곳. 일반적인 답변.
- 조나단 데보인 폴라드(2004).DNS 쿼리 해결이란 무엇입니까? . 일반적인 답변.
- 조나단 데보인 폴라드(2016).소프트웨어 통합(Daniel J. Bernstein). 소프트웨어.