브라우저가 SRV 레코드를 사용하지 않는 이유는 무엇입니까? [닫은]

최소한의 작업처럼 보이며 신뢰할 수있는 웹 사이트의 서버 측 구현이 훨씬 간단 해집니다. 또한 SRV 레코드는 몇 년 동안 사용되어 왔습니다 ...

내가 여기서 놓친 것이 있습니까?

편집 : @DJ Pon3-내가 말하는 것은 다음과 같습니다.

한 사이트는 BGP없이 두 개의 데이터 센터에서 서비스를 제공했지만 두 데이터 센터가 오프라인 상태가 되어도 여전히 작동합니다. 짧은 DNS TTL을 통해서도 달성 할 수 있습니다.
하나의 IP 주소에서 다른 포트의 여러 httpS 서버

domain-name-system srv-record

— 페이드 비
소스

나는 이것이 어떤 문제에 대해 명확하지 않은지 정확하게 알 수 있습니다. 지금까지 srv 레코드없이 안정적인 웹 서비스를 만들 수있었습니다.

— Rob Moir

사용자가 사이트가 어떤 포트에서 실행되고 있는지 알 필요없이 대체 포트에서 웹 사이트를 실행하는 문제를 해결할 것이라고 생각합니다 (단지 단순하기 때문에). URL.

— joeqwerty

부끄럽지 않습니까?

— JdeBP

정확한의 중복 stackoverflow.com/questions/9063378/...

— 알니 타크

@ chrisdew 왜 두 사이트에서 똑같은 질문을 했습니까?

— Alnitak

답변:

브라우저가 SRV 레코드를 사용하지 않는 이유는 무엇입니까?

http가 한 번만있을 때 SRV 레코드가 존재하지 않았고 http가 서비스라고 가정하지 않았기 때문입니다.

SRV 기록은 수년 동안 존재 해 왔습니다 ...

하하하 HTTP가 시작된 시간을 기억하십니까? 최초의 브라우저가 작성 되었습니까? 그것은 오래 전입니다.

SRV는 RFC 2782에서 처음입니다. HTTP는 RFC 1945에서 1.0으로 이동합니다. 처음이었던 것 같아

— 톰톰
소스

HTTP 1.1은 2616이므로 누락되었습니다. SRV 지원 HTTP 1.2가 필요한가요?

— fadedbee

아니, 무엇을 묻기 때문에-그것은 필요하지 않습니다;)

— TomTom

상대 연령이 상호 운용성을 제한한다는 다소 어리석은 주장에 대해서는 -1입니다. 세계는 정말 하지 그들이 존재하면 두 개의 발명품이 함께 일을 만드는 능력을 가지고 있고, 역사를 통해 그냥 몇 번을했다. SRV리소스 레코드와 HTTP에 대해 두 번 이상 처리했습니다 .

— JdeBP

@ JdeBP 당신은 그것이 그렇게 쉽다면 지금까지 끝났을 것임을 잘 알고 있습니다. 문제는 오래된 브라우저에 갇힌 수많은 사용자에게 열등한 경험을 제공하지 않고 사이트를 HTTP + SRV 메커니즘으로 전환하는 것입니다.

— Alnitak

누군가 인터넷 초안을 쓴 적이 몇 번입니까? 그것은 거의 동일하지 않습니다. 하나를 작성 하는 것은 사소한 일입니다. 그러면 실제 세계가 당신을 때리고 실제로 실제 사례에서 작동하지 않을 수있는 많은 엣지 케이스 및 기타 문제가 발생하고 결국 초안이 만료되고 대부분 잊혀졌습니다. 지옥, 나는 이미 꽤 많은 광산에서 일어났다.

— Alnitak

SRV 기록은 세 가지를 제공합니다.

여러 개의 호스트 이름-없이 수행 가능
대체 포트-나쁜 생각-아래 참조
영역 정점 문제에서 CNAME에 대한 수정

대체 포트-SRV 레코드는 URL에서 해당 사실을 알리지 않고 대체 포트에서 웹 서버를 실행하는 방법으로 사용될 수 있습니다. 이것은 나쁜 것 입니다. 회사 방화벽 정책은 일반적으로 "비정상적인"포트에 대한 액세스를 금지하며 대체 포트 사용에 대한 아이디어를 장려하는 것은 사이트 접근성이 좋지 않습니다.

내가 볼 수있는 유일한 유형의 이점은 # 3에 대한 것입니다- (영역 정점에서 허용되지 않는) 또는 레코드 (영역 유지 관리에 좋지 않은)를 요구하지 않고 example.com리디렉션 될 수 있습니다.webhost.example.netCNAMEA

— 알 니탁
소스

-1 많은 사람들이 이것을 요구하고 질문자를 암시하기 때문에 수년에 걸쳐서 요점을 잃어 버렸음에도 불구하고 -1은 요점을 잃어버린 점입니다. 물론 이것은 고객에게 명백한로드 밸런싱 및 폴백 정보입니다.

— JdeBP

@JdeBP IMNSHO로드 밸런싱 및 폴백 데이터는 DNS에 속하지 않습니다. "Stupid DNS Tricks (TM)"영역에 해당합니다. 둘 다 IP 라우팅 계층에 속하며 서비스간에 완벽한 장애 조치를 제공 할 수있는 유일한 곳입니다.

— Alnitak

실제로 프로토콜은 포트에 바인딩되어서는 안되므로 대체 포트가 좋습니다. 우체국이 항상 건물의 2 층에 있어야했던 세상을 상상해보십시오. 이것이 바로 주소록 (DNS)입니다. 실제로 나쁜 생각은 포트를 기반으로 나가는 방화벽 규칙을 정의하는 것입니다. 공격자가 항상 차단되지 않은 포트를 사용할 수 있기 때문에 의미가 없습니다. 또한 우체국 일 수 있기 때문에 모든 건물에서 2 층으로가는 것이 거부되는 세상을 상상해보십시오. 재밌지 않니? ;)

— FlashFan

@FlashFan 불행히도, 기업 들은 모든 웹 사이트가 포트 80 또는 443에 있다고 가정하여 인터넷 발신 을 차단 하려고합니다.

— Alnitak

예, 알아요 그렇기 때문에 SRV 레코드를 사용하는 것이 좋은 이유는 기업이 그 무의미하고 나쁜 관행을 중단하도록 강요하기 때문입니다. 하나의 포트가 열려있는 한 얼마나 많은 발신 포트를 차단하든 모든 포트를 통해 모든 작업을 수행 할 수 있으므로 원하는 모든 작업을 수행 할 수 있습니다. 사실, 포트 443에서 TLS 연결을 통과하는 것이 실제로 HTTP인지 알 수 없다는 사실은 밑줄 만 표시합니다.

— FlashFan