호스트 이름을 확인하는 데 5초가 걸립니다.

Question 1

짧은 답변:

해결 방법은 다음 줄을 추가하여 glibc조회 및 로깅을 위해 소켓을 강제로 재사용하는 것입니다.AAAAA/etc/resolv.conf

options single-request-reopen

이 문제의 실제 원인은 다음과 같습니다.

잘못 구성된 방화벽 또는 라우터(예:여기에 설명된 주니퍼 방화벽 구성)은 AAAADNS 패킷 손실을 유발합니다.
DNS 서버 오류

긴 답변:

curlwgetglibc의 기능과 유사하거나 이를 사용하는 프로그램주소정보 가져오기(), DNS 레코드를 병렬로 조회하여 IPv4 및 IPv6 호환을 시도합니다. 두 개의 레코드가 수신될 때까지 결과를 반환하지 않습니다.이 동작과 관련된 몇 가지 문제) - strace위와 같은 내용이 설명됩니다. 예를 들어 IPv4를 강제로 사용하는 경우 curl -4내부적으로 레코드만 gethostbyname()쿼리됩니다 A.

이것으로부터 tcpdump우리는 다음을 볼 수 있습니다:

-> A?처음에 두 개의 요청을 보냅니다.
-> AAAA?(IPv6 주소 요청)
<- AAAA회신하다
-> A?IPv4 주소를 다시 요청하세요.
<- A답장을 받았습니다
-> AAAA?IPv6 다시 요청
<- AAAA회신하다

A어떤 이유로 답글이 삭제되었으며 다음과 같은 오류 메시지가 표시됩니다.

error sending response: host unreachable

AAAA그러나 두 번째 쿼리가 필요한 이유는 명확하지 않습니다 .

동일한 문제가 발생하는지 확인하려면 다음에서 시간 초과를 업데이트할 수 있습니다 /etc/resolv.conf.

options timeout:3

먼저 텍스트 파일을 만듭니다.맞춤 시간 보고 구성:

cat >./curl-format.txt  <<-EOF
   time_namelookup: %{time_namelookup}\n
      time_connect: %{time_connect}\n
   time_appconnect: %{time_appconnect}\n
     time_redirect: %{time_redirect}\n
  time_pretransfer: %{time_pretransfer}\n
time_starttransfer: %{time_starttransfer}\n
                    ----------\n
time_total: %{time_total}\n
EOF

그런 다음 요청을 보냅니다.

$ curl -w "@curl-format.txt" -o /dev/null -s https://example.com

            time_namelookup:  3.511
               time_connect:  3.511
            time_appconnect:  3.528
           time_pretransfer:  3.528
              time_redirect:  0.000
         time_starttransfer:  3.531
                            ----------
                 time_total:  3.531

다른 두 가지 관련 옵션이 있습니다 man resolv.conf.

단일 요청(glibc 2.10부터)설정 기본적 RES_SNGLKUP 으로 _res.optionsglibc는 버전 2.9부터 IPv4 및 IPv6 조회를 병렬로 수행합니다. 일부 장치 DNS 서버는 이러한 쿼리를 올바르게 처리하지 않아 요청 시간이 초과됩니다. 이 옵션은 이 동작을 비활성화하고 glibc가 IPv6 및 IPv4 요청을 순차적으로 수행하도록 합니다(구문 분석 프로세스가 느려지지만).

단일 요청 다시 열기(glibc 2.9부터) 확인자는 A 및 AAAA 요청에 동일한 소켓을 사용합니다. 일부 하드웨어는 하나의 응답만 잘못 돌려보냅니다. 이런 일이 발생하면 클라이언트 시스템은 앉아서 두 번째 응답을 기다립니다. 이 옵션을 켜면 이 동작이 변경되어 동일한 포트의 두 요청이 올바르게 처리되지 않으면 두 번째 요청을 보내기 전에 소켓을 닫고 새 소켓을 엽니다.

관련 질문:

Answer

짧은 답변:

해결 방법은 다음 줄을 추가하여 glibc조회 및 로깅을 위해 소켓을 강제로 재사용하는 것입니다.AAAAA/etc/resolv.conf

options single-request-reopen

이 문제의 실제 원인은 다음과 같습니다.

잘못 구성된 방화벽 또는 라우터(예:여기에 설명된 주니퍼 방화벽 구성)은 AAAADNS 패킷 손실을 유발합니다.
DNS 서버 오류

긴 답변:

