Descobrindo a localização da ISS via DNS

 (shkspr.mobi)
3 pontos por GN⁺ 2025-07-07 | 1 comentários | Compartilhar no WhatsApp
  • É possível consultar a localização em tempo real da Estação Espacial Internacional (ISS) usando um registro DNS LOC
  • O registro LOC armazena informações de latitude, longitude e altitude, oferecendo um recurso adequado para rastrear a posição de satélites
  • Ao fazer uma consulta DNS para o domínio de exemplo (where-is-the-iss.dedyn.io), ele retorna a posição mais recente da ISS
  • Os dados de localização são obtidos com a API da N2YO, e o registro LOC é atualizado automaticamente a cada 15 minutos
  • Com um serviço de domínio com suporte a API, como o deSEC, é possível atualizar informações LOC com eficiência

Visão geral

  • A partir do interesse pelas esoterica do DNS (recursos de nicho para entusiastas), é possível usar um registro DNS LOC para distribuir informações de localização física real pelo mundo inteiro
  • Em geral, nomes de domínio estão ligados à localização física de servidores, e os registros LOC permitem registrar não só servidores, mas também a posição de dispositivos incomuns

O que é um registro DNS LOC?

  • É um padrão experimental definido na RFC 1876 que permite registrar no DNS informações de latitude, longitude e altitude de um servidor
  • Altitude mínima de -100.000 m (permitindo representar locais subterrâneos, como bunkers) e máxima de 42.849.672 m (permitindo representar até satélites em órbita geoestacionária)
  • Oferece um recurso para transmitir via DNS informações de localização de vários equipamentos, incluindo satélites

Implementando um serviço de consulta da localização da Estação Espacial Internacional (ISS)

  • Foi criado o domínio where-is-the-iss.dedyn.io, que funciona apenas com consulta DNS, sem site separado, ping ou interação convencional

  • Em Linux e Mac, é possível consultar a posição da ISS com o comando abaixo

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

  • Exemplo de retorno: informações de latitude/longitude/altitude são fornecidas no formato LOC

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

  • A informação é atualizada com a posição mais recente a cada 15 minutos (em modelo best-effort)

Obtenção e conversão dos dados de localização

  • Pelo site e pela API da N2YO, é possível rastrear vários objetos em órbita, e há uma API no plano gratuito

  • Com a chamada de API de exemplo, é possível obter a posição mais recente do satélite (latitude, longitude, altitude etc.) em formato JSON

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

  • A latitude/longitude retornada vem em formato decimal, e a altitude em Km → ao converter para um registro LOC, é necessário transformar em graus, minutos e segundos (DMS) e metros (m)

Automatizando a atualização do registro LOC

  • Com a deSEC (organização sem fins lucrativos sediada em Berlim), é possível criar e atualizar registros LOC via API
  • Exemplo de cadastro inicial do LOC 
    curl https://desec.io/api/v1/domains/where-is-the-iss.dedyn.io/rrsets/ ... --data '{"type": "LOC", "records": ["..."], "ttl": 900}'
  • Para atualizar, usa-se HTTP PATCH para enviar apenas as informações alteradas
  • O TTL (900 segundos, 15 minutos) é configurado para que o código faça a atualização automática a cada 15 minutos
  • Assim, é possível fornecer dados recentes com eficiência, respeitando o limite de uso da API
  • Além disso, também é possível expandir a ideia com registros TXT para armazenar informações como o horário da atualização

Conclusão

  • Esta tentativa é uma demonstração técnica das possibilidades de uso pouco convencionais do DNS
  • No futuro, ela sugere a possibilidade de representar via registros DNS LOC a posição de objetos espaciais ainda mais variados, como o Mars Rover
  • Como um caso criativo de uso do DNS, também oferece potencial de expansão para automação em infraestrutura/TI, gerenciamento de informações de localização e outras aplicações

Leituras relacionadas

