[DNSOP] Second Working Group Last Call: draft-ietf-dnsop-refuse-any

[tjw ietf]

All

During the first WGLC of draft-ietf-dnsop-refuse-any, several issues were
raised by the working group that needed to be addressed. The Authors
addressed the issues, but the changes are enough that there should be a
second Working Group Last Call on the changes.

This begins a Second WGLC for draft-ietf-dnsop-refuse-any.  The Document is
located here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/

However, the changes that were made since the last WGLC can be found here:

https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-refuse-any-03&url2=draft-ietf-dnsop-refuse-any-04

Please take a few moments to refer the changes and let the working group
know if the document is ready to move forward.   We're mostly looking for
remaining issues that have not been addressed.

This WGLC ends on Thursday 30 March 2017.

Thanks

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

[DNSOP] DNSOP Call for Adoption: draft-hardaker-rfc5011-security-considerations

[tjw ietf]

All

We've had a lot of WG discussion on this, and it seems relevant to do a
formal call for adoption.   If there are outstanding issues raised during
the CfA, time in Chicago will be set aside to have those discussions.


This starts a Call for Adoption for:
 draft-hardaker-rfc5011-security-considerations

The draft is available here:
https://datatracker.ietf.org/doc/draft-hardaker-rfc5011-security-considerations/

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.

If there are

This call for adoption ends: 30 March 2017

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

[DNSOP] The DNSOP WG has placed draft-hardaker-rfc5011-security-considerations in state "Call For Adoption By WG Issued"

[IETF Secretariat]

The DNSOP WG has placed draft-hardaker-rfc5011-security-considerations in
state 
Call For Adoption By WG Issued (entered by Tim Wicinski)

The document is available at
https://datatracker.ietf.org/doc/draft-hardaker-rfc5011-security-considerations/

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

Re: [DNSOP] DNSOP Call for Adoption: draft-hardaker-rfc5011-security-considerations

[Petr Špaček]

On 16.3.2017 08:16, tjw ietf wrote:
> All
> 
> We've had a lot of WG discussion on this, and it seems relevant to do a
> formal call for adoption.   If there are outstanding issues raised
> during the CfA, time in Chicago will be set aside to have those
> discussions. 
> 
> 
> This starts a Call for Adoption for:
>  draft-hardaker-rfc5011-security-considerations

Having seen version 03 I support adoption.

Petr Špaček  @  CZ.NIC

> 
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-hardaker-rfc5011-security-considerations/
> 
> 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.
> 
> If there are 
> 
> This call for adoption ends: 30 March 2017
> 
> Thanks,
> tim wicinski
> DNSOP co-chair

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

Re: [DNSOP] DNSOP Call for Adoption: draft-hardaker-rfc5011-security-considerations

[Shane Kerr]

Tim,

At 2017-03-16 03:16:50 -0400
tjw ietf  wrote:

> We've had a lot of WG discussion on this, and it seems relevant to do a
> formal call for adoption.   If there are outstanding issues raised during
> the CfA, time in Chicago will be set aside to have those discussions.
> 
> 
> This starts a Call for Adoption for:
>  draft-hardaker-rfc5011-security-considerations
> 
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-hardaker-rfc5011-security-considerations/
> 
> 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.

While from a practical point of view this mostly only useful for ICANN,
it is important to document this issue so that anyone who implements
their own trust anchors understands it, and also so that future DNS
people know that the issue was considered.

I am in favor of adoption.

Cheers,

--
Shane


pgpTTqIZdTZqu.pgp
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New terminology for root name service

[Tim Wicinski]

https://www.icann.org/en/system/files/files/rssac-026-14mar17-en.pdf


On 3/16/17 2:03 AM, Wessels, Duane wrote:

Bill,

You can find RSSAC026 at the top of this page:

https://www.icann.org/groups/rssac/documents

DW




On Mar 16, 2017, at 6:58 AM, william manning  wrote:

do you have a pointer to the rssac document?

/Wm

On Wed, Mar 15, 2017 at 10:31 AM, Paul Hoffman  wrote:
Greetings again. RSSAC has published a lexicon of terms that are commonly used 
with respect to the root of the public DNS, but are not in RFC 7719. I have 
opened an issue for the terminology-bis document at 
https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/17 and would 
be intereted to hear what people think about including those terms in our 
document.

--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


___
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 draft-wouters-sury-dnsop-algorithm-update

[tjw ietf]

Hi

The Call for Adoption ended some time ago with very little discussion in
that period, but a significant and fruitful discussions since.

