On Wed, 12 Dec 2018, Dave Crocker wrote:
we used a DNS scheme like my DBOUND one, whoever runs the DNS policy
server can see all the queries and will have some idea of the mail
traffic from various names. This approach doesn't have that problem.
1. Doesn't the query to the registry suffer the same risk?
2. I'm not sure what a "DNS policy server" is. I'm guessing it's meant as a
DNS server that contains the dbound-ish records?
For #2, that's right. For #1, my DBOUND scheme does a lookup which
includes the full name, e,g, if you're checking the boundary for
foo.bar.com it looks up foo.bar._dbound.com. It will likely be
matched by a wildcard *._dbound.com, but the query's in the logs. With
your scheme it just looks up _dmarc.com.
3. Given queries for MX record, don't we already have massive exposure of
this privacy-related info in DNS activity? How would this be so much more
(and/or worse)?
Particularly with large passive DNS databases, you're right. I believe
that Scott's point was that we can try not to make it worse.
a lot of mail. (Real mail, they're the county govermnent.) This is
easily addressed by clients ignoring the report advice in the OD
parent record.
What does it mean for a /client/ to ignore the advice in the OD parent
record? I thought that record was for servers.
I meant the DNS client, which is likely to be the mail server receiving a
message.
This invites an exercise at writing a policy directive to characterize the
types of TLDs that are good candidates for saying yes and those that are good
candidates for saying no. The most useful part of such a document would be
charactizing 'types' of registries...
That's already done. Some limit registrations to identified members of a
community, some don't. You can argue how well those limits are enforced
(what am I doing with names in .aero and .travel?) but the principle is
clear enough.
Regards,
John Levine, [email protected], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
