On December 12, 2018 3:30:20 PM UTC, Dave Crocker <[email protected]> wrote:
>On 12/11/2018 9:01 PM, Scott Kitterman wrote:
>> On Tuesday, December 11, 2018 08:17:38 PM Dave Crocker wrote:
>
>>> 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.)
>....
>
>> I think your analysis is essentially correct, but I think point 1 is
>> backwards. Since (in the current draft), based on the registry
>> entries, the third level queries will usually not take place. It's
>> not that the PSOs are constrained not to publish records (they
>> aren't), it's that no one will (should) query for them based on the
>> third level test if they aren't in the registry.
>>
>> This may seem like a small thing, but I believe it makes all the
>difference.
>> You are certainly correct that nothing in an RFC can prevent a PSO
>from
>> publishing such records. What we can do is give guidance on when not
>to look
>> at them.
>
>That's a cost-saving line of concern. My point is that the existing
>mechanism already has quite a bit operational inefficiency from queries
>that fail, so that adding one more is a minor issue, especially as
>against the considerable administrative and operational cost of
>creating
>and running a registry.
>
>
>> I believe avoiding the privacy implications of the related feedback
>> are worth the transactional costs of the registry (but then I would,
>> wouldn't I). I don't think a bad situation justifies making it
>> worse.
>
>Sorry but I don't know what privacy implications you are referring to.
>I don't even have a guess.
>
>And the draft makes no reference to privacy issues. Or rather, the
>Privacy Considerations section says the draft doesn't introduce any.
As written, it doesn't. If you change it the way you propose, it will.
Scott K
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
