On 12/12/2018 8:59 AM, John Levine wrote:
In article <[email protected]> you write:
So I think that the functional goal of kitterman-dmarc-psd is fully
satisfied by merely doing a version of the 3A update to DMARC, directing
the client to query the immediate parent of the organizational domain,
if the OD has been queried and no DMARC record has been found.
Given that anything we do to handle public suffix defaults will need
some code changes, this seems about the simplest change that would do
the trick.
I am aware of two security or privacy issues that might come up. If
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?
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)?
> The DNS operator can tell that someone is asking about a subdomain,
> but not which subdomain.
Sorry but I don't understand this. A bout of densitude has enveloped
me. Please explain, pedantically.
The other is that the DMARC record might have rua= and ruf= and get
detailed reports about subdomains. This is not an unreasonable concern --
I am the legacy registrar for various <geographic>.ny.us domains and
my DMARC reports tell me a lot about one of my registrants who sends
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'm now guessing that your note is primarily (or completely) about the
basic, potential dangers of having a default DMARC record in a public
registry, rather than being about the refinements to the PSD spec I've
suggested?
One issue that is not our problem but might be Scott's is that in
ICANN contracted TLDs, they're not allowed to publish TXT records at
_dmarc.BANK or _dmarc.INSURANCE unless they apply to get special
permission to do so. I happen to know the people who evaluate the
applications (as do many other people here) and I'm sure they would
say yes for those two TLDs, but it would involve some time and money.
This might actually be a feature, since a similar appplication for
_dmarc.XYZ or _dmarc.SUCKS would be treated with a lot more
scepticism.
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...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