Considering the strong hum of the room in Seoul and the conversations on
this version, the chairs consider the draft adopted,  If there are items
that wish to be raised during Chicago, the chairs will set aside time in
the meeting to bring these up.

thanks
tim


On Thu, Jan 5, 2017 at 4:28 PM, Tim Wicinski  wrote:

> All
>
> Since we're having so much fun on adopting work, let's have another one.
> We discussed this work in Seoul, and there was a solid hum on adopting this
> work.
>
> This starts a Call for Adoption for:
> draft-wouters-sury-dnsop-algorithm-update
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-wouters-sury-dnsop-al
> gorithm-update/
>
> 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: 19 January 2017
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt

[Philip Homburg]

>1. I do not think there is consensus that having PTRs is or is not a best
>practice, so emphasizing the lack of consensus lets us move on to what an
>ISP can do, if they care to do anything.
>The first paragraph has been overhauled to say "While the need for a PTR
>record and for it to match
>   is debatable as a best practice, some network services [see Section 3]
>still do rely on PTR lookups, and some check the source address of
>incoming connections and verify that the PTR and A records match before
>providing service.=B2

Is it possible to have a separate section about e-mail?

In my experience, without reverse DNS it is essentially impossible to have
mail delivered to the internet at large.

So where most uses of PTR records are a nice to have to can be decided locally,
for e-mail it is other parties on the internet that force the use of PTR
records.

At the same time, if someone is capable of operating a mail server then 
operating an auth. DNS server is not really out of line.

So I'd like some text that describes the importance of reverse DNS for e-mail
and then basically says that if an ISP allows customers to handle their
own outgoing e-mail then that ISP SHOULD provide customers with a way of
setting up PTR records for those mail servers, even if it is just delegating
part of the name space by setting up NS records.

Do you have a reference for the following statement
Serving ads: "This host is probably in town.province."  An ISP that does not
provide PTR records might affect somebody else's geolocation.

Extracting geo information from reverse DNS is very hard. As far as I know,
geo location services for IPv4 mostly rely on other sources. 

The following is not clear to me:
Some ISP DNS administrators may choose to provide only a NXDomain
response to PTR queries for subscriber addresses. [...]
Providing a negative response in response to PTR
queries does not satisfy the expectation in [RFC1912] for entries to
match.  Users of services which are dependent on a successful lookup
will have a poor experience.  For instance, some web services and SSH
connections wait for a DNS response, even NXDOMAIN, before
responding.

Why would a NXDOMAIN response to a PTR query have a negative impact
on performance? If any, it would be faster because it saves a forward
lookup.

Maybe you want to say that a PTR lookup has to result in a quick reply,
even it is an NXDOMAIN. A delegation to a name server that does not respond
will cause a delay in applications that wait for the reverse DNS lookup to
complete.

I don't see a discussion about DNAME. Maybe that's worth adding?

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

Re: [DNSOP] DNSOP Call for Adoption: draft-hardaker-rfc5011-security-considerations

[william manning]

this is a useful and needed document.  I support its adoption by the WG.
As a note to the authors, there was a proposed alternate to what became RFC
5011 which addressed some of the same issues as the current draft. It might
be useful to review
https://tools.ietf.org/html/draft-ietf-dnsext-trustupdate-threshold-01
going forward.

/Wm

On Thu, Mar 16, 2017 at 12:16 AM, tjw ietf  wrote:

> All
>
> We've had a lot of WG discussion on this, and it seems relevant to do a
> formal call for adoption.   If there are outstanding issues raised during
> the CfA, time in Chicago will be set aside to have those discussions.
>
>
> This starts a Call for Adoption for:  draft-hardaker-rfc5011-
> security-considerations
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-hardaker-rfc5011-
> security-considerations/
>
> 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.
>
> If there are
>
> This call for adoption ends: 30 March 2017
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>
> ___
> 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] WGLC for draft-ietf-dnsop-sutld-ps

[Edward Lewis]

On 3/15/17, 20:22, "DNSOP on behalf of Russ Housley"  wrote:

>I see that draft-ietf-dnsop-sutld-ps-03 still references 
>I-D.lewis-domain-names, but I have not seen ant WG Last Call for that 
>document.  What is the plan?

Just accidently saw this...I haven't been reading DNSOP much recently.

