Been thinking on this - #4 is great option. Sent from my iPhone
> On Nov 3, 2021, at 11:49, Scott Kitterman <[email protected]> wrote: > > Sure you can. In your example host1 has an a record. > > Scott K > >> On Wednesday, November 3, 2021 11:42:44 AM EDT Douglas Foster wrote: >> Correct, but you cannot query _dmarc.host1.domain because host1 is not a >> DNS domain, even though it can be a mail sender and receiver >> >> I wish DMARCv1 had not created this anomaly by using subdomains, but it is >> too late to fix. >> >> Do we leave these as anomalies, or give them the best available DMARC >> participation by ensuring that their parent policy is checked? >> >>> On Wed, Nov 3, 2021, 11:08 AM Scott Kitterman <[email protected]> wrote: >>> That's the same thing as host1.a.b.c.d.e.f.example.com, right? >>> >>> I don't think there's any special case needed to find a common parent. >>> >>> Scott K >>> >>> On November 3, 2021 2:49:03 PM UTC, Douglas Foster < >>> >>> [email protected]> wrote: >>>> Type=A, name=host1, domain=a.b.c.d e.f.example.com >>>> >>>> Assuming that we will be walking the top n levels, it is only an issue on >>>> long domain names. >>>> >>>> >>>> >>>> >>>> On Wed, Nov 3, 2021, 10:19 AM Scott Kitterman <[email protected]> >>> >>> wrote: >>>>> Would you please provide a specific example where this would be needed? >>>>> I'm not sure I understand what you mean by resource record names that >>>>> is >>>>> not a DNS domain. >>>>> >>>>> Scott K >>>>> >>>>> On November 3, 2021 10:53:07 AM UTC, Douglas Foster < >>>>> >>>>> [email protected]> wrote: >>>>>> The tree walk should address whether we do anything for domain-part >>> >>> names >>> >>>>>> that are resource record names rather than DNS domains. Such names >>>>> >>>>> cannot >>>>> >>>>>> be given a _dmarc. subdomain, so they cannot be given an exact-match >>> >>> DMARC >>> >>>>>> policy. >>>>>> >>>>>> Always doing a one-level walk from the bottom would ensure that they >>> >>> can >>> >>>>>> have a policy at the closest possible layer. >>>>>> >>>>>> On Tue, Nov 2, 2021, 10:09 PM John Levine <[email protected]> wrote: >>>>>>> It appears that Scott Kitterman <[email protected]> said: >>>>>>>> 4. Common parent domain not marked PSD. We could add a new tag to >>> >>> the >>> >>>>>>> DMARC >>>>>>> >>>>>>>> records for PSDs to indicate it's a PSD, so it's record shouldn't >>>>>>>> be >>>>> >>>>> used >>>>> >>>>>>> for >>>>>>> >>>>>>>> alignment. Getting this added to the literal handful of PSD >>>>>>>> records >>>>> >>>>> that >>>>> >>>>>>>> exist and specifying it should be used going forward is doable. To >>>>>>> >>>>>>> implement >>>>>>> >>>>>>>> this approach should produce identical (modulo PSL errors and >>>>> >>>>> omissions) >>>>> >>>>>>>> results to the RFC 7489 approach. It seems like we've decided to >>> >>> trust >>> >>>>>>> that >>>>>>> >>>>>>>> ICANN and ccTLD operators will effectively manage publication of >>>>>>>> PSL >>>>>>> >>>>>>> records >>>>>>> >>>>>>>> for policy discovery, so this leverages that trust to simplify >>>>> >>>>> alignment >>>>> >>>>>>> while >>>>>>> >>>>>>>> maintaining backward compatibility. >>>>>>> >>>>>>> This is a much better worked out version of my DNS tree climbing >>>>>>> proposal. I like it too. >>>>>>> >>>>>>> R's, >>>>>>> John >>>>>>> >>>>>>> PS: Just out of nosiness, what PSD records exist now? >>> >>> _______________________________________________ >>> dmarc mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/dmarc > > > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
