Re: [DNSOP] Call for Adoption: Survey of Domain Verification Techniques using DNS

[Wessels, Duane]

I support the adoption of this draft.

I think there is value in keeping the specific examples (with named companies, 
etc) but agree with John that placing them in an appendix would be better.

DW


> On Jul 12, 2022, at 6:29 AM, Tim Wicinski  wrote:
> 
> 
> 
> This starts a Call for Adoption for Survey of Domain Verification Techniques 
> using DNS
> 
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-sahib-domain-verification-techniques/
> 
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and send any 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: 26 July 2022
> 
> Thanks,
> tim wicinski
> For DNSOP co-chairs
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://secure-web.cisco.com/1j_nbcnzt4ZJGN4caxS93xsfX7iK9I57uV4Ng0wl1Y2FRmYzo6jKzWiUGQABMDr4XLJ2xSYU5KP3JULJn7iS9NTEbpiuUNFV7AJcJDFBVZxHi2s8XJQ8qBOplztk_HhdNOPN7-62ZNRHPb_QZ9FuZ0D_dCVV31gkasuLhhe54cuySQTfMjAljl7nMDPSgmrdizutF1YFQhTLIFtxtGPa04TvmSf9w47cMaEUtoqUD0Yj_-gxlA9b983ZtyzIYo95K/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: Survey of Domain Verification Techniques using DNS

[Shivan Kaul Sahib]

On Tue, 12 Jul 2022 at 15:04, Paul Hoffman  wrote:

> On Jul 12, 2022, at 2:16 PM, Melinda Shore 
> wrote:
> >
> >> I agree that the list of implementations should be deleted or
> summarized in an appendix.
> >
> > Well, maybe.  The "Let's Encrypt" example is actually part of the
> > acme spec (RFC 8555) and is an IETF product.
>
> It is definitely worth keeping the pointer to the ACME spec without naming
> Let's Encrypt. That organization might choose to do something different in
> the future, and it would confuse a reader who found this RFC if it said
> "Let's Encrypt does this" when they don't.
>

Makes sense, that's what I've done in the latest update (not yet pushed to
Datatracker for the usual reasons):
https://shivankaul.com/draft-sahib-domain-verification-techniques/draft-sahib-domain-verification-techniques.html#section-3.1-5

>
> --Paul Hoffman
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: Survey of Domain Verification Techniques using DNS

[Paul Hoffman]

On Jul 12, 2022, at 2:16 PM, Melinda Shore  wrote:
> 
>> I agree that the list of implementations should be deleted or summarized in 
>> an appendix.
> 
> Well, maybe.  The "Let's Encrypt" example is actually part of the
> acme spec (RFC 8555) and is an IETF product.

It is definitely worth keeping the pointer to the ACME spec without naming 
Let's Encrypt. That organization might choose to do something different in the 
future, and it would confuse a reader who found this RFC if it said "Let's 
Encrypt does this" when they don't.

--Paul Hoffman



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Quick review of draft-dwmtwc-dnsop-caching-resolution-failures-00

[Wessels, Duane]

Hi Mukund,

> On Jul 12, 2022, at 8:24 AM, Mukund Sivaraman  wrote:
> 
> Some comments quickly browsing this draft, as we're handling a quirky
> issue around NS timeouts and it looked relevant.
> 
> Firstly, some resolver implementations do cache upstream NS timeouts in
> various non-standard ways. The resolver I work on has at least 3-4
> different mechanisms within the same codebase. Documentation on how
> timeouts should be handled seems good, so I support this draft.
> 
>> Internet Engineering Task Force   D. Wessels
>> Internet-DraftW. Carroll
>> Intended status: Standards Track   M. Thomas
>> Expires: 17 July 2022   Verisign
>> 13 January 2022
> 
> 
>>  Negative Caching of DNS Resolution Failures
>>   draft-dwmtwc-dnsop-caching-resolution-failures-00
> 
> [snip]
> 
>>   [RFC4697] is a Best Current Practice that documents observed
>>   resolution misbehaviors.  It describes a number of situations that
>>   can lead to excessive queries from recusrive resolvers. including:
> 
> There's a spelling mistake in "recusrive", and the period after
> "resolvers." should be removed.

Thanks, these will be fixed.


