3P by GN⁺ | ★ favorite | 댓글 1개
  • where-is-the-iss.dedyn.io는 웹사이트가 아니라 DNS LOC 레코드만으로 국제우주정거장(ISS)의 대략적 위치를 돌려주는 장난스러운 실험임
  • DNS LOC는 RFC 1876의 실험적 표준으로, 도메인 레코드에 위도·경도뿐 아니라 고도까지 담을 수 있음
  • LOC 레코드의 고도 범위는 -100,000m부터 42,849,672m까지라서 지하 시설부터 정지궤도 위성까지 표현 가능함
  • ISS 좌표는 N2YO API에서 가져오며, LOC 형식에 맞추려면 고도는 km에서 m로, 위도·경도는 도·분·초 형식으로 변환해야 함
  • deSEC API로 레코드를 갱신하고 TTL은 900초로 설정해, 15분마다 최선 노력(best-effort) 방식으로 최신 위치를 반영함

DNS LOC 레코드로 위치를 담기

  • 도메인 이름은 보통 서버를 가리키지만, 서버도 결국 데이터센터 안의 물리적 위치를 가진 장비임
  • DNS LOC 레코드는 도메인에 위도·경도·고도를 담을 수 있는 DNS 레코드임
  • RFC 1876은 LOC 레코드를 정의한 실험적 표준
    • 데이터센터가 고층 건물에 있거나 지하에 있을 수 있어 고도 파라미터도 포함함
    • 최소 고도는 -100,000m임
    • 최대 고도는 42,849,672m로, 정지궤도 위성에도 쓸 수 있는 범위임

where-is-the-iss.dedyn.io

  • where-is-the-iss.dedyn.io는 ISS의 대략적 위치를 DNS 질의로 얻기 위해 만든 도메인임
  • 이 도메인은 웹사이트가 아니며, ping도 할 수 없고 DNS 외의 상호작용 방식이 없음
  • Linux와 Mac 사용자는 다음 명령으로 LOC 레코드를 조회할 수 있음
dig where-is-the-iss.dedyn.io LOC
  • 응답은 ISS의 위도·경도·고도를 LOC 형식으로 반환함
;; ANSWER SECTION:
where-is-the-iss.dedyn.io. 1066 IN  LOC 47 24 53.500 N 66 12 12.070 W 430520m 10000m 10000m 10000m
  • DNS 레코드는 15분마다 최선 노력 방식으로 갱신됨
  • Windows의 PowerShell이나 Command Prompt에서는 LOC 레코드를 조회하는 방법을 찾기 어렵다고 봄

위치 데이터 가져오기

  • N2YO는 궤도상의 여러 객체를 추적할 수 있는 웹사이트와 무료 티어가 넉넉한 API를 제공함
  • ISS는 N2YO API에서 위성 ID 25544로 조회함
  • API 응답에는 satlatitude, satlongitude, sataltitude, timestamp, eclipsed 같은 필드가 들어 있음
{
    "info": {
        "satname": "SPACE STATION",
        "satid": 25544,
        "transactionscount": 7
    },
    "positions": [
        {
            "satlatitude": -21.25409321,
            "satlongitude": 140.3335763,
            "sataltitude": 420.09,
            "azimuth": 292.92,
            "elevation": -70.95,
            "ra": 202.69300845,
            "dec": -32.16097472,
            "timestamp": 1751366048,
            "eclipsed": true
        }
    ]
}
  • N2YO 응답의 고도는 km 단위지만, LOC 형식은 m 단위를 요구함
  • 위도와 경도는 십진수로 오기 때문에 LOC 레코드에 넣으려면 도·분·초(Degrees, Minutes, Seconds) 형식으로 바꿔야 함

deSEC로 LOC 레코드 갱신하기

  • LOC 레코드 업데이트 API를 제공하는 무료 도메인 이름 제공자는 많지 않았고, 베를린의 자선 단체인 deSEC를 선택함
  • deSEC는 API 문서를 제공함
  • 초기 LOC 레코드는 rrsets 엔드포인트에 curl로 추가함
curl https://desec.io/api/v1/domains/where-is-the-iss.dedyn.io/rrsets/ \
    --header "Authorization: Token _______" \
    --header "Content-Type: application/json" --data @- <<< \
    '{"type": "LOC", "records": ["40 16 25.712 S 29 32 36.243 W 427550m 0.00m 10000m 10m"], "ttl": 900}'
  • 레코드 갱신은 조금 더 까다로워, HTTP PATCH를 다른 URL에 보내야 함
  • PATCH 요청에는 바뀐 데이터만 담으면 됨
curl -X PATCH https://desec.io/api/v1/… \
    --header "Authorization: Token _______" \
    --header "Content-Type: application/json" --data @- <<< \
    '{"records": ["40 16 25.712 S 29 32 36.243 W 427550m 0.00m 10000m 10m"]}'

갱신 주기와 한계

  • TTL900초로 설정함
  • 코드는 15분마다 실행되어 DNS 레코드를 갱신함
  • 이 주기는 N2YO와 deSEC 양쪽의 API 제한 안에 머무르게 함
  • TXT 레코드로 마지막 갱신 시각이나 다른 비정형 데이터를 넣을 수도 있지만, 이 데모에서는 빠른 개념 증명으로 충분하다고 봄
  • DNS TXT 레코드에 데이터를 배포하면 요청 제한이 사실상 없는 API처럼 쓸 수도 있으며, 정적이거나 자주 바뀌지 않는 데이터에 더 적합함

DNS에 담을 수 있는 특이한 데이터

  • 이 데모는 DNS가 예상 밖의 레코드도 담을 수 있음을 보여주는 복잡하고 장난스러운 방식임
  • ISS 좌표를 LOC 레코드로 표현한 것처럼, Mars Rover의 좌표를 어떻게 표현할지도 떠올릴 수 있음
  • 관련 DNS 글로는 BIMI - SVG in DNS TXT WTF?!Why you can't dig Switzerland가 있음

