[dns-esp] Hyperlocal++ - Abertura de zonas

Douglas Fischer fischerdouglas en gmail.com
Jue Feb 25 08:32:16 -03 2021


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 en 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 en 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 en ietf.org>, <rfc-dist en rfc-editor.org>
> Cc: <drafts-update-ref en iana.org>, <dnsop en ietf.org>, <
> rfc-editor en 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 en verisign.com,
>                     pbarber en verisign.com,
>                     matweinb en amazon.com,
>                     warren en kumari.net,
>                     ietf en 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 en 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 en ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
> _______________________________________________
> dns-esp mailing list
> dns-esp en listas.nic.cl
> https://listas.nic.cl/mailman/listinfo/dns-esp
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://listas.nic.cl/pipermail/dns-esp/attachments/20210225/e47cb779/attachment.html>


Más información sobre la lista de distribución dns-esp