> 
> [snip]
> 
>> 3.2.  TTLs
> 
>>   Resolvers MUST cache resolution failures for at least 5 seconds.
>>   Resolvers SHOULD employ an exponential backoff algorithm to increase
>>   the amount of time for subsequent resolution failures.  For example,
>>   the initial negative cache TTL is set to 5 seconds.  The TTL is
> 
> I am guessing the authors meant to write "timeout cache TTL" here
> instead of negative cache TTL. In any case, the phrase "negative cache
> TTL" has a well-understood meaning per RFC 2308, and should not be
> overloaded/reused to indicate timeout cache TTL.

We didn’t really mean “timeout cache TTL” here.  Rather, the intention 
is specify requirements for caching all types of resolution failures.
That means SERVFAIL, REFUSED, timeouts, and the others listed in Section 2.

I think perhaps your point is that RFC 2308 talks about TTLs for negative
*answers* (NXDOMAIN, NODATA) and what we are proposing is different, often
in the absence of an answer.

Would this rewrite alleviate your concern?

   For example,
   the initial TTL for negatively caching a resolution failure is set to
   5 seconds.  The TTL is doubled after each retry that results in
   another resolution failure.  Consistent with [RFC2308], resolution
   failures MUST NOT be cached for longer than 5 minutes.


> 
> [snip]
> 
>> 3.3.  Scope
> 
>>   Resolution failures MUST be cached against the specific query tuple
>>   .
> 
> Have you considered the effect of caching the timeout against just an
> upstream server's IP address? I'm not saying you should, but wondering
> if any of the other tuple fields are relevant to have separate
> more-specific timeout cache entries.
> 
> In other words, is it necessary for there to be a distinction among
> timeouts for:
> 
> (1) example.org., A, IN, 10.0.0.1
> 
> (2) example.org., TYPE65, IN, 10.0.0.1
> 
> (3) example.com., A, IN, 10.0.0.1
> 
> Traditionally, a resolver's upstream RTTs and timeouts are tracked
> against the nameserver IP address. A failure to respond has been
> considered as a property of the NS (implementation) or path to that NS.
> 
> My colleagues are handling an issue where an authoritative nameserver
> does not respond to TYPE65 queries, but responds to queries for common
> query types such as address records. In this case, without mitigating
> with controls, the resolver is a little stumped and keeps attempting to
> contact the upstream NS because it receives some responses from it. The
> queries for which there are no responses eventually end up waiting for
> the maximum timeout limit because the resolver keeps trying to talk to
> it. On a busy resolver, these queries consume resources.
> 
> We could consider the upstream NS as "bad" if it appears to respond to
> some queries but doesn't respond to others with some response. But
> one-off or transient timeouts can occur sometimes due to network packet
> loss.
> 
> In our case, if the resolver were to block this zone's upstream NSs as
> bad, it wouldn't be able to respond to any queries within that zone
> (even address records). It appears to be a popular country-level zone,
> and it's unlikely the upstream operators will fix it to respond to
> TYPE65 queries in the short-term. In such cases, a heavy-handed approach
> may not be practical.

We have not really considered a recommendation to cache against a name
server’s IP address only.  The idea to cache against the 4-tuple comes
from 2308 (sections 7.1 and 7.2).

We feel that improved caching based on the 4-tuple would be a big win.
It sounds like perhaps you are suggesting a more aggressive approach might
encourage authoritative operators to 

Re: [DNSOP] Call for Adoption: Survey of Domain Verification Techniques using DNS

[Melinda Shore]

On 7/12/22 10:50 AM, John R. Levine wrote:
That ship sailed a long time ago with the failure of the SPF record. 
People use TXT records for one-off things and they're not going to stop.


What John said.

I agree that the list of implementations should be deleted or summarized 
in an appendix.


Well, maybe.  The "Let's Encrypt" example is actually part of the
acme spec (RFC 8555) and is an IETF product.

Melinda

--
Melinda Shore
melinda.sh...@nomountain.net

Software longa, hardware brevis

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: Survey of Domain Verification Techniques using DNS

[Shivan Kaul Sahib]

Thanks all for the feedback! I've attempted to capture the following
feedback here

