Reviewer: Allison Mankin
Review result: Almost Ready
Overall Comment - there is a lot of illumination in here, but one overall point
and a few smaller ones explain why I rated the draft Almost Ready, rather than
Ready.
The overall points is that it should give the reader more guidance. It is ve
Thank you for your comments.
On Aug 13, 2018, at 3:26 PM, John C Klensin wrote:
> First, as far as the definitions are concerned and as far as I
> can tell, where a term appeared in RFC 7719 and the definition
> has been changed, almost every change is for the better. The
> authors and WG are t
> On Aug 13, 2018, at 6:26 PM, John C Klensin wrote:
>
> the string 128.0.0.1, is a domain name
Yes, it is the presentation form of the domain name whose
list of labels is: "128", "0", "0", "1". There is of course
no TLD named "1", so this domain is not registered, and it
would also not be a us
IESG and others,
Unfortunately and due to some other priorities, I have not been
able to do a comprehensive review of this document. The
following is based on reading through and trying to get an
understanding of this rather long document and its many
definitions, some of which are, as the docume
>
>
> Another limitation I've mentioned before, where DNSSEC doesn't protect you,
> is that a delegation could be falsified such that traffic goes to an
> eavesdropper that just records but doesn't modify messages.
>
> but on most networks you connect to that you don't trust, they could
> just be
On 8/13/18, 13:35, "John R Levine" wrote:
>Hey, I have a great idea. We could make sure that the zone file received
>matches the zone file sent by including a hash of the zonee in a record in the
>zone. Whaddaya think?
In some sense, it's re-inventing the wheel.
>I realize you coul
but the obvious consumer is a DNS server.
Maybe, maybe not. I've seen DNS used in turnkey ways. Nevertheless,
given the complexity of DNSSEC validation, a wise implementer should
re-use the parts of a DNS server for this.
If the question is whether one might use this to create a kludge and
On 8/13/18, 11:50, "John Levine" wrote:
>As we may have mentioned once or twice before in this discussion, it lets you
>do zone transfers over insecure channels and batch verify the zone before
>using it.
Yes, I see that. As in no more argument is needed to convince me of that.
>but the obvi
On Mon, 13 Aug 2018, Edward Lewis wrote:
On 8/11/18, 10:44, "DNSOP on behalf of John Levine" wrote:
The way that ZONEMD is defined in the draft, it's not very useful if the ZONEMD
record isn't signed.
That's my read too, which is why I question the incremental benefit over relying on
DNSSE
In article <7223eeb4-57a4-4c54-8c62-631b5fbee...@icann.org>,
Edward Lewis wrote:
>On 8/11/18, 10:44, "DNSOP on behalf of John Levine" wrote:
>
>>The way that ZONEMD is defined in the draft, it's not very useful if the
>>ZONEMD record isn't signed.
>
>That's my read too, which is why I question t
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.
Title : DNS Terminology
Authors : Paul Hoffman
Andrew Sullivan
On 8/11/18, 10:44, "DNSOP on behalf of John Levine" wrote:
>The way that ZONEMD is defined in the draft, it's not very useful if the
>ZONEMD record isn't signed.
That's my read too, which is why I question the incremental benefit over
relying on DNSSEC while doing the query/response over port 5
12 matches
Mail list logo
