Resumo

  • SIZE descreve a dimensão da entidade, enquanto os campos de precisão descrevem a incerteza da posição. Um não pode substituir o outro.
  • O padrão textual de LOC combina tamanho de um metro com erro horizontal de dez quilômetros de diâmetro. A resolução fina das coordenadas não elimina essa margem.
  • Consultar a posição de uma rede como aproximação para um host altera o alcance da resposta. Cache, assinatura e registro de formato não comprovam localização física nem adoção.

Saber o tamanho não era saber o endereço

Imagine um objeto que cabe numa esfera de um metro de diâmetro. Essa informação pode ser boa. Ainda assim, talvez só se conheça sua posição por uma referência regional, com quilômetros de incerteza. Não há contradição entre as duas descrições: uma fala do objeto; a outra, do conhecimento sobre onde ele está.

O RFC 1876, publicado em janeiro de 1996 como experimental, reservou campos diferentes para esses dois assuntos. Seu registro LOC permitia ao DNS transportar informações geográficas de hosts, redes e sub-redes sem obrigar o consumidor a confundir dimensão com precisão.

A separação parecia pequena no formato. Na prática, era o que impedia uma máquina pequena de se tornar, por inferência indevida, uma máquina precisamente localizada. Um mapa que lesse apenas o centro e desenhasse um símbolo estreito podia apagar essa cautela.

A questão não era se o símbolo ficava bonito ou legível. Era se o leitor ainda tinha acesso às condições da afirmação. Um ponto central com um erro declarado não tem o mesmo significado de um ponto central apresentado sozinho.

O metro que vinha acompanhado de dez mil

Na notação textual, LOC permite omitir tamanho, precisão horizontal e precisão vertical. Nesse caso, os valores assumidos são, respectivamente, um metro, dez mil metros e dez metros. O documento relaciona esses padrões à disponibilidade de posições aproximadas associadas a códigos postais.

Os dez mil metros representam o diâmetro do círculo de erro horizontal, não seu raio. O campo vertical também representa a extensão total do possível erro, e não diretamente uma margem de mais ou menos aquele valor. Já SIZE é o diâmetro da esfera que envolve a entidade.

É possível converter uma extensão total em uma interpretação de meia largura, quando apropriado. O que não se pode fazer é trocar as duas sem aviso. Também não há no RFC um nível de confiança estatística que autorize afirmar determinada probabilidade de o objeto estar dentro do círculo.

Omitir o campo no texto não o elimina da informação transmitida. A forma binária incorpora o valor padrão. Assim, uma interface que mostre coordenadas e esconda a precisão pode descartar uma limitação que o próprio publicador efetivamente enviou.

Uma geografia mantida perto do nome

A motivação vinha de um problema de manutenção. Mapas UUCP reuniam informações geográficas de alguns sites, mas sua atualização e verificação centralizadas davam trabalho. O DNS oferecia uma maneira de deixar cada responsável cuidar da descrição ligada ao nome que administrava.

Em novembro de 1994, o RFC 1712 havia proposto GPOS, também experimental. A descrição pretendia ser atualizada localmente e consultada de forma ampla. O texto comparava essa escolha com sysLocation de SNMP, ligado a agentes e descrições locais, e com as limitações de implantação de X.500 observadas naquele momento. Não se trata de uma avaliação desses sistemas em uso hoje.

GPOS guardava três cadeias numéricas imprimíveis. Não eram três números binários IEEE de ponto flutuante. A capacidade de escrever várias casas decimais não demonstrava que alguém tivesse realizado uma observação com a mesma precisão.

O DNS resolvia um problema de circulação da descrição. Não resolvia o problema de produzir a descrição correta. A autoridade para editar uma zona não era um certificado de levantamento geográfico.

Um número sem o eixo certo

O próprio texto de GPOS ajuda a mostrar por que o significado precisa acompanhar o número. Nomes e definições de longitude e latitude aparecem trocados em partes do RFC 1712. A errata oficial 541, relatada em 2006, identifica essa inversão e propõe corrigir as etiquetas preservando a ordem numérica.

O estado da errata é «Held for Document Update», não «Verified». Portanto, a proposta não deve ser apresentada como uma atualização já incorporada ao padrão. Tampouco permite supor que todos os programas tenham interpretado os exemplos antigos da mesma maneira. Aqui, os exemplos de coordenadas não são reutilizados como instrução de configuração.

LOC veio depois, mas essa sequência não autoriza chamar GPOS de formalmente abolido. O RFC 1876 não declara obsoleto o RFC 1712. O registro de parâmetros DNS da IANA mantém GPOS como tipo 27 e LOC como tipo 29. A presença dos dois informa a identidade dos formatos; não mede a adoção de nenhum deles.

O que cabia em dezesseis octetos

A versão zero de LOC contém dezesseis octetos de RDATA. Esse é o tamanho dos dados específicos, não do registro DNS completo nem da mensagem inteira. Versão, tamanho e as duas precisões ocupam um octeto cada. Latitude, longitude e altitude ocupam quatro cada uma.

