내 사무실 LAN 내부에서 .local 도메인을 확인할 수 없습니다.

내 사무실 LAN 내부에서 .local 도메인을 확인할 수 없습니다.

my.sample-domain.localLinux Debian 9에서는 Postgres 클라이언트와 같은 다른 명령이 아닌 또는 등의 명령을 사용하여 특정 로컬 도메인을 확인할 수 있습니다 .nslookuphostpingpsql

Network Manager와 같은 것이 내 DNS 확인자를 올바르게(의 내용 /etc/resolv.conf) 설정한 것 같은데 왜 이런 일이 발생하는지 잘 모르겠습니다.

Windows 10을 사용하는 동료들과 확인해 보니 호스트 파일에 사용자 정의 항목이 없습니다. 하지만 이들의 경우에는 pingWindows 버전의 Postgres와 데이터베이스 UI가 예상대로 작동하여 도메인을 IP 주소로 확인합니다.

아래를 보세요:

$ ping my.sample-domain.local
ping: my.sample-domain.local: Name or service not known

$ host my.sample-domain.local
my.sample-domain.local has address <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>

$ ping -c 5 <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>
PING <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN> (<THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>) 56(84) bytes of data.
64 bytes from <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>: icmp_seq=1 ttl=128 time=1.16 ms
64 bytes from <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>: icmp_seq=2 ttl=128 time=0.644 ms
64 bytes from <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>: icmp_seq=3 ttl=128 time=0.758 ms
64 bytes from <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>: icmp_seq=4 ttl=128 time=0.684 ms
64 bytes from <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>: icmp_seq=5 ttl=128 time=0.794 ms

--- <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN> ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4056ms
rtt min/avg/max/mdev = 0.644/0.808/1.160/0.183 ms

$ nslookup my.sample-domain.local
Server:        <THE_IP_REPRESENTING_THE_NAMESERVER>
Address:    <THE_IP_REPRESENTING_THE_NAMESERVER>#53

Non-authoritative answer:
Name:    my.sample-domain.local
Address: <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>


$ cat /etc/resolv.conf
domain <AN_INTERNAL_DOMAIN>
search <AN_INTERNAL_DOMAIN>
nameserver <THE_IP_REPRESENTING_THE_NAMESERVER>
nameserver <ANOTHER_IP_REPRESENTING_THE_NAMESERVER>

편집하다:

동시에 같은 사무실 LAN에 Ubuntu 16 가상 머신이 있다는 것을 깨닫고 로그인하여 ping그곳에서 실행한 명령을 시도했습니다.

또한 Ubuntu VM에는 특정 사용자 정의가 없습니다 /etc/hosts(사용자 정의되지 않은 Debian 9 노트북과 동일 /etc/hosts).

둘 다 /etc/resolv.conf비슷해 보입니다(일부 공유 도메인/IP, 동일한 도메인의 다른 IP).

그러나 파일이 다르기 때문에 /etc/nsswitch.conf이 파일과 호스트가 이전처럼 해결되는 순서에 문제가 있는 것 같습니다.mdsn4_minimalmdsn4_minimaldns

hosts:      files mdns4_minimal [NOTFOUND=return] dns

우분투에서:

hosts:      files dns

편집 2:

Ubuntu 16 VM과 Debian 9 노트북 모두 .local이 명령을 사용하여 dig도메인을 확인할 수 있었습니다.

답변1

hostnslookupDNS 조회를 수행하지만 대부분의 애플리케이션은 glibc를 사용합니다 .이름 서비스 스위치호스트 이름을 찾는 방법을 결정합니다.

mDNS가 활성화되어 있을 수 있으며 이로 인해 /etc/nsswitch.conf이름을 확인할 때 문제가 발생할 수 있습니다. .local조회 순서를 변경하거나 필요하지 않다고 생각되면 mDNS 서비스를 제거하면 됩니다.

당신의 경우는 nsswitch.conf그렇습니다 mdns4_minimal.멀티캐스트 DNS( .local이름)을 찾아보세요. 그 후에 [NOTFOUND=return]는 조회가 중지되므로 DNS가 사용되지 않으며 애플리케이션이 호스트 이름을 확인할 수 없습니다. mdns4_minimal [NOTFOUND=return]mDNS 조회가 사용되지 않도록 전체를 제거하거나, mDNS 조회가 실패할 경우 DNS 조회가 발생하도록 NOTFOUND 작업만 제거할 수 있습니다.

자세한 내용은 확인해 보는 것이 좋습니다.이름 서비스 전환 설명서.

답변2

.local여기서 더 큰 문제는 DNS 인프라를 설정할 때 .로 끝나는 DNS 도메인 이름을 사용해서는 안 된다는 점입니다 .

.localDNS 외에 로컬 이름/서비스를 확인하기 위한 병렬 서비스인 Zeroconf/avahi(일명 bonjour)에서 사용하도록 예약되어 있습니다.

