On Thu, May 2, 2024 at 6:44 AM John Levine wrote:
> It appears that Philip Homburg said:
> >In your letter dated Thu, 2 May 2024 10:27:17 +0200 you wrote:
> >>I'm not following what breaks based on the wording I suggested, and I'm
> not su
> >>re why you keep bringing that up. :-)
> >
> >Then a
On Thu, May 2, 2024 at 7:32 AM John R Levine wrote:
> MUST NOT is advice on how to interoperate, not on how to write software
> tools. It's up to the zone operator to follow the advice, not to the tool
> provider to hold them hostage.
>
??? RFC 8624 is explicitly guidance to implementers not o
On Thu, May 2, 2024 at 9:19 AM John R Levine wrote:
> On Thu, 2 May 2024, Scott Morizot wrote:
> > ??? RFC 8624 is explicitly guidance to implementers not operators. The
> > "MUST NOT" means MUST NOT implement in a conforming implementation of
> > either signing
On Thu, May 2, 2024 at 11:38 AM John R Levine wrote:
> I think we're agreeing that it would be a good idea to continue to
> discourage SHA1, but not a good idea to surprise people by making it
> suddenly stop working, a la Redhat.
>
Yep. Conceptually I agree with that. I also realized its inhere
Ah. Should have used the Oxford comma for clarity. I'm normally one of the
people who always uses it so that was probably an accidental omission.
There should be a comma before that last 'and'. I was describing the three
possible states for any query and response. We have all three scenarios in
pro
On Mon, Jun 15, 2020 at 12:59 PM Tim Wicinski wrote:
> On Mon, Jun 15, 2020 at 1:48 PM John Levine wrote:
>
>> In article <
>> cah1iciouffmryorewhhtbqfnnserw3rvups8pzc8cvnehys...@mail.gmail.com> you
>> write:
>> >E.g. use an FQDN belonging to you (or your company), so the namespace
>> would
>> >
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 delegat
I guess I'll speak up as someone who has been managing the DNS/DNSSEC
design and implementation of a large organization with a complex set of DNS
requirements (operational and security-related) since we began the process
of signing our zones in 2011. We have universal DNSSEC validation in place
acr
this draft. I'm not sure I understand
the rationale behind Informational as opposed to Proposed Standard, but if
the IETF wishes to have any input on the mechanism, this would seem to be
the place to discuss it. I'm in favor of adopting it as a working group
draft.
Scott Morizot
On Wed,
On Sat, Apr 4, 2015 at 12:28 AM, Ralf Weber wrote:
> Yes. I used the term hidden primary in the past, and technically there
> would be no reason for a setup hidden primary -> primary -> secondaries, as
> you have two single point of failure (SPOF) there. I wouldn't deploy that.
> For me these wor
10 matches
Mail list logo
