답변:
이러한 많은 답변은 부분적으로 만 사실이거나 명백한 잘못입니다. WINS는 이름을 IP 주소로 확인하는 또 다른 방법입니다. 응용 프로그램이 DNS 사용 방법을 알고있는 한 WINS는 전혀 필요하지 않습니다.
편집 : 좋아, 나는이 스레드에 얼마나 많은 잘못된 정보가 있는지 믿을 수 없다. 우선 서브넷이 서로 다르더라도 WINS를 사용할 필요가 없습니다. 응용 프로그램이 DNS 서버의 udp / tcp 포트 53과 통신 할 수있는 한 호스트 이름을 정확하게 확인할 수 있습니다 (예, \\ hostname도 작동 함).
두 번째로, 짧은 호스트 이름을 사용하여 어떤 것도 해결할 수없는 이유가 궁금하다면 (예 : 도메인이없는 호스트 이름) 클라이언트에서 기본 도메인 (또는 도메인 검색 목록)을 구성하지 않았기 때문일 수 있습니다.
마지막으로 (최소한!) Active Directory 도메인은 Windows 네트워크에서 DNS를 사용하기위한 필수 구성 요소가 아닙니다. 컴퓨터를 도메인에 가입시킬 때 Windows가 기본 도메인 이름을 설정하기 때문이라고 생각합니다. 다른 방법 (아마도 DHCP)을 통해 직접 설정하지 못하게하는 것은 없습니다.
요약하면, 기본 도메인을 설정하고 21 세기에 우리와 같은 DNS를 사용하십시오!
승리는 여전히 많은 것들에 필요합니다 (매일 적게!). 내가 본 가장 일반적인 예는 클러스터 된 2003 서버에서 Exchange 2007을 실행하기 위해서는 wins가 필요하다는 것입니다. 승리는 Netbios 이름으로 작동합니다. NetBIOS 이름은 컴퓨터에서 실행되는 NetBIOS 서비스에서 사용하는 식별자입니다. 서비스를 나타내는 15 자 (바이트) 이름과 16 자 문자의 조합입니다. NetBIOS 네트워크 리소스를 식별 할 때이 이름이 사용됩니다. NetBIOS는 인터넷에서 이름을 확인할 수 없습니다. NetBIOS 이름은 단일 부품 이름이며 계층 구조가 없습니다.
NetBIOS 네임 스페이스는 단순하므로 NetBIOS 이름에 접미사가 추가되지 않으며 두 컴퓨터가 동일한 NetBIOS 이름을 가질 수 없습니다. 즉, 한 네트워크의 각 NetBIOS 이름은 고유해야합니다.
참고 Microsoft Windows 용 TCP / IP 기본 사항, 제 11 장 - TCP / IP를 통한 NetBIOS
엔터프라이즈에서는 여전히 많은 레거시 애플리케이션에 필요합니다.
가장 답답한 답변이 잘못 작성되었으므로 이것을 편집해야했습니다!
요즘 많은 조직에서 WINS가 반드시 필요합니다.
WINS 작동 방식 업데이트 : 2005 년 1 월 21 일
WINS 작동 방식 기본적으로 Microsoft® Windows® 2000, Windows XP 또는 Windows Server 2003 운영 체제를 실행하는 컴퓨터가 이름 확인을 위해 WINS 서버 주소 (수동 또는 DHCP를 통해)로 구성된 경우 하이브리드 노드 (h 다른 NetBIOS 노드 유형이 구성되어 있지 않으면 NetBIOS 이름 등록을위한 노드 유형으로 -node). NetBIOS 이름 쿼리 및 확인의 경우 h- 노드 동작도 사용하지만 몇 가지 차이점이 있습니다.
NetBIOS 이름 확인의 경우 WINS 클라이언트는 일반적으로 이름을 확인하기 위해 다음과 같은 일반적인 단계를 수행합니다.
클라이언트는 쿼리 된 이름이 해당 로컬 NetBIOS 컴퓨터 이름인지 확인합니다.
클라이언트는 원격 이름의 로컬 NetBIOS 이름 캐시를 확인합니다. 원격 클라이언트에 대해 확인 된 모든 이름은이 캐시에 저장되어 10 분 동안 유지됩니다.
클라이언트는 NetBIOS 쿼리를 구성된 기본 WINS 서버로 전달합니다. 기본 WINS 서버가 쿼리에 사용할 수 없거나 이름에 대한 항목이 없어서 쿼리에 응답하지 않으면 클라이언트는 나열된 WINS 서버에 나열된 순서대로 구성된 다른 WINS 서버에 연결을 시도합니다. 그것의 사용.
클라이언트는 NetBIOS 쿼리를 로컬 서브넷으로 브로드 캐스트합니다.
Lmhosts 파일을 사용하도록 구성된 경우 클라이언트는 Lmhosts 파일에서 쿼리와 일치하는지 확인합니다.
클라이언트는 Hosts 파일을 시도한 다음 DNS 서버가 구성된 경우이를 시도합니다.
문제는 모든 응용 프로그램이 DNS를 사용하도록 구성 할 수는 없다는 것입니다.
Microsoft 자체의 Active Directory 설정 설명에서도 WINS의 필요성을 언급합니다.
"이전 버전의 Windows에서는 Active Directory 도메인의 네트워크 리소스를 확인하기 위해 NetBIOS 이름 확인 (WINS 서버, LMHosts 파일 또는 NetBIOS 브로드 캐스트)이 여전히 필요합니다."
그렇습니다. WINS를 사용하지 않고 도망 갈 수있는 일부 조직이 있지만 DNS 서버를 공격 할 수 있다면 WINS가 필요하지 않다는 마법을 잘못 언급 할 수 있습니다.
WINS는 전 세계의 모든 Windows 관리자가이를 폐기하기 위해 시도하는 모든 시도에도 불구하고 여전히 많은 요구 사항입니다. 서브넷이 분리 될 때마다 WINS가 필요합니다. 별도의 사이트에 VPN을 실행하고 있습니까? 이는 서브넷과 WINS를 의미합니다. AD를 이해하지 못하는 이전 고객이 있습니까? WINS가 필요합니다. 네트워킹중인 DOS 응용 프로그램이 있습니까? 다시 와인.
WINS는 찾아보기 목록을 채우는 데에도 사용됩니다. Active Directory 기반 컴퓨터는 WINS없이 작동 할 수 있지만 찾아보기 목록이 다음 순서로 채워 지므로 지연 될 수 있습니다.
이 문제의 핵심은 LANFS의 뿌리에서 비롯됩니다. LANFS는 SMB를 낳았으며 CIFS를 낳았습니다 ... 이것이 어디로 가고 있는지 알 수 있습니다. LANMAN은 LAN 기반 프로토콜이었으며 "인터넷"이라는 개념이 없었으며 "라우팅"이 훨씬 적었습니다. WINS는 이러한 격차를 해소하고 라우팅을 가능하게하기 위해 개발되었습니다. CIFS는 현재까지 LANMAN에 대한 이전 버전과 호환되는 일부 지원 기능을 가지고 있습니다. UNC 경로 이름은 "현대"일 수 있지만 여전히 LANMAN 서버에 연결됩니다. 그런 다음 "찾아보기 목록"전체가 있습니다 ...
MS는 WINS 서버 비즈에서 벗어나는 데 매우 가깝지만 OS뿐만 아니라 WINS 서버를 필요로하는 응용 프로그램 및 서비스에도 너무 많은 "레거시"후크가 있습니다. 그리고 한 LANMAN 스타일의 전송에 대한 지원이 있기 때문에 , 주위에 WINS 서버가 할 필요가있을 것이다.
편집하다:
예, 플랫 도메인에서 WINS를 해제 할 수 있습니다.
하나...
이 서비스가 마음을 사로 잡는 것을보고 싶은 한, Microsoft가 돌아와서 LAN 서비스 수행 방식을 개선하기 전까지는 사라지지 않을 것입니다. (예, 링크가 필요하지 않은 방법에 대한 의견이 있습니다 ... 그러나 말의 입으로 말한 내용을 읽으십시오 ...)
이러한 답변 중 다수가 잘못되었거나 부분적으로 정확합니다. 먼저 WINS가 처음 사용되는 이유를 알아 봅니다.
WINS는 호스트 이름을 IP 주소로 확인하는 솔루션으로 사용되지만 NetBIOS가 모든 시나리오에서 작동한다면 왜 WINS가 필요합니까? 읽어!
정규화 된 도메인 이름과 호스트 이름을 IP 주소로 확인하기 위해 같은 목적으로 사용 된 DNS.
이제 WINS가 개발 된 이유를 살펴 보겠습니다.
문제 : NetBIOS는 원래 이름을 확인하는 데 사용되었지만 브로드 캐스트 네트워크 프로토콜이었습니다. 따라서 대부분의 네트워크, 레거시 및 현재 네트워크에서 브로드 캐스트 트래픽은 라우터를 통과하지 못하고 곧 충분한 방화벽을 통과 할 수 있습니다. 나중에 VPN 트래픽에서도 발견됩니다. 따라서 대부분의 서브넷은 NetBIOS 트래픽을 다른 서브넷으로 복제하지 않습니다. 실제 IT 네트워크 관리자 인 경우 라우터, 스위치 및 방화벽의이 NetBIOS 트래픽에 익숙합니다.
ACL에 의해 HOST-17 / 137에서 내부로 UDP 액세스가 거부 됨 : 10.0.1.127/137
ACL에 의해 HOST-A / 137에서 내부로 UDP 액세스가 거부 됨 : 10.0.1.127/137
ACL에 의해 HOST-09 / 137에서 내부로 UDP 액세스가 거부 됨 : 10.0.1.127/137
ACL에 의해 HOST-02 / 137에서 내부로 UDP 액세스가 거부 됨 : 10.0.1.127/137
ACL에 의해 HOST-02 / 137에서 내부로 UDP 액세스가 거부 됨 : 10.0.1.127/137
이것은 Cisco Pix 515E Firewall syslog 파일의 25 비트 네트워크에서 5 개의 NetBIOS 브로드 캐스트의 예입니다. linksys 라우터가 25 비트 네트워크 이외의 다른 것에 익숙하지 않은 사용자의 경우 24 비트 네트워크보다 작습니다.
네트워크 : 10.0.1.0/25, 서브넷 마스크 : 255.255.255.128, 브로드 캐스트 주소 : 10.0.1.127, 최대 호스트 : 126. 알 수 있듯이 트래픽은 세그먼트 내에 포함되어 있습니다.
해결 방법 : WINS는 브로드 캐스트 트래픽이 포함 된 서브넷에 배포되도록 개발되었으며 클라이언트는 WINS 서버를 구성하여 브로드 캐스트 트래픽에 의존하지 않고 이름을 확인하여 WINS 쿼리가 실패 할 때 NetBios가 폴 백이되었습니다.
그러나 잠시만 기다려주십시오. Microsoft 네트워크를 구축 할 때 DNS 서버를 구성합니다. 이제 DNS가 기본이며 DNS가 실패하면 NetBIOS가 폴백입니다. WINS 서버가 배포 된 경우 DNS, WINS 및 NetBIOS.
많은 사람들이 겪을 수있는 문제는 호스트 이름을 핑하려고 할 때 HOST-A라고 말합니다. 컴퓨터 인터페이스 구성에 따라 주로 DNS 만 구성하고 등록 된 호스트 NetBIOS 이름이 만료 된 경우 주소를 IP로 확인하지 못할 수 있습니다.
HOST-A가 domainhosts.com의 일부이고 domainhosts.com에 대한 기본 DC DNS 서버의 호스트에 대한 (A) 레코드 인 해당 도메인에 가입했다고 가정 해 보겠습니다. FQDN (정규화 된 도메인 이름)이 아닌 호스트 이름만으로 주소를 확인하려면 IP 구성에 "기본 및 연결 별 DNS 접미사 추가"가 있어야하고 "이 연결에 대한 DNS 접미어 최소한 : domainhosts.com"이 있어야합니다. 채워! HOST-A가 해결되면 추가 정보 2 개가 반환됩니다. 호스트 이름이 확인되는 IP 주소와 HOST-A.domainhosts.com의 FQDN. 아래 예에서 호스트 이름 확인은 WINS 또는 NetBIOS 대신 도메인의 (A) 레코드를 검색하여 수행됩니다.
[User @ localhost ~] $ 핑 호스트 -A
PING HOST-A.domainhosts.com (10.0.1.10) 56 (84) 바이트의 데이터.
HOST-A.domainhosts.com (10.0.1.10)에서 64 바이트 : icmp_seq = 1 ttl = 128 time = 0.826ms
HOST-A.domainhosts.com (10.0.1.10)에서 64 바이트 : icmp_seq = 2 ttl = 128 time = 0.342ms
주 DNS 접미사 만 채울뿐 아니라 호스트가 다른 호스트를 검색하고 다른 순서로 추가하도록 구성 할 수 있습니다. 따라서 WINS와 NetBIOS를 모두 제거합니다.
이제 "Microsoft 제품이 작동하려면 NetBIOS 및 WINS가 필요합니다."라고 말하는 사람들이있을 것입니다. 실제로는 사실이지만 소수의 제품에만 해당됩니다. 대부분의 제품은 중소기업 및 대기업 환경에만 배포되며 SMS 2003과 같은 응용 프로그램은 1A 레코드를 사용하는 SQL Server 2000입니다. 명명 된 파이프와 Exchange Server 2000 및 2003을 사용하려면 모든 기능을 사용하기 위해 WINS가 필요합니다 ... 전체 기능, WINS 또는 NetBIOS 없이도 필요에 따라 모두 작동합니다.
네, 2000 년 이전의 Microsoft 배포 인 경우에만 가능합니다. 그래도 WINS를 배포하는 것보다 더 나은 솔루션을 얻었습니다 ... 업그레이드!
아무도 언급하지 않은 한 가지는 NetBIOS 이름을 확인하려면 별도의 서브넷에있는 VPN 사이트가 필요하다는 것입니다. 이 시나리오를 고려하십시오.
회사 네트워크는 개인 10.xxx LAN을 사용하고 원격 사무실은 개인 192.xxx LAN을 사용합니다. 그들 사이에 VPN 터널이 있지만 원격 사무실은 회사 DHCP 서버 나 방화벽의 터널을 통해 DHCP를 사용하지 않습니다.
회사 서버를 WINS에 등록한 경우 원격 클라이언트는 완전히 별개의 서브넷에서도 \ ServerName을 확인할 수 있습니다. Eventaully 저는 원격 사무실 방화벽을 업그레이드하고 DHCP over VPN을 사용할 수 있지만 지금은이 설정을 통해 다음을 수행 할 수 있습니다.
내가 틀렸다면 누군가 나를 수정하십시오. 그러나 NetBIOS를 라우팅 할 수 없다는 것을 이해합니다. 따라서 WINS를 사용하지 않고 서브넷에서 NetBIOS 이름을 확인할 수 없습니다.
아, 우리는 여전히 그것을 사용하고 있습니다. Windows 워크 스테이션의 약 3 분의 1은 도메인에 없으므로 이름 확인에 도메인의 DNS 도메인을 사용하도록 구성되지 않았습니다. 또한 우리는 엄청나게 조각난 DNS 환경을 가지고 있으며, 이는 엄청나게 조각난 기본 도메인 설정으로 이어집니다. 이로 인해 WINS는 가장 많은 기능을 갖춘 단일 이름 확인 서비스를 나타냅니다. 글로벌 서비스 인덱스에 가장 근접한 것입니다.
우리가 모든 것을 도메인으로 만들려고한다면, 우리는 단순한 DNS 환경을 갖게 될 것입니다. 잘 될 것입니다.
레거시 Exchange는 여전히 WINS를 사용하므로 Exchange 2003 또는 이전 버전을 사용하는 경우에는 WINS를 사용하도록 설정해야합니다.
또한 다중 도메인 환경에서 FQDN을 사용하지 않는 앱 또는 스크립트에는 문제가있을 수 있습니다.
WINS를 제거 할 수는 있지만 체계적으로 테스트해야하며 대기업에서는 많은 앱, SAP, Exchange 및 기타 레거시 앱을 실행해야합니다. 와인.
나는 WINS를 사용하지 않고 4 년 동안 WINS를 사용하지 않았습니다. Microsoft DDNS는 Active Directory 네트워크에서 훌륭한 이름 확인 작업을 수행합니다. 지금 WINS가 필요한 프로그램을 생각할 수 없지만 몇 가지를 기억합니다. Guardian Firewall은 그 날 LAN 측 NIC에서이를 필요로했습니다.
2007 Exchange 클러스터에는 WINS가 필요하지 않습니다. 내가 가지고있는 문서에 따르면, MS는 IP가 변경되지 않기 때문에 해당 설정에서 HOST 파일의 사용을 권장합니다.
DDNS의 유일한 문제는 WAN을 통하는 것입니다. 각 WAN 세그먼트의 DDNS + ADC ... 타인의 이름 테이블을 업데이트하는 DDNS에 문제가 자주 있습니다.
WINS는 원격 사이트 나 WAN 링크가없는 클래스 C 네트워크에 적합합니다. WINS에 대한 한 가지 큰 ... SSL VPN + WINS = IP의 cus WINS에 입력하는 것은 너무 어리석지 않습니다.