Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-chain-query-03.txt

[Paul Wouters]

On Tue, 6 Oct 2015, Shane Kerr 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   : Chain Query requests in DNS
Author  : Paul Wouters
Filename: draft-ietf-dnsop-edns-chain-query-03.txt
Pages   : 15
Date: 2015-10-03


I've updated the draft based on your review and that of Evan Hunt.


* I note that the terminology section has been superseded a bit by the
 terminology draft, now approved for an informational RFC. I didn't
 follow that work too closely, but I notice that that document
 declares that "validating resolver" is referred to but not defined
 anywhere... and then uses the term "validating resolver" later in the
 document! :P

 Anyway, the soon-to-be-RFC still doesn't seem to define the two terms
 you want, so you may be stuck with defining them.

 You may want to also use "Forwarder" rather than "DNS Forwarder", as
 that seems to be what is in the terminology draft.


I've cleaned this up a bit, and will try to find PaulH tomorrow to talk
about the lack of a term for full resolver.


* It's not clear whether answers should always be limited to TCP or
 something like DNS cookies, or whether this is only for answers more
 than 512 bytes. I assume always, but this text implies only sometimes:


I clarified it to be always.


* I guess that the "Last Known Query Name" disallows compression as
 part of a general rule for queries. That's fine. It might be
 worthwhile changing "No compression is allowed for this value." to
 say "No DNS name compression is allowed for this value." just to be
 completely clear.


done.


* The discovery mechanism seems to imply that a DNS Forwarder that has
 not done discovery MUST NOT use this option. My own feeling is that
 this is not true (a forwarder could just add the option to the first
 packet and do just-in-time discover, as it were). Perhaps this should
 be clarified? (Reading forward to section 5.3 shows that this is
 actually discussed!)


That is what I meant. I clarified the text.


* I don't understand the motivation for keeping query size to less than
 512 bytes.


I removed that text.


* I'm not sure about handling large responses. The advice seems to be
 to to send a REFUSED response. Should a client try again without the
 EDNS option? There are other reasons for REFUSED, and maybe it makes
 more sense to have a way for a resolver to signal to the forwarder
 the reason for the refusal, so the forwarder knows this is the best
 way to react.


Evan suggested returning partial chains, from the top down, so clients
can send multiple requests to gain the complete chain. The answer now
also contains the lowest trust point included in the CHAIN answer. So
that should address this issue.


* There doesn't seem to be advice for a resolver when support for Chain
 Query is disabled when it was previously working. Probably something
 like "A resolver MUST handle the case where a Chain Query does not
 return the full chain. It MAY change resolvers in this case. It MAY
 periodically attempt to try getting a Chain Query at that server."


I didn't address this yet. Isn't this more of a local implementation
kind of thing?


* A comment: It is possible for DNSKEY and RRSIG to time out at
 different intervals (and DS, I suppose), right?. It seems that this
 will result in a bit of extra data now and then, the resolver needs to
 specify an entire "last known query name". I think this is okay, but
 it might be possible to avoid this by specifying which particular
 records are needed. Probably that is unneeded complication for this
 case.


Evan suggested I define the Trust Point as the lowest FQDN for which you
have both DS and DNSKEY records, so that case should be covered now.
I don't think DNSKEY and RRSIGs can have a different TTL? But if they do,
then I guess the resolver will define that as "not having a validated
copy".


* A wayward thought: this technique reveals a small amount of
 information about the cache on the forwarder side in the "last known
 query name". Maybe not worth mentioning because this is basically
 irrelevant when compared to, well, all the DNS resolution the
 resolver is doing?


I did not any text for it. It's true it could leak some data if it
used more than one resolver to feed its cache, but it's pretty
arbitrary. the privacy leak is using the forwarders, whether it is
one or more.


Anyway, I support it moving forward with or without any changes.


Thanks!

Paul

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-cookies-06.txt

[Donald Eastlake]

This revision incorporated editorial improvements and improvements in
explanatory and motivational text based on comments on the WG mailing
list.

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

On Mon, Oct 19, 2015 at 5:31 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   : Domain Name System (DNS) Cookies
> Authors : Donald E. Eastlake
>   Mark Andrews
> Filename: draft-ietf-dnsop-cookies-06.txt
> Pages   : 30
> Date: 2015-10-19
>
> Abstract:
>DNS cookies are a lightweight DNS transaction security mechanism that
>provides limited protection to DNS servers and clients against a
>variety of increasingly common denial-of-service and amplification /
>forgery or cache poisoning attacks by off-path attackers. DNS Cookies
>are tolerant of NAT, NAT-PT, and anycast and can be incrementally
>deployed.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-cookies/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-cookies-06
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-cookies-06
>
>
> 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/
>
> ___
> 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] I-D Action: draft-ietf-dnsop-cookies-06.txt

[internet-drafts]

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   : Domain Name System (DNS) Cookies
Authors : Donald E. Eastlake
  Mark Andrews
Filename: draft-ietf-dnsop-cookies-06.txt
Pages   : 30
Date: 2015-10-19

