[lacnog] [dns-esp] Se publicó la RFC 8976 (Message Digest for DNS Zones: ZONEMD RR)

Mie Feb 10 13:22:48 -03 2021

Gracias por el aviso Nico!
Aprovecho de recomendarles la herramienta "dns-tools" que permite
calcular los ZONEMD y verificarlos, desarrollada en .CL por NICLabs :)
  https://github.com/niclabs/dns-tools

y que de paso también valida correctitud DNSSEC:

-----
$ ./dns-tools verify -f vulcano.cl.signed -z vulcano.cl
[dns-tools] 2021/02/10 13:17:59 Zone parsed is vulcano.cl.
[dns-tools] 2021/02/10 13:17:59 DS for KSK with tag 56632 is "vulcano.cl.	7200	IN	DS	56632 8 1 01024E755F54372284FB730F03150812B55F52CA"
[dns-tools] 2021/02/10 13:17:59 number of signatures: 130
[dns-tools] 2021/02/10 13:17:59 [ OK  ] vulcano.cl.#IN#DNSKEY
[ ... ]
[dns-tools] 2021/02/10 13:17:59 Zone Signature: Verified Successfully.
Validating Scheme 1, HashAlg 1... ok
[dns-tools] 2021/02/10 13:17:59 Zone Digest: Verified Successfully.
-----

Para complementar lo que dice Nico, esta herramienta no es lo mismo que
DNSSEC. Está pensada para verificar una zona "at rest", es decir un
archivo en disco que puede haber sido bajado desde un sitio web, por
ftp, etc., al estilo de los sha256sum al descargar software. Esperemos
que Verisign lo incluya pronto para la raíz!

Saludos,

Hugo

On 08:26 10/02, Nicolas Antoniello via dns-esp wrote:
> 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
> 
------------ próxima parte ------------
Se ha borrado un mensaje adjunto que no está en formato texto plano...
Nombre     : signature.asc
Tipo       : application/pgp-signature
Tamaño     : 833 bytes
Descripción: no disponible
Url        : <https://mail.lacnic.net/pipermail/lacnog/attachments/20210210/5887f800/attachment.sig>