:


   1. Remove the naming of specific implementations
   2. Remove normative language
   3. Summarize recommendations up front

The audience here are providers. I think specific feedback about what
recommendations to include can be worked upon by the WG as a whole, once/if
we agree that the document is worth pursuing.

Does this help?

On Tue, 12 Jul 2022 at 11:50, John R. Levine  wrote:

> > Alternately, mostly deleting section 3 (the survey part), renaming the
> > document and focusing on section 4 (the recommendations part) might be
> > worthwhile, but that section is all about formatting TXT messages in a
> > specific way and that's generally been considered anathema for DNS for
> oh so
> > many reasons.  So that may also not be a correct approach.
>
> That ship sailed a long time ago with the failure of the SPF record.
> People use TXT records for one-off things and they're not going to stop.
>
> I agree that the list of implementations should be deleted or summarized
> in an appendix.
>
> What might be useful is a shorter recommendation section with no MUST
> stuff, since it's not standards track, saying something like:
>
> If you use a TXT record, use a _prefix ond register it in the IANA prefix
> registry.  Use a fixed descriptive initial part in the text string so you
> don't get faked out by wildcards.  Do not add more junk to the TXT records
> in the domain itself.
>
> If you use a CNAME record, use either a registered _prefix, or a
> pseudo-random prefix.
>
> R's,
> John
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: Survey of Domain Verification Techniques using DNS

[John R. Levine]

Alternately, mostly deleting section 3 (the survey part), renaming the 
document and focusing on section 4 (the recommendations part) might be 
worthwhile, but that section is all about formatting TXT messages in a 
specific way and that's generally been considered anathema for DNS for oh so 
many reasons.  So that may also not be a correct approach.


That ship sailed a long time ago with the failure of the SPF record. 
People use TXT records for one-off things and they're not going to stop.


I agree that the list of implementations should be deleted or summarized 
in an appendix.


What might be useful is a shorter recommendation section with no MUST 
stuff, since it's not standards track, saying something like:


If you use a TXT record, use a _prefix ond register it in the IANA prefix 
registry.  Use a fixed descriptive initial part in the text string so you 
don't get faked out by wildcards.  Do not add more junk to the TXT records 
in the domain itself.


If you use a CNAME record, use either a registered _prefix, or a 
pseudo-random prefix.


R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOP Document Adoption Poll (June 2022)

[Ted Lemon]

This doesn't feel like a consensus call to me, Tim. It feels like voting.
We don't care how many people were in favor versus against. We care why
they were in favor or against. If everyone who's against is against because
"we don't like it" and everybody whos in favor is in favor because "we have
this use case that it addresses and would like to work on the problem", and
most are against adopting, you have consensus to adopt. If everyone in
favor is in favor because "we like it" and everyone against is against
because "this would break the internet," and there are many more in favor
than against, we don't have consensus to adopt.

I did not vote in this poll, and I am against adopting any of these drafts
based on the poll, for the reason I just stated. If we are voting, please
count this as a -1 for all drafts for which you polled. Sorry to be a
sticky wicket, but I am not okay with this process.

On Tue, Jul 12, 2022 at 10:56 AM Vittorio Bertola  wrote:

>
> Il 12/07/2022 15:02 Tim Wicinski  ha scritto:
>
> Our Poll answers are "Adopt Now","Adopt Not Now", and "Don't Adopt"
>
> We mapped these responses to 1, 0, -1 (no answer is also 0).
>
>
>
> Final Results:
>
>
> * draft-sahib-domain-verification-techniques, 14
>
> * draft-dwmtwc-dnsop-caching-resolution-failures, 13
>
> * draft-rebs-dnsop-svcb-dane, 12
>
> draft-klh-dnsop-rfc8109bis, 7
>
> draft-wing-dnsop-structured-dns-error-page, 2
>
> draft-dulaunoy-dnsop-passive-dns-cof, -2
>
> It would be useful to get the full results, to be able to tell between
> these two cases:
> 1. some drafts did not get many points because very few people are
> interested in them (so mostly zeroes and a few ones);
> 2. some drafts did not get many points because several people are
> interested in them but several others actively oppose their adoption (so
> both ones and minus ones).
>
> This would help the authors in deciding whether changes in the draft (or
> better information about its usefulness) could lead to adoption, or whether
> the work is not welcome here and should move elsewhere.
>
> --
>
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> vittorio.bert...@open-xchange.com
> Office @ Via Treviso 12, 10144 Torino, Italy
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: Survey of Domain Verification Techniques using DNS