Abstract:
   DNS cookies are a lightweight DNS transaction security mechanism that
   provides limited protection to DNS servers and clients against a
   variety of increasingly common denial-of-service and amplification /
   forgery or cache poisoning attacks by off-path attackers. DNS Cookies
   are tolerant of NAT, NAT-PT, and anycast and can be incrementally
   deployed.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-cookies/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-cookies-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-cookies-06


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/

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

[DNSOP] I-D Action: draft-ietf-dnsop-edns-chain-query-04.txt

[internet-drafts]

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   : Chain Query requests in DNS
Author  : Paul Wouters
Filename: draft-ietf-dnsop-edns-chain-query-04.txt
Pages   : 16
Date: 2015-10-19

Abstract:
   This document defines an EDNS0 extension that can be used by a
   security-aware validating Resolver configured as a Forwarder to send
   a single query, requesting a complete validation path along with the
   regular query answer.  The reduction in queries lowers the latency.
   This extension requries the use of source IP verified transport such
   as TCP or UDP with EDNS-COOKIE so it cannot be abused in
   amplification attacks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-chain-query/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-edns-chain-query-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-edns-chain-query-04


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/

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

Re: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dns-catalog-zones-00

[Evan Hunt]

On Mon, Oct 19, 2015 at 10:10:29AM -0700, Paul Vixie wrote:
> there's been enough churn at isc in recent years that probably noone now 
> working there remembers metazones.
> 
> muks, et al, see: .

Metazones, and that particular URL, are referenced in the draft.

I've had no significant involvement in the catalog zones design, so
I can't tell you why the metazone format wasn't used, but I'm pretty
sure there were reasons for the decision.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

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

Re: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dns-catalog-zones-00

[Bob Harold]

On Mon, Oct 19, 2015 at 1:10 PM, Paul Vixie  wrote:

> On Monday, October 19, 2015 11:32:27 Tony Finch wrote:
> > Mukund Sivaraman  wrote:
> > >
> > > ISC is implementing a zone catalog synchronization method in BIND. This
> > > is the first public draft of various ideas and suggestions that were
> > > pooled together and is named "DNS catalog zones".
> >
> > Yay! Why not call the feature "metazones" since that's the term we are
> > familiar with?
>
> there's been enough churn at isc in recent years that probably noone now
> working there remembers metazones.
>
> muks, et al, see: .
>
> > I recently hacked together a crappy version, which is deliberately dumb
> > and BIND-specific. http://dotat.at/prog/nsnotifyd/
> >
> > I didn't implement Vixie-format metazones mainly out of laziness. ...
>
> it's terribly simple. laziness can't be an excuse, it just wasn't that
> difficult! see: .
>
> --
> Paul
>
> After reading both formats, I prefer
http://family.redbarn.org/~vixie/mz.tgz - ordered lists are multiple
records and can be as large a list as needed.  No new record types needed.
If I had seen this before, I probably would have implemented it by now.  It
has been on my wish list for a while.

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

Re: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dns-catalog-zones-00

[Paul Vixie]

On Monday, October 19, 2015 11:32:27 Tony Finch wrote:
> Mukund Sivaraman  wrote:
> > 
> > ISC is implementing a zone catalog synchronization method in BIND. This
> > is the first public draft of various ideas and suggestions that were
> > pooled together and is named "DNS catalog zones".
> 
> Yay! Why not call the feature "metazones" since that's the term we are
> familiar with?

there's been enough churn at isc in recent years that probably noone now 
working there remembers metazones.

muks, et al, see: .

> I recently hacked together a crappy version, which is deliberately dumb
> and BIND-specific. http://dotat.at/prog/nsnotifyd/
> 
> I didn't implement Vixie-format metazones mainly out of laziness. ...

it's terribly simple. laziness can't be an excuse, it just wasn't that 
difficult! see: .

-- 
Paul

signature.asc
Description: This is a digitally signed message part.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-muks-dnsop-dns-catalog-zones-00

[Tony Finch]

Mukund Sivaraman  wrote:
> >
> > Name:   draft-muks-dnsop-dns-catalog-zones-00
> > Title:  DNS catalog zones
> > Htmlized:   
> > https://tools.ietf.org/html/draft-muks-dnsop-dns-catalog-zones-00
> >
> > Abstract:
> >This document describes a method for automatic zone catalog
> >provisioning and synchronization among DNS primary and secondary
> >nameservers by storing and transferring the catalogs as regular DNS
> >zones.
>
> ISC is implementing a zone catalog synchronization method in BIND. This
> is the first public draft of various ideas and suggestions that were
> pooled together and is named "DNS catalog zones".

Yay! Why not call the feature "metazones" since that's the term we are
familiar with?

I recently hacked together a crappy version, which is deliberately dumb
and BIND-specific. http://dotat.at/prog/nsnotifyd/

I didn't implement Vixie-format metazones mainly out of laziness. My
configuration is based on named ACLs and server lists (etc.) which helps
to decouple the zone configurations from the server configurations -
addresses, TSIG keys, etc. I incorrectly thought that Vixie's format was
too address-based, but in fact I could have just left out the *.servers
sub-tree and let the metazone refer to implicit out-of-zone data. I would
have had to add an allow-query subtree too.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Thames, Dover, Wight, Portland, Plymouth: Northeast 4 or 5. Slight,
occasionally moderate in Plymouth. Occasional rain or drizzle. Moderate or
good, occasionally poor.

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