댓글과 토론

Hacker News 의견들
  • 다른 레코드인 이름 권한 포인터(NAPTR) 에는 휴스턴 Johnson Space Center의 전화번호가 들어 있음
    dig where-is-the-iss.dedyn.io NAPTR로 보면 E2U+voice:teltel:+12814830123이 나옴

  • API 제한은 이해하지만, 지구를 90분에 한 바퀴 도는 물체에 15분 갱신 주기는 꽤 길어 보임
    평균적으로 지구 둘레의 1/12 정도, 대략 리스본과 이스탄불 사이 거리만큼 위치가 어긋날 수 있음

    • 맞음. 글에서도 말했듯이 이걸 도킹 작업에 쓰면 안 됨
      무료로 분 단위 갱신을 허용하는 DNS 업데이트 방법을 알면 기꺼이 옮기겠음
    • ISS의 궤도 속도는 약 7.66km/s라서 15분 동안 약 6,900km를 이동함
      정밀 위치 추적에는 확실히 큰 오차임
  • 첫 문장을 “I love DNS erotica”로 읽었는데, 너무 오래 실내에 있었으니 산책을 가야겠다는 신호 같음

    • 의외겠지만 이런 걸 파고들 사람은 꽤 많을 것 같음
    • 나도 처음에 그렇게 읽어서, 나만 이상한 사람이 아니라는 게 다행임
      이제 산책하러 가겠음
    • 이게 그게 아니었나 싶음
      찬물 샤워도 필요할 듯
    • “항상 DNS 문제다”라는 말에 완전히 새로운 의미가 생김
  • 꽤 멋짐. 방금 dns.toys에도 추가했음
    dig iss.sky +short @dns.toys
    [1] https://dns.toys

    • 정말 깔끔함. 도구들이 전부 TXT 레코드를 쓰는지, 아니면 LOC, NAPTR 같은 것도 쓰는지 궁금함
    • 날씨 쪽 버그가 있음. 브라티슬라바는 한여름에 섭씨 영하일 리가 없고, Tallinn도 약 17°C 정도 어긋났음
  • 훌륭함. 영리하면서도 교육적임. JWST에도 비슷한 걸 할 수 있을지 바로 궁금해졌음
    아쉽게도 DNS LOC 레코드는 약 4,200만 미터, 즉 고도 42,000km 정도가 한계인데 JWST는 그보다 38배 먼 약 150만km 거리에 있음
    그래서 LOC의 고도 필드로는 위치를 표현할 수 없음. Hubble이라면 가능할지도 모름

    • JWST는 제2 라그랑주점을 공전하므로 어떻게 될지 잘 모르겠음
      달의 GPS 좌표를 묻는 것과 비슷함. NASA가 2023년에 LRO로 달에서 약한 GPS 신호 수신을 시험하긴 했지만, 아직 항법에는 유용하지 않음
      ISS에 이 방식이 맞는 이유는 지구 표면 위의 위성 직하점이 있기 때문임. 고도와 관계없이 GPS 신호를 받을 수 있음
      또 TLE는 지구 궤도 물체인 ISS에 적용됨. TLE는 지구 궤도 위성의 위치와 속도를 궤도 요소로 정의하고, SGP4 같은 모델이 이를 해석하도록 설계됨
    • 아마 정지궤도(GSO) 가 바로 그 고도 근처라서 그런 것 같음
  • “RFC 1876은 실험 표준이다”라니, 정말 오래 지속된 실험임
    University of Warwick, January 1996
    [1] https://datatracker.ietf.org/doc/html/rfc1876

  • DNS LOC 레코드에 대한 추가 자료: <https://www.ckdhr.com/dns-loc/>

  • 조금 더 복잡하지만 훨씬 더 반응성이 좋은 방법은 where-is-the-iss.shkspr.mobiNS 레코드를 자기 VPS의 IP로 향하게 하는 것임
    그다음 UDP/53과 TCP/53을 듣는 프로그램을 실행하고, LOC 레코드와 메시지 ID만 동적으로 바뀌는 DNS 패킷을 응답하게 하면 됨
    DNS 명세를 완전히 따르지는 않겠지만 이 용도에는 충분함. API 응답은 캐시해서 호출 제한을 피할 수 있음

    • 핵심은 서버를 운영하고 싶지 않다는 것임. 대신 전 세계에 분산된 시스템을 남용할 수 있음
    • 그 방식은 DNS 명세에 완전히 부합함
      직접 그런 서비스를 운영 중이고, 2+2.op.dyn.bortzmeyer.fr/TXTparis.now.weather.dyn.bortzmeyer.fr/TXT로 테스트할 수 있음
  • DNS는 연합형, 읽기 최적화, 지리적 복제, 최종적 일관성을 가진 키-값 저장소임

  • RFC를 봐도 왜 이게 필요했는지 설명이 없음
    1996년 당시 대학이나 데이터센터 물류와 관련된 이유가 있었던 걸까 싶음

    • 5.1장 “Suggested Uses”에 최소한의 모호한 활용 예시는 있음
      LOC RR은 USENET 백본 흐름 지도, IP 패킷의 지리적 경로를 보여주는 “시각적 traceroute”, 관리 중인 호스트와 라우터 지도를 생성하는 네트워크 관리 앱 등에 쓸 수 있다고 되어 있음
    • 경험상 RFC는 자신들이 풀려는 문제를 대체로 모호하게 적음
      이게 “42 Wallaby Way, Sidney” 같은 사람이 읽을 수 있는 문자열이면 안 될 이유도 없음