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
