▲

ISS의 위치를 DNS로 확인하기

 (shkspr.mobi)
2P by GN⁺ 6시간전 | ★ favorite | 댓글 1개
  • DNS LOC 레코드를 사용하여 국제우주정거장(ISS) 의 실시간 위치 정보를 조회할 수 있음
  • LOC 레코드는 위도, 경도, 고도 정보를 저장하며, 위성의 위치 추적에 적합한 기능 제공
  • 예시 도메인(where-is-the-iss.dedyn.io)에 DNS 질의 시 ISS의 최신 위치를 반환함
  • N2YO API를 활용하여 위치 데이터를 가져오고, 15분마다 자동으로 LOC 레코드가 갱신됨
  • deSEC와 같은 API 지원 도메인 서비스를 통해 효율적인 LOC 정보 업데이트 가능함

개요

  • DNS의 esoterica(마니아용 기능)에 대한 흥미를 바탕으로, DNS LOC 레코드를 이용해 실제 물리적 위치 정보를 전 세계로 배포할 수 있음
  • 일반적으로 도메인 이름은 서버의 물리적 위치와 연결되며, LOC 레코드를 통해 서버 뿐 아니라 특이한 기기 위치도 기록 가능함

DNS LOC 레코드란?

  • RFC 1876에 정의된 실험적 표준으로, 서버의 위도, 경도, 고도 정보를 DNS에 기록 가능함
  • 최소 고도 -100,000m(벙커 등 지하 위치 표현 가능), 최대 고도 42,849,672m(정지궤도 위성 등까지 표현 가능)
  • 위성을 비롯한 다양한 장비 위치 정보를 DNS로 전달할 수 있는 기능 제공

국제우주정거장(ISS) 위치 조회 서비스 구현

  • where-is-the-iss.dedyn.io 도메인 생성, 별도의 웹사이트·핑·일반 인터랙션 없이 DNS 질의만으로 작동

  • Linux, Mac에서 아래 명령어로 ISS 위치 정보 질의 가능함

    dig where-is-the-iss.dedyn.io LOC

  • 반환 예시: 위도/경도/고도 정보가 LOC 형식으로 제공됨

    where-is-the-iss.dedyn.io. 1066 IN  LOC 47 24 53.500 N 66 12 12.070 W 430520m 10000m 10000m 10000m

  • 15분마다 최신 위치 정보로 갱신됨 (best-effort 방식)

위치 데이터 취득 및 변환

  • N2YO의 웹사이트와 API를 통해 다양한 궤도 내 객체를 추적할 수 있으며, 무료 티어 API를 제공함

  • 예시 API 호출로 최신 위성 위치(위도, 경도, 고도 등)를 JSON 형식으로 획득 가능

    https://api.n2yo.com/rest/v1/…=_____

  • 반환되는 위도/경도는 소수점 형식, 고도는 Km 단위 → LOC 레코드로 변환시 도분초(DMS) 및 미터(m) 단위로 컨버팅 필요

LOC 레코드 갱신 자동화

  • deSEC(베를린 기반 비영리)에 API로 LOC 레코드 최초 생성 및 갱신 가능
  • LOC 최초 등록 예시 
    curl https://desec.io/api/v1/domains/where-is-the-iss.dedyn.io/rrsets/ ... --data '{"type": "LOC", "records": ["..."], "ttl": 900}'
  • 갱신은 HTTP PATCH를 이용해 변경된 정보만 전송함
  • TTL(900초, 15분) 로 설정해, 코드가 15분마다 자동 갱신을 수행함
  • API 사용량 제한을 준수하면서 효율적으로 최신 데이터 제공
  • 추가적으로 TXT 레코드 등을 통해 갱신 시간 기록 등 다양한 확장도 가능함

결론

  • 이번 시도는 DNS의 색다른 활용 가능성을 보여주는 기술적 시연임
  • 앞으로 Mars Rover 등 더 다양한 우주 객체 위치도 DNS LOC 레코드로 표현 가능성 제시
  • DNS를 활용한 참신한 응용 사례로, 인프라/IT 업무의 자동화, 위치 정보 관리 등에도 확장성 제공
▲
GN⁺ 6시간전  [-]
Hacker News 의견
  • 또 다른 레코드인 Name Authority Pointer (NAPTR)은 휴스턴 Johnson Space Center의 전화번호 정보 제공 
    > dig where-is-the-iss.dedyn.io NAPTR

; <<>> DiG 9.10.6 <<>> where-is-the-iss.dedyn.io NAPTR
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31786
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;where-is-the-iss.dedyn.io. IN NAPTR

;; ANSWER SECTION:
where-is-the-iss.dedyn.io. 3600 IN NAPTR 100 100 "u" "E2U+voice:tel" "!^.*$!tel:+12814830123!" .

