Domínio principal
Infraestrutura de Internet
Na faceta Domínio principal, Infraestrutura de Internet grupos de inteligência são organizados por domínio principal para que os leitores possam acompanhar uma área de foco em infraestrutura da internet, governança, mercados de conectividade ou capital digital. A página reúne artigos relacionados, evidências públicas, instituições, empresas, pessoas, exposição regional, dependências operacionais e contexto de mercado que, de outra forma, poderiam estar espalhados por páginas de categorias separadas. Ela explica o domínio, a provável classe de atores, o contexto de mercado ou de governança e o material de origem que os leitores devem usar ao comparar sinais. Operadores, analistas e leitores de governança podem ver como o mesmo domínio aparece em eventos, perfis, mudanças de mercado, evidências de fontes públicas, dependências regionais e decisões de infraestrutura de ciclos mais longos ao longo do tempo.
IETF
O custo do hash estava configurado; a capacidade de login ainda não
A RFC 9106 torna explícitos memória, passadas e paralelismo do Argon2id. Esses números definem o orçamento de uma verificação de senha, mas não medem a frota de autenticação, a migração de registros antigos nem o custo real de um ataque.
História
RFC 2214 tornou C, D e a folga gerenciáveis, não autoevidentes
A interface passou a declarar o custo de se afastar de um servidor fluido e a margem usada para poupar recursos. A precisão da tabela descrevia uma configuração local; não comprovava o serviço entregue a um fluxo.
IETF
O diálogo continuou; a autoridade não veio no identificador
A proposta do Agentproto quer manter uma interação reconhecível quando ela atravessa agentes, ferramentas, intermediários, redes e interrupções. Essa continuidade produz um recibo operacional importante. Ela não prova, sozinha, quem podia agir, qual delegação continuava válida, o…
IETF
A cor do enlace chegou; a decisão de política, não: RFC 9104
Um consumidor BGP-LS pode receber um Extended Administrative Group perfeitamente formado sem que isso prove que os bits foram entendidos conforme o dicionário do operador, que uma política os utilizou ou que o caminho esperado foi instalado. A RFC 9104 padroniza o transporte até…
História
O SET criou a reserva, mas não provou a negociação: RFC 2213
A seção de segurança de RFC 2213 registrou uma diferença que um painel poderia esconder: uma escrita SNMP podia produzir uma reserva sob regras diferentes da negociação RSVP. O estado criado era real no plano de gestão, mas sua origem não podia ser rebatizada como consentimento…
IETF
A transferência foi cifrada. A cópia da zona ainda exigia custódia: RFC 9103
O XoT fecha uma via específica de coleta: a leitura passiva de um AXFR ou IXFR em texto claro. A autorização por requisição, a guarda da réplica e as demais superfícies públicas do DNS continuam exigindo evidências próprias.
História
O servidor anunciou o caminho da caixa. Não confirmou a caixa: RFC 2342
O NAMESPACE do IMAP permitiu ao cliente descobrir prefixos pessoais, compartilhados e de outros usuários sem pedir configuração manual. Esse anúncio ensinava a formar nomes. Existência, visibilidade, permissão, seleção, conteúdo e leitura continuavam dependendo de etapas…
História
Um caminho, quatro álgebras e um desconhecido contagioso: RFC 2215
Valores sobre a mesma rota não respondem necessariamente à mesma pergunta. A RFC 2215 preservava uma quebra com OR, contava saltos capazes, retinha o mínimo de banda e MTU e somava a latência mínima. Quando um elemento não conseguia produzir evidência, a precisão dos elementos…
IETF
O proxy aceitou o túnel. O destino ainda não provou o resultado
A revisão 14 do CONNECT-TCP dá ao proxy TCP uma origem HTTP, um modelo de URI e um protocolo de cápsulas comum a HTTP/1.1, HTTP/2 e HTTP/3. A mudança melhora o controle de entrada. Também torna indispensável separar autorização do proxy, estabelecimento da conexão, entrega dos…
História
Áudio e vídeo cabiam no mesmo pacote; a reprodução não cabia: RFC 2343
A RFC 2343 descreveu uma carga RTP capaz de transportar slices de vídeo MPEG-2 e frames de áudio como um único programa. Ela reduziu overhead e tornou a relação temporal explícita. Ainda assim, os campos do pacote não observavam o caminho, o estado do decoder, a saída do…
História
RFC 2216: o nome do serviço não carregava a prova da entrega
Um número comum permitia que aplicações, roteadores e protocolos falassem do mesmo serviço. Não permitia que tratassem o número como o próprio resultado. Em 1997, a RFC 2216 criou um roteiro de prestação de contas: cada promessa precisava expor seus parâmetros, o contrato de…
ICANN
4,3 milhões de IDNs medem registros, não aceitação universal
Um nome pode estar delegado, registrado e resolvendo no DNS e ainda assim ser recusado pelo primeiro formulário de cadastro. O relatório de 2026 da ICANN mostra as duas realidades: a oferta de identificadores multilíngues ganhou escala, mas o caminho de software que precisa…
História
RFC 2345: a URL encontrada não era a identidade da empresa
Digitar o nome de uma empresa e receber um endereço web parecia eliminar a incerteza. A RFC 2345 testou justamente uma resposta mínima: uma URL e um rótulo, entregues por um serviço inspirado em WHOIS. O formato ajudava a localizar, mas não informava quem controlava o domínio…
História
RFC 2212: o roteador expôs seus erros antes de prometer atraso
Em vez de receber um selo opaco de “qualidade garantida”, a aplicação podia receber os termos necessários para refazer a conta. RFC 2212 obrigava cada elemento a declarar quanto se afastava de um servidor ideal: uma parcela que encolhia com a taxa reservada, `C/R`, e outra que…
IETF
O salto respondeu, mas qual nó falou?
Uma linha de traceroute pode exibir um endereço compartilhado e esconder qual equipamento realmente produziu o erro. O novo objeto proposto para ICMP acrescenta contexto com endereço ou nome de nó. A escolha operacional, porém, não é apenas habilitar um recurso: é definir quem…
História
O endereço não era o caminho: o limite que a RFC 2333 impôs ao NHRP
Uma entrada NHRP podia associar um destino IP a um endereço NBMA, indicar a origem da resposta e permanecer válida por um Holding Time. Isso não a transformava em comprovante de conectividade. A RFC 2333 colocava a resolução depois da escolha de rota e antes de várias etapas…
IETF
Menos consultas à raiz não significam menos tráfego
O LocalRoot mantém muitas consultas dentro do próprio resolvedor e reduz a dependência do caminho até o Root Server System. Em troca, cria uma obrigação de distribuição: encontrar uma fonte, detectar mudanças, obter a zona, validar ZONEMD e DNSSEC, ativar uma cópia e recuar antes…
História
O pedido chegou à cafeteira. A xícara ainda não provava o café: RFC 2324
HTCPCP transformou o café em recurso de rede e a cafeteira em servidor. O efeito mais útil dessa sátira é outro: mostrar que uma resposta de protocolo pode ser verdadeira e, ainda assim, insuficiente para provar preparo físico, entrega, segurança para consumo ou o ato de beber.
História
RFC 2210 e o bit que tirava do ADSPEC o direito de falar pelo caminho inteiro
Uma rota podia ser resumida em números úteis sem carregar um inventário de cada salto. A RFC 2210 fazia o ADSPEC acumular propriedades enquanto o PATH seguia até o receptor. Mas o próprio formato reconhecia um limite: se algum elemento não participasse de RSVP e Integrated…
IETF
O acesso está ativo; a capacidade ainda precisa de recibo: RFC 4084
Uma conexão pode entregar navegação e velocidade sem entregar a superfície operacional de que o cliente depende. A RFC 4084 oferece nomes neutros para essa diferença; um recibo de capacidades transforma os nomes em critérios de compra e operação.