[Paul Hoffman]

I support adoption of this document as long as the WG version does not list 
current implementations by name. As Mike StJohns points out, listing current 
methods in a long-lived RFC has significant problems, and it doesn't help the 
future reader decide what they want to do. It is still fine to call this a 
"survey".

I would also like to see a more specific proposal at the top of the document 
(_name and TXT) instead of making the reader wade through the survey. 

--Paul Hoffman



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: Negative Caching of DNS Resolution Failures

[Michael StJohns]

Disregard this - it was targeted for a different adoption call.

Thanks to Paul H for noticing.

Mike


On 7/12/2022 12:51 PM, Michael StJohns wrote:

On 7/12/2022 9:54 AM, Tim Wicinski wrote:


This starts a Call for Adoption for Negative Caching of DNS 
Resolution Failures



The draft is available here: 
https://datatracker.ietf.org/doc/draft-dwmtwc-dnsop-caching-resolution-failures/


Please review this draft to see if you think it is suitable for adoption
by DNSOP, and send any 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: 26 July 2022

Thanks,
tim wicinski
For DNSOP co-chairs

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Hi -

I think this draft SHOULDN'T be adopted on a cost/benefit basis.  My 
main issue is that it's not really clear who the audience for this 
might be.   It's clearly not the developers.   I doubt it's the 
customers as any customer is going to have to follow the guidance laid 
down by their provider.  That leaves the providers as a possible 
target, but they've already implemented their solutions (as evidenced 
by the content of this document) and really aren't going to change 
things unless it saves or makes them money.   So I question putting WG 
(or reviewer) time in on this document.  Instead, see if ICANN might 
stand up a wiki page to memorialize this - at least that wiki might 
not be obsolete upon publication.


Alternately, mostly deleting section 3 (the survey part), renaming the 
document and focusing on section 4 (the recommendations part) might be 
worthwhile, but that section is all about formatting TXT messages in a 
specific way and that's generally been considered anathema for DNS for 
oh so many reasons.  So that may also not be a correct approach.


If this does proceed, I'd revise it to not use the RFC 2119 constructs 
in section 4.  Basically, use lower case, and avoid the "its is 
RECOMMENDED" passive structure.  Most of these are targeted at people, 
not at implementations and people are not protocol elements.  Instead, 
explain why doing it the way being suggested makes sense and leave it 
for the operator to do what works for them.


Mike



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: Survey of Domain Verification Techniques using DNS

[Michael StJohns]

Let's try and attach the comment to the right call... *sigh*.  See below.

On 7/12/2022 9:29 AM, Tim Wicinski wrote:


This starts a Call for Adoption for Survey of Domain Verification 
Techniques using DNS


The draft is available here: 
https://datatracker.ietf.org/doc/draft-sahib-domain-verification-techniques/


Please review this draft to see if you think it is suitable for adoption
by DNSOP, and send any 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: 26 July 2022

Thanks,
tim wicinski
For DNSOP co-chairs

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Hi -

I think this draft SHOULDN'T be adopted on a cost/benefit basis.  My 
main issue is that it's not really clear who the audience for this might 
be.   It's clearly not the developers.   I doubt it's the customers as 
any customer is going to have to follow the guidance laid down by their 
provider.  That leaves the providers as a possible target, but they've 
already implemented their solutions (as evidenced by the content of this 
document) and really aren't going to change things unless it saves or 
makes them money.   So I question putting WG (or reviewer) time in on 
this document.  Instead, see if ICANN might stand up a wiki page to 
memorialize this - at least that wiki might not be obsolete upon 
publication.


Alternately, mostly deleting section 3 (the survey part), renaming the 
document and focusing on section 4 (the recommendations part) might be 
worthwhile, but that section is all about formatting TXT messages in a 
specific way and that's generally been considered anathema for DNS for 
oh so many reasons.  So that may also not be a correct approach.


