(these are just my comments alone. So take it as such)
The draft states in the Motivation section:
"The motivation and design of this protocol enhancement is tied to the DNS
root zone [InterNIC]."
Your Design Overview states that this will work for zones that are
"relatively stable and have
In article <208f049b-b35a-4755-9a20-fa0c7f685...@isc.org> you write:
>a) the hash has to be independent to zone, so either the hash has to reside
>outside of the root zone, or the root zone file would
>have to be reconstructed with “the torrent hash” and “the torrent data”;
>generally you would
Warren wrote:
> how do they know they
> can trust the zone file before loading it?
And Joe Abley commented about non-apex NS records and glue, not being part
of the current DNSSEC design/goals/requirements.
I'll start my questions/proposal(s) with a scope question:
- Is it a safe
The way BitTorrent works, it’s basically a Merkle tree over the chunks. So, you
need to compute the main hash over the zone data.
Maybe there’s a smart way to compute hash over the data that includes that
hash, but my poor brain thinks it would break the Matrix (or at least the
hashing
that the served zone is too large. Otherwise, the receiver has to
download the entire zone before it can determine that the hash does
not match. ...
On the other hand, clients will likely have a pretty good idea for the
size of the zone, so they could transfer it twice: ...
Now I'm really
Therefore either you need to exclude the data that changes (hash and its RRSIG)
when computing the hash for the BitTorrent and the receiving side would have to
reassemble this. Or you would need OOB mechanism to distribute the hash
(different part of the tree, CDN, ...).
Of course you
* Paul Wouters:
> Another reason for an rr count number in the rrtype.
The typical RR size is perhaps 1/300 of the protocol maximum (much
less without DNSSEC), so this is only sufficient for small zones.
___
DNSOP mailing list
DNSOP@ietf.org
Hi All -
This is a wrap-up email for the Resolverless DNS meeting held on July 16 in
Montreal. We had, by my rough count, about 50 people and two sets of
minutes are attached. If you attended, contributed, or took minutes (Thanks
Shane and Ben!) thank you - it was, imo, a productive,
Oh folks like my employer where half of the security teams scream and say no,
and the other half want to see to collect threat intelligence information.
From my high tech gadget
> On Jul 28, 2018, at 15:43, Ondřej Surý wrote:
>
> @ISC, we have been discussing this since we started
* John Levine:
> In article <87h8kp7sqf@mid.deneb.enyo.de> you write:
>>The ZONEMD record should contain a size indicator for the zone,
>>something that allows a receiver to stop downloading if it is clear
>>that the served zone is too large. Otherwise, the receiver has to
>>download the
* John R. Levine:
that the served zone is too large. Otherwise, the receiver has to
download the entire zone before it can determine that the hash does
not match. ...
>
>> On the other hand, clients will likely have a pretty good idea for the
>> size of the zone, so they could
@ISC, we have been discussing this since we started implementing RZ local copy
and it’s not that simple.
There are at least two problems with BitTorrent:
a) the hash has to be independent to zone, so either the hash has to reside
outside of the root zone, or the root zone file would have to be
12 matches
Mail list logo
