Re: [dmarc-ietf] org domain and levine-dbound and dns-perimeter drafts

[Alessandro Vesely <[e-mail]>]

On 19/11/2020 21:33, Todd Herr wrote:
> On Thu, Nov 19, 2020 at 7:39 AM Alessandro Vesely <[e-mail]> wrote:
>> On 18/11/2020 22:33, John R Levine wrote:
>>>> On 11/18/2020 12:44 PM, John Levine wrote:
>>>>> so I encourage the group to limit the debate to the existing Org/PSL
>>>>> kludge and a tree walk.
>>>>
>>>> "and a tree walk" is not a minor 'and'.  neither conceptually nor
>>>> operationally.  assurances to the contrary notwithstanding.
>>>
>>> I didn't say they were equivalent.  But I do think they are the only
>>> options that are likely to get much interest from the WG. >>
>> I don't think tree walk is a viable option, as it distorts semantics.
>>
> Forgive me, but I don't know what you mean by the phrase "distorts
> semantics"; can you please help me understand?


The current semantics considers an Organizational Domain to be the expression 
of the organization itself, the organization's master domain.  That's quite 
nearly what the PSL strive for.

Tree walk, instead, discards any organizational boundary.


> As for the viability of a tree walk, it is possible in complex environments
> to have something resembling the following:
> 
>     - RFC5322.From domain - a.b.foo.com - _dmarc.a.b.foo.com non-existent
>     - _dmarc.b.foo.com record exists, p=x, rua=r1
>     - _dmarc.foo.com record exists, p=y, rua=r2
       - _dmarc.com record doesn't exist, for the time being.


> On the other hand, one might infer from the DNS records that are published
> that their intent was for a.b.foo.com to inherit x for the policy and r1 as
> the destination for aggregate reports from the b.foo.com record; this would
> be an error on their part, because DMARC does not currently support
> discovery of the record at _dmarc.b.foo.com in this case.


Without asking them directly, we could also infer that folks at b.foo.com are 
sneakily trying to divert feedback traffic.


> The way I see it, we can choose one of three paths here:
> 
>     1. Keep things as they are, where if there is no policy published for
>     RFC5322.From, the policy is inherited from the org domain, if a policy is
>     published there


Easiest and safest option.


>     2. Change the spec so that the only policy lookup done is for the
>     RFC5322.From domain, and if there's no policy there, then DMARC doesn't
>     exist for that domain


SPF experience shows that large domains don't have the ability to maintain a 
script that defines suitable DNS records for all their subdomains.  This would 
force inconsistent usage of '*' domains.  BTW, as of your example, we have:

ale@pcale:~$ dig _dmarc.b.foo.com txt

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> _dmarc.b.foo.com txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44418
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ab33c1fc9c9860b18b1294575fb788126f7a88216eadcab7 (good)
;; QUESTION SECTION:
;_dmarc.b.foo.com.		IN	TXT

;; ANSWER SECTION:
_dmarc.b.foo.com.	600	IN	TXT	"v=spf1 -all"

;; AUTHORITY SECTION:
foo.com.		250	IN	NS	ns2.digimedia.com.
foo.com.		250	IN	NS	ns1.digimedia.com.

;; ADDITIONAL SECTION:
ns1.digimedia.com.	172450	IN	A	23.21.242.88
ns2.digimedia.com.	172450	IN	A	23.21.243.119


>     3. Change the spec so that policies published between the RFC5322.From
>     domain and the organizational domain can be discovered, in order to support
>     the most flexibility across organizations.


Besides making a lot of confusion about where policies and feedback addresses 
might come from, this feature inflates DNS queries more than it is desirable. 
If you have From: DoS <ugh@a.b.c.d. ... x.y.z> you have to look up each 
subdomain in the required order.  (Maybe you can check if z exists, and in case 
if m.n.o. ... x.y.z exists, and so on in a dichotomic anti-DoS tactic.  Hm...)


Best
Ale
--