On Tue, 19 Apr 2011, Marc Lampo wrote:
The present document states, "neutrally", that double-sign rollover involves more signatures and hence, larger zone files. While this is true, well maintained (public) zone files should be small anyway (except for tld's). The average company does not offer hundreds of services on hundreds of IP addresses.
In almost all enterprises and government locations I have seen, there is one very large dhcp based zone, with thousands or tens of thousands of entries in a single zone. Picking the latest customer I was at, these are the top sizes: [paul@bofh]$ for zone in intranet/*ldns; do wc -l $zone | sed "s/ .*$//"; done | sort -n -r | head -10 144711 132489 52430 41155 20312 17326 15087 11196 10289 8587 These zones, all hosted on the same primary server, would see an additional half a million RRSIGs with a double-sign rollover. And for redundancy, this customer also loads all their auth zones on most of their name servers globally, and it would surely mean they need to upgrade hardware just to comply with this recommendation. -1 for this recommendation. TLDs are not that special in size. Whether this is "well maintained" or "public" I will not judge on. It is just what I encounter in the wild.
A DNS administrator who leaves data like "test-mx" in hers or his public data should learn not to publish anything not meant to be distributed.
I don't think 4641bis is supposed to make any value judgement about DNS data. Nor in fact, do we really know what other new RRTYPE records (like HASTLS and TLSA) will end up in the "well maintained public zone files". 4641bis should be about what is safe for the general use. If anything, TLDs are less important for 4641bis because I expect TLDs to have DNS experts that can make their own judgement and interpretation, whereas 4641bis will hopefully be a "default" setting for most DNS servers/signers for organisations with less embedded DNS skills. Paul _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
