▲
GN⁺ 10달전 | parent | ★ favorite | on: ISS의 위치를 DNS로 확인하기(shkspr.mobi)
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를 가진다는 정리