FWIW, the document ("-domain-names-") was informally attached to the IAB's 
Names and Identifier's Program, that program was recently scuttled by the IAB 
like, maybe, 2-3 weeks ago.  I had been wondering (but more tied up with this 
week's ICANN meeting) what happens next, and haven't gotten around to dealing 
with that.  In that sense "Good Question."

The domain-names draft was never considered for a DNSOP WG document as it is 
mostly about how this is not a DNS problem.  In 2015, I did get comments from 
folks on this list and then for most of 2016 the discussion was under the IAB 
program.  There wasn't much discussion which is the prime reason the document 
was in a suspended, waiting state.

The document currently has two pieces.  One is the historical narrative and 
written to justify clarifying domain names, with "clarifying" being an action 
not to be undertake without much consideration.  (Having written two 
clarifications, I've learned.)  The other piece is where I wanted discussion, 
defining domain names.

I could edit the document to include just the first piece and submit it to the 
Independent Stream whatever, Editor.  There's not much reason not to do that - 
it just hadn't happened while the IAB program was in place (potentially 
adopting the document).  On the other hand, I was still "discovering" some of 
the elements of the relevant history as late as December based on the only set 
of comments I'd received in months (got it in private email in September).

What are the chances that the Independent Stream Editor will bounce this 
document towards DNSOP?  So - as a question to the chairs - is it worth DNSOP 
adopting this document (covering the history) at the risk of it being out of 
scope for the charter, or is it better to, if the Independent Stream Editor 
bounces this to DNSOP, reply with a "it's not our bailiwick?"

I suppose in any case there will be an IETF-wide last call before the document 
stands a chance of being a vetted, published document.  I've just never thought 
of any other vetting (WG) to be done.

Ed



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

Re: [DNSOP] DNSOP Call for Adoption: draft-hardaker-rfc5011-security-considerations

[Bob Harold]

On Thu, Mar 16, 2017 at 3:16 AM, tjw ietf  wrote:

> All
>
> We've had a lot of WG discussion on this, and it seems relevant to do a
> formal call for adoption.   If there are outstanding issues raised during
> the CfA, time in Chicago will be set aside to have those discussions.
>
>
> This starts a Call for Adoption for:  draft-hardaker-rfc5011-
> security-considerations
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-hardaker-rfc5011-
> security-considerations/
>
> 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.
>
>
> Yes, please adopt, willing to review.

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

Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps

[Ralph Droms]

> On Mar 16, 2017, at 12:08 PM, Edward Lewis  wrote:
> 
> On 3/15/17, 20:22, "DNSOP on behalf of Russ Housley"  on behalf of hous...@vigilsec.com> wrote:
> 
>> I see that draft-ietf-dnsop-sutld-ps-03 still references 
>> I-D.lewis-domain-names, but I have not seen ant WG Last Call for that 
>> document.  What is the plan?
> 
> Just accidently saw this...I haven't been reading DNSOP much recently.
> 
> FWIW, the document ("-domain-names-") was informally attached to the IAB's 
> Names and Identifier's Program, that program was recently scuttled by the IAB 
> like, maybe, 2-3 weeks ago.  I had been wondering (but more tied up with this 
> week's ICANN meeting) what happens next, and haven't gotten around to dealing 
> with that.  In that sense "Good Question."
> 
> The domain-names draft was never considered for a DNSOP WG document as it is 
> mostly about how this is not a DNS problem.  In 2015, I did get comments from 
> folks on this list and then for most of 2016 the discussion was under the IAB 
> program.  There wasn't much discussion which is the prime reason the document 
> was in a suspended, waiting state.
> 
> The document currently has two pieces.  One is the historical narrative and 
> written to justify clarifying domain names, with "clarifying" being an action 
> not to be undertake without much consideration.  (Having written two 
> clarifications, I've learned.)  The other piece is where I wanted discussion, 
> defining domain names.
> 
> I could edit the document to include just the first piece and submit it to 
> the Independent Stream whatever, Editor.  There's not much reason not to do 
> that - it just hadn't happened while the IAB program was in place 
> (potentially adopting the document).  On the other hand, I was still 
> "discovering" some of the elements of the relevant history as late as 
> December based on the only set of comments I'd received in months (got it in 
> private email in September).
> 
> What are the chances that the Independent Stream Editor will bounce this 
> document towards DNSOP?  So - as a question to the chairs - is it worth DNSOP 
> adopting this document (covering the history) at the risk of it being out of 
> scope for the charter, or is it better to, if the Independent Stream Editor 
> bounces this to DNSOP, reply with a "it's not our bailiwick?"
> 
> I suppose in any case there will be an IETF-wide last call before the 
> document stands a chance of being a vetted, published document.  I've just 
> never thought of any other vetting (WG) to be done.
> 
> Ed

Ed - I think your document is a valuable reference and worth publishing.  The 
first question to ask is whether you want to continue with the publication 
process.  If you do, I'm sure we can find some way to publish it.

I need to re-read the document to refresh myself on the two aspects of the 
document that you mention.  If you really are looking for IETF discussion and 
consensus on the defining domain names, a third path would be an AD-sponsored 
submission, independent of any WG.

- Ralph

> 
> ___
> 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] WGLC for draft-ietf-dnsop-sutld-ps

[Paul Hoffman]

On 16 Mar 2017, at 12:59, Ralph Droms wrote:

If you really are looking for IETF discussion and consensus on the 
defining domain names, a third path would be an AD-sponsored 
submission, independent of any WG.


Please do note that we already have such a discussion (that will go for 
IETF consensus) active in draft-ietf-dnsop-terminology-bis. We've been 
asking for feedback on this topic already, and even you gave us some. 
:-)