If this does proceed, I'd revise it to not use the RFC 2119 constructs 
in section 4.  Basically, use lower case, and avoid the "its is 
RECOMMENDED" passive structure.  Most of these are targeted at people, 
not at implementations and people are not protocol elements.  Instead, 
explain why doing it the way being suggested makes sense and leave it 
for the operator to do what works for them.


Mike
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: Negative Caching of DNS Resolution Failures

[Michael StJohns]

On 7/12/2022 9:54 AM, Tim Wicinski wrote:


This starts a Call for Adoption for Negative Caching of DNS Resolution 
Failures



The draft is available here: 
https://datatracker.ietf.org/doc/draft-dwmtwc-dnsop-caching-resolution-failures/


Please review this draft to see if you think it is suitable for adoption
by DNSOP, and send any 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: 26 July 2022

Thanks,
tim wicinski
For DNSOP co-chairs

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Hi -

I think this draft SHOULDN'T be adopted on a cost/benefit basis.  My 
main issue is that it's not really clear who the audience for this might 
be.   It's clearly not the developers.   I doubt it's the customers as 
any customer is going to have to follow the guidance laid down by their 
provider.  That leaves the providers as a possible target, but they've 
already implemented their solutions (as evidenced by the content of this 
document) and really aren't going to change things unless it saves or 
makes them money.   So I question putting WG (or reviewer) time in on 
this document.  Instead, see if ICANN might stand up a wiki page to 
memorialize this - at least that wiki might not be obsolete upon 
publication.


Alternately, mostly deleting section 3 (the survey part), renaming the 
document and focusing on section 4 (the recommendations part) might be 
worthwhile, but that section is all about formatting TXT messages in a 
specific way and that's generally been considered anathema for DNS for 
oh so many reasons.  So that may also not be a correct approach.


If this does proceed, I'd revise it to not use the RFC 2119 constructs 
in section 4.  Basically, use lower case, and avoid the "its is 
RECOMMENDED" passive structure.  Most of these are targeted at people, 
not at implementations and people are not protocol elements.  Instead, 
explain why doing it the way being suggested makes sense and leave it 
for the operator to do what works for them.


Mike


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: Survey of Domain Verification Techniques using DNS

[Anthony Eden]

One concern I have is that this draft references many companies as
examples, and as such I worry it will become stale quickly, either due
to those companies changing policies or because they change directions
as a whole. I for one would like to see a version focusing on the
techniques used only. I would be in favor of adopting the draft if
that happens.

Sincerely,
Anthony Eden

On Tue, Jul 12, 2022 at 9:29 AM Tim Wicinski  wrote:
>
>
> This starts a Call for Adoption for Survey of Domain Verification Techniques 
> using DNS
>
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-sahib-domain-verification-techniques/
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and send any 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: 26 July 2022
>
> Thanks,
> tim wicinski
> For DNSOP co-chairs
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
DNSimple.com
http://dnsimple.com/
Twitter: @dnsimple

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Quick review of draft-dwmtwc-dnsop-caching-resolution-failures-00

[Mukund Sivaraman]

Some comments quickly browsing this draft, as we're handling a quirky
issue around NS timeouts and it looked relevant.

Firstly, some resolver implementations do cache upstream NS timeouts in
various non-standard ways. The resolver I work on has at least 3-4
different mechanisms within the same codebase. Documentation on how
timeouts should be handled seems good, so I support this draft.

> Internet Engineering Task Force   D. Wessels
> Internet-DraftW. Carroll
> Intended status: Standards Track   M. Thomas
> Expires: 17 July 2022   Verisign
>  13 January 2022


>   Negative Caching of DNS Resolution Failures
>draft-dwmtwc-dnsop-caching-resolution-failures-00

[snip]

>[RFC4697] is a Best Current Practice that documents observed
>resolution misbehaviors.  It describes a number of situations that
>can lead to excessive queries from recusrive resolvers. including:

There's a spelling mistake in "recusrive", and the period after
"resolvers." should be removed.

[snip]

> 3.2.  TTLs

>Resolvers MUST cache resolution failures for at least 5 seconds.
>Resolvers SHOULD employ an exponential backoff algorithm to increase
>the amount of time for subsequent resolution failures.  For example,
>the initial negative cache TTL is set to 5 seconds.  The TTL is

