At the tail of this thread, I'll add my (random) thoughts. 1) Upward referrals are an example of something that started out as a good idea, good intention, but ran into operational problems as the DNS setting changed. Early, in the late 90's, a popular DNS implementation would chase an upward referral meant to indicate a lame delegation, resulting in an infinite loop in iteration. (Better coding stopped that. See also ARIN Policy [proposal] 2002-01 as an artifact of that time.) Later, upward referrals were seen as a tool in building a flood attack, which is what cause implementations to stop using them as lame delegation notices.
2) I learned this long ago (while implementing ancient DNSSEC code) - the DNS
tree is inherently unidirectional. A parent knows about its children and not
vice versa. DNSSEC wanted to have arbitrary security chains but had to settle
for on-tree ("Domain Name System Security (DNSSEC) Signing Authority" aka RFC
3008). The same issue came into play when trying to design the "Automating
DNSSEC Delegation Trust Maintenance" - related to scaling (the parent has to
poll the children, not the other way around). (In "Detecting a Changed
CDS/CDNSKEY", the parent either polls or has to have something out-of-DNS-band:
" The delegation user interface has a button".)
I.e., trying to see referrals as going anyway but down is an uphill battle.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
