Does he.net support DNSSEC?
We have the following findings:-
$ dig +short rs.dns-oarc.net txt
rst.x479.rs.dns-oarc.net.
rst.x488.x479.rs.dns-oarc.net.
rst.x493.x488.x479.rs.dns-oarc.net.
"2001:470:0:c0::2 DNS reply size limit is at least 493"
"2001:470:0:c0::2 lacks EDNS, defaults to 512"
"Tested at 2010-10-02 17:16:18 UTC"
$ dig txt test.rs.ripe.net +short
rst.x477.rs.ripe.net.
rst.x481.x477.rs.ripe.net.
rst.x486.x481.x477.rs.ripe.net.
"216.66.38.58 summary bs=512,rs=486,edns=0,do=0"
"216.66.38.58 DNS reply size limit is at least 486 bytes"
"216.66.38.58 lacks EDNS, defaults to 512"
Thanks
That test is actually flawed, the recursors handle EDNS0.
As to DNSSEC, the software doesn't support it yet.
What software are you using for your resolvers? Bind and Unbound (two of the larger DNS resolvers) support DNSSEC without any problem, so I guess it's not one of those.
I'm asking because I have setup my own DNS (with DNSSEC) resolver last weekend on an old test machine that is usually powered down. It works without any problem, the only thing is that I need to leave this machine running (its just a home connection) and obviously this resolver is not using Google whitlist.
I'm looking for a resolver that has IPv6 address (for DHCPv6), is on the Google whitlist and supports DNSSEC. HE is only missing that last one..
QuoteDNSSEC (timeframe, 3-6 months)
- Updated 08.01.2010 - dnsadmin@he.net
OK, it's 4.3 months later: Any update?
Inquiring servers want to know!
Any word yet - now 7 months since August 1 which estimated 3-6 months?
I hve received complaints about some of my DNSSEC-enabled domains not being resolvable because some of their servers are not serving NSEC3 records (some => HE's servers)....
PS: This message CC'ed to dns@he.net
As noted before, we're waiting for the software to support it, but it's getting close.
According to the author of your DNS software, a version supporting DNSSEC was released July 22 (2011). Could you please revisit the issue? Thank you.
So your complaining that the FREE ipv6 recursive server HE is providing does not support dnssec because of lack of edns0 support, is that the problem?
Well then just run your own - I don't see what the problem is??
Here is my own unbound resolver I run on my local network that has full ipv6 support.
C:\Windows\System32>dig +short rs.dns-oarc.net txt
rst.x996.rs.dns-oarc.net.
rst.x1956.x996.rs.dns-oarc.net.
rst.x2442.x1956.x996.rs.dns-oarc.net.
"24.13.xx.xx DNS reply size limit is at least 2442"
"24.13.xx.xx sent EDNS buffer size 4096"
"Tested at 2011-08-05 12:22:17 UTC"
here is HE server
C:\Windows\System32>dig @2001:470:20::2 +short rs.dns-oarc.net txt
rst.x479.rs.dns-oarc.net.
rst.x488.x479.rs.dns-oarc.net.
rst.x493.x488.x479.rs.dns-oarc.net.
"2001:470:0:6e::2 DNS reply size limit is at least 493"
"2001:470:0:6e::2 lacks EDNS, defaults to 512"
"Tested at 2011-08-05 12:23:46 UTC"
You say their resolver supports edns0 since the july 22 release? Not seeing that, sure I see this in the release notes
PowerDNS Authoritative Server 3.0 comes with DNSSEC support
But that is not what they are running
;; ANSWER SECTION:
version.bind. 86191 CH TXT "PowerDNS Recursor 3.3 $Id: pdns_recursor.cc 1712 2010-09-11 13:40:03Z
Which I do not see any new versions of with dnssec support?
He's talking about Authoritative Servers (ns1-5.he.net) and not the anycasted recursor. I believe DNSSEC will be part of a paid service, not the free, but not 100% certain if that is the final decision.
Ok that would make more sense - but how would he be using ns1 to ns5.he.net for recursive lookups?
The way I understand the test he did was checking if his recursive dns supports edns0, which allows him to do dnssec. Not that dns server that is authoritative for his domain can provide dnssec.
His tests are not directed at a specific server, so he would be using whatever recursive dns his box is pointed at, so how would that in anyway test the support of HE authoritative nameservers for edns0?
Or maybe I just completely off base?
edit:
Ah -- 2 different posters, snarked was the one asking about the authoritative HE dns, woosingwoo is the one that did the recursive test.
I'm not certain if you recently tried to upgrade your server software, but starting at Aug 5 19:13:44 (PDT), there appears to be a problem with ns1.he.net and AXFRs for a zone it is a secondary (or slave) server for. In my logs, I'm seeing an AXFR about once per minute (or ~70 seconds). I think that your server may be taking the zone but then faulting when trying to reload it, or something like that?
Logs:
QuoteAug 5 19:13:44 snarked named[1068]: client 216.218.130.2#13113: transfer of '4.0.0.0.d.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa/IN': AXFR started
Aug 5 19:13:44 snarked named[1068]: client 216.218.130.2#13113: transfer of '4.0.0.0.d.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa/IN': AXFR ended
Aug 5 19:14:49 snarked named[1068]: client 216.218.130.2#19930: transfer of '4.0.0.0.d.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa/IN': AXFR started
Aug 5 19:14:49 snarked named[1068]: client 216.218.130.2#19930: transfer of '4.0.0.0.d.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa/IN': AXFR ended
Aug 5 19:16:10 snarked named[1068]: client 216.218.130.2#11209: transfer of '4.0.0.0.d.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa/IN': AXFR started
Aug 5 19:16:10 snarked named[1068]: client 216.218.130.2#11209: transfer of '4.0.0.0.d.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa/IN': AXFR ended
Aug 5 19:17:15 snarked named[1068]: client 216.218.130.2#14450: transfer of '4.0.0.0.d.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa/IN': AXFR started
Aug 5 19:17:15 snarked named[1068]: client 216.218.130.2#14450: transfer of '4.0.0.0.d.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa/IN': AXFR ended
...
Aug 6 00:07:28 snarked named[1068]: client 216.218.130.2#13118: transfer of '4.0.0.0.d.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa/IN': AXFR started
Aug 6 00:07:28 snarked named[1068]: client 216.218.130.2#13118: transfer of '4.0.0.0.d.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa/IN': AXFR ended
Aug 6 00:08:35 snarked named[1068]: client 216.218.130.2#16103: transfer of '4.0.0.0.d.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa/IN': AXFR started
Aug 6 00:08:35 snarked named[1068]: client 216.218.130.2#16103: transfer of '4.0.0.0.d.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa/IN': AXFR ended
Aug 6 00:09:40 snarked named[1068]: client 216.218.130.2#13159: transfer of '4.0.0.0.d.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa/IN': AXFR started
Aug 6 00:09:41 snarked named[1068]: client 216.218.130.2#13159: transfer of '4.0.0.0.d.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa/IN': AXFR ended
I post the comment here because all of my zones are DNSSEC signed (with NSEC3 validation records).
Total AXFR size: 522 records (messages 2, bytes 75480)
Any new info about this?
I'm really interested on this feature.
Also, please mods move this topic to: https://forums.he.net/index.php?board=14.0
Not configurable from their web GUI as master for your zone, but you can use DNSSEC if HE.net is your slave DNS server. Besides, DNSSEC is kind of tricky to configure via CLI if you don't know what you are doing, so doing it via web, some "not so technical" people will screw things up pretty quickly.
See http://dnssec-debugger.verisignlabs.com/hquest.pro.br for an example (expand the +more) a few times and scroll down until you see something similar to
QuoteQuery to ns1.he.net for hquest.pro.br/A
Received 359 bytes from 2001:470:100::2
;; Answer received from 2001:470:100::2 (359 bytes)
;; HEADER SECTION
;; id = 5541
;; qr = 1 aa = 1 tc = 0 rd = 0 opcode = QUERY
;; ra = 0 z = 0 ad = 0 cd = 0 rcode = NOERROR
;; qdcount = 1 ancount = 2 nscount = 0 arcount = 1
;; do = 1
;; EDNS version 0
;; flags: 8000
;; rcode: NOERROR
;; size: 1680
;; option:
;; QUESTION SECTION (1 record)
;; hquest.pro.br. IN A
;; ANSWER SECTION (2 records)
hquest.pro.br. 300 IN RRSIG A 7 3 300 (
20180131041151 20180101041151 22937 hquest.pro.br.
aFMYRbpyoB++VIRUKA+fxApr3nel57P4Oj0rx8oxPlmoF0gFMI5Mw1tTJK3EiqmNcZtOaGsb3DS8
2Yke6WC8DyJpqG8/js+C3OxU49HgsmXEVdy5hJLTupC1OU4qL9YhXv7NKqjTrGt6tWTGVYYk7ZC/
sGFN2jVlQZYXq8zmxBtNEHtuiAAKctcM4xgB+awBWF+G7aFgA5NToj3NdWEND4syqaSLnkiZDT9P
ULJ+uIOr6b3IXptk8qFnHlKgkmMK0/Wl2/LhN4Wy4FOCYDz2yJuDhxxP8BmoEefODT5OQyk9I/yT
n6BZ/py2Y9Rd2gIUPPiFg4r0o/Y2i210MRFn7A== )
hquest.pro.br. 300 IN A 71.179.174.165
;; AUTHORITY SECTION (0 records)
;; ADDITIONAL SECTION (1 record)
;; EDNS version 0
;; flags: 8000
;; rcode: NOERROR
;; size: 1680
;; option:
I've tried to use HE's DNS as a slave for the DNSSEC secured zone but it failed miserably. It was some time ago however so maybe they improved it since then.
Requesting an update on this 7-year-old thread.....
How is DNSSEC support coming along?
With the release of RFCs defining CDS, CDNSKEY, and CSYNC records more than a year ago, any chance on sub-zones of HE's address range (i.e. reverse zones under 2001:470::/32) being processed so that our sub-reverse zones will have recognized DNSSEC signatures (i.e, "chain of trust")? :)
cf. RFCs 7344 (Sept 2014), 7477 (March 2015), and 8078 (March 2017).
I see that PowerDNS through 4.1.2 has a lot of DNSSEC improvements (but no mention of the RRs above). Meanwhile, ISC's BIND handles all of this.
1) DNSSEC: I note that powerdns indicates it supports all of the current signing algorithms. I updated my zones to include most of them. However, although 4 of them "validate," they are not loading. Is your version of powerdns current (i.e. version 4.0 or better)? cf. https://doc.powerdns.com/authoritative/dnssec/profile.html (indicating which DNSSEC algorithms are supported). I can only guess it's rejecting the zones due to unknown signature algorithms. (Dns.he.net should provide more help, like actual log messages, but currently doesn't). I used algorithms 7, 8, 10, and 12-14. Algorithms 15 and 16 don't yet seem to be supported by BIND (9.12.1), so I didn't use them.
2) The only hint at size restrictions listed on dns.he.net is that "zones over 10000 records will be purged." However, I note that with the additional DNSSEC signatures added to my zones, only the 4 which have less than 1000 records (note: a factor of 10 less) when signed will "validate" (see the "validate" button at dns.he.net's slave zone page). The others, which range from about 1,800 to 5,000, don't. This is less than the 10,000 indicated up front. Is the limit really one thousand, not ten thousand? If so, I'll cut back my signatures to algorithm 7 only (so as to fit).
Follow-up: Cutting back to signing my zones with only algorithm 7 (and NOT 8, 10, 12, 13, and 14) resulted in my zones being servable again.
Looks as if the DNS server software needs an upgrade and/or the zone size needs to be increased to accommodate the additional records that DNSSEC adds to each RRset when multiple signing algorithms are used.
I still hope for DNSSEC support on dns.he.net, using it as master.
I have the exact same question. I've tried phrasing it different ways to support but cannot get a direct answer.
As is I would hesitate to cut over to HE's DNS because I have support for DNSSEC now using PowerDNS. I would be sacrificing security for performance, which is a questionable motive as performance is not particularly awesome but is okay at the time.
I'm desparately looking for DNSSEC support too, using dns.he.net and its webinterface as master/primary dns server.
seems still no support yet :(
Quote from: Gee-Gee on July 02, 2019, 06:38:01 AM
I'm desparately looking for DNSSEC support too, using dns.he.net and its webinterface as master/primary dns server.
As master/primary dns server, it's currently not possible.
DNSSEC support is only if dns he.net are slaves.
From what I understood, HE does not support DNSSEC yet, but please correct me if I am wrong.
My question is: My domain registrar supports DNSSEC. HE is my DNS provider. If I understand correctly, I need to obtain DS keys from HE and enter them in my registrar interface. Is this currently possible?
he.net's DNS service has support to function as a secondary DNSSEC DNS server. It cannot act as a primary DNSSEC DNS server, i.e., he.net's DNS service cannot sign zones. You have to have your sign the zones and then transfer the signed zones to he.net's secondary DNS service.
In a nutshell, here's how I do it...
Have a "hidden primary" DNS server, i.e. it is not public. On that hidden primary DNS server, I run OpenDNSSEC to sign the zones and NSD to act as the transfer agent.
When OpenDNSSEC signs a zone, it triggers a script that loads the newly-signed zone into NSD. NSD then contacts the secondary server at he.net, and the secondary server initiates a zone transfer of the newly signed zone from NSD to he.net.
Also, in answer to your comment, OpenDNSSEC generates the DS keys, which I then insert into my registrar's interface.
I need to note that the DNSSEC at he.net does not support all DNSSEC records, but it does support all the ones I need. :)
Thank you for the detailed explanation. I am not a very technical person in terms of Web and DNS servers, so my understanding is limited on this topic. What I understood is that I cannot avail DNSSEC with my current setup at HE. I'd need a middleman (a hidden DNS server that acts as primary) that generates required zones/DS keys using openDNSSEC and transfers them to HE (which will be my secondary DNS then).
Is it possible to get a hidden DNS server for free online? Or is it something that one needs to setup at home or subscribe to a paid service?
I do not know of any service that offers a hidden DNS primary.
I do know that the registrar I use (gkg.net) offers free DNS (including DNSSEC which is enabled via a single checkbox. gkg.net takes care of all the signing details.) for domains that are registered there. Maybe something like that is more what you need. I use gkg.net for three of my domains and have been very pleased with them.
Thank you again. I'll check it out.