Over in the DMARC working group we have this DNS application. If someone sends you a messsage from, say, [email protected]. your mail system looks for a policy record at _dmarc.sales.east.bigcorp.com. If it doesn't find one, it looks for one in the "organizational domain", in this case _dmarc.bigcorp.com.
The way we currently find the organizational domain is straight out of HOSTS.TXT. Everyone in the world periodically downloads a public suffix list from https://publicsuffix.org/list/public_suffix_list.dat and the organizational domain is one label below the longest public suffix of the name. You don't have to tell us this is ridiculous. The DBOUND WG tried to create a way to put the info in the DNS but failed for various non-technical reasons. It occurs to me that for DMARC's purposes, walking up the tree would work better than the current hack. I know it would sometimes find a different answer from what it gets now, which is OK. When this came up before, the advice was that DNS tree walks are very bad, so don't do them. Is that still true? As I understand it, the main problem with tree walks is that a malicious sender could send long non-existent names and cause floods of queries, but RFC 8020 lets DNS caches dispose of those cheaply. We know they're ugly, but in a situation like this where none of the options are great, why not? R's, John _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
