서버의 IP 주소 대신 FQDN을 사용해야하는 이유는 무엇입니까?


29

서버 작업에서 외부 서버에 주소를 입력해야하는 구성 파일을 살펴 보았습니다. 일부는 서버의 IP 주소를 직접 사용하는 것을 보았지만 대신 호스트 이름 FQDN ( 정규화 된 도메인 이름) 을 사용하는 것이 좋습니다 . 직접 IP 주소 대신 호스트 이름을 사용해야하는 이유는 무엇입니까?

호스트 이름을 사용하는 경우 각 호스트 이름을 IP 주소에 연결하는 로컬 DNS 서버가 필요합니다. 호스트 이름 또는 IP 주소 사용의 단점은 무엇입니까?


5
동적 IP가 있다면 DNS 레코드를 변경하는 것이 더 쉽습니다. 왜 로컬 DNS 서버입니까? 모든 머신이 공개적으로 해석 가능한 IP를 갖도록 만드는 이유는 무엇입니까? IP의 또 다른 단점은 동적이지 않더라도 여전히 물리적 위치에 의존하여 다른 위치로 마이그레이션하기가 더 어렵다는 것입니다. 기본적으로 DNS가 왜 발명되었는지 묻는 것처럼 들립니다. 이 질문은 다른 곳에서 여러 번 대답되었습니다.
야누스 트로 엘슨

1
응용 프로그램 수준 1에서는 호스트 이름 만 처리 하는 것이 항상 권장됩니다 (예 : RFC) . 그러나 일부 응용 프로그램은 IP가 없으면 작동하지 않습니다. 그럼에도 불구하고, 나 자신은 종종 대신 호스트 이름의 IP가 내 장치에 연결할 유죄입니다 -하지만 나쁜 습관은 확실히 바로 우리가 완전히 :) IPv6 로의 마이그레이션 한으로 종료됩니다
하겐 폰 Eitzen

물론 외부 서버는 SSL과의 모든 통신을 보호하고 FQDN에 대한 SSL 인증서에 서명하며 IP 주소를 사용하는 경우 응용 프로그램에서 올바른 서버를 확인할 수 없습니다. 권리? : |
TessellatingHeckler

1
@HagenvonEitzen 물론 절대로 입력하지 ::1않습니까? :-)
CVn

답변:


54

IP 주소를 사용하면 DNS 서버에 의존하지 않습니다. 또한 DNS 스푸핑을 통한 공격을 방지 할 수 있다는 이점이 있습니다.

IP 주소 대신 FQDN을 사용하면 다른 IP 주소를 가진 서버로 서비스를 마이그레이션하는 경우 IP 주소가 사용되는 모든 곳에서 시도하지 않고 단순히 DNS에서 레코드를 변경할 수 있습니다. .

이 기능은 여러 개인이 여러 서버와 서비스를 구성한 경우에 특히 유용합니다.


1
특히 고객이나 파트너 또는 공급 업체가 사용하는 것처럼 해당 IP 주소에 대한 지식이 외부에있는 경우에도 마찬가지입니다. stackoverflow.com 대신에 우리 모두가 stackoverflow.com으로 알려진 IP로 갔다가 IP를 변경해야한다고 상상해보십시오. 그들은 사이트의 모든 가능한 모든 사용자에게 IP가 변경되었음을 어떻게 알 수 있습니까? 따라서 이름.
Brandon

@Brandon 이제 stackoverflow.com에서 heapunderflow.com으로 변경하기로 결정한 것과 동일합니다. 도메인 이름의 원래 장점은 사람이 stackoverflow.com대신 기억하는 것입니다 151.101.1.69. 물론 오늘날에는 가상 호스팅, 부모와 관련된 하위 도메인 및 그로 인한 다른 이점도 허용됩니다.
Ángel

2
이 답변의 핵심은 조직이 FQDN을 소유하고 있다는 것입니다. IP 주소를 소유하지 않을 수 있습니다.
Pieter Geerkens

1
IP / FQDN을 통한 HTTPS / Kerberos를 실행 해보십시오.
Aron

이것은 문자 그대로 DNS의 목적입니다.
Monica와의 가벼움 경주

40

DNS는 FQDN = IP가 아닙니다

DNS의 중요한 점은 A 레코드 (호스트 이름 = IP) 이상을 제공한다는 것입니다. DNS는 일부 소프트웨어에 필요할 수있는 MX, CNAME, TXT 등과 같은 다양한 유형의 레코드를 제공합니다. 여러 주소 레코드, IPv4 + IPv6 레코드, 동적 주소,로드 밸런싱, 지리적 위치 기반 해상도, 장애 조치 / 이중화 등을 허용합니다. .4.110? 무엇입니까?)이 설정 / 레코드를 변경하고 모든 클라이언트를 변경하지 않고도 클라이언트가 선택 / 레코드를 받도록 할 수 있습니다. DNS는 복잡한 작업을 수행 할 수 있습니다.

