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/RFC8976

This 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


--
Douglas Fernando Fischer
Engº de Controle e Automação