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 <skl...@kitterman.com> 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 < > > > > dougfoster.emailstanda...@gmail.com> 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 <skl...@kitterman.com> > > > > 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 < > > >> > > >> dougfoster.emailstanda...@gmail.com> 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 <jo...@taugh.com> wrote: > > >> >> It appears that Scott Kitterman <skl...@kitterman.com> 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 > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
