> On Jul 25, 2018, at 20:47, Ondřej Surý wrote:
>
>
> For ZONEMD, this isn’t true, as you can (in theory) feed the zone with
> infinite amount of non-DNSSEC-signed
> data (GLUEs, delegations) thus making the collision attack feasible.
That’s why I suggested already to add the count of the
Hi Matt, and other authors,
with my cryptoplumber[1] hat, I am strongly opposed to using SHA-1 and GOST R
34.11-94 for ZONEMD.
It is my understanding, that the specific usage of hashing function in the DS
record improves the collision
resistance of the algorithm, because the input data is so
Duane,
> My first reaction is that it adds a lot of additional records to the zone.
> If I understand correctly, one XHASH for every NSEC/NSEC3, plus an RRSIG for
> each XHASH. You didn't really say how (or if) XHASH could be used on an
> unsigned zone.
What if the ZONEMD+RRSIG would be
On wrote:
> On 07/25/2018 05:18 AM, Tony Finch wrote:
>
>> I recommend having an empty public view of your private zone, so that
>> external queries succeed with NXDOMAIN / NODATA.
>>
>
> ACK.
>
> What is your opinion on blindly grafting the sub-domain onto the parent
> zone without proper
In article <9ac469b7-031a-4d8c-53d0-a82abca0d...@dcrocker.net>,
Dave Crocker wrote:
>On 7/25/2018 10:59 AM, Bob Harold wrote:
>> Dot "." has special meaning in DNS, so I would prefer:
>>
>> Â Â _ta-*
>>
>> Not regex, but a common wildcard usage.
>
>wfm.
I suppose. A plausible actual regex
On 07/25/2018 05:18 AM, Tony Finch wrote:
I recommend having an empty public view of your private zone, so that
external queries succeed with NXDOMAIN / NODATA.
ACK.
What is your opinion on blindly grafting the sub-domain onto the parent
zone without proper delegation. I.e. internal DNS
I like Bob's suggestion.
On Wed, Jul 25, 2018 at 2:06 PM, Dave Crocker wrote:
> On 7/25/2018 10:59 AM, Bob Harold wrote:
>
>> Dot "." has special meaning in DNS, so I would prefer:
>>
>> _ta-*
>>
>> Not regex, but a common wildcard usage.
>>
>
> wfm.
>
> anyone else care to chime in?
>
> d/
On 7/25/2018 10:59 AM, Bob Harold wrote:
Dot "." has special meaning in DNS, so I would prefer:
_ta-*
Not regex, but a common wildcard usage.
wfm.
anyone else care to chime in?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
On 7/25/2018 10:59 AM, Bob Harold wrote:
Dot "." has special meaning in DNS, so I would prefer:
_ta-*
Not regex, but a common wildcard usage.
wfm.
anyone else care to chime in?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
On Wed, Jul 25, 2018 at 1:50 PM Dave Crocker wrote:
> On 7/25/2018 2:32 AM, Mats Dufberg wrote:
> > _ta- should go into table 2 on page 9 of draft-ietf-dnsop-attrleaf.
>
>
> Wow. This is a unique case, since it reserves essentially all of an
> even-more-subordinate namespace -- everything to
> On Jul 25, 2018, at 10:09 AM, Paul Wouters wrote:
>
> If you do want all of that protected, which I don't think there are
> strong reasons for, why not place an OPENPGPKEY record in the zone and
> use pgp to sign it? No new custom software needed, and equally
> annoying validing the
On 7/25/2018 2:32 AM, Mats Dufberg wrote:
_ta- should go into table 2 on page 9 of draft-ietf-dnsop-attrleaf.
Wow. This is a unique case, since it reserves essentially all of an
even-more-subordinate namespace -- everything to the right of that dash.
Theoretically it isn't that
On Wed, 25 Jul 2018, Warren Kumari wrote:
One of the original promises of DNSSEC is that I'd be able to find a
zonefile written on a napkin on a bar floor, and trust it -- currently
I cannot do this.
That's a harder problem :P
As an example, let's say we'd like to distribute the rootzone
On 25 Jul 2018, at 12:30, Warren Kumari wrote:
> One of the original promises of DNSSEC is that I'd be able to find a
> zonefile written on a napkin on a bar floor, and trust it -- currently
> I cannot do this.
I don't think this is correct.
The main thrust of DNSSEC (as finally standardised)
On Sun, Jul 22, 2018 at 2:51 PM Paul Wouters wrote:
>
> On Fri, 20 Jul 2018, George Michaelson wrote:
>
> > The intent (to me at least) is to be able to use exterior fetch, *not*
> > DNS, to source this as a file. curl. wget. ncftp. rsync.
>
> So pull it over HTTPS/TLS and you are good? No bits
On Sun, Jul 15, 2018 at 9:21 AM wrote:
>
> 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 Attrleaf Changes: Fixing Specifications with
>
Changed milestone "IESG Appoval for dnssec-key-timing", resolved as "Done".
URL: https://datatracker.ietf.org/wg/dnsop/about/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
tjw> We discussed this and there appears to be support to adopt this,
tjw> with the caveat of adding more content to the section on
tjw> Operational Considerations.
[...]
tjw> Please review this draft to see if you think it is suitable for
tjw> adoption by DNSOP, and comments to the list,
/no/ changes to the spec, except to correct the typo Bob Harold spotted.
Correct?
On Wed, Jul 25, 2018 at 9:23 AM, Dave Crocker wrote:
>
> For completeness:
>
> Absent further discussion and agreement in the wg, I taking this
> exchange as producing /no/ changes to the spec.
>
> d/
>
>
>
For completeness:
Absent further discussion and agreement in the wg, I taking this
exchange as producing /no/ changes to the spec.
d/
On 7/24/2018 7:58 AM, John Levine wrote:
In article <9da145f4-df6a-4bfa-b3c9-56027b228...@iis.se> you write:
-=-=-=-=-=-
In table 2 on page 9, the
Grant Taylor wrote:
>
> Is there a best practice around this method of delegating to sub-domain(s)
> that are inaccessible to the public?
I recommend having an empty public view of your private zone, so that
external queries succeed with NXDOMAIN / NODATA. Returning REFUSED for a
private zone
On 24.7.2018 18:32, Tim Wicinski wrote:
>
> We discussed this and there appears to be support to adopt this, with
> the caveat of adding more content to the section on Operational
> Considerations.
>
>
> This starts a Call for Adoption for draft-bortzmeyer-rfc7816bis
>
> The draft is
RFC 8145 defines the _ta- node name:
A Key Tag query consists of a standard DNS query of type NULL and of
class IN [RFC1035].
The first component of the query name is the string "_ta-" followed
by a sorted, hyphen-separated list of hexadecimal-encoded Key Tag
values. The zone
On 24.7.2018 18:33, Tim Wicinski wrote:
> We discussed this and there appears to be support to adopt this, with
> the caveat of fleshing out some of the discussions which came up.
>
>
> This starts a Call for Adoption for draft-kh-dnsop-7706bis
I support adoption with caveat that it should
24 matches
Mail list logo