I am guessing the authors meant to write "timeout cache TTL" here
instead of negative cache TTL. In any case, the phrase "negative cache
TTL" has a well-understood meaning per RFC 2308, and should not be
overloaded/reused to indicate timeout cache TTL.

[snip]

> 3.3.  Scope

>Resolution failures MUST be cached against the specific query tuple
>.

Have you considered the effect of caching the timeout against just an
upstream server's IP address? I'm not saying you should, but wondering
if any of the other tuple fields are relevant to have separate
more-specific timeout cache entries.

In other words, is it necessary for there to be a distinction among
timeouts for:

(1) example.org., A, IN, 10.0.0.1

(2) example.org., TYPE65, IN, 10.0.0.1

(3) example.com., A, IN, 10.0.0.1

Traditionally, a resolver's upstream RTTs and timeouts are tracked
against the nameserver IP address. A failure to respond has been
considered as a property of the NS (implementation) or path to that NS.

My colleagues are handling an issue where an authoritative nameserver
does not respond to TYPE65 queries, but responds to queries for common
query types such as address records. In this case, without mitigating
with controls, the resolver is a little stumped and keeps attempting to
contact the upstream NS because it receives some responses from it. The
queries for which there are no responses eventually end up waiting for
the maximum timeout limit because the resolver keeps trying to talk to
it. On a busy resolver, these queries consume resources.

We could consider the upstream NS as "bad" if it appears to respond to
some queries but doesn't respond to others with some response. But
one-off or transient timeouts can occur sometimes due to network packet
loss.

In our case, if the resolver were to block this zone's upstream NSs as
bad, it wouldn't be able to respond to any queries within that zone
(even address records). It appears to be a popular country-level zone,
and it's unlikely the upstream operators will fix it to respond to
TYPE65 queries in the short-term. In such cases, a heavy-handed approach
may not be practical.

Mukund


signature.asc
Description: PGP signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOP Document Adoption Poll (June 2022)

[Vittorio Bertola]

> Il 12/07/2022 15:02 Tim Wicinski  ha scritto:
> 
> Our Poll answers are "Adopt Now","Adopt Not Now", and "Don't Adopt"
> We mapped these responses to 1, 0, -1 (no answer is also 0).
> 
> 
> Final Results:
> 
> * draft-sahib-domain-verification-techniques, 14
> * draft-dwmtwc-dnsop-caching-resolution-failures, 13
> * draft-rebs-dnsop-svcb-dane, 12
> draft-klh-dnsop-rfc8109bis, 7
> draft-wing-dnsop-structured-dns-error-page, 2
> draft-dulaunoy-dnsop-passive-dns-cof, -2
> 
It would be useful to get the full results, to be able to tell between these 
two cases:
1. some drafts did not get many points because very few people are interested 
in them (so mostly zeroes and a few ones);
2. some drafts did not get many points because several people are interested in 
them but several others actively oppose their adoption (so both ones and minus 
ones).

This would help the authors in deciding whether changes in the draft (or better 
information about its usefulness) could lead to adoption, or whether the work 
is not welcome here and should move elsewhere.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-yorgos-dnsop-dry-run-dnssec-01.txt

[Willem Toorop]

Dear dnsop,

We submitted a new version of a “dry-run DNSSEC” draft. The draft
describes a method that allows for testing DNSSEC deployments in real
world DNS(SEC) deployments without affecting the DNS service in case of
DNSSEC errors. Any encountered errors are signaled to the DNS operator
of the faulty zone with DNS Error Reporting
(draft-ietf-dnsop-dns-error-reporting).

This is a new idea which will be presented during dnsop at the IETF114
and was also presented at the IETF113. A recording of the IETF113
presentation is here: https://youtu.be/watch?v=7HxcmvFOnlU=3675s
Slides here:
https://datatracker.ietf.org/meeting/113/materials/slides-113-dnsop-dry-run-dnssec-01

We received a lot of feedback with our presentation which we used to
reorganize the draft to convey the idea more clearly and coherently. We
also received some critique and objections which were non-technical in
nature. Below is a list with these objections followed by our response.

** This is another straw on the camel’s back **

