In the world of trade-offs: Having one record:
1) Can retrieve it in one query 2) Easier to specify what to publish and what to read 3) Parsing involved inspection of RDATA Having two records: 1) Need two queries or rely on ANY 2) Have to explain to the client what to publish, server has to deal with inconsistencies 3) Parsing reuses existing code I invite more trade-offs to be added. The parsing should not be in the DNS client or server, that would be buried in the client key manager and the parent provisioning systems. Each of those have to add and check a that there’s a other-wise valid signature corresponding to a key with a SEP bit set, so, they have some rewriting to do anyway. There’s no reason that a RFC 1034-style DNS server and client need to read these records. They are not used by the name server. By RFC-1034 style I am excluding DNS servers that have on-line key management built in (such as ISC’s BIND 9.7 and on - don’t quote me on version numbers, it may have been earlier). I don’t see why the RDATA presentation can’t just be a hex sequence (or Base64)….so long as the end points can read and write it. Come to think of it - we can use the TXT record for maximum flexibility! ;) Looking at these tradeoffs, I see the expense of trying to specify and explain to operators - via the tools they use - of why there are two records and what happens if they aren’t the same as far more costly than having the name server need to deal with varying formats. Yes, I know that NAPTR is also a poor example, in fact, there aren’t too many examples of varying record formats out there - except of course for TXT. (Hmmm, perhaps that is one reason why it is so popular. I mean, besides the firewall pass through and other acceptance “features.") On Apr 14, 2014, at 9:16, Matthijs Mekking <[email protected]> wrote: > On 04/14/2014 03:05 PM, Edward Lewis wrote: >> I think it is silly to burn two RR types to communicate the same >> thing. You’re inviting debate on testing and handling the two being >> out of sync. > > Would you prefer one RR type with varying RDATA format (like with > IPSECKEY)? I don't. > > Best regards, > Matthijs > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
