<div dir="ltr"><div class="gmail_default" style="font-size:small">As folk who are following a certain FB page know, I am configuring a BIND server direct for the first time in a while and so just for the heck of it, I decided to configure using only sources that I find on the Web that are not actual manuals.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">This has turned into an audit of the 'advice' out there. Some of the best is n how to generate TSIG keys. Take this for example:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(29,33,41);font-family:Helvetica,Arial,sans-serif;font-size:14px">$echo $(date) | openssl base64</span><br></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(29,33,41);font-family:Helvetica,Arial,sans-serif;font-size:14px"><br></span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(29,33,41);font-family:Helvetica,Arial,sans-serif;font-size:14px">Because 2^20 is a huge key space for any attacker to brute force.</span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(29,33,41);font-family:Helvetica,Arial,sans-serif;font-size:14px"><br></span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(29,33,41);font-family:Helvetica,Arial,sans-serif;font-size:14px">And then there was this gem:</span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(29,33,41);font-family:Helvetica,Arial,sans-serif;font-size:14px"><br></span></div><div class="gmail_default" style=""><p style="font-size:14px;margin:0px 0px 15px;color:rgb(56,56,56);font-family:merriweather,Verdana,Helvetica,Arial,sans-serif">The public key, <strong>kprod.tsigkey.+157+57861.key</strong> contains:</p><pre style="font-size:13px;padding:9.5px;font-family:Monaco,Menlo,Consolas,"Courier New",monospace;color:rgb(51,51,51);border-radius:4px;margin-top:0px;margin-bottom:10px;line-height:20px;word-break:break-all;word-wrap:break-word;white-space:pre-wrap;background-color:rgb(245,245,245);border:1px solid rgba(0,0,0,0.15)">prod.tsigkey. IN KEY 512 3 157 wzs+I/9e6CthD0BT3Uh00w==</pre><p style="font-size:14px;margin:0px 0px 15px;color:rgb(56,56,56);font-family:merriweather,Verdana,Helvetica,Arial,sans-serif">While the private key, <strong>Kprod.tsigkey.+157+57861.private</strong>contains:</p><pre style="font-size:13px;padding:9.5px;font-family:Monaco,Menlo,Consolas,"Courier New",monospace;color:rgb(51,51,51);border-radius:4px;margin-top:0px;margin-bottom:10px;line-height:20px;word-break:break-all;word-wrap:break-word;white-space:pre-wrap;background-color:rgb(245,245,245);border:1px solid rgba(0,0,0,0.15)">Private-key-format: v1.2<br>Algorithm: 157 (HMAC_MD5)<br>Key: wzs+I/9e6CthD0BT3Uh00w==<br>Bits: AAA=</pre><p style="font-size:14px;margin:0px 0px 15px;color:rgb(56,56,56);font-family:merriweather,Verdana,Helvetica,Arial,sans-serif">Now that we have generated the DNSSEC keys, we need to put them to use and incorporate them into our configuration.  </p><p style="margin:0px 0px 15px">This is the sort of explanation where a little bit of knowledge hinders rather than helps. And I hadn't spotted the reference to 'DNSSEC' until I cam to cut and paste.</p><p style="margin:0px 0px 15px"><br></p><p style="margin:0px 0px 15px">This is really not acceptable. In 2018 we have to set a different standard for security: </p><p style="margin:0px 0px 15px">A protocol is not secure unless the typical administrator following the line of least resistance to do their job is likely to configure it correctly.</p><p style="margin:0px 0px 15px">This is essentially the old orange book criteria 'secure by default'.</p><p style="margin:0px 0px 15px"><br></p><p style="margin:0px 0px 15px">OK so how do we get from where we are to where we should be?</p><p style="margin:0px 0px 15px">In the short term we need a set of instructions on how to configure DNS securely that has had some expert review. And by 'secure' I mean, conforms to a high level of security best practice not 'we haven't had issues with this'. Whether ICANN/IETF/OTA is best for this, I don't know but it needs to come into being.</p><p style="margin:0px 0px 15px">Another thing we should do is to remove as many prat-falls from the process as possible. TSIG is an adequate approach to authenticating zone transfers, it is not an adequate approach to managing authentication secrets. These should always be public key pairs.</p><p style="margin:0px 0px 15px"><br></p></div></div>