;; Query time: 84 msec
;; SERVER: 100.100.100.100#53(100.100.100.100)
;; WHEN: Sun Jul 06 10:53:39 EDT 2025
;; MSG SIZE rcvd: 111
  • API 제한이 있다는 것은 알지만, 전체 지구를 90분 만에 도는 객체에 15분 업데이트 간격은 상당히 큰 편이라는 생각 공유, 평균적으로 지구 둘레의 1/12 정도, 리스본에서 이스탄불 사이 거리만큼 오차 발생 가능성 언급
    • 맞는 말이라고 생각, 포스팅에도 도킹 작업에는 사용하지 말라는 얘기 포함, 1분마다 무료로 업데이트 가능한 DNS가 있다면 당장 이쪽으로 전환할 생각 있음
  • 시작 문장을 "I love DNS erotica"로 잘못 읽은 경험 공유, 자신이 너무 오랫동안 실내에 있었던 것 같다는 깨달음, 산책의 필요성 느낀다는 이야기
    • 아마 놀라울 수도 있지만, 많은 사람들이 이런 내용 흥미롭게 느낄 거라는 확신
    • 사실 이 프로젝트가 바로 그 DNS 에로티카가 아니냐는 농담, 차가운 샤워가 필요할지도 모르겠다는 이야기
    • OnlyFans 크리에이터로 진출하고 싶지 않으니 자제 요청
    • "It's always DNS"라는 밈이 새로운 의미를 가지게 된다는 농담
  • 너무 멋진 프로젝트라 생각, 바로 dns.toys에 추가했다는 소식 공유 
    dig iss.sky +short @dns.toys
    • 정말 편리하고 신기하다는 감탄, 고마움 표현, 모든 도구가 TXT 레코드만 사용하는지, 아니면 LOC, NAPTR도 활용하는지 궁금증
  • 정말 기발하고 교육적인 아이디어라는 찬사, 비슷한 방법을 JWST에도 적용 가능한지 바로 궁금증 생김, 아쉽게도 LOC DNS 레코드는 약 4,200만 미터(42,000km)까지 지원, JWST는 이보다 38배 멀기 때문에 위치 표현에 한계, Hubble의 경우는 가능성 있을지도 모르겠다는 언급
    • JWST는 제2 라그랑주 포인트를 공전하기 때문에 GPS 좌표 지정 쉽지 않음, 달에 GPS 좌표를 요청하는 것과 비슷한 상황, 2023년 NASA가 LRO로 달에서 미약한 GPS 신호 수신 테스트한 적 있지만 탐색에는 실용적이지 않음, ISS는 서브새틀라이트 포인트 외에도 지상 고도와 상관없이 GPS 신호 수신 가능, TLE(이중선 궤도요소)는 ISS처럼 지구 저궤도를 도는 위성에 적용 가능, SGP4 모델 등으로 위치·속도 연산
    • GSO(정지궤도 위성)의 고도와 LOC 레코드 한계가 거의 일치한다는 의견
  • 하드코딩된 캐시 외에도 DNS 인프라 자체의 TTL 값이 캐싱에 도움이 되어야 한다는 주장, 특히 Cloudflare 1.1.1.1, Google 8.8.8.8 등 대형 퍼블릭 DNS 리졸버가 많다는 점에서 더욱 그러함, DNS는 전 세계적으로 일관성 있게 동작하는 데이터베이스 특성, 임시 데이터 저장 가능, 방화벽에 쉽게 막히지 않는 순진한 프로토콜로서의 장점, 다만 많이 가로채기도 하는 현실 언급
  • OpenNotify라는 다른 리소스(제공 기능은 제한되고 화려하지 않음) 소개
    http://open-notify.org/
  • DNS LOC 레코드에 대한 자세한 정보 소개
    https://www.ckdhr.com/dns-loc/
  • RFC를 보니 왜 이 기능이 필요했는지 설명이 없음, 1996년 당시 대학이나 데이터센터 물류와 관련된 이유가 있었던 건 아닐까 하는 의문
    • RFC의 5.1장(Suggested Uses)에서는 모호하나마 적용 가능성 제시 중, 예를 들면 USENET 백본 흐름 지도, 시각적 traceroute 앱(IP 패킷의 지리적 이동 경로 시각화), 네트워크 관리 앱에서 호스트·라우터 맵 생성 등 활용 가능성
    • RFC에서는 문제 해결을 명확하게 정의하지 않는 경우가 다수, LOC 레코드는 굳이 좌표가 아니라 사람이 읽을 수 있는 주소 문자열이어도 충분하다는 생각
  • DNS는 연합형, 읽기 최적화, 지리복제된 키-값 저장소이며 eventual consistency를 가진다는 정리
답변달기