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