Print

[woosingwoo]

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

[kcochran]

That test is actually flawed, the recursors handle EDNS0.

As to DNSSEC, the software doesn't support it yet.

[chiel]

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..

[snarked]

DNSSEC (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!

[snarked]

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

[kcochran]

As noted before, we're waiting for the software to support it, but it's getting close.

[snarked]

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.

[johnpoz]

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?

[broquea]

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.

[johnpoz]

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.

[snarked]

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:

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 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)

[Er_Maqui]

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

[HQuest]

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

Query 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:

[tomkep]

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.

[snarked]

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.