Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error

From: Tony Finch <[email-masked]>
Date: Wed, 2 Aug 2017 15:12:37 +0100

Viktor Dukhovni <[email-masked]> wrote:
> On Mon, Jul 31, 2017 at 05:11:07PM +0000, Evan Hunt wrote:
>
> > Are there applications specifically trusting AD=1 and behaving differently
> > than with AD=0?
>
> On Mon, Jul 31, 2017 at 02:16:37PM -0400, Paul Wouters wrote:
>
> > Postfix is one but last I knew only when resolv contains localhost.
>
> Not only Postfix, also Exim, and perhaps also Sendmail some day
> if/when DANE support appears there,

And ssh can be configured to use the AD bit for SSHFP authentication.
There are a few alternatives for ssh + DNSSEC and they interact in ways
that are not always ideal - see http://fanf.livejournal.com/130577.html

> The AD bit is exactly the right DNSSEC interface.  All that's
> missing from the traditional libresolv (and not missing from recent
> innovations in res_ninit(), res_nsearch(), ...) is the ability to
> specify the loopback address as the sole resolver in the application.

Yep.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Forties, Cromarty: South 3 or 4, backing east 5 or 6, becoming cyclonic, then
southwest 4 or 5 later. Slight becoming moderate. Rain or showers. Moderate or
good.

---

From: 神明達哉 <[email-masked]>
Date: Thu, 3 Aug 2017 11:29:32 -0700

At Sat, 29 Jul 2017 14:27:57 +0100,
Tony Finch <[email-masked]> wrote:

> > - One possible idea of another extended error code: one that indicates
> >   a type-ANY query is responded with just one type of RRset when there
> >   can be more.
>
> Note that it is almost always the case that ANY answers from
> non-authoritative servers are a subset of the records :-)
>
> And it seems difficult for a cache to determine when to use this extended
> error code. If the cache was populated by an A query (say) it can't know
> if this is a subset of the owner's records or not; if it populated the
> cache from an ANY query then the records can expire at different times, so
> it would have to keep track of this to know if the extended error becomes
> relevant.

Good point, I was not thinking about the full path from auth via
recursive to stub when I made this comment.  As you said it's not
straightforward.  This could still be possible, e.g., if the
authoritative server deliberately returns a single RRset to an ANY
query with the extended (error) code and the recursive server caches it
with marking the sense of the extended code.  But it will introduce
additional special case to the recursive server implementation, and
the benefit may not be worth the complexity.

--
JINMEI, Tatuya

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 8 Aug 2017 06:53:22 -0400

All

The Call for Adoption period has ended and there is some strong 
consensus to adopt this work, and move it forward.  The authors will 
upload a new version with the right naming, and the real work can begin 
on gather consensus.

thanks for all the comments

for the chairs,

tim

On 7/25/17 12:04 PM, tjw ietf wrote:
> This draft was the only one which seemed to have broad support in some 
> form during the meeting last week.
> 
> This starts a Call for Adoption for draft-wkumari-dnsop-extended-error
> 
> The draft is available here:
> https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02
> 
> Please review this draft to see if you think it is suitable for adoption 
> by DNSOP, and comments to the list, clearly stating your view.
> 
> Please also indicate if you are willing to contribute text, review, etc.
> 
> This call for adoption ends: 8 August 2017, 23:59
> 
> Thanks,
> tim wicinski
> DNSOP co-chair
> 
>

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 08 Aug 2017 22:22:54 -0700

Edward Lewis <[email-masked]> writes:

> But the draft itself isn't exactly the way I'd go about solving the
> problem.  Does that mean it shouldn't be adopted?  I suppose not, I
> suppose the answer is to adopt it and change it mercilessly.

And such is the IETF way; so to quote someone recently:

> I mean, bring it on.

-- 
Wes Hardaker
USC/ISI