On Tue, Jul 25, 2023 at 03:39:01PM -0700, Shumon Huque wrote:
> Viktor - your original suggestion was to only define the ENT sentinel
> instead of NXNAME. How would that solve the problem of systems and
> applications needing to precisely obtain the NXDOMAIN signal. Resolvers
> won't then be able
DNSOP,
Based on some discussions both in person at IETF 117 and on the list, we have
updated some of the requirements language for caching resolution failures.
We’ve also used an excerpt of Evan’s previous email to the list in the
Implementation Status section of the document. It would be nic
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Domain Name System
Operations (DNSOP) WG of the IETF.
Title : Negative Caching of DNS Resolution Failures
Authors : Duane Wessels
On Thu, Jul 27, 2023 at 2:49 PM Brian Dickson
wrote:
>
>
> On Tue, Jul 25, 2023 at 10:59 PM Viktor Dukhovni
> wrote:
>
>> On Tue, Jul 25, 2023 at 08:19:21PM -0700, Brian Dickson wrote:
>>
>> > At the name that does not exist, generate and sign (on the fly) a CNAME
>> > record with RDATA of somet
On Tue, Jul 25, 2023 at 10:59 PM Viktor Dukhovni
wrote:
> On Tue, Jul 25, 2023 at 08:19:21PM -0700, Brian Dickson wrote:
>
> > At the name that does not exist, generate and sign (on the fly) a CNAME
> > record with RDATA of something like "nxname.empty.as112.arpa" (or
> something
> > functionally
As a reminder, the (non-consensus) IETF definition of consensus is that
there all remaining technical objections have been addressed, or a decision
has been made not to address them. I think there are people reading this
who think this bad idea has some chance of actually happening. I don't
think t
Brian Dickson wrote:
> Top-reply (since there are already a bunch of threaded replies that might
> benefit from this):
> Queries are small, and have room in the first packet for EDNS (and often the
> resulting size will still be < 576).
> Idea:
> EDNS "signal" + bits -> tells server the client know
Please no. If we really want to stop fragmentation attacks just use well known
TSIG. This doesn’t require new code. It just requires configuration.
> On 28 Jul 2023, at 02:50, Brian Dickson wrote:
>
> Top-reply (since there are already a bunch of threaded replies that might
> benefit from
(I know I need to respond to some of the earlier DNSOP threads on compact
DoE etc, but I'm already tired from IETF week, so am giving my brain a
short break ..)
I was wondering if George Michaelson's musings on re-using 15-bits of
QDCOUNT were also just for fun :) But here's a post that is undeni
Top-reply (since there are already a bunch of threaded replies that might
benefit from this):
Queries are small, and have room in the first packet for EDNS (and often
the resulting size will still be < 576).
Idea:
EDNS "signal" + bits -> tells server the client knows about the new meaning
of the 15
On 7/26/23, 4:11 PM, "DNSOP on behalf of George Michaelson"
wrote:
>
>if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in
>the header.
I don't think you can repurpose them.
One concern is backwards compatibility - code in place now wouldn't understand.
The practice of
11 matches
Mail list logo
