All Thanks for this highly entertaining and also information conversation. I apologize for kicking up the dust but I feel this is one of those conversations where the end-users/operators and protocol people are disconnected. I do know when we talked with several DNS providers about a standard was of synthesizing names at the apex, we encountered a similar level of pushback. Most of them spent the time explaining how sophisticated their method was over Vendor Y.
But I don't think it's an impossible problem to solve, and this thread is full of very smart people attempting to do that. I admit I look at this problem too much through the lens of someone who thinks about operational issues. (I am probably not the only one here who was paged in the middle of the night when someone rolled out 9.12 without reading the fine print). What we do know is: - We're not going to do SRV records (sorry Mark). - We're not going to ask the IAB to give a waiver on DNSSEC. - We still bang into each other over this. The chairs have decided to set aside some time in Montreal and see if we can work through this problem. We've asked Ondřej from ISC and Willem from NLnetLabs to help guide the talk. Thanks Tim On Mon, Jun 25, 2018 at 1:00 PM, Paul Vixie <p...@redbarn.org> wrote: > > > Tony Finch wrote: > >> Paul Wouters<p...@nohats.ca> wrote: >> >>> I understand, I just disagree this is the right way. I don't see why >>> this entire problem shouldn't be resolved at the well, resolver level. >>> >> >> I don't see how that can be deployed in a way that is compatible with >> existing software. >> > > there are now a half dozen x.x.x.x (where x is the same in all four > octets) public anycast resolvers. if they can all be upgraded to handle > dnssec or ECS, they can all be upgraded to handle something like ANAME. > > the "resolver" here is the recursive, not the stub. stubs believe what > they hear, for good or ill. if we need to change what they hear, it's not > as impossible as changing what they understand. > > -- > P Vixie > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
