ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Ticket #10: public key example -- no change needed

2011-04-26 20:57:37
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