Not all resolvers have to support/implement it. Most important is that
provisioning at the registry and signaling of Dry-run is supported. If
needed we can say it is OPTIONAL for resolvers in the draft. We intend
to implement it ourselves in Unbound and have it enabled by default when
error reporting is enabled. We know from experience with trust-anchor
signaling and sentinel record that with only a small, up to date
resolver population, the signaling is already quite substantial.

There are different kinds of straws and this one is one that has the
good cause of enabling operators to deploy DNSSEC with confidence.


** Why not have a duplicate parallel test deployment? **

There is nothing better than testing with your actual user population to
dry-run your DNSSEC deployment. Note that slack’s parallel test
deployment did not show them the Route53 failure that caused them to
have an DNSSEC outage eventually[1]


** Why not sell DNSSEC domains cheaper? **

Yes, we’re all for that too, but that’s orthogonal to seeing what the
actual effect of starting DNSSEC with your deployment with your real
user population would be.


The other objections which were more technical, like for example
“registries supporting only fixed sized hashes per algorithm” and
“couldn’t we normalize the different DS hacks somehow” are all addressed
in the new version of the document.

We’re looking forward to a new round of feedback and critique ;)
Both on-list and in-person at the IETF-114!

Kind regards,

Yorgos, Willem and Roy


Op 11-07-2022 om 23:58 schreef internet-dra...@ietf.org:
> 
> A new version of I-D, draft-yorgos-dnsop-dry-run-dnssec-01.txt
> has been successfully submitted by Yorgos Thessalonikefs and posted to the
> IETF repository.
> 
> Name: draft-yorgos-dnsop-dry-run-dnssec
> Revision: 01
> Title:dry-run DNSSEC
> Document date:2022-07-11
> Group:Individual Submission
> Pages:12
> URL:
> https://www.ietf.org/archive/id/draft-yorgos-dnsop-dry-run-dnssec-01.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-yorgos-dnsop-dry-run-dnssec/
> Html:   
> https://www.ietf.org/archive/id/draft-yorgos-dnsop-dry-run-dnssec-01.html
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-yorgos-dnsop-dry-run-dnssec
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-yorgos-dnsop-dry-run-dnssec-01
> 
> Abstract:
>This document describes a method called "dry-run DNSSEC" that allows
>for testing DNSSEC deployments without affecting the DNS service in
>case of DNSSEC errors.  It accomplishes that by introducing a new DS
>Type Digest Algorithm that signals validating resolvers that dry-run
>DNSSEC is used for the zone.  DNSSEC errors are then reported with
>DNS Error Reporting, but any bogus responses to clients are withheld.
>Instead, validating resolvers fallback from dry-run DNSSEC and
>provide the response that would have been answered without the
>presence of a dry-run DS.  A further option is presented for clients
>to opt-in for dry-run DNSSEC errors and allow for end-to-end DNSSEC
>testing.
> 
>   
> 
> 
> 
> The IETF Secretariat
> 
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] IETF 114 DNSOP WG agenda published

[Benno Overeinder]

All,

The (draft) DNSOP WG agenda for the IETF 114 has been published, see 
https://datatracker.ietf.org/doc/agenda-114-dnsop/.


The agenda now spans the full 2 hours, but if new requests for existing 
WG documents are received, room will be made and "time permitting" 
drafts will be bumped off the agenda.


Reminder, the adoption call of three drafts has been started.  The WG is 
asked to discuss the WG call for adoption on the mailing list, whether 
you consider the document appropriate for adoption, comments and 
feedback.  And please indicate if you are willing to contribute text, 
revise the draft, etc.



Best regards,

Suzanne
Tim
Benno

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Call for Adoption: Negative Caching of DNS Resolution Failures

[Tim Wicinski]

This starts a Call for Adoption for Negative Caching of DNS Resolution
Failures


The draft is available here:
https://datatracker.ietf.org/doc/draft-dwmtwc-dnsop-caching-resolution-failures/

Please review this draft to see if you think it is suitable for adoption
by DNSOP, and send any 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: 26 July 2022

Thanks,
tim wicinski
For DNSOP co-chairs
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: Using Service Bindings with DANE

[Bill Woodcock]

> On Jul 12, 2022, at 6:51 AM, Tim Wicinski  wrote:
> This starts a Call for Adoption for Using Service Bindings with DANE
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-rebs-dnsop-svcb-dane/
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and send any comments to the list, clearly stating your view.
> Please also indicate if you are willing to contribute text, review, etc.