--Paul Hoffman

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

Re: [DNSOP] [Ext] Re: WGLC for draft-ietf-dnsop-sutld-ps

[Edward Lewis]

On 3/16/17, 20:59, "Ralph Droms"  wrote:

>Ed - I think your document is a valuable reference and worth publishing.  The 
>first question to ask is whether you want to continue with the publication 
>process.  If you do, I'm sure we can find some way to publish it.

In the sense of first things first, its time I "cut" the document to get the 
history and an argument for a clarification.

But...the last comment I received was about the history which led me to a bit 
more research.  Thinking this over, I think it's time for a IETF wide last call 
to see if there are more comments out there like that.



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

[DNSOP] term-bis and was Re: [Ext] Re: WGLC for draft-ietf-dnsop-sutld-ps

[Edward Lewis]

On 3/16/17, 21:26, "DNSOP on behalf of Paul Hoffman"  wrote:

>Please do note that we already have such a discussion (that will go for 
>IETF consensus) active in draft-ietf-dnsop-terminology-bis. We've been 
>asking for feedback on this topic already, and even you gave us some. 
>:-)

I'm not sure if the "you" is directed at me, I did comment, so perhaps.

There's a certain catch-22 [https://en.wikipedia.org/wiki/Dilemma] in play.  
Yes, the DNS needs a definition for Domain Names as the term is used across the 
documents on the DNS protocol and system.  But there's never been work to 
define Domain Names beyond the DNS protocol.  The dilemma is that for 
dns-terminology-bis, not having Domain Name defined would be a serious 
omission, but the general, "beyond the DNS" definition has never been 
formalized and documented.



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

Re: [DNSOP] term-bis and was Re: [Ext] Re: WGLC for draft-ietf-dnsop-sutld-ps

[Paul Hoffman]

On 16 Mar 2017, at 14:25, Edward Lewis wrote:

On 3/16/17, 21:26, "DNSOP on behalf of Paul Hoffman" 
 wrote:


Please do note that we already have such a discussion (that will go 
for
IETF consensus) active in draft-ietf-dnsop-terminology-bis. We've 
been

asking for feedback on this topic already, and even you gave us some.
:-)


I'm not sure if the "you" is directed at me, I did comment, so 
perhaps.


No, it was directed to Ralph. The text that I quoted (that you cut out 
here) was from him.


There's a certain catch-22 [https://en.wikipedia.org/wiki/Dilemma] in 
play.  Yes, the DNS needs a definition for Domain Names as the term is 
used across the documents on the DNS protocol and system.  But there's 
never been work to define Domain Names beyond the DNS protocol.  The 
dilemma is that for dns-terminology-bis, not having Domain Name 
defined would be a serious omission, but the general, "beyond the DNS" 
definition has never been formalized and documented.


Can you say more why you think that is a dilemma? It seems that 
draft-ietf-dnsop-terminology-bis could certainly be the first place 
where it is formalized and documented.


--Paul Hoffman

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

[DNSOP] Review of draft-ietf-dnsop-nsec-aggressiveuse-08

[Joel Halpern]

Reviewer: Joel Halpern
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-dnsop-nsec-aggressiveuse-??
Reviewer: Joel Halpern
Review Date: 2017-03-16
IETF LC End Date: 2017-03-27
IESG Telechat date: Not scheduled for a telechat

Summary: This document is ready for publication as a Proposed
Standard.

Major issues: N/A

Minor issues: N/A

Nits/editorial comments:  N/A


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

Re: [DNSOP] Second Working Group Last Call: draft-ietf-dnsop-refuse-any

[Richard Gibson]

