Ben Schwartz <[email protected]> writes: > We could simply say that LocalRoot as a whole is an optional > extension, but I really like LocalRoot, and would like to see it > deployed to most resolvers. (It may end up being valuable for > privacy.)
Well, all RFCs are fundamentally optional. That makes it interesting sometimes, but there is no mandate to follow anything in particular (and it's clear that some implementations of some protocols pick and choose which they say they're supporting). We need the *industry* to agree to decide to request those features and to deploy the things we really care about. > > IXFR actually isn't useful for signed zones, as the IXFR content ends up > > being about the same size after every zone signing. > > Interesting! I don't understand why so many RRSIGs need to change in > every revision, but I assume that is hard to fix now. RRSIGs as you know have an expiration time that is frequently short lived. Some operations use 3-day long RRSIGs and I've heard of others that use a year. All depends on your security threat analysis. Some implementations do incremental signing, signing only some records in a zone over time (in which case IXFR is great) while other deployments resign the entire zone at once (in which case IXFR may not be the right choice). The root zone always resigns, and on average 2x a day (sometimes 3-ish) and uses 14 day RRSIGs. > >> The proposed "root zone publication points" system effectively > >> introduces a hard dependency on HTTP, to accomplish the equivalent of > >> what DNS Priming does in-band. > > > No, it says that both AXFR and HTTP records should be available for use. > > Yes, but how do you get that list? (Presumably via HTTP.) There are two separate elements that need to be considered separately: 1. How do you get the root zone data and from where? This is the list of publication points and the document spells three ways to get it at run time: local config, compiled defaults (like root.hints now), and from a new IANA source over HTTP. It would be pretty easy to simply refetch the list from cron once a week, which would require no HTTP support within the browser itself. 2. How do you get the contents of the root zone from one of those sources. In which case, AXFR is one option that is not going away (and the guidelines document suggests it should always be an option in the sources) and HTTP(S) is another option. Some implementations would require AXFR and likely all implementations can use it. Others may prefer HTTP(S). -- Wes Hardaker Google _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