직접 IP 주소를 통해 DNS를 사용하는 경우가 종종 있습니다.

FQDN은 요구 사항이 될 수 있습니다

이름 기반 가상 호스팅 또는로드 밸런서 등을 사용하는 웹 서버와 같은 것은 FQDN 또는 호스트 이름을 통해 주소를 지정해야합니다. 연결하려는 FQDN을 기반으로 요청에 응답하는 방법을 결정합니다. IP를 통한 연결이 전혀 작동하지 않을 수 있습니다.

SSL 인증서는 도메인 이름을 기준으로 발급되므로 DNS없이 일부 SSL 지원 서비스를 제대로 사용하지 못할 수 있습니다.

이것은 DNS의 복잡성을 엿볼 수 있도록 google.com 도메인에 대한 발굴 쿼리입니다.

google.com. 172.217.0.174에 299
google.com. 299 IN AAAA 2607 : f8b0 : 400b : 807 :: 200e
google.com. 599 IN MX 10 aspmx.l.google.com.
google.com. 599 IN MX 40 alt3.aspmx.l.google.com.
google.com. 59 IN SOA ns2.google.com. dns-admin.google.com. 126990955900900 1800 60
google.com. 599 IN MX 30 alt2.aspmx.l.google.com.
google.com. NS ns2.google.com의 21599
google.com. 599 IN MX 20 alt1.aspmx.l.google.com.
google.com. 599 IN MX 50 alt4.aspmx.l.google.com.
google.com. NS ns1.google.com에서 21599
google.com. TXT에서 3599 "v = spf1 include : _spf.google.com ~ all"
google.com. 21599 IN CAA 0 문제 "symantec.com"
google.com. NS ns3.google.com의 21599
google.com. NS ns4.google.com에서 21599

Yahoo가 3 개의 IP 주소로 응답

$ 호스트 -ta yahoo.ca
yahoo.ca의 주소는 77.238.184.24입니다.
yahoo.ca의 주소는 74.6.50.24입니다.
yahoo.ca의 주소는 98.137.236.24입니다.

IP 주소 사용의 이점

나를 위해 그것은 일반적으로 DNS가 어떻게 든 방해가되거나 사용할 수없는 경우입니다. 일반적으로 대부분의 경우 DNS를 사용합니다.

IP 주소가 더 좋은 위치의 한 가지 예는 사설 네트워크 주소 (192.168.1.1 및 192.168.1.2)와 직접 연결되어있는 두 대의 컴퓨터 (스위치 없음)가 있고 고 가용성 통신에 사용하는 경우입니다. 또는 DRBD 또는 다른 매우 구체적인 서비스. 이 경우 DNS에서 설정하는 것이 의미가 없습니다. 필요하지 않고, 복잡성, 성능 문제가 추가 될 수 있으며 실패 지점이 발생할 수 있습니다.

다른 예는 라우팅입니다. 라우팅 테이블은 여러 가지 이유로 IP 주소를 기록합니다.

다른 하나는 /etc/resolv.conf와 같은 이름 서버를 참조하는 것입니다. 네임 서버가 없기 때문에 아무것도 해결할 수 없습니다.


이것은 훌륭한 답변이지만, 호스트 서비스에 대해서도 언급해야합니다. IP⟷FQDN은 다대 다가 아니라 다 대다 매핑입니다.
푹신한

감사합니다. DNS는 이름 기반 가상 호스팅에 매우 유용합니다.
Ryan Babchishin

그래, 내가 말한거야.
푹신한

실제로 DNS를 올바르게 얻는 훌륭한 답변-나중에 참조 할 수 있도록 북마크합니다. 내가 가진 한 가지 사소한 점은 "여러 가지 이유로 라우팅 테이블에 IP 주소를 기록합니다." 당신이 언급 한 여러 가지 이유는 무엇입니까? 라우팅은 인터넷 계층에서 발생하기 때문에 IP를 사용하는 것 외에는 선택의 여지가 없지만 DNS는 응용 프로그램 계층을 사용하므로 라우팅에 반드시 의존합니다.
gardenhead

@gardenhead 감사합니다. 그것은 라우팅에 관한 것입니다. 나는 단지 그것에 들어가고 싶지 않았습니다. 내가 선택한 단어를 용서하십시오.
Ryan Babchishin
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.