DNSSec configuration
Hello Luv members, I've recently added DNSSec signatures to my domain (jasonjgw.net), and supplied the key to my DNS registrar, gandi.net. Unfortunately, my ISP's name servers, which perform DNSSec validation, now return a SERVFAIL (indicating a validation failure) when I look up the domain. Google's public servers succeed, however, as DNSSec Analyzer appears to do: http://dnssec-debugger.verisignlabs.com/ The primary DNS server is running Bind 9 and I essentially followed the instructions here: https://nocko.se/2012/03/21/dnssec-quickly-and-correctly/ Is there anything that seems amiss? I have friends who are contemplating following in my footsteps with their own domains, thus anything we work out here should be helpful to them also.
Jason White via luv-main <luv-main@luv.asn.au> writes:
Google's public servers succeed, however, as DNSSec Analyzer appears to do: http://dnssec-debugger.verisignlabs.com/
http://dnssec-debugger.verisignlabs.com/jasonjgw.net shows an error: opera.rednote.net/66.228.34.147 returns REFUSED for jasonjgw.net/DNSKEY http://dnsviz.net/d/jasonjgw.net/dnssec/ shows a number of REFUSED errors. -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
Yeah I'd remove that authoritative name server from your registrar and NS records in your zone, then retest (obviously waiting for all the records to propagate everywhere). This is what a working validation should look like (for my domain hosted on bind). http://dnssec-debugger.verisignlabs.com/frizianz.com http://dnsviz.net/d/frizianz.com/dnssec/ Any questions let me know. Cheers, Fraser On 25/01/16 10:19, Brian May via luv-main wrote:
Jason White via luv-main <luv-main@luv.asn.au> writes:
Google's public servers succeed, however, as DNSSec Analyzer appears to do: http://dnssec-debugger.verisignlabs.com/ http://dnssec-debugger.verisignlabs.com/jasonjgw.net shows an error: opera.rednote.net/66.228.34.147 returns REFUSED for jasonjgw.net/DNSKEY
http://dnsviz.net/d/jasonjgw.net/dnssec/ shows a number of REFUSED errors.
Quoting Jason White (jason@jasonjgw.net):
Hello Luv members,
Greetings from the SCALE14x conference in Pasadena, California. https://www.socallinuxexpo.org/scale/14x
I've recently added DNSSec signatures to my domain (jasonjgw.net), and supplied the key to my DNS registrar, gandi.net.
Unfortunately, my ISP's name servers, which perform DNSSec validation, now return a SERVFAIL (indicating a validation failure) when I look up the domain. Google's public servers succeed, however, as DNSSec Analyzer appears to do: http://dnssec-debugger.verisignlabs.com/
The primary DNS server is running Bind 9 and I essentially followed the instructions here: https://nocko.se/2012/03/21/dnssec-quickly-and-correctly/
Is there anything that seems amiss?
I lack a solution, but wish to offer a data point, which being lazy, I had a Web site work out for me: http://www.dnsstuff.com/tools#dnsReport|type=domain&&value=jasonjgw.net finds no problems whatsoever with your DNSSec information. The report[1] offers tips on a number of other things, so I will comment on those, below: 1. SOA EXPIRE: $ dig -t soa jasonjgw.net @svr.jasonjgw.net +short svr.jasonjgw.net. jason.jasonjgw.net. 2016010101 3600 1200 9676800 10800 $ RFC1912 suggests a value between 1209600 to 2419200 seconds (14 to 28 days). You have 9676800 seconds = 112 days. Of course, you might have an edge condition making this desirable, but that would be rare. 2. svr.jasonjgw.net (IP 192.155.90.172) is cheerfully responding correctly to queries about its nameserver software type and verion, and OS/distro and version. On the one hand, some would say concealing this information is security by obscurity, but most sysadmins would say it's unwise to assist attackers in their preparatory task of 'resource discovery' (probing potential targets), especially without any compensating benefit. This is all derived from an unwise feature from early days of DNS called Chaosnet, a pseudo-TLD of class CHAOS publishing these data about the server: version: name version.bind, type TXT, class CHAOS hostname: name hostname.bind, type TXT, class CHAOS server-id: name ID.SERVER, type TXT, class CHAOS $ dig -t txt -c chaos version.bind @svr.jasonjgw.net +short "9.10.3-P2-RedHat-9.10.3-7.P2.fc23" $ dig -t txt -c chaos hostname.bind @svr.jasonjgw.net +short "svr.jasonjgw.net" $ dig -t txt -c chaos ID.SERVER @svr.jasonjgw.net +short $ FWIW, this is what my nameserver answers: $ dig -t txt -c chaos version.bind @ns1.linuxmafia.com +short "Shirley, you're joking" $ dig -t txt -c chaos hostname.bind @ns1.linuxmafia.com +short "ns1.linuxmafia.com" $ dig -t txt -c chaos ID.SERVER @ns1.linuxmafia.com +short $ BIND9 configuration for the above: options { [...] version "Shirley, you're joking"; hostname "ns1.linuxmafia.com"; [...] }; 3. One of your MXes (the third-priority one, opera.rednote.net) doesn't accept mail to your postmaster or abuse addresses. Example using postmaster: $ telnet opera.rednote.net smtp Trying 66.228.34.147... Connected to opera.rednote.net. Escape character is '^]'. opera.rednote.net ESMTP Sendmail 8.15.2/8.15.2; Sun, 24 Jan 2016 23:28:46 GMT HELO jasonjgw.net 250 opera.rednote.net Hello [38.98.46.140], pleased to meet you MAIL FROM: <rick@linuxmafia.com> 250 2.1.0 <rick@linuxmafia.com>... Sender ok RCPT TO: <postmaster@jasonjgw.net> 550 5.7.1 <postmaster@jasonjgw.net>... Relaying denied. IP name lookup failed [38.98.46.140] quit 221 2.0.0 opera.rednote.net closing connection Connection closed by foreign host. $ Domains sending and receiving mail are required by RFC822 6.3, RFC1123 5.2.7, and RFC2821 4.5.1 to have valid, deliverable postmaster@ and abuse@ addresses. [1] The site prorprietor allows random members of the public several free of charge uses of this CGI and then asks you to subscribe. Clearing cookies resets. -- Cheers, QA engineer walks into a bar. Orders a beer. Rick Moen Orders 0 beers. Orders 999999999 beers. Orders rick@linuxmafia.com a lizard. Orders -1 beers. Orders a sfdeljknesv. McQ! (4x80) -- @sempf, https://www.sempf.net/post/On-Testing1.aspx
I wrote:
3. One of your MXes (the third-priority one, opera.rednote.net) doesn't accept mail to your postmaster or abuse addresses. Example using postmaster:
In the middle 1990s, I had an epiphany about backup MX service. It sucks and is a bad idea on balance -- and particularly backup MX service on a machine of which you are not the administrator. 1. Spammers long ago figured out that they should drop off spam for domain example.com on the _highest_ (lowest priority) MX for example.com. Usually, the priority 30 MX host has looser (or at least different) antispam heuristics than does priority 10 MX host. Having dropped off that mail, the spammer's job is done, and now your backup MX host's antispam measures are at war with your primary MX host's antispam measures, as host priority 30 struggles to redeliver spam to host priority 10. Essentially, the former host has become collateral damage as an SMTP relay. In extreme cases, you may end up teergrubing or greylisting your relay. 2. Inevitably, you find out at the worst possible time, e.g., your unplanned downtime, that your buddy who provides backup MX for you dropped your domain from his MTA configuraiton and forgot to tell you, or has adopted some pathological practice like challenge-response or worse. Or, of course, less disasterously but annoyingly, your backup MX whimsically decided to ignore RFCs (such as accepting mail for postmaster and abuse). After contemplating these sad facts ~20 years ago, I dropped all backup MX (except for hosts I administer and on which I enforce the same antispam regime as on other hosts). This means I have an incentive to bring downed SMTP service back online before hardfail timeouts, but that's really not difficult even if your NOC took a meteor hit. It's what failover measures are for.
Thanks for the responses so far - very helpful and informative as they are. Recent versions of Bind have automatic DNSSec key/signature maintenance via inline signing. I'm tying to put that in place now.
For anyone else who is contemplating a similar path, I would recommend the following article, which explains how to set up in-line signing of zones using NSSEC3: https://deepthought.isc.org/article/AA-00711/0/In-line-Signing-With-NSEC3-in... Note that if you have /etc/rndc.key installed (the exact location may depend on the distribution), you don't need to include the rndc-related material from the sample configuration shown in the article. Also, if you're running Fedora, as my server is, you need to configure SELinux to allow Bind to write to the zone files: setsebool -P named_write_master_zones 1 Yes, I discovered this the hard way with file creation errors and audit logs. audit2allow recommended changing the above setting. Comments are welcome, as always. I have more work to do to implement some of Rick's suggestions, but that won't happen tonight.
participants (4)
-
Brian May -
Fraser McGlinn -
Jason White -
Rick Moen