<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">P.S.: Eu ainda patino no espanhol, então vou tomar a liberdade de escrever pt_BR<br><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.<br><br>Será que já existe alguma iniciativa de um "hyperlocal++"?<br>Algo que além dos gTLDs, permitisse também um compartilhamento de alguns dos próximos níveis da hierarquia de nomes?</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br><br>Exemplificando:<br>A capital do estado onde eu moro é Curitiba, no Paraná(também conhecida como Rússia brasileira... haha)<br>Existe o domínio <a href="http://curitiba.pr.gov.br">curitiba.pr.gov.br</a><br><br>O Estado do Paraná mantém uma estrutura de NSs do <a href="http://pr.gov.br">pr.gov.br</a> e delega SOA para os NS das cidades do PR.<br>- Hypelocal do "." que aponta para ".br"<br>- NSs do ".br" que apontam para o ".<a href="http://gov.br">gov.br</a>" (que também está no anycast Lacnic)</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">- NSs do ".<a href="http://gov.br">gov.br</a>" que apontam para o "<a href="http://pr.gov.br">pr.gov.br</a>"<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">- NSs do "<a href="http://pr.gov.br">pr.gov.br</a>" que apontam para o "<a href="http://curitiba.pr.gov.br">curitiba.pr.gov.br</a>" <br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br>Se existisse alguma coisa parecida com o Hyperlocal que me permitisse ao meu recursivo ir buscar para replicar localmente zona do <a href="http://pr.gov.br">pr.gov.br</a>, poderíamos replicar o mesmo efeito positivo do Hypelocal da zona raiz, mas para outras estruturas de DNS.<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">Obviamente até agora só pensei no lado bom dessa ideia, e ainda não pensei nos impactos negativos.<br>E justamente trago essa ideia aos colegas, mas me mostrarem do que estou esquecendo.</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">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.<br>Com a RFC8976, acredito que isso se resolva.<br><br>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.<br>Quanto a isso, sendo pragmático:</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"> - 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.</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"> - Os "well know" names (Ex.: www, smtp, ns1, ns2, etc...) também seriam facilmente obtidos por consultas de dicionário.<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"> - 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.</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">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...</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">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.<br>Isso "resolveria" o problema de entregar todos os RRs da zona, revelando assim coisas que não se deseja.<br>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.</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">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.<br><br><br><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">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.</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em qua., 10 de fev. de 2021 às 08:27, Nicolas Antoniello via dns-esp <<a href="mailto:dns-esp@listas.nic.cl">dns-esp@listas.nic.cl</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Esta es una excelente noticia !!!<br>
<br>
Y definitivamente algo que estaba "faltando" y era muy necesario.<br>
Básicamente con este nuevo RFC tenemos una forma de verificar que una<br>
zona que obtenemos de una transferencia (XFR) es exactamente igual a<br>
la que fue publicada (no sufrió ninguna modificación).<br>
Esto es sumamente útil, por ejemplo, en los casos de implementación de<br>
Hyperlocal para confirmar que la copia de la zona raíz que obtenemos<br>
coincide con la original... completando así la seguridad que agrega<br>
DNSSEC en esos casos.<br>
<br>
Fraterno saludo,<br>
Nico<br>
<br>
<br>
<br>
---------- Forwarded message ---------<br>
De: <<a href="mailto:rfc-editor@rfc-editor.org" target="_blank">rfc-editor@rfc-editor.org</a>><br>
Date: mié, 10 de feb. de 2021 a la(s) 03:20<br>
Subject: RFC 8976 on Message Digest for DNS Zones<br>
To: <<a href="mailto:ietf-announce@ietf.org" target="_blank">ietf-announce@ietf.org</a>>, <<a href="mailto:rfc-dist@rfc-editor.org" target="_blank">rfc-dist@rfc-editor.org</a>><br>
Cc: <<a href="mailto:drafts-update-ref@iana.org" target="_blank">drafts-update-ref@iana.org</a>>, <<a href="mailto:dnsop@ietf.org" target="_blank">dnsop@ietf.org</a>>, <<a href="mailto:rfc-editor@rfc-editor.org" target="_blank">rfc-editor@rfc-editor.org</a>><br>
<br>
<br>
A new Request for Comments is now available in online RFC libraries.<br>
<br>
<br>
RFC 8976<br>
<br>
Title: <span class="gmail_default" style="font-family:"courier new",monospace;font-size:small"></span>Message Digest for DNS Zones<br>
Author: D. Wessels,<br>
P. Barber,<br>
M. Weinberg,<br>
W. Kumari,<br>
W. Hardaker<br>
Status: Standards Track<br>
Stream: IETF<br>
Date: February 2021<br>
Mailbox: <a href="mailto:dwessels@verisign.com" target="_blank">dwessels@verisign.com</a>,<br>
<a href="mailto:pbarber@verisign.com" target="_blank">pbarber@verisign.com</a>,<br>
<a href="mailto:matweinb@amazon.com" target="_blank">matweinb@amazon.com</a>,<br>
<a href="mailto:warren@kumari.net" target="_blank">warren@kumari.net</a>,<br>
<a href="mailto:ietf@hardakers.net" target="_blank">ietf@hardakers.net</a><br>
Pages: 31<br>
Updates/Obsoletes/SeeAlso: None<br>
<br>
I-D Tag: draft-ietf-dnsop-dns-zone-digest-14.txt<br>
<br>
URL: <a href="https://www.rfc-editor.org/info/rfc8976" rel="noreferrer" target="_blank">https://www.rfc-editor.org/info/rfc8976</a><br>
<br>
DOI: 10.17487/RFC8976<br>
<br>
This document describes a protocol and new DNS Resource Record that<br>
provides a cryptographic message digest over DNS zone data at rest.<br>
The ZONEMD Resource Record conveys the digest data in the zone<br>
itself. When used in combination with DNSSEC, ZONEMD allows<br>
recipients to verify the zone contents for data integrity and origin<br>
authenticity. This provides assurance that received zone data matches<br>
published data, regardless of how the zone data has been transmitted<br>
and received. When used without DNSSEC, ZONEMD functions as a<br>
checksum, guarding only against unintentional changes.<br>
<br>
ZONEMD does not replace DNSSEC: DNSSEC protects individual RRsets<br>
(DNS data with fine granularity), whereas ZONEMD protects a zone's<br>
data as a whole, whether consumed by authoritative name servers,<br>
recursive name servers, or any other applications.<br>
<br>
As specified herein, ZONEMD is impractical for large, dynamic zones<br>
due to the time and resources required for digest calculation.<br>
However, the ZONEMD record is extensible so that new digest schemes<br>
may be added in the future to support large, dynamic zones.<br>
<br>
This document is a product of the Domain Name System Operations<br>
Working Group of the IETF.<br>
<br>
This is now a Proposed Standard.<br>
<br>
STANDARDS TRACK: This document specifies an Internet Standards Track<br>
protocol for the Internet community, and requests discussion and suggestions<br>
for improvements. Please refer to the current edition of the Official<br>
Internet Protocol Standards (<a href="https://www.rfc-editor.org/standards" rel="noreferrer" target="_blank">https://www.rfc-editor.org/standards</a>) for the<br>
standardization state and status of this protocol. Distribution of this<br>
memo is unlimited.<br>
<br>
This announcement is sent to the IETF-Announce and rfc-dist lists.<br>
To subscribe or unsubscribe, see<br>
<a href="https://www.ietf.org/mailman/listinfo/ietf-announce" rel="noreferrer" target="_blank">https://www.ietf.org/mailman/listinfo/ietf-announce</a><br>
<a href="https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist" rel="noreferrer" target="_blank">https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist</a><br>
<br>
For searching the RFC series, see <a href="https://www.rfc-editor.org/search" rel="noreferrer" target="_blank">https://www.rfc-editor.org/search</a><br>
For downloading RFCs, see <a href="https://www.rfc-editor.org/retrieve/bulk" rel="noreferrer" target="_blank">https://www.rfc-editor.org/retrieve/bulk</a><br>
<br>
Requests for special distribution should be addressed to either the<br>
author of the RFC in question, or to <a href="mailto:rfc-editor@rfc-editor.org" target="_blank">rfc-editor@rfc-editor.org</a>. Unless<br>
specifically noted otherwise on the RFC itself, all RFCs are for<br>
unlimited distribution.<br>
<br>
<br>
The RFC Editor Team<br>
Association Management Solutions, LLC<br>
<br>
<br>
_______________________________________________<br>
IETF-Announce mailing list<br>
<a href="mailto:IETF-Announce@ietf.org" target="_blank">IETF-Announce@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/ietf-announce" rel="noreferrer" target="_blank">https://www.ietf.org/mailman/listinfo/ietf-announce</a><br>
_______________________________________________<br>
dns-esp mailing list<br>
<a href="mailto:dns-esp@listas.nic.cl" target="_blank">dns-esp@listas.nic.cl</a><br>
<a href="https://listas.nic.cl/mailman/listinfo/dns-esp" rel="noreferrer" target="_blank">https://listas.nic.cl/mailman/listinfo/dns-esp</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><font size="2"><span style="font-family:"courier new",monospace">Douglas Fernando Fischer</span><br style="font-family:"courier new",monospace"><span style="font-family:"courier new",monospace">Engº de Controle e Automação</span></font><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;color:black;text-align:left;line-height:130%;font-family:"courier new",monospace"></div></div></div>