From: Olafur Gudmundsson [mailto:o...@ogud.com] Subject: Re: [DNSOP] discussion for draft-woodworth-bulk-rr-00.txt > > On Nov 2, 2015, at 12:28 AM, Woodworth, John R > <john.woodwo...@centurylink.com> wrote: > > See inline comments: > > > > > -----Original Message----- > > > From: Edward Lewis [mailto:edward.le...@icann.org] > > > Subject: Re: [DNSOP] discussion for draft-woodworth-bulk-rr-00.txt > > > > > > Process wise, you should seek to have this on the experimental track. It > > > has potential but is far from a sure thing. > > > > > > > Edward, Thank you very much for your time. I will need to research more in > > regard to the experimental track, thank you. Any more advice you could > > offer here would be great. > > > > This is a quite interesting proposal, too early to tell what track the > document > should be on, for now Standards track is fine. >
Olafur, First thanks for the feedback. As advised I have done some research regarding the experimental track and being new to the process it seems to me it could be the "kiss of death" for this proposal. > > > > The idea of being able to send formulas for generating responses, > > > particularly for address records, reverse map and CNAME is a latent need > > > in the DNS hosting industry. These types are special in that way, so it's > > > no surprise they are singled out. > > > > > > I'll admit that I read and scanned portions to get an idea of what is > > > discussed. I do like that you have the section 7.1, addressing DNSSEC. > > > > > +1 > > > > > > One "red flag" to me is the idea of hidden wildcards. One of the design > > > principles of DNSSEC is that it exposes the "thinking" process of the > > > server to the requestor. That alone isn't a dead end - hidden records and > > > on-the-fly signing would "work" (but as you note not all name server > > > implementations have the ability to sign on-the-fly). > > > > > > > Good point. Our reasoning behind this was to avoid undue discrimination. > > Many providers, especially in the context of "anti-spam" make seemingly > > arbitrary decisions to block or disable huge batches of addresses based > > on coin-toss accuracy. I've personally seen the simple changing of "dyn" > > to "static" in a hostname make all the difference and wanted to entirely > > avoid this set of circumstances where possible. By hiding the fact the > > records are part of a pattern (i.e. hiding a "BULK" RR request with the > > same owner) the generated records are no longer susceptible to this form > > of discrimination. Since one of our primary motivations was in essence to > > provide $GENERATES which could AXFR there is a zero externally-identifiable > > change to $GENERATEd records (i.e. no change to operational support). > > > > I understand you want the way to minimize the zone transfers, and not > expose to the world your auto generate rules. IMHO this limits your > operational to 3 options > > a) no DNSSEC > b) on-line signing DNSSEC > c) delegate to zones that are either a) or b) > > The option of modifying resolvers is likely to hinder the deployment > of the proposal as the community that your are trying to trick > are <rant suppressed> . > > One way is that your document can be simplified is by dropping any > attempt to support off-line signed zones. > > I do not see this as operational complication as in most cases BULK > records will be interpreted by servers that are under a single > administrative control. Very true. The off-line signed zones are definitely the most complex part of our proposal. We originally thought this feature (NPN) should be broken out separately but did not want to leave this obvious condition unaccounted for and felt a self-contained solution would be best. I will revisit breaking the NPN out of this document and into its own (my gut tells me experimental track). This way, at least the solution is available for where pre-signed zones may make more sense. The NPN also seems to fit better as a DNSSEC specific feature and will most definitely find a very dedicated opposition. > > > This, of course, is negated where pre-signed DNSSEC records are used and > > supplemental "NPN" records are required. In this case, hiding the wildcards > > would prove moot for this purpose. However, the NPN record provides a > > level of transparency for DNSSEC's "thinking" process while also offering > > some additional protection against would-be attackers probing DNS for a > > zone's internal organizational structure a la NSEC. > > > > > > > > Cutting to the chase, there are various elements here that could work > > > together. But also combinations that wouldn't work so well. Simply put, > > > this is complicated. For reasons I'll not include here, complicating the > > > protocol isn't leading in the right direction. > > > > > > > Before continuing let me state your opinion is greatly respected and > > appreciated and my enthusiasm should not be taken as disrespect toward you > > or your comments in any way. > > > > While I wholeheartedly agree this adds a fair amount of complexity to the > > authoritative side of the equation, disregarding DNSSEC the burden on the > > recursive side is unaffected. Where DNSSEC is required and on-the-fly is > > available, the recursive side is just as unaffected. Where DNSSEC is > > required and on-the-fly is unavailable, we feel this complication is > > unavoidable. > > > > A big compliment to you for thinking about how to support DNSSEC > IMHO on-line signing is the only realistic way forward, as the there is little > motivation by resolvers operators that you want mostly to affect to run > modern stuff. > > > When placed into a similar context as DNSSEC and the complexity of > > recursively chained cryptographic validation the added complexity supporting > > these records would add is relatively trivial. > > > > This is not a question of complexity, it is about inertia. > <snip> > I had not thought of it this way. This makes a lot of sense, thanks again. Best regards, John > > > Best regards, > > John > > > > Olafur > This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
