On 31.7.2018 16:58, Tony Finch wrote:
> Petr Špaček wrote:
>> On 30.7.2018 15:32, Tony Finch wrote:
>>>
>>> I keep thinking it might make sense to sign non-authoritative delegation
>>> records, though it's really hard to see how we could get there from here.
>>> For instance, there isn't a flags
On 30 Jul 2018, at 13:19, Mirja Kühlewind wrote:
> --
> DISCUSS:
> --
I’m responding to the “DISCUSS” items right now. I’ll get to the “COMMENT”
items shortly.
Petr Špaček wrote:
>
> One problem I can see is that these additional RRSIGs effectively
> prevent modification of data but not removal of glue (or NS in out-out
> intervals) ...
I was kind of assuming that the NSEC chain would include the glue -
obviously delegations and glue in opt-out interval
Might not hurt to also just mention this in the doc as a reminder for the
reader...
> Am 31.07.2018 um 22:25 schrieb Benjamin Kaduk :
>
> On Tue, Jul 31, 2018 at 04:14:41PM -0400, Tom Pusateri wrote:
>>
>>
>>> On Jul 31, 2018, at 3:53 PM, Tom Pusateri wrote:
>>>
If the RCODE is s
On 7/31/18, 15:25, "DNSOP on behalf of Wessels, Duane" wrote:
>Olafur wrote a little about this a couple weeks ago. He said:
Oh, okay, never mind me then.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Hi Stuart,
please see below.
> Am 01.08.2018 um 09:48 schrieb Stuart Cheshire :
>
> On 30 Jul 2018, at 13:19, Mirja Kühlewind wrote:
>
>> --
>> DISCUSS:
>> --
On 8/1/18, 07:29, "DNSOP on behalf of Tony Finch" wrote:
>I was kind of assuming that the NSEC chain would include the glue -
>obviously delegations and glue in opt-out intervals are not protected at
>all.
The reason cut point information is not signed is that the copies are not
authoritative,
On Aug 1, 2018, at 7:17 AM, Mirja Kuehlewind (IETF) wrote:
> Might not hurt to also just mention this in the doc as a reminder for the
> reader...
Good point. I have made the following change:
The format for DSO messages
({{format}}) differs somewhat from the traditional DNS message
format
Maybe changing RFC 4034 and RFC 4035 to have RRSIGs over
non-authoritative data is not the right way to go. It could break some
current validators, and it would be hard to let zones sign some but not
all of the non-authoritative data. (For example, I could imagine a zone
owner wanting to sign t
I strongly prefer a regular rrtype over any kind of special processing or
complicating dnssec further.
If axfr signatures aren’t enough because people envision non-dns zonefile
transports, do a single ZONEMD, which signs the whole thing or only all records
without RRSIG.
Paul
Sent from my pho
On 1 Aug 2018, at 9:31, Paul Wouters wrote:
I strongly prefer a regular rrtype over any kind of special processing
or complicating dnssec further.
Agree.
If axfr signatures aren’t enough because people envision non-dns
zonefile transports, do a single ZONEMD, which signs the whole thing
or
Hi Paul,
I agree that it would be foolish to change 4034/4035 without understanding the
implications of doing so (e.g. breaking validators).
However, it's possible that it would be a fairly minor semantic change, e.g. if
signing records with an owner name below a zone cut was optional and if
v
On Tue, Jul 24, 2018 at 9:33 AM Tim Wicinski wrote:
>This starts a Call for Adoption for draft-bortzmeyer-rfc7816bis
>The draft is available here:
https://datatracker.ietf.org/doc/draft-bortzmeyer-rfc7816bis/
>Please review this draft to see if you think it is suitable for
adoption
Ben Campbell has entered the following ballot position for
draft-ietf-dnsop-session-signal-12: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
On Wed, Aug 1, 2018 at 7:03 PM, Ben Campbell wrote:
> §5.1,"
>If the RCODE is set to any value other than NOERROR (0) or DSOTYPENI
>([TBA2] tentatively 11), then the client MUST assume that the server
>does not implement DSO at all. In this case the client is permitted
>to contin
On Wed, Aug 1, 2018 at 8:02 AM, Mirja Kuehlewind (IETF) wrote:
> >> 1) In addition to the bullet point in the 6.2 that was flagged by
> Spencer, I
> >> would like to discuss the content of section 5.4. (DSO Response
> Generation). I
> >> understand the desire to optimize for the case where the a
On Mon, Jul 30, 2018 at 4:19 PM, Mirja Kühlewind
wrote:
[Skipping the DISCUSS, which I hope we have already addressed.]
1) sec 3: I really find it a bit strange that there is normative language
> about
> error handling (as well as in the "same service instance" definition part)
> in
> the termin
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 Stateful Operations
Authors : Ray Bellis
Stuart Cheshire
18 matches
Mail list logo
