On Jul 17, 2023, at 20:10, John Levine <jo...@taugh.com> wrote: > >> I’m sure there are still plenty of tools crafting dns packets or using >> simplistic tools that are not able to do TCP or DNSSEC. > > I'm sure there used to be, but in 2023? Really? An example or two would be > intersting.
As most of the people implementing this write in house code and are not DNS engineers, we won’t know. Again, for my $dayjob, where we are also in need of customer proof of ownership of domain, the engineers started mucking with python-dns DNS queries until I told them to use python-unbound. So yes, if they didn’t have a dns engineer on staff they would have ended up with partial UDP packets and possible false negatives in their code. >>> It’s literally what happened to me in the first week of my current $dayjob. >>> I found 5 tokens that no one knew what they were, whom they were >> for and whether or not they were still needed. > > Um, no. John, please do not make claims about my experiences. They are mine not yours. > I believe you don't know what they were, but that doesn't mean > anyone or anything thought that a token for A was a token for B. I didn’t claim that. Perhaps reread what I wrote. I said no one within the the company knew what or whom these were for. I did not say anything about collisions. > Anyway, we agree that adding a bunch of extra stuff to SPF results is a bad > idea and > that's sufficient motivation to tell people to use _names for their tokens. It’s interesting that you care about SPF TXT records needing to parse through other TXT records, but didn’t seem to care about domain validation TXT records needing to parse through SPF TXT records. Paul, respectfully agreeing with Brian _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
