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

Mar Mar 2 11:21:33 -03 2021

Olá Douglas.
En realidad las técnicas del RFC8806 también sirven para dominios en
otro nivel del DNS.

El punto es que tal como dices, la raíz tiene varias características
que la hacen atractiva para ponerla local:

- es completamente pública,
- está firmada con DNSSEC (cosa que pr.gov.br no hace),
- cambia muy poco (2 veces al día),
- existen varias formas para obtener una copia, no solo usando DNS
con AXFR, sino por también por https;
- recibe muchas consultas "negativas" por dominios que no existen.

Aunque es verdad que uno se puede beneficiar con zonas en otros
niveles, creo que debería partir convenciendo al autoritativo de
ese sub-árbol, quienes en forma voluntaria podrían publicar su
zona, quizás filtrada para evitar nombres privados, firmarla con
ZONEMD, y ojalá permitiendo alguna señalización como los notify
de localroot.

No es poco trabajo. En lo personal creo que el propio DNS tiene
sus mecanismos para mejorar los tiempos de respuesta, como poner
NS más cercanos a los clientes, TTLs más largos, o usar anycast.
Incluso el gran beneficio original de 8806, lo de tener respuestas
negativas inmediatas, ahora se puede lograr con nsec aggressive
caching.

Saludos,

Hugo

On 08:32 25/02, Douglas Fischer via dns-esp wrote:
> 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

> _______________________________________________
> dns-esp mailing list
> dns-esp en listas.nic.cl
> https://listas.nic.cl/mailman/listinfo/dns-esp

------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: no disponible
URL: <https://listas.nic.cl/pipermail/dns-esp/attachments/20210302/32a290fc/attachment.sig>