> On 13 Oct 2021, at 05:24, Viktor Dukhovni wrote:
>
> On Sat, Oct 09, 2021 at 07:18:58AM +1100, Mark Andrews wrote:
>
>> Yes it will be unfiltered but the point of DNSSEC is to filter out bad
>> answers (that is what the ignore bogus responses achieves) and if you
>> are behind a recursive
On Sat, Oct 09, 2021 at 07:18:58AM +1100, Mark Andrews wrote:
> Yes it will be unfiltered but the point of DNSSEC is to filter out bad
> answers (that is what the ignore bogus responses achieves) and if you
> are behind a recursive server you need it to do the filtering of the
> answers it gets
On 07/10/2021 08:52, Mark Andrews wrote:
DNSSEC will work reasonably well if the upstream are just DNSSEC aware (keep the
RRSIGs with the data they cover, pass through negative proofs required for
the answers) if there is not spoofed traffic, a mix of DNSSEC aware and DNSSEC
oblivious server for
Thanks for the explanation. That's super helpful.
-Ekr
On Fri, Oct 8, 2021 at 1:19 PM Mark Andrews wrote:
>
>
> Yes it will be unfiltered but the point of DNSSEC is to filter out bad
> answers (that is what the ignore bogus responses achieves) and if you are
> behind a recursive server
Yes it will be unfiltered but the point of DNSSEC is to filter out bad answers
(that is what the ignore bogus responses achieves) and if you are behind a
recursive server you need it to do the filtering of the answers it gets as you
aren’t in a position to wait for the good answer as they
Hi Mark,
Thanks for your response.
On Wed, Oct 6, 2021 at 7:41 PM Mark Andrews wrote:
> You should also note that a validating stub resolver (or anything talking
> through a validating resolver) should be prepared to send *both* DO and
> DO+CD queries. There are different error conditions /
> On 8 Oct 2021, at 02:44, Andrew Sullivan wrote:
>
> Still speaking only for myself :)
>
> On Thu, Oct 07, 2021 at 02:49:53PM +1000, George Michaelson wrote:
>>> if there's ever been explicit protocol requirement of this, I have
>>> forgotten it.
>>
>> Sorry, but I think this is just an
Still speaking only for myself :)
On Thu, Oct 07, 2021 at 02:49:53PM +1000, George Michaelson wrote:
if there's ever been explicit protocol requirement of this, I have forgotten it.
Sorry, but I think this is just an over-reach. There is no necessary
reason for a single information model to
On Wed, 2021-10-06 at 16:47 -0700, Eric Rescorla wrote:
> Hi folks,
>
> We've been trying to take some measurements of the success of endpoint
> DNSSEC validation and run into some confusion about the implications
> of the DO and CD bits. Sorry if these are dumb questions.
Not dumb questions!
>
On Oct 7, 2021, at 10:43, Brian Dickson wrote:
>> Do you mean reliably determine if a resolver is claiming to validate, or
>> reliably determine whether a resolver is actually validating?
>>
> Claiming… if the answer is that it is not claiming that, it might simplify
> some parts of the logic
Sent from my iPhone
> On Oct 7, 2021, at 12:55 AM, Joe Abley wrote:
>
> On Oct 7, 2021, at 09:49, Brian Dickson
> wrote:
>
>> Quick question in a top-reply, sorry:
>> Mark:
>> Is there any combination of flag bits or EDNS options that a stub can use to
>> reliably determine if a resolver
On Oct 7, 2021, at 09:49, Brian Dickson wrote:
> Quick question in a top-reply, sorry:
> Mark:
> Is there any combination of flag bits or EDNS options that a stub can use to
> reliably determine if a resolver is validating?
Do you mean reliably determine if a resolver is claiming to validate,
Quick question in a top-reply, sorry:
Mark:
Is there any combination of flag bits or EDNS options that a stub can use
to reliably determine if a resolver is validating?
Obviously there are clever tricks possible, such as sending queries to a
small set of domains that identify whether resolvers
> On 7 Oct 2021, at 15:49, George Michaelson wrote:
>
>> First of all, it is apparent that if a resolver maintains a unified cache in
>> which it has DNSSEC-aware and DNSSEC-oblivious data, things will definitely
>> break. The general wisdom appears to be that you need to maintain two
>>
> First of all, it is apparent that if a resolver maintains a unified cache in
> which it has DNSSEC-aware and DNSSEC-oblivious data, things will definitely
> break. The general wisdom appears to be that you need to maintain two
> caches, and only answer DO-set queries with DO-set cache (or go
Hi,
Disclaimer: I work for the Internet Society but am speaking for myself.
On Wed, Oct 06, 2021 at 04:47:32PM -0700, Eric Rescorla wrote:
Sorry if these are dumb questions.
They are not dumb questions, unfortunately.
Looking at things from the stub resolver's perspective, if the zone is
You should also note that a validating stub resolver (or anything talking
through a validating resolver) should be prepared to send *both* DO and
DO+CD queries. There are different error conditions / threats that are
mitigated by each of these settings and only by trying the other on error
can you
Hi EKR -
Your table looks correct and hope.
You may want to take a look at section 5.9 of RFC 6840, as well as
appendix B as there's some implementation guidance with respect to the
setting of the CD bit.
Mike
On 10/6/2021 7:47 PM, Eric Rescorla wrote:
Hi folks,
We've been trying to
Hi folks,
We've been trying to take some measurements of the success of endpoint
DNSSEC validation and run into some confusion about the implications
of the DO and CD bits. Sorry if these are dumb questions.
In the section on stub resolvers RFC 4035 says:
A validating security-aware stub
19 matches
Mail list logo