어떤 경우에는 내부 DNS 이름 서비스가 Zeroconf와 확실히 충돌할 수도 있습니다. 그래서 당신은 질문의 해결책을 받아들입니다.

장기적으로 내부 네트워크 DNS 이름은 .local.

PS 그런데 DNS 외에 로컬 Microsoft DC/AD .local도 이름을 지정하면 안 됩니다. 이렇게 하면 이상한 문제에 봉착하게 됩니다.

멀티캐스트 DNS(mDNS) 표준.
IETF(Internet Engineering Task Force) 표준 추적 RFC 6762(2013년 2월 20일)는 멀티캐스트 DNS를 통해 확인할 수 있는 LAN의 호스트 이름에 대해 도메인 이름 레이블 local을 사용하는 의사 최상위 도메인 이름 확인 프로토콜을 예약합니다.

MS Technet에서(Wikipedia)

Macintosh 클라이언트 컴퓨터에서 Macintosh OS를 실행 중인 경우 .local 태그를 사용해야 하는 경우 Macintosh 컴퓨터에서도 네트워크의 다른 컴퓨터를 검색할 수 있도록 설정을 구성해야 합니다.

RFC 6762

".local"로 끝나는 이름에 대한 DNS 쿼리입니다.
mDNS IPv4 링크-로컬 멀티캐스트 주소 224.0.0.251(또는 IPv6에
해당하는 FF02::FB) 로 전송되어야 합니다 .

...

  1. 역방향 주소 매핑

    ".local."과 마찬가지로 IPv4 및 IPv6 역방향 매핑 도메인도 링크-로컬로 정의됩니다.

    "254.169.in-addr.arpa"로 끝나는 이름에 대한 DNS 쿼리입니다. mDNS IPv4 링크-로컬 멀티캐스트 주소 224.0.0.251 또는 mDNS IPv6 멀티캐스트 주소 FF02::FB로 전송되어야 합니다. 이 도메인 아래의 이름은 IPv4 링크-로컬 주소에 해당하므로 링크-로컬이 이러한 이름과 관련된 정보를 찾는 가장 좋은 장소라는 것은 논리적입니다.

...

명시적으로 ".local"로 끝나는 이름의 경우 멀티캐스트 DNS를 활성화 및 비활성화하는 데 특별한 제어가 필요하지 않습니다. 사용자가 입력했습니다.
사용자가 ".local"로 끝나는 이름에 대해 멀티캐스트 DNS를 비활성화할 필요는 없습니다. 사용자가 멀티캐스트 DNS를 사용하지 않으려는 경우 해당 이름을 사용하지 않음으로써 이를 달성할 수 있기 때문입니다.
사용자인 경우하다".local"로 끝나는 이름을 입력하면 사용자의 의도가 작동할 것이라고 안전하게 가정할 수 있습니다.

공식적인 출처는 아니지만, 문제를 아주 잘 설명하는 단락이 있는 이 내용도 찾았습니다..local을 LAN의 최상위 도메인으로 사용 중지

.local 도메인은 의사 최상위 도메인이라고 합니다. 그게 무슨 뜻이야? 즉, 인터넷에서 사용 가능한(라우팅 가능한) 공식적인 최상위 도메인은 아니지만, 일부 애플리케이션에서 사용되기 때문에 준공식적인 상태를 갖습니다.
.local의 경우 mDNS(멀티캐스트 도메인 이름 서비스)에서 사용됩니다. 이 서비스를 구현하는 호스트는 .local을 도메인 이름으로 사용하고 고유한 이름 확인 방법을 가지고 있습니다. 일반적으로 이는 문제가 되지 않습니다. 그러나 네트워크에 DNS를 구현하고 .local을 최상위 도메인으로 사용하는 경우 심각한 이름 확인 문제가 발생할 수 있습니다.
나는 이런 일이 Linux 시스템에서 많이 일어나는 것을 보았고 Apple의 OS X도 이러한 문제로 어려움을 겪을 것이라고 생각합니다. 이러한 유형의 네트워크에서는 DNS 이름 확인이 전혀 작동하지 않거나 일부 시간에만 작동하는 경우가 많습니다. 결국 이름이 확인될지 알 수 없기 때문에 항상 IP 주소를 사용해야 합니다(이로 인해 애초에 DNS 서버 보유의 요점이 무산됩니다).

답변3

아마 너도 하나 갖고 있을 거야NBNS와 충돌하다도메인 명 시스템, 문제를 해결하거나주인명령을 파일 또는 래퍼로 작성하세요.

NAME=my.sample-domain.local
ping $(host $NAME | perl -pe 's/.* //g')

DNS를 확인해야 합니다파기;

dig @$SERVER $NAME +short

나는 추측한다주인먼저 NBNS를 검색하세요(또는 그 반대).

관련 정보