1 comentários

 
GN⁺ 2025-07-07
Comentários do Hacker News
  • Outro registro, o Name Authority Pointer (NAPTR), fornece o número de telefone do Johnson Space Center, em Houston 
    > 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
  • Sei que há limitações de API, mas um intervalo de atualização de 15 minutos para um objeto que dá a volta completa na Terra em 90 minutos parece bastante grande; em média isso pode gerar um erro de cerca de 1/12 da circunferência terrestre, algo como a distância entre Lisboa e Istambul
    • Concordo, e o post também diz para não usar isso em operações de acoplamento; se existisse um DNS gratuito com atualização por minuto, eu mudaria para ele na hora
  • Alguém compartilhou que leu a frase inicial como "I love DNS erotica" por engano, percebeu que talvez estivesse tempo demais dentro de casa e sentiu que precisava sair para caminhar
    • Pode até surpreender, mas tenho certeza de que muita gente acharia esse tipo de conteúdo interessante
    • Na verdade, a piada é que este projeto já seria exatamente essa tal "DNS erotica", e talvez alguém precise de um banho frio
    • Pedido para se controlar, porque ninguém quer virar criador no OnlyFans
    • Piada de que o meme "It's always DNS" ganhou um novo significado
  • Projeto considerado incrível demais; compartilharam que ele foi adicionado imediatamente ao dns.toys 
    dig iss.sky +short @dns.toys
    • Comentário de que é realmente prático e impressionante, agradecimento, e curiosidade sobre se todas as ferramentas usam apenas registros TXT ou se também aproveitam LOC e NAPTR
  • Elogio à ideia por ser muito criativa e educativa; surgiu imediatamente a curiosidade se algo parecido poderia ser aplicado ao JWST; infelizmente, o registro DNS LOC só suporta até cerca de 42 milhões de metros (42.000 km), e o JWST fica 38 vezes mais longe, então há um limite para representar sua posição; no caso do Hubble, talvez haja alguma possibilidade
    • Como o JWST orbita o ponto de Lagrange 2, não é simples atribuir coordenadas GPS a ele; é parecido com pedir coordenadas GPS para a Lua; em 2023 a NASA testou com a LRO a recepção de sinais fracos de GPS na Lua, mas isso não é prático para navegação; a ISS, além do ponto subsatélite, também pode receber sinais de GPS independentemente da altitude em relação ao solo; TLE (elementos orbitais de duas linhas) pode ser aplicado a satélites em órbita baixa da Terra como a ISS, com cálculo de posição e velocidade por modelos como o SGP4
    • Opinião de que a altitude de um GSO (satélite geoestacionário) quase coincide com o limite do registro LOC
  • Argumento de que, além de caches hardcoded, a própria infraestrutura de DNS, por meio dos valores de TTL, deveria ajudar no caching, ainda mais considerando a quantidade de resolvedores públicos grandes como o Cloudflare 1.1.1.1 e o Google 8.8.8.8; o DNS é visto como um banco de dados federado, otimizado para leitura e com comportamento consistente em escala global; permite armazenar dados temporários e tem a vantagem de ser um protocolo ingênuo que não é bloqueado facilmente por firewalls, embora na prática também seja frequentemente interceptado
  • Apresentação de outro recurso chamado OpenNotify (com recursos limitados e menos chamativo)
    http://open-notify.org/
  • Compartilhamento de informações detalhadas sobre o registro DNS LOC
    https://www.ckdhr.com/dns-loc/
  • Ao olhar o RFC, alguém comentou que não há explicação sobre por que essa funcionalidade era necessária, levantando a dúvida se em 1996 isso não teria relação com universidades ou logística de datacenters
    • A seção 5.1 do RFC (Suggested Uses) sugere, ainda que de forma vaga, algumas aplicações possíveis, como mapas de fluxo do backbone da USENET, aplicativos visuais de traceroute (visualizando o trajeto geográfico de pacotes IP) e geração de mapas de hosts e roteadores em aplicativos de gerenciamento de rede
    • Muitos RFCs não definem claramente o problema que estão resolvendo; também há a opinião de que, no caso do registro LOC, uma string de endereço legível por humanos já bastaria, em vez de coordenadas
  • Resumo de que o DNS é um armazenamento chave-valor federado, otimizado para leitura, georreplicado e com consistência eventual