Descobrindo a posição da ISS via DNS

 (shkspr.mobi)
3 pontos por GN⁺ 2025-07-07 | 1 comentários | Compartilhar no WhatsApp
  • where-is-the-iss.dedyn.io não é um site, e sim um experimento brincalhão que retorna a posição aproximada da Estação Espacial Internacional (ISS) usando apenas um registro DNS LOC
  • DNS LOC é um padrão experimental da RFC 1876 que pode armazenar em um registro de domínio não só latitude e longitude, mas também altitude
  • O intervalo de altitude do registro LOC vai de -100.000m a 42.849.672m, então dá para representar desde instalações subterrâneas até satélites em órbita geoestacionária
  • As coordenadas da ISS são obtidas pela API da N2YO e, para se adequar ao formato LOC, a altitude precisa ser convertida de km para m, enquanto latitude e longitude precisam ser convertidas para o formato graus, minutos e segundos
  • O registro é atualizado pela API da deSEC com TTL de 900 segundos, refletindo a posição mais recente a cada 15 minutos em um esquema de melhor esforço (best-effort)

Armazenando localização com registros DNS LOC

  • Nomes de domínio normalmente apontam para servidores, mas servidores também são equipamentos com uma localização física dentro de um datacenter
  • O registro DNS LOC é um tipo de registro DNS capaz de armazenar latitude, longitude e altitude em um domínio
  • A RFC 1876 define o registro LOC como um padrão experimental
    • Como um datacenter pode ficar em um prédio alto ou no subsolo, o parâmetro de altitude também foi incluído
    • A altitude mínima é -100.000m
    • A altitude máxima é 42.849.672m, uma faixa que também serve para satélites em órbita geoestacionária

where-is-the-iss.dedyn.io

  • where-is-the-iss.dedyn.io é um domínio criado para obter a posição aproximada da ISS por meio de uma consulta DNS
  • Esse domínio não é um site, não responde a ping e não oferece nenhuma forma de interação além do DNS
  • Usuários de Linux e Mac podem consultar o registro LOC com o seguinte comando
dig where-is-the-iss.dedyn.io LOC
  • A resposta retorna latitude, longitude e altitude da ISS no formato 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
  • Os registros DNS são atualizados em melhor esforço a cada 15 minutos
  • O autor considera difícil encontrar uma forma de consultar registros LOC no PowerShell ou no Prompt de Comando do Windows

Obtendo os dados de localização

  • A N2YO oferece um site para rastrear vários objetos em órbita e também uma API com uma camada gratuita generosa
  • A ISS é consultada na API da N2YO com o ID de satélite 25544
  • A resposta da API inclui campos como satlatitude, satlongitude, sataltitude, timestamp e 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
        }
    ]
}
  • A altitude na resposta da N2YO vem em km, mas o formato LOC exige metros
  • Como latitude e longitude vêm em decimal, elas precisam ser convertidas para o formato graus, minutos e segundos (Degrees, Minutes, Seconds) antes de serem colocadas no registro LOC

Atualizando o registro LOC com a deSEC

  • Não havia muitos provedores gratuitos de nomes de domínio com API para atualizar registros LOC, então a escolha foi a deSEC, uma organização beneficente de Berlim
  • A deSEC oferece documentação de API
  • O registro LOC inicial é adicionado ao endpoint rrsets com 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}'
  • Atualizar o registro é um pouco mais complicado, porque é preciso enviar um HTTP PATCH para outra URL
  • A requisição PATCH precisa conter apenas os dados alterados
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"]}'

Intervalo de atualização e limitações

  • O TTL foi definido como 900 segundos
  • O código roda a cada 15 minutos para atualizar o registro DNS
  • Esse intervalo mantém o uso dentro dos limites de API tanto da N2YO quanto da deSEC
  • Também seria possível usar um registro TXT para armazenar o horário da última atualização ou outros dados não estruturados, mas para esta demo o autor considera suficiente uma prova de conceito rápida
  • Distribuir dados via registro DNS TXT pode até funcionar como uma API praticamente sem limite de requisições, sendo mais adequado para dados estáticos ou que mudam com pouca frequência

Dados curiosos que podem ser guardados no DNS

  • Esta demo mostra, de forma complexa e brincalhona, que o DNS pode armazenar tipos de registro inesperados
  • Assim como as coordenadas da ISS foram representadas em um registro LOC, dá para imaginar como representar também as coordenadas do Mars Rover
  • Textos relacionados sobre DNS incluem BIMI - SVG in DNS TXT WTF?! e Why you can't dig Switzerland

Leituras relacionadas

