Hi, Joe,
Please allow me to interject, on a few different issues from this thread…
Sent from my iPhone
> On Aug 12, 2021, at 4:39 PM, Joe Abley wrote:
>
> Hi Paul,
>
>> On 12 Aug 2021, at 15:48, Paul Wouters wrote:
>>
>> On Thu, 12 Aug 2021, Joe Abley wrote:
>>
This would have been
A new meeting session request has just been submitted by Tim Wicinski, a Chair
of the dnsop working group.
-
Working Group Name: Domain Name System Operations
Area Name: Operations and Management Area
Session Requester: Tim Wicinski
On Aug 12, 2021, at 16:53, Paul Wouters wrote:
> On Thu, 12 Aug 2021, Joe Abley wrote:
>
>> I think the set of acceptable algorithms is constrained sufficiently often
>> by registries and registrars that it makes little sense to consider any
>> other case.
>
> I think this problem is more
On Thu, 12 Aug 2021, Joe Abley wrote:
I think the set of acceptable algorithms is constrained sufficiently often by
registries and registrars that it makes little sense to consider any other case.
I think this problem is more easilly solved. You can reach out to them.
So my own order of
Hi Paul,
On 12 Aug 2021, at 15:48, Paul Wouters wrote:
> On Thu, 12 Aug 2021, Joe Abley wrote:
>
>>> This would have been excellent to do when we did DS. It would still be
>>> good to do this now, I agree. But it would be too late for some of the
>>> things discussed now.
>>
>> Can you talk
On Thu, 12 Aug 2021, Joe Abley wrote:
This would have been excellent to do when we did DS. It would still be
good to do this now, I agree. But it would be too late for some of the
things discussed now.
Can you talk more about why you think so?
I did a small presentation during IETF 111
Sent from my iPhone
> On Aug 12, 2021, at 12:21 PM, John Levine wrote:
>
> It appears that Brian Dickson said:
>> -=-=-=-=-=-
>>
>> This is the work I will be submitting in DNSOP.
>>
>> This is what has been described as a “hack”, but provides a needed
>> validation link for
On Aug 12, 2021, at 10:57, Paul Wouters wrote:
> On Thu, 12 Aug 2021, Olafur Gudmundsson wrote:
>
>> The DS record is a unique record that it lives only at the parent side of
>> delegation, when DNS was defined no such records were
>> envisioned, if more are needed this working should take up
It appears that Brian Dickson said:
>-=-=-=-=-=-
>
>This is the work I will be submitting in DNSOP.
>
>This is what has been described as a “hack”, but provides a needed validation
>link for authoritative servers where the latter are in
>signed zones, but where the served zones may not be
On Thu, 12 Aug 2021, Olafur Gudmundsson wrote:
IMHO the ONLY benefit of it is to encourage DS record overloading with random
data that has no DNSSEC relevance, leading to abuse that
threatens to turn the DS record into the new TXT overloading record resulting
in large DS sets.
Not the
> On Aug 4, 2021, at 11:29 AM, Tim Wicinski wrote:
>
>
> All
>
> This starts a Working Group Last Call for draft-ietf-dnsop-dnssec-iana-cons
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-iana-cons/
>
Some things I noticed:
* Section 6.1 -- the semantics of 'no-default-alpn' are not actually specified
anywhere, as far as I can see; the reader has to infer them from context.
* Section 8 -- 'This section specifies the mapping for HTTPS and HTTP.' It
would be good if the HTTP Semantics
Hello,
I read draft-dickson-dnsop-ds-hack-00 and it proposes that
- it assign three new DNSKEY algorithms (alg_ns, alg_A, alg_)
- it generate 3 new DS RRs for all parent side NS RR and glue (A/)
It will increase DS reponse 48bytes * 3 = 144 bytes. (in case of digest type 2)
owner
13 matches
Mail list logo
