Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refuse-any-01.txt

[Evan Hunt]

On Wed, Oct 14, 2015 at 09:49:59AM +0100, Ólafur Guðmundsson wrote:
> Sorry for the typo : RFC4470
> 
>   Minimally Covering NSEC Records and DNSSEC On-line Signing

Ah, thanks. Yes, the first and second points mentioned in the security
considerations there are both applicable.

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

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

Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refuse-any-01.txt

[Ólafur Guðmundsson]

On Tue, Oct 13, 2015 at 11:00 PM, Evan Hunt  wrote:

> On Tue, Oct 13, 2015 at 10:10:39PM +0100, Ólafur Gušmundsson wrote:
>
>
> > Is reference to RFC4770 security considerations good enough  ?
>
> Sorry, which RFC?  "vCard Extentions for Instant Messaging" doesn't
> seem likely to be what you meant here, but my brain is failing to
> figure it out from context.
>
>
Sorry for the typo : RFC4470

  Minimally Covering NSEC Records and DNSSEC On-line Signing


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

Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refuse-any-01.txt

[Joe Abley]

On 13 Oct 2015, at 13:30, Bob Harold wrote:

> In general, the draft looks good to me.  Minor changes suggested:
>
> Section 4 includes:
> "1.  A DNS responder may choose to search for an owner name that matches
> the QNAME and, if that name owns multiple RRs, return just one of them."
>
> I think "RRs" should be "RRSets", as in section 5.
>
> Section 5:
> "mulitple" -> "multiple"

Thanks for the review, fixed for the next rev.


Joe

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

Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refuse-any-01.txt

[Evan Hunt]

Hi Joe,

I think you need some more text in the description of pick-one-rrset,
something like:


  A DNS responder which receives an ANY query MAY decline to provide
  a complete response, and MAY instead choose to return only one of
  the the RRsets present at the node specified in QNAME, and the
  associated RRSIGs if any.

  If this approach is chosen, the following limitations apply:

   - If there is an NS, CNAME, or DNAME RRset present, then the
 responder MUST return those RRsets. (Note that DNAME can
 coexist with NS; if this is the case, both RRsets MUST be
 returned.) *

   - Otherwise, when multiple RRsets exist, the responder SHOULD
 select an RRset to return using a deterministic mechanism,
 so that subsequent queries of type ANY to the same server will
 continue to receive the same data so long as the contents of
 the node remain unchanged.  For example, the responder MAY
 choose the smallest RRset, in order to reduce the amplification
 potential of a type ANY query.

   - The responder MUST NOT choose to return an RRset of type RRSIG,
 but MUST include the covering RRSIG RRs for whichever RRset is
 chosen.


I'd suggest breaking this into a separate subsection of section 5.

I would also mention in security considerations that synthesizing
responses from a signed zone requires the private signing key to be online
and available to every responder; offline signing, or signing on the master
server only, are not possible.

* I'm not completely certain DNAME needs to be mentioned in the first
  bullet point, but I'm concerned there may be unintended consequences
  if it's present but omitted.)

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

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

Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refuse-any-01.txt

[Evan Hunt]

Belated thought: In the text about synthesized responses, I think you
should specifically mention that if the responder would normally have
returned a delegation, a CNAME, a DNAME, or an NXDOMAIN, then it MUST
still do so.

That's implied by the final paragraph of section 5, but IMHO it ought
to be explicit.

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

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

Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refuse-any-01.txt

[Evan Hunt]

On Tue, Oct 13, 2015 at 10:10:39PM +0100, Ólafur Guðmundsson wrote:
> Having DNAME and NS below a zone apex is non-sensical as both are
> "delegation records" i.e.
> NS says where to find more specific name,
> DNAME how to write a more specific name to another name.

It's legal, though.

> NS and DNAME can co-exist at zone apex, and if the ANY query is for
> the apex then it should not matter which RRset is returned from the APEX is
> returned.

That's why I qualified this point -- I'm not certain anything would
break if you chose to omit a DNAME; I'm just concerned that something
might.

