On 7/30/24 19:40, John Levine wrote:
It appears that Shumon Huque said:
-=-=-=-=-=-
Thank you Michael,
Your observation is certainly true. However, I want to point out that
inability to
synthesize NXDOMAIN via aggressive negative caching applies to any online
signing scheme that uses minim
On 7/30/24 19:22, Shumon Huque wrote:
Thank you Michael,
Your observation is certainly true. However, I want to point out that
inability to
synthesize NXDOMAIN via aggressive negative caching applies to any online
signing scheme that uses minimally covering NSEC, not just Compact DoE.
Yes,
I have also added a nit (as an Issue) to the github repo for this doc,
as I'd like the authors consider explicitly stating that the inability
for resolvers to synthesize NXDOMAIN responses for zones using this CDoE
mechanism can make certain DOS attacks (e.g. Water Torture) more
effective than
On 9/5/19 2:07 PM, Paul Vixie wrote:
sam weiler argued unsuccessfully that trust should not be required to follow
the delegation path, and with a decade or more of perspective i can see that
he was right. however, DLV as specified and implemented would not be the
mechanism i'd propose if non-hie
WG and outside. I think the document is ready to go,
pending resolution of the various nits identified in the Genart review.
Michael Sinatra
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 3/13/19 6:17 PM, Stephen Farrell wrote:
> Those seem like unrelated (and repetitive) points, except for your
> attempt to try equate (I assume) a browser using DoH with malware.> That's
> the kind of overblown statement that detracts from any other
> reasonable points you may make (for me a
On 3/13/19 1:43 PM, Stephen Farrell wrote:
>
> (dropping dprive list at WG chair request)
>
> Hiya,
>
> On 13/03/2019 20:29, Brian Dickson wrote:
>> The starting place for the conversation needs to acknowledge this, and
>> accommodate it. It is entirely possible that a DoH client that doesn't do
I realize you're responding to Paul, but your message below did pique
(in a good way) my thinking and the distinction in my mind, as an
operator, between DoH and DoT (and other forms of encrypted
communication). I am top-posting intentionally because I am responding
to your entire message.
I supp
On 3/12/19 9:14 AM, Jim Reid wrote:
>
>
>> On 12 Mar 2019, at 16:01, Stephane Bortzmeyer wrote:
>>
>> I still do not understand why people have a problem with DoH whch did
>> not already exist before with my-own-name-resolution-protocol-over-HTTPS.
>
> It’s a question of scale/ubiquity. These
Section 8 - Acknowledgements:
"We wish to thank Michael Sinatra, Roland van Rijswijk-Deij, Olafur
Gudmundsson, Paul Hoffman and Evan Hunt for their imminent feedback."
Paraphrasing one of my colleagues, is the part about "imminent feedback"
a prediction, or a hint that we
On 03/27/18 10:22, Paul Hoffman wrote:
> On 27 Mar 2018, at 10:21, Michael Sinatra wrote:
>
>> My goal is to basically avoid confusion and just tell people to use the
>> strongest algorithm they can reasonably use. I.e. follow the CNSA
>> recommendations and don't
On 03/27/18 05:43, Paul Hoffman wrote:
> On 26 Mar 2018, at 17:30, Michael Sinatra wrote:
>
>> I am a bit uncomfortable with the document's disrecommendation of SHA384
>> and ECDSAP384SHA384. The main reason for this is that for crypto
>> recommendations here in
On 03/22/18 08:08, Ondřej Surý wrote:
> * Separate operational recommendations for default algorithm to
> ECDSAP256SHA256
> * Deprecation of ECC-GOST (that actually happened elsewhere, so we reflect it
> here)
>
> I also squeezed paragraph about DS algorithm upgrade to operational
> consider
On 3/19/18 11:14 AM, Jim Reid wrote:
On 19 Mar 2018, at 18:09, Artyom Gavrichenkov wrote:
Another issue here is that, for some enterprises at least, there's no
single "internal network" anymore.
We don't need to enumerate every potential split DNS scenario (or how it's implemented).
The o
On 3/25/15 3:37 PM, Tim Wicinski wrote:
>
> Speaking for myself, I love Evan's idea with picking one rrset. It is
> simple. Would the simplest be to grab the first rrset it finds?
I think that's the simplest solution. If you instead pick a record to
return beforehard, (e.g. A), then what if the
On 03/18/15 01:11, Michael Sinatra wrote:
> I think there are a few issues at play. google and other public
> recursives will sometimes have multiple backend servers fetch a given RR
> when they receive a single query for that RR on one instance of, say,
> 8.8.8.8. I am basing
On 03/16/15 23:31, Paul Vixie wrote:
> removing dns-operations@ as a cc. one mailing list at a time, please?
Sorry, saw this response late...
> Michael Sinatra wrote:
>> On 3/16/15 4:15 PM, P Vixie wrote:
>>> > Michael, what attacks do you think we can st
On 3/17/15 6:17 AM, Yunhong Gu wrote:
> > Sounds to me this is the root cause of the problem and ANY is the just a
> > scapegoat.
>
> Giving NSEC3PARAM a positive TTL would prevent my headache, but it
> wouldn't help the victim of the attack, and would probably make it worse
>
On 03/16/15 18:07, Yunhong Gu wrote:
>
>
> On Mon, Mar 16, 2015 at 8:50 PM, Michael Sinatra <mailto:mich...@brokendns.net>> wrote:
>
> On 3/16/15 4:15 PM, P Vixie wrote:
> >
> >
> > On March 17, 2015 7:42:09 AM GMT+09:00, Micha
On 3/16/15 4:15 PM, P Vixie wrote:
>
>
> On March 17, 2015 7:42:09 AM GMT+09:00, Michael Sinatra
> wrote:
>>
>>
>> On 03/16/15 07:23, bert hubert wrote:
>>
>>> Separately, I fail to see why we actually need to outlaw ANY queries
>> when
20 matches
Mail list logo
