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
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
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
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
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
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
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 field in RRSIG so you can't explicitly
>
On 30.7.2018 15:32, Tony Finch wrote:
> Paul Wouters wrote:
>>
>> We are looking at a way to distribute the root zone, presumably to
>> make the root servers less mission critical and for enhanced
>> privacy and reduced NXDOMAIN queries.
>
> RFC 8198 with qname minimization give you the latter
On Jul 30, 2018, at 5:03 PM, Wes Hardaker wrote:
>> I think the use for non-root zones is quite a different use case,
I don’t.
>> so if
>> I ignore that, we are looking at specifically the root zone only.
>
> Please don't ignore that. We really do ourselves a disservice when we
> design a
Paul Wouters writes:
> What I see is that:
>
> We are looking at a way to distribute the root zone
> maybe this is also useful for non-root zones, so the method was sort
> of made to apply generically.
> I think the use for non-root zones is quite a different use case, so if
> I
Paul Wouters wrote:
>
> We are looking at a way to distribute the root zone, presumably to
> make the root servers less mission critical and for enhanced
> privacy and reduced NXDOMAIN queries.
RFC 8198 with qname minimization give you the latter two.
> We are depening on DNSSEC for integrity
On Fri, Jul 27, 2018 at 06:17:37PM -0400, Paul Wouters wrote:
> we can do AXFR but that would keep the root servers mission critical.
Also, the only currently practical channel security for AXFR is TSIG and
it can't scale to hundreds of thousands of clients.
Speaking as an implementer, I like
On Fri, 27 Jul 2018, Warren Kumari wrote:
This can, but does not have, to be built into the nameserver itself.
Those are just more arguments to not have a DNS checksum/sig option.
What I see is that:
We are looking at a way to distribute the root zone, presumably to
make the root servers
13 matches
Mail list logo
