I am generally skeptical of the idea that we should write recommendations that
are "for enterprise". The notion of "enterprise" is too slippery for technical
standards. Enterprises are also technically integrated by definition, so they
are less reliant on technical standards than multi-party a
Il lun 22 lug 2024, 11:00 Scott Johnson ha
scritto:
>
> Please find the draft here:
> https://datatracker.ietf.org/doc/draft-johnson-interplanetary-dns/
I don't like (I may be missing something) the way this system permits the
same name to refer to different resources on different planets. It w
Reviewer: Dale Worley
Review result: Ready
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information
> On Jul 18, 2024, at 11:03 AM, Petr Špaček wrote:
>
> Caution: This email originated from outside the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
> On 18. 07. 24 17:28, Shane Kerr wrote:
>> Petr,
>> On 18/07/2024 17.
Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-zoneversion-10: Yes
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 to
https:/
Hey Ben,
Thank you for reading the draft and your comments.
I agree we would not need a draft for saying mTLS works as expected. This draft
is saying something different: "mTLS is the way one should auth clients to
encrypted DNS servers for many reasons, cross-protocol use among them." The
cos
mTLS might be the most pragmatic approach today in many situations, but I don't
think we can recommend it in the way that this draft would. It has some
significant downsides, especially when compared against something like OAuth
(which might integrate better with user account systems) or Privac
Yes, I concur, and good catch Ondrej.
The authors will use IP addresses from the example/documentation prefixes
in the next revision of the draft.
Shumon.
On Mon, Jul 22, 2024 at 2:07 PM Ondřej Surý wrote:
> This is a nit, but an important one. The draft uses IP addresses that
> are not from t
I think mTLS (client certs) makes sense as a recommendation in
draft-tjjk-cared, but is critical to call out the privacy issues with TLS
client certs in TLS versions prior to TLS 1.3. (ie, in TLS 1.2 and before
the client certificates are sent in-the-clear in the handshake unless
renegotiation is
Hi Scott,
FTR .arpa is not "reverse DNS", only the in-addr.arpa and ipv6.arpa is.
.arpa now stands for Address and Routing Parameter Area, and there are
more subdomains than just these two mentioned above.
Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org
My working hours and your working hours may
Hi Bryce,
Interesting. This is the second reply which wishes to use reverse DNS in
this fashion, the first being from Rick Taylor. The thing is, reverse DNS
is not exactly a user facing function. One goal of this effort is to
allow interoperability across worlds with a similar user experien
Hi Ben,
On Mon, 22 Jul 2024, Ben Schwartz wrote:
This document seems to propose that "https" URLs will route through
"route through" is exactly what is not happening here. https will be
secure to the edge of the IP network, which is the limit of the local IP
transaction.
gateways that t
This is a nit, but an important one. The draft uses IP addresses that
are not from the EXAMPLE-NET (and friends). Also I would suggest
to use example IPv6 addresses () in the draft instead of the
Legacy IP addresses (A) (e.g. RFC 3849).
Please don't do that, 100.1.1.1 belongs to Verizon Busin
This document seems to propose that "https" URLs will route through gateways
that terminate end-to-end security, destroying the "https" scheme's
confidentiality and integrity properties. That's a red flag for me.
Rather than trying to retrofit compatibility with existing terrestrial
protocols
Roy
That is on Thursday Agenda. Sorry for the mixuyp
On Mon, Jul 22, 2024 at 3:47 PM Roy Arends wrote:
> I saw this on the agenda for this afternoon.
>
> The proposed solution against zone-walking is to exclude names from an
> nsec chain.
>
> Example, say "B" needs to kept private from zone-wa
For those lacking context on "aggressive negative caching", see
https://datatracker.ietf.org/doc/rfc8198/
--Ben Schwartz
From: Roy Arends
Sent: Monday, July 22, 2024 3:45 PM
To: dnsop
Subject: [DNSOP] Response to draft-fbw-dnsop-dnszonehop
I saw this on the age
I saw this on the agenda for this afternoon.
The proposed solution against zone-walking is to exclude names from an nsec
chain.
Example, say "B" needs to kept private from zone-walking, so have:
A.example. NSEC C.example.
B.example. A 192.168.10.10
C.example. NSEC ...
This is a terrible idea.
Just spitballing, but instead of a new TLD, what about
"{earth,moon,mars}.sol.arpa" as your suffix?
This seems like it's right in the wheelhouse of the "Address Resolution
Parameter Area"...
https://en.wikipedia.org/wiki/.arpa
[Forest Service Shield]
Bryce Nordgren, FRIT
Physical Scientist
This addresses a gap in the DNSSEC specification. DS records need to identify
specific DNSSEC algorithms rather than a set of DNSSEC algorithms.
> Begin forwarded message:
>
> From: internet-dra...@ietf.org
> Subject: New Version Notification for
> draft-andrews-private-ds-digest-types-00.txt
Hi Ben
On Mon, Jul 22, 2024 at 09:40:02AM +, Ben wrote:
> > > I think we should not focus to much specificly on how BIND handles
> > > things
> > > with $ORIGIN. I'm talking about the concept of zones in general. For
> >
> > $ORIGIN is from RFC 1035, for any implementation that supports maste
Hi Mukund,
Thank you for your response. My reponse is inline:
Mukund Sivaraman schreef op 2024-07-22 09:19:
Hi Ben
I've read through the draft quickly. While I don't want you to feel
discouraged, I have a negative opinion of this idea.
(a) This draft is a little confusing without making assum
Hi Ben
I've read through the draft quickly. While I don't want you to feel
discouraged, I have a negative opinion of this idea.
(a) This draft is a little confusing without making assumptions. It
should clearly mention that the relative labels are for name
representation in DNS messages. The draf
>I meant this to be in response to Ben's concern about potential malicious use,
> in which case 99% idling and other normal-use scenarios don't seem to be appl
>icable.
The point of dry-run is to get a statistical sample of failures. If all of
those mostly idle resolver can validate the domain, th
Hi Everyone,
Sorry for the 4-way cross posting, but I wanted to reach all of those
parties who may have interest.
I have published an internet-draft version of a document I have been
privately publishing, in order that the community may understand, pick
apart, improve, and fill in the blanks
Joe Abley schreef op 2024-07-21 23:44:
On 21 Jul 2024, at 15:54, Edward Lewis
wrote:
I don’t think there’s any good to come from shrinking an in-memory
size of the zone this way. Saving space, sure, but I don’t think the
cost in code complexity will favorable.
This sounds right to me.
Oh,
Hi Edward,
My response inline:
Edward Lewis schreef op 2024-07-21 22:53:
The draft reads very different than the email message. The draft
sticks to a protocol definition while the email describes a use case.
This difference is significant.
Wow, that should not be the case. I tried not to men
26 matches
Mail list logo
