What is surreal about this brush back to make a SIMPLE change is that
it touches base with the often stated concern about DKIM DNS
management complexities as one of the barriers for adoption.
In a perfect DKIM spec world, this section should cover the expected
markets of DKIM operators to decrease the barriers:
o Creating Public/Private Keys
If your DKIM software does not offer public/private key
management, there are tools available to help:
- using OpenSSL
- using CAPI
o Publishing Public Key for brisbane._domainkey
- Using ISP managed DNS zones
- Using your *nix wienies DNS server zones
- Using your Windozes DNS Server zones
Instead, its only:
o Creating Public/Private Keys using OpenSSL
o Publishing Public Key for brisbane for *nix wienies
But the issue posting is not asking to get crazy with idealism. Only a
simple clarification is all that is needed.
If the domain considering DKIM is one that uses a ISP managed DNS zone
or has a Windows DNS Server and manages it directly via a ZONE file
or interactively, that section will throw these domains off base.
The former will get the idea he needs to add a TXT record for the
subdomain "brisbane", the result will be queries for
brisbane.<zone-domain>
Same with the interactive Windows DNS GUI method which he right clicks
"Add TXT Record" and it ask for the subdomain.
For the Windows geek who uses ZONE files directly, he may get a faster
clue the DKIM section has an incomplete example targeted at *nix geeks
because he will know record will need to be:
brisbane._domainkey TXT ("v=DKIM1; p=...")
Sure, practical insights of reduce real possible DKIM deployments
confusion is in the eyes of the beholder. My motivation is to help
reduce these questions not for US because will have the GUI softare,
but in general for all. Levine may not need help, but others might.
Adding the complete public subdomain "brisbane._domainkey" is better
than just having "brisbane" and if you must explain the initial ZONE
assumption.
--
HLS
Hector Santos wrote:
John Levine wrote:
Whether the name in the DNS record should be brisbane or
brisbane._domainkey or brisbane._domainkey.example.org depends
entirely on the most recent $ORIGIN line in the master file. If the
$ORIGIN is _domainkey.example.org, an entirely plausible scenario, the
current text is correct.
I see no reason to change it, suggest closing the ticket.
-1
Not everyone uses your unstated $ORIGIN line format, nor knows what it
is nor even is given a clue is to be presumed when its not even
mentioned in the section.
The fact is, for the the ZONE files I see Windows DNS servers, the
public key record will be shown in the subdomain format:
brisbane._domainkey TXT ("v=DKIM1; p=...")
So if the section can not be generic to cover all bases, "Being
Specific is terrific!"
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html