1 comentários

 
GN⁺ 2025-07-07
Comentários do Hacker News

  • Outro registro, o Name Authority Pointer (NAPTR), contém o número de telefone do Johnson Space Center, em Houston
    Ao consultar com dig where-is-the-iss.dedyn.io NAPTR, aparecem E2U+voice:tel e tel:+12814830123

  • Entendo os limites da API, mas um intervalo de atualização de 15 minutos parece bem longo para um objeto que dá uma volta na Terra em 90 minutos
    Em média, a posição pode ficar defasada em cerca de 1/12 da circunferência da Terra, aproximadamente a distância entre Lisboa e Istambul

    • Exato. Como o texto também diz, isso não deve ser usado em operações de acoplamento
      Se eu souber de uma forma de atualizar DNS gratuitamente em intervalos de minutos, migro com prazer
    • A velocidade orbital da ISS é de cerca de 7,66 km/s, então em 15 minutos ela percorre cerca de 6.900 km
      Para rastreamento preciso de posição, é definitivamente um erro grande

  • Li a primeira frase como “I love DNS erotica”, o que parece ser um sinal de que fiquei tempo demais dentro de casa e preciso sair para caminhar

    • Pode parecer surpreendente, mas acho que há bastante gente que se aprofundaria nesse tipo de coisa
    • Eu também li assim de primeira, então fico aliviado por não ser o único estranho
      Agora vou sair para caminhar
    • Achei que fosse isso mesmo
      Talvez eu também precise de uma ducha fria
    • A frase “é sempre problema de DNS” ganhou um significado completamente novo

  • Bem legal. Acabei de adicionar também ao dns.toys
    dig iss.sky +short @dns.toys
    [1] https://dns.toys

    • Muito bem-feito. Fiquei curioso se todas as ferramentas usam registros TXT ou se também usam coisas como LOC e NAPTR
    • Há um bug na parte do clima. Bratislava não deveria estar abaixo de zero Celsius no meio do verão, e Tallinn também estava com uma diferença de cerca de 17°C

  • Excelente. Inteligente e educativo. Fiquei imediatamente pensando se daria para fazer algo parecido com o JWST
    Infelizmente, o registro DNS LOC tem um limite de cerca de 42 milhões de metros, ou seja, altitude por volta de 42.000 km, enquanto o JWST fica cerca de 38 vezes mais longe, a aproximadamente 1,5 milhão de km
    Portanto, não dá para representar sua posição no campo de altitude do LOC. Talvez seja possível com o Hubble

    • O JWST orbita o segundo ponto de Lagrange, então não sei bem como isso funcionaria
      É parecido com perguntar pelas coordenadas GPS da Lua. A NASA testou em 2023 a recepção de sinais GPS fracos na Lua com o LRO, mas isso ainda não é útil para navegação
      O motivo de esse método fazer sentido para a ISS é que existe um ponto subsatélite sobre a superfície da Terra. Independentemente da altitude, é possível receber sinais GPS
      Além disso, TLE se aplica à ISS por ser um objeto em órbita terrestre. TLE foi projetado para definir a posição e a velocidade de satélites em órbita terrestre como elementos orbitais, para que modelos como o SGP4 os interpretem
    • Provavelmente é porque a órbita geoestacionária (GSO) fica justamente perto dessa altitude

  • “RFC 1876 é um padrão experimental” — que experimento duradouro
    University of Warwick, January 1996
    [1] https://datatracker.ietf.org/doc/html/rfc1876

  • Material adicional sobre registros DNS LOC: <https://www.ckdhr.com/dns-loc/>

  • Um método um pouco mais complexo, mas muito mais responsivo, seria apontar o registro NS de where-is-the-iss.shkspr.mobi para o IP do seu próprio VPS
    Depois, é só executar um programa que escute em UDP/53 e TCP/53 e responda com pacotes DNS nos quais apenas o registro LOC e o ID da mensagem mudem dinamicamente
    Não seguiria completamente a especificação DNS, mas seria suficiente para esse uso. A resposta da API poderia ser armazenada em cache para evitar limites de chamadas

    • O ponto principal é que não quero operar um servidor. Em vez disso, posso abusar de um sistema distribuído globalmente
    • Esse método está totalmente em conformidade com a especificação DNS
      Eu mesmo opero um serviço desses, e você pode testar com 2+2.op.dyn.bortzmeyer.fr/TXT ou paris.now.weather.dyn.bortzmeyer.fr/TXT

  • DNS é um armazenamento chave-valor federado, otimizado para leitura, replicado geograficamente e com consistência eventual

  • Mesmo olhando o RFC, não há explicação de por que isso era necessário
    Fico imaginando se havia algum motivo ligado à logística de universidades ou data centers em 1996

    • A seção 5.1, “Suggested Uses”, traz ao menos alguns exemplos de uso vagos
      Diz que o LOC RR pode ser usado para mapas de fluxo de backbone da USENET, um “traceroute visual” que mostra a rota geográfica de pacotes IP, aplicativos de gerenciamento de rede que geram mapas de hosts e roteadores administrados, etc.
    • Pela minha experiência, RFCs geralmente descrevem de forma vaga o problema que estão tentando resolver
      Também não vejo por que isso não poderia ser uma string legível por humanos, como “42 Wallaby Way, Sidney”