I SUPPORT adoption of this draft, and I’m willing to review and edit.

-Bill



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Call for Adoption: Using Service Bindings with DANE

[Tim Wicinski]

This starts a Call for Adoption for Using Service Bindings with DANE


The draft is available here:
https://datatracker.ietf.org/doc/draft-rebs-dnsop-svcb-dane/

Please review this draft to see if you think it is suitable for adoption
by DNSOP, and send any 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: 26 July 2022

Thanks,
tim wicinski
For DNSOP co-chairs
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Call for Adoption: Survey of Domain Verification Techniques using DNS

[Tim Wicinski]

This starts a Call for Adoption for Survey of Domain Verification
Techniques using DNS

The draft is available here:
https://datatracker.ietf.org/doc/draft-sahib-domain-verification-techniques/

Please review this draft to see if you think it is suitable for adoption
by DNSOP, and send any 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: 26 July 2022

Thanks,
tim wicinski
For DNSOP co-chairs
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] The DNSOP WG has placed draft-dwmtwc-dnsop-caching-resolution-failures in state "Call For Adoption By WG Issued"

[IETF Secretariat]

The DNSOP WG has placed draft-dwmtwc-dnsop-caching-resolution-failures in
state Call For Adoption By WG Issued (entered by Tim Wicinski)

The document is available at
https://datatracker.ietf.org/doc/draft-dwmtwc-dnsop-caching-resolution-failures/


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] The DNSOP WG has placed draft-rebs-dnsop-svcb-dane in state "Call For Adoption By WG Issued"

[IETF Secretariat]

The DNSOP WG has placed draft-rebs-dnsop-svcb-dane in state
Call For Adoption By WG Issued (entered by Tim Wicinski)

The document is available at
https://datatracker.ietf.org/doc/draft-rebs-dnsop-svcb-dane/


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] The DNSOP WG has placed draft-sahib-domain-verification-techniques in state "Call For Adoption By WG Issued"

[IETF Secretariat]

The DNSOP WG has placed draft-sahib-domain-verification-techniques in state
Call For Adoption By WG Issued (entered by Tim Wicinski)

The document is available at
https://datatracker.ietf.org/doc/draft-sahib-domain-verification-techniques/


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOP Document Adoption Poll (June 2022)

[Tim Wicinski]

Thanks to everyone who’s participated in the poll. As we’ve said before,
the chairs rely on a number of factors when setting WG administrative
priorities, but occasional polls help us clarify feedback we’re hearing
from the WG list, other DNS-oriented WGs, and the broader community.



Since WG consensus determines whether we advance a draft we’ve adopted, we
work hard to make sure drafts that are adopted are likely to result in
quality documents that will have that consensus support to publish as RFCs.



Additional comments are always welcome.



Our Poll answers are "Adopt Now","Adopt Not Now", and "Don't Adopt"

We mapped these responses to 1, 0, -1 (no answer is also 0).





Final Results:



* draft-sahib-domain-verification-techniques, 14

* draft-dwmtwc-dnsop-caching-resolution-failures, 13

* draft-rebs-dnsop-svcb-dane, 12

draft-klh-dnsop-rfc8109bis, 7

draft-wing-dnsop-structured-dns-error-page, 2

draft-dulaunoy-dnsop-passive-dns-cof, -2

Our Poll answers are "Adopt Now","Adopt Not Now", and "Don't Adopt"

We mapped these responses to 1, 0, -1 (no answer is also 0).


On Mon, Jun 27, 2022 at 6:44 AM Tim Wicinski  wrote:

>
> All
>
> We have six documents that have requested adoption from the working group.
> My opinion is that we send out adoption calls for all of these and let the
> working group sort it out, but was told that is just crazy. Since Warren
> loves these poll things, we put another one together on all the documents
> in question.
>
>
> https://forms.gle/TVKeokYvnU55eq2x7
>
>
> We'll run this poll for two weeks and end on the 9th of July. However, we
> have a chai9rs call on the 5th of July and I'm confident we'll have an
> obvious clear set of documents to begin adoption calls on.
>
> thanks
> tim
>
>
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop