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