Folks, Howdy.
This note is the result of some offline discussions, patiently helping me to work through the purpose of the kitterman-dmarc-psd. After some false starts, here's where I landed:
I believe the registry created by kitterman-dmarc-psd is not needed. More generally I believe the proposal spec can be considerably abbreviated.
1. If the registry is to constrain which public suffix operators are constrained to assert a default record, then I'll claim that's a false sense of security, given the range of unrelated and even more serious powers a parent domain can exert over a subordinate one.
2. If it is to avoid wasting a DNS a query to a record that won't be there, that's false economy. Most queries to the registry will fail. And most queries to both the From: domain name and its organizational domain already fail. The incremental cost of a wasted query to the organizational domain's parent is pretty small.
And the cost of creating and running a query-able database that is kept current is high and error-prone (as the existing PSL demonstrates.)
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.
That is, making DMARC have a 3-level lookup sequence rather than two, where the additional one is the same as for the organizational domain, except one level higher.
Thoughts? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
