where-is-the-iss.dedyn.io không phải là website, mà là một thử nghiệm vui, chỉ dùng bản ghi DNS LOC để trả về vị trí xấp xỉ của Trạm Vũ trụ Quốc tế (ISS)- DNS LOC là tiêu chuẩn thử nghiệm trong RFC 1876, cho phép bản ghi domain chứa không chỉ vĩ độ, kinh độ mà cả độ cao
- Phạm vi độ cao của bản ghi LOC là từ -100.000m đến 42.849.672m, nên có thể biểu diễn từ cơ sở ngầm cho tới vệ tinh quỹ đạo địa tĩnh
- Tọa độ ISS được lấy từ API N2YO; để phù hợp với định dạng LOC, cần đổi độ cao từ km sang m, còn vĩ độ và kinh độ sang định dạng độ-phút-giây
- Bản ghi được cập nhật qua API deSEC, TTL đặt là 900 giây, phản ánh vị trí mới nhất theo kiểu nỗ lực tối đa (best-effort) mỗi 15 phút
Đưa vị trí vào bản ghi DNS LOC
- Tên miền thường trỏ tới máy chủ, nhưng rốt cuộc máy chủ cũng là thiết bị có vị trí vật lý trong một trung tâm dữ liệu
- Bản ghi DNS LOC là bản ghi DNS có thể chứa vĩ độ, kinh độ và độ cao cho một domain
- RFC 1876 là tiêu chuẩn thử nghiệm định nghĩa bản ghi LOC
- Vì trung tâm dữ liệu có thể nằm trong tòa nhà cao tầng hoặc dưới lòng đất, nó cũng bao gồm tham số độ cao
- Độ cao tối thiểu là -100.000m
- Độ cao tối đa là 42.849.672m, đủ để dùng cho cả vệ tinh quỹ đạo địa tĩnh
where-is-the-iss.dedyn.io
where-is-the-iss.dedyn.io là domain được tạo để lấy vị trí xấp xỉ của ISS bằng truy vấn DNS- Domain này không phải là website, không ping được và không có cách tương tác nào ngoài DNS
- Người dùng Linux và Mac có thể truy vấn bản ghi LOC bằng lệnh sau
dig where-is-the-iss.dedyn.io LOC
- Phản hồi trả về vĩ độ, kinh độ và độ cao của ISS theo định dạng 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
- Bản ghi DNS được cập nhật mỗi 15 phút theo kiểu nỗ lực tối đa
- Có vẻ khó tìm cách truy vấn bản ghi LOC trong PowerShell hoặc Command Prompt trên Windows
Lấy dữ liệu vị trí
- N2YO cung cấp website có thể theo dõi nhiều vật thể trên quỹ đạo và một API với gói miễn phí khá hào phóng
- ISS được truy vấn trong API N2YO bằng ID vệ tinh 25544
- Phản hồi API có các trường như
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
}
]
}
- Độ cao trong phản hồi N2YO dùng đơn vị km, nhưng định dạng LOC yêu cầu đơn vị m
- Vì vĩ độ và kinh độ được trả về dưới dạng số thập phân, để đưa vào bản ghi LOC cần đổi sang định dạng độ-phút-giây (Degrees, Minutes, Seconds)
Cập nhật bản ghi LOC bằng deSEC
- Không có nhiều nhà cung cấp tên miền miễn phí hỗ trợ API cập nhật bản ghi LOC, nên tác giả chọn deSEC, một tổ chức từ thiện ở Berlin
- deSEC cung cấp tài liệu API
- Bản ghi LOC ban đầu được thêm vào endpoint
rrsets bằng 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}'
- Việc cập nhật bản ghi phức tạp hơn một chút: cần gửi HTTP PATCH tới một URL khác
- Yêu cầu PATCH chỉ cần chứa dữ liệu đã thay đổi
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"]}'
Chu kỳ cập nhật và giới hạn
- TTL được đặt là 900 giây
- Mã chạy mỗi 15 phút để cập nhật bản ghi DNS
- Chu kỳ này giúp nằm trong giới hạn API của cả N2YO và deSEC
- Cũng có thể đưa thời điểm cập nhật cuối cùng hoặc dữ liệu phi cấu trúc khác vào bản ghi TXT, nhưng với demo này, một proof of concept nhanh là đủ
- Nếu phân phối dữ liệu qua bản ghi DNS TXT, nó cũng có thể được dùng như một API gần như không có giới hạn request; cách này phù hợp hơn với dữ liệu tĩnh hoặc không thay đổi thường xuyên
Dữ liệu khác thường có thể đưa vào DNS
- Demo này là một cách phức tạp và nghịch ngợm để cho thấy DNS có thể chứa cả những bản ghi ngoài dự đoán
- Giống như biểu diễn tọa độ ISS bằng bản ghi LOC, ta cũng có thể nghĩ đến cách biểu diễn tọa độ của Mars Rover
- Các bài viết liên quan về DNS gồm BIMI - SVG in DNS TXT WTF?! và Why you can't dig Switzerland
1 bình luận
Các bình luận trên Hacker News
Một bản ghi khác, Name Authority Pointer (NAPTR), chứa số điện thoại của Johnson Space Center ở Houston
Xem bằng
dig where-is-the-iss.dedyn.io NAPTRsẽ thấyE2U+voice:telvàtel:+12814830123Tôi hiểu giới hạn API, nhưng chu kỳ cập nhật 15 phút có vẻ khá dài đối với một vật thể bay một vòng quanh Trái Đất trong 90 phút
Trung bình vị trí có thể lệch khoảng 1/12 chu vi Trái Đất, đại khái bằng khoảng cách giữa Lisbon và Istanbul
Nếu biết cách cập nhật DNS miễn phí cho phép cập nhật theo từng phút thì tôi sẵn sàng chuyển sang
Chắc chắn là sai số lớn đối với việc theo dõi vị trí chính xác
Tôi đọc câu đầu thành “I love DNS erotica”, có lẽ đó là dấu hiệu cho thấy tôi đã ở trong nhà quá lâu và nên đi dạo
Giờ tôi sẽ đi dạo
Có lẽ cũng cần tắm nước lạnh
Khá hay. Tôi vừa thêm nó vào dns.toys
dig iss.sky +short @dns.toys[1] https://dns.toys
Tuyệt vời. Vừa thông minh vừa mang tính giáo dục. Tôi lập tức tự hỏi liệu có thể làm điều tương tự với JWST không
Đáng tiếc là bản ghi DNS LOC có giới hạn khoảng 42 triệu mét, tức độ cao khoảng 42.000km, trong khi JWST ở cách xa khoảng 1,5 triệu km, xa hơn 38 lần
Vì vậy trường độ cao của LOC không thể biểu diễn vị trí đó. Có lẽ Hubble thì có thể
Nó giống như hỏi tọa độ GPS của Mặt Trăng. NASA từng thử thu tín hiệu GPS yếu trên Mặt Trăng bằng LRO vào năm 2023, nhưng hiện vẫn chưa hữu ích cho điều hướng
Lý do cách này phù hợp với ISS là vì nó có điểm dưới vệ tinh trên bề mặt Trái Đất. Có thể nhận tín hiệu GPS bất kể độ cao
Ngoài ra TLE áp dụng cho ISS, một vật thể trên quỹ đạo Trái Đất. TLE được thiết kế để định nghĩa vị trí và vận tốc của vệ tinh quỹ đạo Trái Đất bằng các phần tử quỹ đạo, để các mô hình như SGP4 diễn giải
“RFC 1876 là tiêu chuẩn thử nghiệm” ư, đúng là một thử nghiệm kéo dài thật lâu
University of Warwick, January 1996
[1] https://datatracker.ietf.org/doc/html/rfc1876
Tài liệu bổ sung về bản ghi DNS LOC: <https://www.ckdhr.com/dns-loc/>
Một cách phức tạp hơn một chút nhưng phản hồi tốt hơn nhiều là trỏ bản ghi NS của
where-is-the-iss.shkspr.mobitới IP VPS của bạnSau đó chạy một chương trình lắng nghe UDP/53 và TCP/53, rồi trả lời các gói DNS trong đó chỉ bản ghi LOC và message ID thay đổi động
Có thể không hoàn toàn tuân thủ đặc tả DNS, nhưng đủ cho mục đích này. Có thể cache phản hồi API để tránh giới hạn số lần gọi
Tôi đang tự vận hành một dịch vụ như vậy, và có thể thử với
2+2.op.dyn.bortzmeyer.fr/TXThoặcparis.now.weather.dyn.bortzmeyer.fr/TXTDNS là một kho khóa-giá trị liên hợp, tối ưu cho đọc, sao chép theo địa lý và nhất quán cuối cùng
Đọc RFC cũng không thấy giải thích vì sao cần cái này
Tôi tự hỏi liệu hồi năm 1996 có lý do nào liên quan đến logistics của các trường đại học hoặc trung tâm dữ liệu không
LOC RR được nói là có thể dùng cho bản đồ luồng backbone USENET, “traceroute trực quan” hiển thị đường đi địa lý của gói IP, các ứng dụng quản trị mạng tạo bản đồ máy chủ và router đang quản lý, v.v.
Cũng không có lý do gì để cái này không thể là một chuỗi cho người đọc được như “42 Wallaby Way, Sidney”