[DNSOP] Stephen Farrell's Yes on draft-ietf-dnsop-qname-minimisation-08: (with COMMENT)

[Stephen Farrell]

Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-qname-minimisation-08: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-qname-minimisation/



--
COMMENT:
--


Thanks - this looks like it's really really well worked
out. I like the basic idea of course, but the execution
here is very well done. 

The secdir review noted some nits you might want to fix
at auth-48. [1]

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06230.html


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

Re: [DNSOP] I-D Action: draft-lee-dnsop-recursion-performance-improvement-00.txt

[Stephane Bortzmeyer]

On Fri, Dec 11, 2015 at 09:21:32AM -0800,
 internet-dra...@ietf.org  wrote 
 a message of 42 lines which said:

> Title   : An approach to improve recursion performance 
> Authors : Xiaodong Lee
>   Hongtao Li
>   Haikuo Zhang
>   Peng Zuo
>   Filename: 
> draft-lee-dnsop-recursion-performance-improvement-00.txt

At the first reading, I do not see the difference between your RQID
and a cookie, as documented in draft-ietf-dnsop-cookies (currently
past working group last call and sent to the IESG).

If there is a difference, and a reason why you just don't use DNS
cookies, please document it.

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

Re: [DNSOP] New Version Notification for draft-adpkja-dnsop-special-names-problem-00.txt

[John R Levine]

There's talk about protocol switches.  I think that's a misnomer.  There
are resolution switches.  I see a lot of utility in it being the top-level
name in a Domain Name.  (I'm not ready to say that's the best way to go.)


Until .onion, the protocol switch for all of the special names was at the 
point where you map a name into an IP address, since localhost and .local 
give you a real IP that you use the same way as any other IP.  You can 
open a TCP socket for web or submit, you can send UDP packets for DNS, you 
can send ICMP packets for ping.  For .test, .example. and .invalid. the 
mapping always fails.


Now .onion comes along and the switch is at a different layer, at whatever 
level SOCKS is.  You can open TCP-like virtual circuits, you might be able 
to do DNS if your SOCKS driver simulates UDP, you can't do ping ping, 
since SOCKS doesn't simulate ICMP.


.onion is a special case for a variety of reasons, but it's not clear to 
me whether people think that slicing at the SOCKS level rather than the 
address resolution level is an exception, or we will be defining a new 
application API for every new special name.


R's,
John

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

Re: [DNSOP] Stephen Farrell's Yes on draft-ietf-dnsop-qname-minimisation-08: (with COMMENT)

[Stephane Bortzmeyer]

On Fri, Dec 11, 2015 at 08:30:29AM -0800,
 Stephen Farrell  wrote 
 a message of 30 lines which said:

> The secdir review noted some nits you might want to fix
> at auth-48. [1]

Yes, it has been done in -08


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

Re: [DNSOP] The DNSOP WG has placed draft-crocker-dns-attrleaf in state "Candidate for WG Adoption"

[Bob Harold]

On Wed, Dec 2, 2015 at 1:56 PM, IETF Secretariat <
ietf-secretariat-re...@ietf.org> wrote:

>
> The DNSOP WG has placed draft-crocker-dns-attrleaf in state
> Candidate for WG Adoption (entered by Tim Wicinski)
>
> The document is available at
> https://datatracker.ietf.org/doc/draft-crocker-dns-attrleaf/
>
>
> Comment:
> There is useful need for this to be documented, for better or for worse.
>
>
Looks useful.  A few concerns:
_adsp. has trailing dot, none of the others do.
pgpkeys missing leading _
_im listed twice, but with different rfc's - should at least put the
entries next to each other

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-01.txt

[Bob Harold]

On Mon, Nov 30, 2015 at 11:07 PM,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the Domain Name System Operations Working
> Group of the IETF.
>
> Title   : A Common Operational Problem in DNS Servers -
> Failure To Respond.
> Author  : M. Andrews
> Filename: draft-ietf-dnsop-no-response-issue-01.txt
> Pages   : 16
> Date: 2015-11-30
>
> Abstract:
>The DNS is a query / response protocol.  Failure to respond or to
>respond correctly to queries causes both immediate operational
>problems and long term problems with protocol development.
>
>This document identifies a number of common classes of queries to
>which some servers either fail to respond or else respond
>incorrectly.  This document also suggests procedures for TLD and
>other similar zone operators to apply to help reduce / eliminate the
>problem.
>
>The document does not look at the DNS data itself, just the structure
>of the responses.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-no-response-issue-01
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> Minor nits:

Section 4.  Firewalls and Load Balancers

"Requests with unknown EDNS versions is expected client behaviour
should not be trued as an attack The correct"

should be:

"Requests with unknown EDNS versions is expected client behaviour
and should not be construed as an attack.  The correct"

change "should" to "and should"
change "trued" to "construed"
change "attack" to "attack. "

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-01.txt

[Mark Andrews]

In message 
, Bob Harold writes:
> Section 4.  Firewalls and Load Balancers
> 
> "Requests with unknown EDNS versions is expected client behaviour
> should not be trued as an attack The correct"
> 
> should be:
> 
> "Requests with unknown EDNS versions is expected client behaviour
> and should not be construed as an attack.  The correct"
> 
> change "should" to "and should"
> change "trued" to "construed"
> change "attack" to "attack. "

Added to next version.
 
> -- 
> Bob Harold
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

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

Re: [DNSOP] new Resource record?

[Viktor Dukhovni]

On Thu, Dec 10, 2015 at 09:56:26PM +0100, Hosnieh Rafiee wrote:

> > Second, from the quick description, I don't quite understand what you want
> > to solve.  Not complaining, but in preparing to ask for a new type, the
> > use case might need to be clearer.
> 
> Authentication and authorization in multi-tenancy environment where it is
> based on certificates and TLS and not giving direct access to resource
> policy that belongs to the owner of infrastructure while at the same time
> giving flexibility to each tenant to delegate all or a part of its resources
> to third party.

This is still much too vague.  Is the goal here to turn DNS into
something akin to "Active Directory"?  Perhaps a better design is
to use DNS primarily for cross-organizational key management (solving
the "introduction" problem), and to leave more fine-grained security
policy storage to dedicated services such as Kerberos, ...  There've
been mutterings of facilitating cross-realm Kerberos via DANE, thus
avoiding the need for manual pairwise shared keys.


> I actually asked in the mailinglist whether their charter is open to having
> the bounding of authentication and authorization there since the purpose
> would be also use DANE. But what I heard (in private message exchanges)
> that they do not want to recharter to consider this.

I was one of the off-list responders.  I still think the scope was
much too broad (not well defined), and that a more narrow definition
would likely suffice, probably just use DANE TLSA to secure the
transport, and do everything else at higher layers (above the DNS).

A requirements draft might be the right starting point, and "aaa"
is much more of a topic for "kitten" than for DANE or DNSOP.

-- 
Viktor.

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

Re: [DNSOP] I-D Action: draft-lee-dnsop-recursion-performance-improvement-00.txt

[Mark Andrews]

In message <20151211173028.ga27...@nic.fr>, Stephane Bortzmeyer writes:
> On Fri, Dec 11, 2015 at 09:21:32AM -0800,
>  internet-dra...@ietf.org  wrote 
>  a message of 42 lines which said:
> 
> > Title   : An approach to improve recursion performance 
> > Authors : Xiaodong Lee
> >   Hongtao Li
> >   Haikuo Zhang
> >   Peng Zuo
> > Filename: draft-lee-dnsop-recursion-performance-improvement-00.
> txt
> 
> At the first reading, I do not see the difference between your RQID
> and a cookie, as documented in draft-ietf-dnsop-cookies (currently
> past working group last call and sent to the IESG).

It's half of the client half/part of a cookie.  I would also suggest
not just accepting responses without the option but rather fall back
to port randomisation.

We were planning to switch back to a fixed port.  The only question
was for the first query and retry with a random port if one didn't
get the cookie option in a reply or to only send using the fixed
port when you know that cookies are supported by the server.  The
choice of which strategy to employ is really dependent on the uptake
of cookie support in servers.

At 50%+ deployment the first strategy should give the greatest
benefit.  Before that the second strategy should be the winning
one.

Mark

> If there is a difference, and a reason why you just don't use DNS
> cookies, please document it.
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

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