요약
FreeDNS는 20년 넘게 무료 DNS 호스팅과 동적 DNS를 제공해 온 서비스입니다.
freedns.afraid.org에서는 자기 도메인의 DNS를 직접 관리할 수 있습니다. 다른 회원이 공유한 도메인 아래에 서브도메인을 무료로 만들 수도 있습니다. 페이지의 저작권 표기는 2001년부터 시작합니다.
왜 중요한가
- 집이나 클라우드의 컴퓨터를 IP 주소 대신 이름으로 찾아가게 해 주는 도구를 돈 없이 쓸 수 있습니다.
- 회원 716만여 명 가운데 유료 회원은 5,594명이라, 사실상 거의 모든 이용자가 무료로 씁니다.
핵심 내용
- 회원들이 공유한 도메인 23,229개 가운데 하나를 골라 서브도메인을 만들 수 있습니다.
- 동적 DNS(바뀌는 IP 주소를 이름에 자동으로 다시 연결하는 기능)는 고유 주소를 curl로 호출해 갱신합니다.
- 보조 DNS, IPv6 역방향 DNS(IP 주소로 이름을 찾는 조회), URL 전달 기능도 제공합니다.
- 유료 회원은 월 5달러에 서브도메인 50개를 더 받고 와일드카드 DNS(모든 하위 이름을 한 번에 연결하는 설정)도 씁니다.
- 지금도 초당 2,270건 안팎의 DNS 질의를 처리하며, 저장된 레코드는 1,383만여 개입니다.
HN 반응
- 15~20년째 문제없이 쓴다는 호평이 많았고, 운영자가 그만두면 어떻게 되느냐는 걱정에는 오랜 이력이 답이라는 반론이 나왔습니다.
- 공유 도메인은 공개 접미사 목록(쿠키 범위를 정하는 브라우저용 목록)에 없고 인증서 발급 한도에도 자주 걸린다는 지적이 있었습니다.
저는 테스트용 도메인이나 일회성 실험 같은 용도로 FreeDNS를 가끔 써 왔습니다. 이런 서비스가 있다는 것 자체는 정말 고맙지만, 비슷한 다른 서비스가 더 잘 다루는 불편한 점이 몇 가지 있습니다.
이 도메인들은 Public Suffix List(PSL)에 올라 있지 않습니다. 이 목록은 도메인 이름별 쿠키 처리 방식에 영향을 주는데, 브라우저가 서브도메인이 아니라 공유 도메인 이름 전체에 소프트웨어가 쿠키를 설정하도록 허용할 우려가 있습니다. 보안 문제가 될 수 있습니다. PSL 등재는 안 될 가능성이 큽니다: https://github.com/publicsuffix/list/pull/79
서브도메인용 무료 HTTPS 인증서를 받기도 어렵습니다. Let's Encrypt는 도메인 이름별로 발급 횟수를 제한하는데, 이 도메인들에는 발급 요청이 엄청나게 몰립니다. 이 제한을 풀어 주는 절차가 있지만, 제가 마지막으로 확인했을 때 FreeDNS는 그 절차를 이용하고 있지 않았습니다. 물론 인증서를 돈 주고 살 수는 있습니다.
무료 도메인에는 악용 사례가 넘쳐나기 때문에, 여러 차단 목록에 도메인이 올라가 있을 수도 있습니다.
이런 문제를 더 잘 처리해서 제가 지금 쓰는, 괜찮은 대안은 다음과 같습니다.
https://messwithdns.net/ - DNS를 배우기에 아주 잘 만든 DNS 콘솔
https://open-domains.com/ - Cloudflare를 쓰고, Discord 모임이 훌륭함
더 많은 곳: https://free.hrsn.dev/#/?id=domains
상황에 따라서는 공유기가 직접 동적 DNS 갱신을 해 주는 게 가장 편하고 현실적인데, 공유기에 따라 선택지가 제한돼서 "딱 좋은" 방법이 없을 때가 있습니다.
PSL에 대한 지적은 타당하지만, 이미 도메인이 있다면 무료 동적 DNS 업체의 서브도메인 레코드로 CNAME 레코드를 걸어 두면 됩니다. 저는 No-IP의 ddns.net 레코드로 몇 년째 그렇게 하고 있습니다. 30일마다 확인해야 하는 게 좀 귀찮아서 No-IP를 특별히 추천하지는 않지만, 한 달에 1분도 안 걸리는 일이라 무료 서비스치고는 참을 만합니다. 월 2.50달러는 동적 DNS 레코드 하나의 값어치보다 한 자릿수는 비싸다고 생각하고요.
집에 pfSense 장비를 두고부터는 동적 DNS에 Cloudflare를 쓰는데, 추가 요금도 없고 완벽하게 잘 돌아갑니다. 다만 위에서 말했듯이, 일반 가정용 공유기에서는 공유기 뒤의 일반 컴퓨터가 IP를 주기적으로 확인해서 동적 DNS 레코드를 갱신해 주지 않는 한 아마 쓸 수 없을 겁니다.
저는 Namecheap을 쓰고 있었기 때문에 처음에는 그쪽 동적 DNS 옵션을 쓰려고 했는데, 도메인 관리용 API를 전부 쓰려면 더 비싼 요금을 내야 하더군요. 정말 어이없는 일이지만, 어차피 사모펀드에 인수된 곳이라 계속 남아 있고 싶지도 않았습니다.
Public Suffix List 이 모든 게 정말 엉망이에요. 그 프로젝트가 존재한다는 것부터가 어처구니없고요. 왜 이걸 DNS 설정으로 할 수 없는 거죠?
애초에 쿠키의 서브도메인 간 접근을 허용하지 말았어야 해요. 모든 서브도메인은 다른 서브도메인들과 완전히 무관한 것으로 취급해야죠.
한숨
클라우드가 나오기 전에는 코드를 실제 물리 서버에 배포했어요. 사이트가 정말 인기를 끌면 서버가 한 대로는 모자랐고요.
상용이든 오픈소스든 로드 밸런서라는 게 나오기 전에는 말 그대로 HTTP 리다이렉트로 부하를 분산했습니다. www.example.com에 접속하면 데이터센터에 있는 실제 장비인 www13.example.com으로 넘겨지는 식이었죠.
동시 접속자 수가 서버 한 대의 용량을 넘을 때마다 웹사이트가 제멋대로 뻗었다면 오늘날의 인터넷은 존재하지 못했을 거라고 생각합니다.
제가 야후에 있을 때도 로드 밸런서는 분명히 있었지만, 경로별로 트래픽을 나눠 주는 엄청 고급스러운 로드 밸런서는 없었습니다. 그래서 '프로퍼티'마다 다른 호스트 이름을 썼고(저는 travel.yahoo.com을 맡았는데, 몇 년 전에 없어졌습니다), 로그인 쿠키(와 몇몇 다른 쿠키)는 전부 공유했습니다.
쿠키를 공유할 수 없었어도 분명 어떻게든 적응했겠지만, 훨씬 지저분해졌을 겁니다.
왜요? 그건 엉망으로 보이는데요. 프록시는 http보다 먼저 있었는데, 그냥 여러 물리 서버 사이에서 트래픽을 프록시로 넘겨서 부하를 관리하면 안 됐나요? 말 그대로 가난한 사람의 로드 밸런서잖아요. 옛날에 Travelocity가 그렇게 돌아갔습니다.
그냥 내부 DNS로 내부 IP가 서로 다른 여러 서버에 라운드 로빈을 돌리는 식으로 대충 로드 밸런싱하면 안 됐을까요?
DNS 캐싱이 있어서 부하가 어떻게 분산되는지는 서버를 운영하는 쪽이 통제할 수 없습니다. 공개한 IP 주소마다 트래픽이 대략 비슷하게 들어올 거라고 가정하고, 어떤 주소를 두 번 등록하면 다른 서버보다 부하를 두 배로 받을 거라고(트래픽을 두 배 처리할 수 있는 서버를 세워 뒀다면) 생각하기도 하지만, 현실에서는 캐싱과 불운 때문에 그중 IP 주소 하나가 요청의 90%를 받을 수도 있습니다(예를 들면요).
그러니 도메인 이름 하나에 IP 주소 여러 개를 연결하는 방식으로는 로드 밸런싱을 믿을 만하게 통제할 수 없습니다. (IP 애니캐스트가 더 적합하지만 구현하기가 훨씬 어렵습니다.)
자주 거론되는 복잡한 문제 중 하나는, 도메인끼리 서로 관련 있다는 게 무슨 뜻인지에 대해 요구 사항이 서로 다른 사용 사례가 너무 많다는 점입니다. 쿠키 문제는 브라우저가 풀어야 하는 문제이니, 모질라(와 자원봉사자들)가 그 사용 사례에 초점을 맞춘 목록을 관리하는 건 어느 정도 합리적입니다. 하지만 다른 사용 사례에는 잘 맞지 않습니다.
그래도 이 문제를 고민하는 사람은 많습니다. 어느 정도 관련된 예로 https://datatracker.ietf.org/doc/draft-manelidis-dnsop-domain-affiliation/ 가 있는데, 양쪽이 모두 동의해야 하는 DNS TXT 레코드 방식을 담고 있습니다. 이 초안과 앞으로 메일링 리스트에서 이어질 논의를 보면 이 문제가 얼마나 복잡한지 이해하기 좋습니다.
예를 들어 클라이언트를 속여서 "com"이 공개 접미사(public suffix)가 아니라고 믿게 만들 수 있다면, malicious.com에서 paypal.com의 쿠키를 설정할 수 있게 됩니다.
DNSSEC은 널리 배포되어 있지 않아서, DNS의 진위를 믿고 의존할 수가 없습니다.
DNSSEC이 있다면 publicsuffix에도 그걸 믿고 쓸 수 있을지 모릅니다. 그게 있다면 다른 문제도 많이 더 쉽게 풀릴지 모르고요.
DNSSEC 자동화가 다가오고 있습니다. 예를 들어 https://www.rfc-editor.org/info/rfc10026/ 가 있죠. 주류가 되지 못할 수도 있지만, DNS의 진위 보장으로 우리가 득을 볼 수 없다고 말하는 사람이 있더라도 그 말에 넘어가지 마세요!
그 제한을 푸는 절차를 제가 잘 압니다. Let's Encrypt는 인증서 한도를 최대 25만 개까지는 흔쾌히 올려 줬지만, 50만 개는 "저희가 감당하기에는 너무 큽니다"라며 난색을 보였습니다.
(저는 nip.io / sslip.io라는 DNS 서비스를 운영하는데, 사용자 중에 인증서를 요청하는 사람이 많아서 늘 한도에 부딪힙니다.)
온라인 서비스 중에서 가장 탄탄하고 오래가는 서비스 중 하나입니다. 거의 20년째 써 오고 있는 것 같은데 달라진 게 하나도 없어요.
한 가지는 달라졌습니다. 언제부터인가 '공유 관리 대기열(shared management queue)'이 생겨서, 아무나 제 도메인에 서브도메인을 붙일 수 있게 됐고, 그걸 막으려면 제가 일일이 거부해야 하는 것 같습니다. 거부하기 전까지는 사기꾼이 제 도메인에 서브도메인을 만들어서 원하는 IP로 연결하고 불순한 용도로 쓸 수 있어요.
저도 공짜로 쓰는 처지인 건 압니다. FreeDNS에 돈을 낸 적이 없으니 불평할 자격이 별로 없죠. 그래도 이건 정말 끔찍한 '기능'이라고 생각합니다. 유료 구독자라면 도메인이 비공개라서 사기꾼들이 쓸 수 없을 텐데요. 저는 한 개만 빼고 도메인을 전부 이 서비스에서 옮겼습니다(옮기는 건 다 아주 쉬웠어요. 마지막 하나만 아직 못 끝냈을 뿐입니다).
20년 넘게 쓴 사용자인데, 문제가 한 번도 없었습니다. 그때도 Josh가 이메일에 답장을 해 줬고, 지금도 해 줍니다. 그분에게 무슨 일이 생기더라도(신이시여 그런 일은 없게 하소서) 뒤를 이어 줄 사람이 있기를 바랄 뿐입니다.
DNS가 왜 화제인지 모르겠네요. 어차피 전부 루트 힌트 서버로 포워딩하잖아요.
다들 그냥 IANA 리졸버를 쓰면 되지 않나요?
두 가지 다른 개념을 혼동하고 계십니다. DNS 호스팅과 DNS 리졸빙(resolving)은 별개입니다.
이 서비스는 호스팅 서비스를 제공하는 것으로 보입니다. 즉 여러분 도메인의 레코드를 DNS 권한 서버(authoritative server)에 게시하는 일입니다.
DNS 리졸빙 서비스는 여러분을 대신해 DNS 데이터를 조회하고 대용량 캐시로 보관합니다. 덕분에 여러분의 기기가 수많은 DNS 서버에 재귀적으로 질의하지 않아도 되도록 조회를 최적화해 줍니다. 이 조회는 DNS 루트 존에 대한 질의에서 시작되는데, 루트 존은 루트 힌트 파일에 나열된 DNS 권한 서버들이 게시합니다.
시스템 리졸버를 IANA 루트로 설정해 보고 어떻게 되는지 보세요.
이 서비스와 비슷한 서비스들이 살아남는 건, 공유기 중에 이런 서비스를 이용해 유동 IP를 DNS 이름에 연결해 주는 기능을 지원하는 기종이 많기 때문입니다. 서비스 자체는 엄청 단순한데, 내 서버가 실제로 지원하는 서비스를 찾는 건 운에 맡겨야 합니다.
백업 DNS 서비스가 훌륭해서, 서버 한 대만으로도 자체 DNS를 운영할 수 있습니다.
도메인 이름을 사는 게 부담스럽다면 https://nic.eu.org/ 도 도메인을 얻기에 아주 좋은 곳입니다.
https://nic.eu.org 는 아주 좋은데, 저는 한참 전부터 거기서 도메인을 등록하지 못하고 있어요.
https://dns.he.net/ 과 너무 닮아서 우연일 리가 없다는 생각이 드는데요. 잘 알려진 디자인을 베낀 건가요, 아니면 다른 사연이 있나요?
둘 다 XName의 후손일 수 있습니다: https://web.archive.org/web/20120625081138/http://source.xname.org/
"포털" 레이아웃 스타일은 웹 1.0 시절에 아주 인기가 많았어요. PHP-Nuke가 떠오르네요.
세상에, PHP-Nuke라니 옛날 생각 나네요. 재밌던 시절이었죠(최근 php2shell 사태라는 난리가 있긴 했지만요). 솔직히 웹 1.5에 가깝죠. 순수하게 손으로 짠 HTML은 아니지만 클라이언트 쪽에서 요란한 짓을 하지도 않았으니까요.
그리고 맞아요, 그 시절 기술이 만들어 낸 특유의 "룩"이 분명히 있었어요. 디자인에 쓰던 테이블, 제한적인 스타일링과 JS 지원, 포털에 끼워 넣거나 바꿔 끼울 수 있던 php "컴포넌트", 그리고 "테마" 같은 것들요.
게다가 빠르죠. 페이지 전체를 받아와서 다시 렌더링해야 하는데도 클릭하면 즉시 반응해요.
SPA와 어디에나 깔린 JS 때문에 우린 너무 많은 걸 잃었어요.
htmx가 우리를 구원해 줄 겁니다!
gitea/forgejo가 딱 그런 느낌이에요. 대부분의 페이지가 ajax를 쓰지 않는데도 엄청 빠릅니다.
제 온라인 일기는 PHP-Nuke로 시작했습니다. 그다음 몇 년 동안은 PostNuke를 쓰다가 Drupal로 옮겼고, 지금도 거기 있어요. 26년 치 콘텐츠죠 ㅎㅎ (Drupal 말고 Wordpress를 골랐으면 좋았을 텐데 싶지만, 이제 바꾸기엔 링크가 너무 많아요.)
오랜만에 듣는 이름이네요!
제 눈엔 그다지 비슷해 보이지 않는데요. 둘 다 그냥 좀 낡아 보일 뿐이에요.