Hello Aditya, On 28 Jul 2026, at 13:10, Aditya Ghosh wrote:
> I haven't seen Carsten’s reply on the list yet, so I would appreciate it if > you could clarify the points he made. please find my response to Ondřej below. As I replied to Ondřej's first email, it also did not make it to dnsop (which should be now fixed): On 20 Jul 2026, at 10:14, Carsten Strotmann wrote: > Hello Ondřej, > > thank you for your feedback. Below is my view and motivation behind > NTA-feed-zones. > > Keep in mind that I mainly see the enterprise / organisational networks > (universities, NGOs etc) as the target audience (because these are the > networks I see most as part of my work, and where I know the pain of the > operators). > > On 19 Jul 2026, at 14:35, Ondřej Surý wrote: > >> Hi, >> >> I briefly looked at the I-D and I think this is a wrong solution to a wrong >> problem. >> >> If the need for NTA is so ubiquitous that it requires automated solution >> than we >> are doing something wrong with DNSSEC that it became so unreliable that we >> need to punch holes in it. >> > > The reliability of DNSSEC is not the problem. In my view, DNSSEC is reliable > enough. There will always be some hickups, and nothing we will do on the > technical level will prevent issues with DNS or DNSSEC (same with any other > protocols). Humans are Humans. > > The problem is risk, and who takes the risk. > > Often when I teach DNSSEC, or when I try to convince operators to enable > DNSSEC validation, I see that the operators are not willing to take the risk. > No matter how small the risk is, there is always some risk in enabling DNSSEC > validation. > > We (in the DNS/IETF community) know the risk is minimal, the risk outweighs > the benefits. But for the operators, it is additional risk that they do not > want to take. This can be a roadblock for DNSSEC validation deployment (in > enterprises and similar networks). > > NTA-Feed-Zones enable DNS resolver operators to outsource the risk of DNSSEC > resolution issues. They can find a vendor or some other party, pay them for a > NTA-feed, and sleep better. > > For us in the DNS community, we can judge the risk of DNSSEC validation > failures, and we would probably never outsource the risk. But we have deeper > insight, and we can "fix DNS" ourself. > >> I would rather support Johan in his efforts to make the rollover more >> automated >> and smooth than develop yet another horrible band-aid that we will have to >> deal >> for eternity. > > key rollover is not the main problem. Yes, a key-rollover incident was the > trigger for the draft work, but the problem (and idea) existed before the > incident. > >> This community has really bad habit of panicking over singular >> incidents and we are still hurting badly from serve-stale because of single >> provider >> had an outage. This time there was a different outage and I would rather >> focus >> on preventing large scale outages than adding more ducttape around the camel >> to hold its burden. > > NTA-Feed-Zones would be optional (to implement and to use). > > I see a use-case for NTA-feed-zones in very specific networks (enterprise and > similar networks). > > I envision there will be never much "use" of NTA-feed-zones (in that there > will be NTA provisioned in the zones), they act more like an insurance policy > (you have them, but you hope you never need them). > > What bad outcome do you see when NTA-feed-zones become a thing? > > What can go wrong? > > What would be the negative effects of deploying them? > > I would like to be able to compare the risks and benefits of NTA-feed-zones. > > So far I see more benefits. > Greetings Carsten _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