To re-raise my unaddressed points from the first Working Group Last Call:

   - There is no mechanism for signaling section 4.1/ section 4.3 "partial
   response" behavior to clients (e.g., a new OPT record EDNS header flag
   bit
   

   ).
   - Insisting that the HINFO OS field SHOULD be empty ("set to the null
   string") seems a little too strong; there's room in it for—and value
   from—a short explanation (e.g., as can be observed today:
   dns.cloudflare.com. 3789 IN HINFO "Please stop asking for ANY" "See
   draft-ietf-dnsop-refuse-any"). I'd prefer text like "The OS field
of the HINFO
   RDATA SHOULD be short to minimize the size of the response, and MAY be
   empty or MAY include a summarized description of local policy."
   - "Conventional [ANY] response" is used but not defined.
   - "ANY does not mean ALL" is misleading—RFC 1035
    is clear about
   QTYPE=255 being "a request for *all* records" (emphasis mine). That
   said, the proposed *response* behavior is consistent with that RFC.


On Thu, Mar 16, 2017 at 3:11 AM, tjw ietf  wrote:

>
> All
>
> During the first WGLC of draft-ietf-dnsop-refuse-any, several issues were
> raised by the working group that needed to be addressed. The Authors
> addressed the issues, but the changes are enough that there should be a
> second Working Group Last Call on the changes.
>
> This begins a Second WGLC for draft-ietf-dnsop-refuse-any.  The Document
> is located here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-
> refuse-any/
>
> However, the changes that were made since the last WGLC can be found here:
>
> https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-refuse-
> any-03&url2=draft-ietf-dnsop-refuse-any-04
>
> Please take a few moments to refer the changes and let the working group
> know if the document is ready to move forward.   We're mostly looking for
> remaining issues that have not been addressed.
>
> This WGLC ends on Thursday 30 March 2017.
>
> Thanks
>
> tim/suzanne
>
>
> ___
> 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] DNSOP Call for Adoption: draft-hardaker-rfc5011-security-considerations

[Wes Hardaker]

william manning  writes:

> this is a useful and needed document.  I support its adoption by the WG.  As a
> note to the authors, there was a proposed alternate to what became RFC 5011
> which addressed some of the same issues as the current draft. It might be
> useful to review 
> https://tools.ietf.org/html/draft-ietf-dnsext-trustupdate-threshold-01 going
> forward.

Thanks Bill!  And I do remember it (and the discussions at the time).

Note that we're not trying to create a document that modifies the
procedures at all, just trying to create one that ensures people can
securely use the existing one with proper knowledge.
-- 
Wes Hardaker
USC/ISI

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

Re: [DNSOP] Second Working Group Last Call: draft-ietf-dnsop-refuse-any

[Doug Barton]

I think this is a bad idea generally, and that RRL is a better solution 
to the amplification vector issue. But since the "War on ANY" doesn't 
show signs of abating ...


On 03/16/2017 09:27 PM, Richard Gibson wrote:

To re-raise my unaddressed points from the first Working Group Last Call:

  * There is no mechanism for signaling section 4.1/ section 4.3
"partial response" behavior to clients (e.g., a new OPT record EDNS
header flag bit


This is my chief concern. However much the purists don't like it, 
various things in the wild ask for ANY fully expecting that it means 
ALL. If something gets an ANY response that does not include the thing 
it really needs, how is it supposed to know that it needs to ask again?




).
  * Insisting that the HINFO OS field SHOULD be empty ("set to the null
string") seems a little too strong; there's room in it for—and value
from—a short explanation (e.g., as can be observed
today: dns.cloudflare.com
. 3789INHINFO"Please stop asking for ANY"
"See draft-ietf-dnsop-refuse-any"). I'd prefer text like "The OS
field of the HINFO RDATA SHOULD be short to minimize the size
of the response, and MAY be empty or MAY include a summarized
description of local policy."


Agreed. I'd rather see this flipped, with auth servers encouraged to 
include a brief explanation, or even a URL that explains the issue.



  * "ANY does not mean ALL" is misleading—RFC 1035
 is clear about
QTYPE=255 being "a request for *all* records" (emphasis mine). That
said, the proposed /response/ behavior is consistent with that RFC.


That may be true technically, but I doubt anyone but a serious DNS RFC 
purist would understand, or agree with that distinction.


Personally I have a lot of sympathy for the school of thought that says 
to send nothing back but the TC bit, and force the requestor to 
reconnect with TCP. But the "War on TCP" doesn't show any signs of 
abating either ...


Doug

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