Latitude e longitude são expressas em milésimos de segundo de arco com inteiros deslocados. Dois elevado a trinta e um indica o equador ou o meridiano de origem; valores maiores seguem para o norte ou para o leste. Não se deve tratar esse arranjo como uma simples cópia de coordenadas com sinal.

O formato consegue diferenciar valores muito próximos. Essa resolução de representação não garante que a fonte conheça a posição com igual detalhe. No caso da longitude, nem sequer há uma conversão fixa para distância no solo que sirva em todas as latitudes.

Tamanho e precisões usam uma codificação compacta: uma parte do octeto contém um algarismo e outra, um expoente de dez, para expressar centímetros. Valores de dez a quinze nessas partes não são definidos. Zero multiplicado por dez elevado a zero significa menos de um centímetro, não certeza absoluta ou erro exatamente nulo.

Versão também tem função. O leitor deve verificar esse campo e não presumir que uma versão desconhecida mantenha a mesma interpretação. Uma sequência de octetos recebida sem dano pode continuar sem significado para o programa que não conhece seu formato.

A altura tinha outra origem

No texto de uma zona, altitude, tamanho e precisão aparecem em metros. Na representação de rede, os campos correspondentes usam centímetros. A mudança de unidade precisa ser feita na passagem entre as duas formas, não inferida pela aparência dos números.

A altitude de LOC toma o elipsoide WGS84 como referência. O campo armazenado começa cem mil metros abaixo dele e conta em centímetros. Por isso, zero metro em relação ao elipsoide corresponde a dez milhões no valor codificado.

Esse deslocamento é um expediente de representação, não uma alteração da altura física. O nível médio do mar e o elipsoide também não são a mesma superfície. O RFC permite aproximações com referência ao mar desde que altitude ou precisão vertical sejam ajustadas de maneira apropriada.

O resultado é uma exigência de contexto: altura em relação a quê, escrita em qual unidade e com qual incerteza? Casas decimais adicionais não consertam uma resposta que começou na superfície errada.

A aproximação mudava o objeto da resposta

LOC podia descrever uma rede, não apenas uma máquina. A busca prevista pelo RFC aproveitava isso. Partindo de um nome, primeiro se consultava seu LOC, seguindo CNAME normalmente. Se não houvesse resposta direta, os endereços A associados podiam servir de base para procurar uma localização de rede ou sub-rede.

Partindo de um endereço IPv4, era necessário obter primeiro um nome por IN-ADDR.ARPA e então consultar o LOC desse nome. Não era uma regra de colocar LOC sob todo nome reverso de endereço.

A busca opcional mais ampla adaptava o procedimento histórico do RFC 1101, de 1989. Esse documento organizava nomes de redes e máscaras com PTR e dados no formato de A em posições especiais do espaço reverso. Alguns valores com aparência de A eram máscaras de sub-rede, não destinos de conexão.

O procedimento de LOC reunia os nomes e examinava primeiro os mais específicos, voltando depois aos mais amplos. Não era simplesmente subir pelos rótulos pais do DNS, nem aplicar a seleção de rota por prefixo mais longo de BGP. Os pressupostos eram os do IPv4 e das redes por classes de então; o texto não entregava uma extensão geral para IPv6.

Encontrar uma posição mais ampla era uma forma de manter alguma utilidade quando faltava informação fina. Mas a posição da rede continuava sendo da rede. Tratá-la como medição daquele host mudava o conteúdo da afirmação. Com vários endereços A, a aplicação ainda tinha escolhas sobre quais posições usar ou combinar.

Frescor de resposta não era frescor de observação

O RFC 1035 situa TTL entre os componentes de um registro de recurso DNS. Ele determina por quanto tempo uma cópia pode ser mantida em cache antes de uma nova consulta à fonte. Não registra quando alguém visitou um lugar ou conferiu um equipamento.

Em março de 2005, o RFC 4033 distinguiu ainda a coerência de cache da validade temporal de assinaturas DNSSEC. Autenticar a origem e a integridade dos dados não é verificar a geografia descrita neles. A inferência é simples: uma coordenada genuinamente publicada pode continuar antiga, mal configurada ou interpretada com a unidade errada.

As possibilidades de mapas de gerenciamento e de traceroute visual mencionadas em LOC eram propostas de uso. Não demonstravam o caminho físico efetivamente percorrido pelos pacotes. Uma localização registrada para um nome e uma observação de trajeto pertencem a conjuntos de evidência distintos.

Há também a divulgação. GPOS deixava claro que informações no DNS eram públicas. LOC advertia que uma posição muito precisa poderia aumentar riscos de segurança física. DNSSEC não oferece confidencialidade, de modo que assinar um lugar não o torna reservado. Esses alertas não comprovam um ataque específico nem uma política atual; delimitam uma decisão que o formato não toma pelo publicador.