On 4.4.2018 07:12, Geoff Huston wrote:
>>>
>>>
>>> All of the following conditions must be met to trigger special
>>> processing inside resolver code:
>>>
>>> o The DNS response is DNSSEC validated
>>>
>>> o The result of validation is “Secure”.
>>>
>>> o The Checking Disabled (CD) bit in the qu
>>
>>
>> All of the following conditions must be met to trigger special
>> processing inside resolver code:
>>
>> o The DNS response is DNSSEC validated
>>
>> o The result of validation is “Secure”.
>>
>> o The Checking Disabled (CD) bit in the query is not set.
>>
>> o The QTYPE is eithe
> On 4 Apr 2018, at 2:30 pm, Geoff Huston wrote:
>
>
>
>>
>> No. Below is self contradictory. Condition 1 requires that
>> CD=1 be turned into CD=0 and condition 3 requires that no special
>> processing happens for CD=1.
>>
>> How CD is handled determines what you are testing when you have
>
> No. Below is self contradictory. Condition 1 requires that
> CD=1 be turned into CD=0 and condition 3 requires that no special
> processing happens for CD=1.
>
> How CD is handled determines what you are testing when you have
> resolvers in series.
>
> Do you want CD=1 to disable special
> On 4 Apr 2018, at 11:17 am, Geoff Huston wrote:
>
>> On 4 Apr 2018, at 10:59 am, Mark Andrews wrote:
>>
>>
>>> On 4 Apr 2018, at 10:28 am, Geoff Huston wrote:
>>>
>>> I thought that if the query contained CD = 1 then the DNS response
>>> would not be validated,
>>
>> This ONLY applies if
> On 4 Apr 2018, at 10:59 am, Mark Andrews wrote:
>
>
>> On 4 Apr 2018, at 10:28 am, Geoff Huston wrote:
>>
>> I thought that if the query contained CD = 1 then the DNS response
>> would not be validated,
>
> This ONLY applies if the answer is NOT ALREADY CACHED. If the answer
> is already
> On 4 Apr 2018, at 10:28 am, Geoff Huston wrote:
>
> I thought that if the query contained CD = 1 then the DNS response
> would not be validated,
This ONLY applies if the answer is NOT ALREADY CACHED. If the answer
is already cached then CD=1 queries will get this processing as the
answer ret
I thought that if the query contained CD = 1 then the DNS response
would not be validated, and precondition 1 would not be met.
But I’m probably wrong, so could you please suggest wording here?
regards,
Geoff
> On 4 Apr 2018, at 10:21 am, Mark Andrews wrote:
>
> You are effectively saying th
You are effectively saying that the resolver MUST ignore CD=1 for these queries.
> On 4 Apr 2018, at 7:36 am, Geoff Huston wrote:
>
>
>
>> On 4 Apr 2018, at 7:11 am, Paul Hoffman wrote:
>>
>> On 3 Apr 2018, at 13:45, Geoff Huston wrote:
>>
>>> Is the wording “that the resolver has to do DNS
> On 4 Apr 2018, at 7:11 am, Paul Hoffman wrote:
>
> On 3 Apr 2018, at 13:45, Geoff Huston wrote:
>
>> Is the wording “that the resolver has to do DNSSEC validation on what it
>> gets back from the authoritative server *regardless* of whether the
>> originating client requests it?” a clarifi
On 3 Apr 2018, at 13:45, Geoff Huston wrote:
Is the wording “that the resolver has to do DNSSEC validation on
what it gets back from the authoritative server *regardless* of
whether the originating client requests it?” a clarification that
updates the validation behaviours as specified in RFC4
> On 3 Apr 2018, at 11:42 pm, Paul Hoffman wrote:
>
>
> On 3 Apr 2018, at 1:34, Geoff Huston wrote:
>
>> I’ll remove the condition then.
>
> Will you re-instate what Petr asked for, namely some wording that indicates
> that the resolver has to do DNSSEC validation on what it gets back from
On Tue, Apr 3, 2018 at 12:12 PM, Evan Hunt wrote:
> On Tue, Apr 03, 2018 at 04:08:46PM +, Evan Hunt wrote:
>> "dig +noends +noadflag" will produce such a query, if you want to try
>> it out.
>
> +noedns, rather.
>
> The edns does not justify the means.
Awgh
W
>
> --
> Evan Hunt -- e
On Tue, Apr 03, 2018 at 04:08:46PM +, Evan Hunt wrote:
> "dig +noends +noadflag" will produce such a query, if you want to try
> it out.
+noedns, rather.
The edns does not justify the means.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
On Tue, Apr 03, 2018 at 06:32:49PM +1000, Geoff Huston wrote:
> So this text is saying that the AD bit is set if the resolver considers all
> RRsets in the Answer section to be authentic. Fair enough.
More correctly, the bit is cleared if the resolver *doesn't* consider all
RRsets to be validly si
On 3 Apr 2018, at 1:34, Geoff Huston wrote:
I’ll remove the condition then.
Will you re-instate what Petr asked for, namely some wording that
indicates that the resolver has to do DNSSEC validation on what it gets
back from the authoritative server *regardless* of whether the
originating c
> On 3 Apr 2018, at 5:38 pm, Mark Andrews wrote:
>
> AD is only set or potentially set in the response if DO or AD is set on the
> query.
>
> The condition boils down to testing for AD or DO in the query because the
> answer needs to be secure and there can’t be a CNAME or DNAME pointing to
> On 3 Apr 2018, at 4:39 pm, Geoff Huston wrote:
>
>
>
>> On 3 Apr 2018, at 1:10 pm, Mark Andrews wrote:
>>
>> Do we really want to test for AD? How many stub resolvers set DO or AD to
>> elicit a AD response?
>>
>
> I’m not sure that we are on the same page here. The precondition is: "
AD is only set or potentially set in the response if DO or AD is set on the
query.
The condition boils down to testing for AD or DO in the query because the
answer needs to be secure and there can’t be a CNAME or DNAME pointing to it.
About the only way it to not have a AD would be for there t
> On 3 Apr 2018, at 1:10 pm, Mark Andrews wrote:
>
> Do we really want to test for AD? How many stub resolvers set DO or AD to
> elicit a AD response?
>
I’m not sure that we are on the same page here. The precondition is: "The AD
bit is to be set in the response” i.e. it is not a test on
Do we really want to test for AD? How many stub resolvers set DO or AD to
elicit a AD response?
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
DNSOP mailing
21 matches
Mail list logo
