On Fri, Feb 17, 2023 at 4:06 PM tjw ietf <tjw.i...@gmail.com> wrote: > John > > Paul is right. As an operator one thing I always obsess on in is the data > in my zones. Why is it there , should it be, etc. Another example you may > understand is “who created this incorrect DMARC record?” > > I’ve given them much much feedback. I am eager for others to sound off. > > And Brian, I appreciate your comments but i do wish you read the drafts as > well. > > Sorry, busy day with DNS-OARC, and $day-job .
Have read the draft, and my comments are no different. BTW, there is a related (dove-tailed) thing, which is a de-facto "standard": Domain Connect (DC). DC is something that was developed at my employer, but maintained by a wider community. DC provides an interoperable mechanism for providers of services which need DNS entries, to supply the domain owner (registrant) specific parameters and a reference to a template to a DNS operator. The domain owner authorizes the update to their DNS (via authenticating to DNS provider), and the DNS provider processes the resulting record set and adds it to the zone. DC templates generally are of the key/value pair structure, with the "value" typically being specific to the customer, such as a validation string. So, not only do I agree with the proposed draft, I specifically note that having this BCP will work with DC, and that the two things both make it a lot easier for actual end users (who no longer need to copy and paste at all). BTW, one of the tasks I currently have at $day-job is to pick up the expired draft for domain connect, find the correct home for it (possibly here), and get it to a usable state that can be published (one way or another... informational, experimental, or standards track; independent stream or WG.) As I said, it is in use with a fair number of DNS providers and a larger number of providers of services (such as email, web hosting, etc.) More info for those interested (including the expired draft specification) are at domainconnect.org. Brian > Sent from my iPhone > > > On Feb 17, 2023, at 18:47, Paul Wouters <p...@nohats.ca> wrote: > > > > On Fri, 17 Feb 2023, John R Levine wrote: > > > >> Surely we know people who run services that use DNS validation. How > about talking to some of them and finding out what kind of user errors they > run into? > > > > The insinuation here is that we didn't talk to them. One of the authors > > is at salesforce, who is a big deployer of this. We talked at a number > > of IETFs to various people and listened to them. One of the dnsop chairs > > also has quite some experience in this field and read previous drafts > > and gave us advise from their viewpoint. > > > > But also, the pain is not felt at the people who dictate how to use > > their DNS validation scheme. It is with the DNS administrators finding > > a bunch of unrecognisable DNS records and not knowing what the hell > > they are for and whether they can or should be deleted. Or those admins > > that now see their APEX going back to TCP (yes dig txt cnn.com gets TC > > and falls back to TCP) > > > >>> (Caveat, I'm responding to this thread, not to the actual draft since I > >>> haven't recently read it.) > >> > >> It's not very long, should take about 5 mins to read. > > > > Its a feature. We try to keep it simple and clear and easy to follow. > > > > And not present people with a number of mostly equivalent ways of > > doing the same thing. In the end, it is a BCP. If you want to insist > > on using randomized prefixes with CNAMEs, make your day. > > > > Paul > > > > _______________________________________________ > > 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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