In any case, I do think an ANY query for a zone apex should always
return the NS.

> If this is a delegation point I think the server SHOULD return a referral,
> i.e. NS record in Authority section.

Agreed.

> For names where there is a CNAME either the CNAME is the only RRset or
> there is a NSEC/NSEC3 RRset
> I think for backwards compatibility CNAME should be returned in this case.

Agreed here too.

> > This is an over specific recommendation and can not be enforced,
> think about the case where an operator uses any-cast and different software
> running on
> various servers.

It doesn't need to be enforced, I suggested it as a SHOULD. I think
it's better if the same server (physical server, that is, not anycast
address) behaves consistently and predictably. I don't care what
selection algorithm is used by any implementation, I just don't
think randomness is desirable.

Choosing the smallest RRset, as you suggested, is a perfectly fine
option.

> Similarly if there is a HINFO record it MAY take precedence over any other
> records by the selection algorithms.

Good point.

> Is reference to RFC4770 security considerations good enough  ?

Sorry, which RFC?  "vCard Extentions for Instant Messaging" doesn't
seem likely to be what you meant here, but my brain is failing to
figure it out from context.

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

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

Re: [DNSOP] New Version Notification for draft-jabley-dnsop-refuse-any-01.txt

[Ólafur Guðmundsson]

On Tue, Oct 13, 2015 at 7:28 PM, Evan Hunt  wrote:

> Hi Joe,
>
> I think you need some more text in the description of pick-one-rrset,
> something like:
>
>
>   A DNS responder which receives an ANY query MAY decline to provide
>   a complete response, and MAY instead choose to return only one of
>   the the RRsets present at the node specified in QNAME, and the
>   associated RRSIGs if any.
>
>
Fine


>   If this approach is chosen, the following limitations apply:
>
>- If there is an NS, CNAME, or DNAME RRset present, then the
>  responder MUST return those RRsets. (Note that DNAME can
>  coexist with NS; if this is the case, both RRsets MUST be
>  returned.) *
>
>
Having DNAME and NS below a zone apex is non-sensical as both are
"delegation records" i.e.
NS says where to find more specific name,
DNAME how to write a more specific name to another name.

NS and DNAME can co-exist at zone apex, and if the ANY query is for
the apex then it should not matter which RRset is returned from the APEX is
returned.
If this is a delegation point I think the server SHOULD return a referral,
i.e. NS record in Authority section.

For names where there is a CNAME either the CNAME is the only RRset or
there is a NSEC/NSEC3 RRset
I think for backwards compatibility CNAME should be returned in this case.

   - Otherwise, when multiple RRsets exist, the responder SHOULD
>  select an RRset to return using a deterministic mechanism,
>  so that subsequent queries of type ANY to the same server will
>  continue to receive the same data so long as the contents of
>  the node remain unchanged.  For example, the responder MAY
>  choose the smallest RRset, in order to reduce the amplification
>  potential of a type ANY query.
>
> This is an over specific recommendation and can not be enforced,
think about the case where an operator uses any-cast and different software
running on
various servers.
IMHO there is nothing wrong with picking always the same one or return
random one,
I think returning NSEC in answer section is fine for online signed zones if
there is no HINFO record, with the
exception of names where there is CNAME.
Similarly if there is a HINFO record it MAY take precedence over any other
records by the selection algorithms.

   - The responder MUST NOT choose to return an RRset of type RRSIG,
>  but MUST include the covering RRSIG RRs for whichever RRset is
>  chosen.
>
>
Fine.


>
> I'd suggest breaking this into a separate subsection of section 5.
>
> I would also mention in security considerations that synthesizing
> responses from a signed zone requires the private signing key to be online
> and available to every responder; offline signing, or signing on the master
> server only, are not possible.
>

Is reference to RFC4770 security considerations good enough  ?


> * I'm not completely certain DNAME needs to be mentioned in the first
>   bullet point, but I'm concerned there may be unintended consequences
>   if it's present but omitted.)


see above.

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