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
I'm sorry to hear that. I would like to provide some information as a
background if it's useful.
dns-wireformat-http draft was originally proposed in DNSOP WG as a
experimental draft in early 2016. We focus on the requirement of enhancing
DNS availability bypassing the middlebox on the path via HT
>
> 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
Martin Thomson writes:
> Right now, abandon draft-ietf-dnsop-dns-wireformat-http. But I'll
> concede that I'm probably missing something.
I think that's right. -05 with the original_transport optional
parameter accommodates the aims of that other draft.
_
On Apr 3, 2018, at 21:32, Frederico A C Neves wrote:
>> On Tue, Apr 03, 2018 at 02:37:12PM +0200, Matthijs Mekking wrote:
>> Hi Frederico,
>>
>>> On 03/29/2018 08:45 PM, Frederico A C Neves wrote:
>>> I was looking at our server to evaluate the MIXFR implementation and
>>> it seams to me that th
On Tue, Apr 3, 2018 at 11:27 PM, Paul Hoffman wrote:
> Martin: Are you saying that you want DOH to remove the optional parameter
> from the application/dns-udpwireformat registration? If so, what do you
> propose for the DNSOP WG?
Right now, abandon draft-ietf-dnsop-dns-wireformat-http. But I'
> 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 3 April 2018 at 17:58, Martin Thomson wrote:
> If I understand your response (not sure that I do), that seems pretty
> academic and not at all persuasive. For instance, if a client cared
> about testing TCP capabilities, it can always do its own resolution.
It's not the emphasis. Peopole ge
Hi Matthijs,
On Tue, Apr 03, 2018 at 02:37:12PM +0200, Matthijs Mekking wrote:
> Hi Frederico,
>
> On 03/29/2018 08:45 PM, Frederico A C Neves wrote:
> > I was looking at our server to evaluate the MIXFR implementation and
> > it seams to me that the current text covering dnssec aware client
> >
> 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
Greetings dnsop,
This draft proposes a technique and new RR type for calculating and verifying a
message digest over the contents of a zone file. Using this technique, the
recipient of a zone containing the new RR type can verify it for completeness
and correctness, especially so when the zone
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 Apr 3, 2018, at 1:00 PM, Dave Lawrence wrote:
> That testing TCP capabilities part is a distraction from the core
> motivation. The request makes sense from a dumb transparent proxy
> point of view, where there's a regular DNS resolver on the one end who
> just wants to be able to get DNS mess
Martin Thomson writes:
> If I understand your response (not sure that I do), that seems pretty
> academic and not at all persuasive. For instance, if a client cared
> about testing TCP capabilities, it can always do its own resolution.
That testing TCP capabilities part is a distraction from the
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 03-04-18 15:22, Mark Andrews wrote:
-- Mark Andrews
On 3 Apr 2018, at 22:37, Matthijs Mekking
wrote:
Hi Frederico,
On 03/29/2018 08:45 PM, Frederico A C Neves wrote: I was looking
at our server to evaluate the MIXFR implementation and it seams
to me that the current text covering dnssec
On Apr 3, 2018, at 2:58 AM, Martin Thomson wrote:
>
> If I understand your response (not sure that I do), that seems pretty
> academic and not at all persuasive.
to you. It was persuasive enough for the DNSOP WG to adopt the document as
a WG item.
> For instance, if a client cared
> abou
--
Mark Andrews
> On 3 Apr 2018, at 22:37, Matthijs Mekking wrote:
>
> Hi Frederico,
>
>> On 03/29/2018 08:45 PM, Frederico A C Neves wrote:
>> I was looking at our server to evaluate the MIXFR implementation and
>> it seams to me that the current text covering dnssec aware client
>> logic d
Hi Frederico,
On 03/29/2018 08:45 PM, Frederico A C Neves wrote:
I was looking at our server to evaluate the MIXFR implementation and
it seams to me that the current text covering dnssec aware client
logic don't take in account that a posterior record at the addition
section, by an MIXFR DNSSEC
If I understand your response (not sure that I do), that seems pretty
academic and not at all persuasive. For instance, if a client cared
about testing TCP capabilities, it can always do its own resolution.
On Tue, Apr 3, 2018 at 7:44 PM, Davey Song wrote:
>
>
> On 3 April 2018 at 15:33, Martin
On 3 April 2018 at 15:33, Martin Thomson wrote:
> This is intended to do what? Indicate where the response came from?
> Why does the client care?
To keep the proxy (API client and server) transparent and bypass the
middlebox along the path. Without the indicate, the API server has no clue
what
> 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: "
On 03/04/2018 08:33, Martin Thomson wrote:
> This is intended to do what? Indicate where the response came from?
> Why does the client care? I assume that it doesn't apply to
> requests, or that would get into draft-bellis-dnsop-xpf territory.
I think there's some overlap here, if the intent of
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
This is intended to do what? Indicate where the response came from?
Why does the client care? I assume that it doesn't apply to requests,
or that would get into draft-bellis-dnsop-xpf territory.
BTW, you really need to drop UDP from the media type name now.
application/dns-udpwireformat;original
36 matches
Mail list logo
