P.S.: Eu ainda patino no espanhol, então vou tomar a liberdade de escrever pt_BR
O anúcio da publicação da RFC8976 me lembrou uma pergunta que já faz tempo que eu quero fazer para os colegas dessa lista.
Será que já existe alguma iniciativa de um "hyperlocal++"? Algo que além dos gTLDs, permitisse também um compartilhamento de alguns dos próximos níveis da hierarquia de nomes?
Exemplificando: A capital do estado onde eu moro é Curitiba, no Paraná(também conhecida como Rússia brasileira... haha) Existe o domínio curitiba.pr.gov.br
O Estado do Paraná mantém uma estrutura de NSs do pr.gov.br e delega SOA para os NS das cidades do PR.
- Hypelocal do "." que aponta para ".br"
- NSs do ".br" que apontam para o ".gov.br" (que também está no anycast
Lacnic)
- NSs do ".gov.br" que apontam para o "pr.gov.br"
- NSs do "pr.gov.br" que apontam para o "curitiba.pr.gov.br"
Se existisse alguma coisa parecida com o Hyperlocal que me permitisse ao meu recursivo ir buscar para replicar localmente zona do pr.gov.br, poderíamos replicar o mesmo efeito positivo do Hypelocal da zona raiz, mas para outras estruturas de DNS.
Obviamente até agora só pensei no lado bom dessa ideia, e ainda não pensei nos impactos negativos. E justamente trago essa ideia aos colegas, mas me mostrarem do que estou esquecendo.
O primeiro ponto negativo, que eu via como um impeditivo para essa ideia do "hyperlocal++" era justamente a possibilidade de zonas de segundo e terceiro nível serem falsificadas no caminho da replicação. Com a RFC8976, acredito que isso se resolva.
Outro ponto negativo que pensei, é que a abertura pública para replicação do arquivo completo das zonas seriam como uma lista de alvos para eventuais ataques direcionados a determinada organização/domínio. Quanto a isso, sendo pragmático:
- Considerando que os "alvos" seriam os NS autoritativos daquela zona,
esses já podem ser obtidos por qualquer um através de consultas de SOA/NS.
- Os "well know" names (Ex.: www, smtp, ns1, ns2, etc...) também seriam
facilmente obtidos por consultas de dicionário.
- Hosts com nomes especiais e diferentes(Ex.: internaldatabase ) ou
serviços delicados (Ex.: _sip._utp ) realmente seria expostos se a zona inteira fosse replicada, podendo facilitar algum tipo de ataque.
Não sou um grande conhecedor de DNS, mas imaginei que se houvesse alguma coisa como um RPZ - Response Police Zone, de pedido de replicação de zona XFR... Ou seja: A possibilidade de se gerar um arquivo sumarizado da zona, contendo somente as informações de SOA/NS/ZONEMD, dependendo se o IP de origem do XFR é um não NS oficial da zona. Isso "resolveria" o problema de entregar todos os RRs da zona, revelando assim coisas que não se deseja. E também permitiria que o recursivo que for usar esse recurso forme uma árvore de autoritativos de zonas, reduzindo assim tempo de consulta, e reduzindo fadiga nos autoritativos mundo afora.
Quem sabe até, poder-se-ia criar uma coletânea gerada automaticamente(ciclicamete) para ser publicada para todos os Recursivos que desejem usar, para que esses já saibam exatamente a quais autoritativos perguntar sobre cada zona.
P.S.2: Terminando de redigir esse e-mail me veio a cabeça que a extrapolação ao máximo desse conceito de "hyperlocal++" seria voltarmos a década de 70, replicando o arquivo hosts da internet inteira de computador em computador. hahaha.
Em qua., 10 de fev. de 2021 às 08:27, Nicolas Antoniello via dns-esp < dns-esp@listas.nic.cl> escreveu:
Esta es una excelente noticia !!!
Y definitivamente algo que estaba "faltando" y era muy necesario. Básicamente con este nuevo RFC tenemos una forma de verificar que una zona que obtenemos de una transferencia (XFR) es exactamente igual a la que fue publicada (no sufrió ninguna modificación). Esto es sumamente útil, por ejemplo, en los casos de implementación de Hyperlocal para confirmar que la copia de la zona raíz que obtenemos coincide con la original... completando así la seguridad que agrega DNSSEC en esos casos.
Fraterno saludo, Nico
---------- Forwarded message --------- De: rfc-editor@rfc-editor.org Date: mié, 10 de feb. de 2021 a la(s) 03:20 Subject: RFC 8976 on Message Digest for DNS Zones To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Cc: drafts-update-ref@iana.org, dnsop@ietf.org, < rfc-editor@rfc-editor.org>
A new Request for Comments is now available in online RFC libraries.
RFC 8976 Title: Message Digest for DNS Zones Author: D. Wessels, P. Barber, M. Weinberg, W. Kumari, W. Hardaker Status: Standards Track Stream: IETF Date: February 2021 Mailbox: dwessels@verisign.com, pbarber@verisign.com, matweinb@amazon.com, warren@kumari.net, ietf@hardakers.net Pages: 31 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dnsop-dns-zone-digest-14.txt URL: https://www.rfc-editor.org/info/rfc8976 DOI: 10.17487/RFC8976This document describes a protocol and new DNS Resource Record that provides a cryptographic message digest over DNS zone data at rest. The ZONEMD Resource Record conveys the digest data in the zone itself. When used in combination with DNSSEC, ZONEMD allows recipients to verify the zone contents for data integrity and origin authenticity. This provides assurance that received zone data matches published data, regardless of how the zone data has been transmitted and received. When used without DNSSEC, ZONEMD functions as a checksum, guarding only against unintentional changes.
ZONEMD does not replace DNSSEC: DNSSEC protects individual RRsets (DNS data with fine granularity), whereas ZONEMD protects a zone's data as a whole, whether consumed by authoritative name servers, recursive name servers, or any other applications.
As specified herein, ZONEMD is impractical for large, dynamic zones due to the time and resources required for digest calculation. However, the ZONEMD record is extensible so that new digest schemes may be added in the future to support large, dynamic zones.
This document is a product of the Domain Name System Operations Working Group of the IETF.
This is now a Proposed Standard.
STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.
The RFC Editor Team Association Management Solutions, LLC
IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ dns-esp mailing list dns-esp@listas.nic.cl https://listas.nic.cl/mailman/listinfo/dns-esp