***************
*** 368,374 ****
That said, DKIM uses DNS to store selectors. Thus there is always
the ability for a domain holder to delegate all or parts of the
_domainkey subdomain to a third party of the domain holder's
! choosing. That is, the domain holder can always set a NS record for
_domainkey.example.com to, say, an email provider who manages that
namespace. There is also the ability for the domain holder to
partition its namespace into subdomains to further constrain how
--- 369,375 ----
That said, DKIM uses DNS to store selectors. Thus there is always
the ability for a domain holder to delegate all or parts of the
_domainkey subdomain to a third party of the domain holder's
! choosing. That is, the domain holder may be able to set a NS record for
_domainkey.example.com to, say, an email provider who manages that
namespace. There is also the ability for the domain holder to
partition its namespace into subdomains to further constrain how
***************
*** 377,382 ****
--- 378,387 ----
the third party to only be able to sign messages on behalf of the
benefits subdomain.
+ [INFORMATIVE NOTE: Not all DNS providers support separate
+ NS records for subdomains, so this approach is not universally
+ available.]
+
There have been concerns expressed about how well this would scale
when the third party is, say, a large ISP that signs for thousands of
domains. There has been concern about how well this would work for
***************
Since this scenario is aimed primarily at small non-technical domain owners
(who would be the most likely to outsource DNS services also) I think it is
important to point out that not all DNS providers support subdomain NS
delegation (personally, I mostly use two providers - one supports it, the
other doesn't). It is another reason why NS delegation is not a complete
solution.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
