/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
At Sat, 29 Jul 2017 14:27:57 +0100,
Tony Finch 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
Viktor Dukhovni wrote:
> On Mon, Jul 31, 2017 at 05:11:07PM +, 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
On Sat, Jul 29, 2017 at 08:53:48AM -0400, Paul Wouters wrote:
> > This starts a Call for Adoption for draft-wkumari-dnsop-extended-error
>
> I have reviewed the draft, and while I think it could be useful, I'm
> seriously worried about sending unauthenticated errors back to the u
On Mon, Jul 31, 2017 at 05:11:07PM +, Evan Hunt wrote:
> Are there applications specifically trusting AD=1 and behaving differently
> than with AD=0? Or are they just ignoring it and trusting every answer
> equally? I would have expected the latter, but I confess to being
> surprised if
Postfix is one but last I knew only when resolv contains localhost.
I think systemd-resolved also does various tricks but haven't looked at that in
a long time.
Software doesn't want to link against a dnssec library. Hopefully we can get
something smaller and better if we can use query-chains
On Mon, Jul 31, 2017 at 09:57:11AM -0400, Paul Wouters wrote:
> But we know people are already building software and systems that DO
> trust the AD bit, even with non-localhost resolv.conf entries. This
> saves them the overhead of adding a dnssec library to their application,
> and saves them
On Sun, 30 Jul 2017, Evan Hunt wrote:
It's clearly helpful for human debugging.
But, yes, you're correct -- diagnostic information included with a
SERVFAIL is about as trustworthy as the AD bit, and in the absence of an
authentication mechanism such as TSIG, clients should not rely on it or
In your previous mail you wrote:
> But, yes, you're correct -- diagnostic information included with a
> SERVFAIL is about as trustworthy as the AD bit, and in the absence of an
> authentication mechanism such as TSIG, clients should not rely on it or
> base policy on it.
=> TSIG can be in a
On Sat, Jul 29, 2017 at 10:04:06AM -0400, Joe Abley wrote:
> If client behaviour is not supposed to change when you return
> an extended RCODE, why bother returning one?
It's clearly helpful for human debugging.
But, yes, you're correct -- diagnostic information included with a
SERVFAIL is about
Hi Shane,
On Jul 29, 2017, at 09:05, Shane Kerr wrote:
> I guess that I understand your concern, but we don't have any way to
> authenticate servers in DNS today and we already send error messages back.
>
> I'm happy with error codes that are informational, but
+1 (in favor)
francis.dup...@fdupont.fr
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
神明達哉 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
the case
today, right?
On 29 July 2017 14:53:48 GMT+02:00, Paul Wouters <p...@nohats.ca> wrote:
>
>> This starts a Call for Adoption for
>draft-wkumari-dnsop-extended-error
>
>I have reviewed the draft, and while I think it could be useful, I'm
>seriously worried about sen
This starts a Call for Adoption for draft-wkumari-dnsop-extended-error
I have reviewed the draft, and while I think it could be useful, I'm
seriously worried about sending unauthenticated errors back to the user,
and fear that software will start using these without first validating
In message <4dd39053-3e33-4bd1-a83d-f81219484...@dnss.ec>, Roy Arends writes:
> > On 27 Jul 2017, at 09:08, Shane Kerr wrote:
> >
> > I support the draft, and am willing to contribute text and review!
> >
> > I have a few points now, in fact:
> >
> > 1. Does it make
> On 27 Jul 2017, at 09:08, Shane Kerr wrote:
>
> I support the draft, and am willing to contribute text and review!
>
> I have a few points now, in fact:
>
> 1. Does it make sense to divide the response codes up into those
> corresponding to each error type? That
the meeting. Several drafts had support with
only a few people whining because it didn't help their own
operations. ;)
> 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-err
https://nic.cz/
- Original Message -
> From: "tjw ietf" <tjw.i...@gmail.com>
> To: "dnsop" <dnsop@ietf.org>
> Sent: Tuesday, 25 July, 2017 18:04:04
> Subject: [DNSOP] Call for Adoption: draf
my next draft will definitely include "I'd like to thank Mark
Andrews for hitting me with a cluestick repeatedly WAIT WAIT WHY IS
THE ORCHESTRA STARTING OH MAN"
On Wed, Jul 26, 2017 at 10:11 AM, Mark Andrews wrote:
>
> In message
>
In message
Jul 25, 2017 at 12:04 PM, tjw ietf <tjw.i...@gmail.com> 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
>>
&g
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, c
ly 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
On Tue, Jul 25, 2017 at 12:04 PM, tjw ietf <tjw.i...@gmail.com> 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
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
26 matches
Mail list logo