요약
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
그 제한을 푸는 절차를 제가 잘 압니다. Let's Encrypt는 인증서 한도를 최대 25만 개까지는 흔쾌히 올려 줬지만, 50만 개는 "저희가 감당하기에는 너무 큽니다"라며 난색을 보였습니다.
(저는 nip.io / sslip.io라는 DNS 서비스를 운영하는데, 사용자 중에 인증서를 요청하는 사람이 많아서 늘 한도에 부딪힙니다.)
Public Suffix List 이 모든 게 정말 엉망이에요. 그 프로젝트가 존재한다는 것부터가 어처구니없고요. 왜 이걸 DNS 설정으로 할 수 없는 거죠?
자주 거론되는 복잡한 문제 중 하나는, 도메인끼리 서로 관련 있다는 게 무슨 뜻인지에 대해 요구 사항이 서로 다른 사용 사례가 너무 많다는 점입니다. 쿠키 문제는 브라우저가 풀어야 하는 문제이니, 모질라(와 자원봉사자들)가 그 사용 사례에 초점을 맞춘 목록을 관리하는 건 어느 정도 합리적입니다. 하지만 다른 사용 사례에는 잘 맞지 않습니다.
그래도 이 문제를 고민하는 사람은 많습니다. 어느 정도 관련된 예로 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의 진위 보장으로 우리가 득을 볼 수 없다고 말하는 사람이 있더라도 그 말에 넘어가지 마세요!
온라인 서비스 중에서 가장 탄탄하고 오래가는 서비스 중 하나입니다. 거의 20년째 써 오고 있는 것 같은데 달라진 게 하나도 없어요.
DNS가 왜 화제인지 모르겠네요. 어차피 전부 루트 힌트 서버로 포워딩하잖아요.
다들 그냥 IANA 리졸버를 쓰면 되지 않나요?
두 가지 다른 개념을 혼동하고 계십니다. DNS 호스팅과 DNS 리졸빙(resolving)은 별개입니다.
이 서비스는 호스팅 서비스를 제공하는 것으로 보입니다. 즉 여러분 도메인의 레코드를 DNS 권한 서버(authoritative server)에 게시하는 일입니다.
DNS 리졸빙 서비스는 여러분을 대신해 DNS 데이터를 조회하고 대용량 캐시로 보관합니다. 덕분에 여러분의 기기가 수많은 DNS 서버에 재귀적으로 질의하지 않아도 되도록 조회를 최적화해 줍니다. 이 조회는 DNS 루트 존에 대한 질의에서 시작되는데, 루트 존은 루트 힌트 파일에 나열된 DNS 권한 서버들이 게시합니다.
시스템 리졸버를 IANA 루트로 설정해 보고 어떻게 되는지 보세요.
백업 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가 우리를 구원해 줄 겁니다!
제 온라인 일기는 PHP-Nuke로 시작했습니다. 그다음 몇 년 동안은 PostNuke를 쓰다가 Drupal로 옮겼고, 지금도 거기 있어요. 26년 치 콘텐츠죠 ㅎㅎ (Drupal 말고 Wordpress를 골랐으면 좋았을 텐데 싶지만, 이제 바꾸기엔 링크가 너무 많아요.)
오랜만에 듣는 이름이네요!
제 눈엔 그다지 비슷해 보이지 않는데요. 둘 다 그냥 좀 낡아 보일 뿐이에요.
15년쯤 즐겁게 공짜로 써 왔습니다. 추천해요.
저도 도메인 몇 개(특히 BBS.io)를 거기에 두고, 사람들이 DDNS 서브도메인으로 쓰게 하고 있습니다. 전반적으로 꽤 만족해요.
관심은 가는데, 소개 페이지에는 나와 있지 않은 것 같은 궁금한 점이 있습니다.
서비스가 계속된다는 보장은 얼마나 되나요?
누군가 인수하면요? 아니면 운영자가 어떤 이유로든 손을 놓으면요?
afraid.org는 2000년부터 26년 동안 무료 DNS 호스팅을 해 왔습니다.
그쪽의 비상 대책이나 존속 계획을 알 수 있으면 좋겠지만, 어차피 어떻게든 비관적으로 해석하실 듣기 좋은 말 몇 마디보다는 지금까지의 이력이 앞날을 더 잘 알려 준다고 생각합니다.
"이 서비스 관리자가 죽으면 어떻게 되나요?"라는 질문에 분명하게 답하는 데 듣기 좋은 말은 필요 없습니다.
무료 프로젝트는 정말 고맙게 생각하지만, 프로젝트 유형에 따라서는 사용자가 거기에 시간을 들이기 전에 어느 정도 보장이 필요하다는 걸 사람들이 이해해야 합니다. 그리고 이건 "비관적"인 것과는 아무 상관이 없습니다. 운영자가 이런 질문에 좋은 답을 줄 수 있다면 프로젝트가 더 탄탄해지고 모두가 더 행복해질 뿐입니다.
"이해해야", "무료 프로젝트", "어느 정도 보장이 필요", "'투자'할 시간", "좋은 답을 줄".
본인이 하는 말이 들리긴 하세요?
더 놀라운 건, 주어지거나 보장된 것은 어차피 아무 가치도 없다는 걸 모른다는 점이죠.
무슨 뜻인지 완전한 문장으로 설명해 주세요. 감사합니다.
“무료 프로젝트는 정말 고맙게 생각하지만,”
"하지만"은 필요 없습니다. 그냥 고마워하세요. 어떤 형태로든 보장이나 존속, 지원을 기대해서는 안 됩니다.
그게 전부입니다.