curlwgetglibc의 기능과 유사하거나 이를 사용하는 프로그램주소정보 가져오기(), DNS 레코드를 병렬로 조회하여 IPv4 및 IPv6 호환을 시도합니다. 두 개의 레코드가 수신될 때까지 결과를 반환하지 않습니다.이 동작과 관련된 몇 가지 문제) - strace위와 같은 내용이 설명됩니다. 예를 들어 IPv4를 강제로 사용하는 경우 curl -4내부적으로 레코드만 gethostbyname()쿼리됩니다 A.

이것으로부터 tcpdump우리는 다음을 볼 수 있습니다:

-> A?처음에 두 개의 요청을 보냅니다.
-> AAAA?(IPv6 주소 요청)
<- AAAA회신하다
-> A?IPv4 주소를 다시 요청하세요.
<- A답장을 받았습니다
-> AAAA?IPv6 다시 요청
<- AAAA회신하다

A어떤 이유로 답글이 삭제되었으며 다음과 같은 오류 메시지가 표시됩니다.

error sending response: host unreachable

AAAA그러나 두 번째 쿼리가 필요한 이유는 명확하지 않습니다 .

동일한 문제가 발생하는지 확인하려면 다음에서 시간 초과를 업데이트할 수 있습니다 /etc/resolv.conf.

options timeout:3

먼저 텍스트 파일을 만듭니다.맞춤 시간 보고 구성:

cat >./curl-format.txt  <<-EOF
   time_namelookup: %{time_namelookup}\n
      time_connect: %{time_connect}\n
   time_appconnect: %{time_appconnect}\n
     time_redirect: %{time_redirect}\n
  time_pretransfer: %{time_pretransfer}\n
time_starttransfer: %{time_starttransfer}\n
                    ----------\n
time_total: %{time_total}\n
EOF

그런 다음 요청을 보냅니다.

$ curl -w "@curl-format.txt" -o /dev/null -s https://example.com

            time_namelookup:  3.511
               time_connect:  3.511
            time_appconnect:  3.528
           time_pretransfer:  3.528
              time_redirect:  0.000
         time_starttransfer:  3.531
                            ----------
                 time_total:  3.531

다른 두 가지 관련 옵션이 있습니다 man resolv.conf.

단일 요청(glibc 2.10부터)설정 기본적 RES_SNGLKUP 으로 _res.optionsglibc는 버전 2.9부터 IPv4 및 IPv6 조회를 병렬로 수행합니다. 일부 장치 DNS 서버는 이러한 쿼리를 올바르게 처리하지 않아 요청 시간이 초과됩니다. 이 옵션은 이 동작을 비활성화하고 glibc가 IPv6 및 IPv4 요청을 순차적으로 수행하도록 합니다(구문 분석 프로세스가 느려지지만).

단일 요청 다시 열기(glibc 2.9부터) 확인자는 A 및 AAAA 요청에 동일한 소켓을 사용합니다. 일부 하드웨어는 하나의 응답만 잘못 돌려보냅니다. 이런 일이 발생하면 클라이언트 시스템은 앉아서 두 번째 응답을 기다립니다. 이 옵션을 켜면 이 동작이 변경되어 동일한 포트의 두 요청이 올바르게 처리되지 않으면 두 번째 요청을 보내기 전에 소켓을 닫고 새 소켓을 엽니다.

관련 질문:

Question 2

@Tombart가 말했듯이 IPv6 해상도 시간 초과를 기다리면 지연이 발생합니다.

또 다른 가능성은 /etc/gai.conf에서 IPv4의 우선순위를 지정하는 것입니다.

/etc/gai.conf의 의견

#   For sites which prefer IPv4 connections change the last line to
#
precedence ::ffff:0:0/96  100

변경한 후 gai.conf변경 사항을 적용하려면 DNS 확인자 라이브러리를 사용하는 모든 애플리케이션을 다시 시작해야 합니다.

namedIPv6 연결 없이 BIND 서버를 사용하는 경우 IPv6를 비활성화 하고 루트 프롬프트에서 IPv6 주소를 가져오는 것이 좋습니다 . 분명히 여전히 AAAA 주소를 확인하려고 시도할 것입니다.

따라서 BIND 구성의 경우

/etc/default/bind9에서 IPv4 주소에 -4를 추가합니다.

OPTIONS="-4 -u bind"

그리고 .NET에서 /etc/bind/db.rootAAAA DNS 루트가 있는 모든 행을 삭제합니다 .

Answer