{"id":2799,"date":"2025-09-06T15:44:54","date_gmt":"2025-09-06T15:44:54","guid":{"rendered":"https:\/\/hauweele.net\/~gawen\/blog\/?p=2799"},"modified":"2025-09-06T15:44:54","modified_gmt":"2025-09-06T15:44:54","slug":"unbound-stub-zone-for-reverse-private-ipv6","status":"publish","type":"post","link":"https:\/\/hauweele.net\/~gawen\/blog\/?p=2799","title":{"rendered":"Unbound stub-zone for reverse private IPv6"},"content":{"rendered":"<p>Today I tried to configure a stub-zone on a unbound resolver. This was for the reverse resolution of some private IPv6. In <code>unbound.conf<\/code>, it looks something like this:<\/p>\n<pre>\r\nstub-zone:\r\n  name: X.X.X.X.X.X.d.f.ip6.arpa.\r\n  stub-addr: {authoritative-server-ip}\r\n<\/pre>\n<p>But trying a reverse resolution on any of those private IPv6 failed:<\/p>\n<pre>\r\n$ drill -x fdXX:XXXX::XXXX\r\n;; AUTHORITY SECTION:\r\nd.f.ip6.arpa.\t10800\tIN\tSOA\tlocalhost. nobody.invalid. 1 3600 1200 604800 10800\r\n<\/pre>\n<p>Found out the problem in a snippet from <code>unbound.conf.sample<\/code>:<\/p>\n<pre>\r\n# By default, for a number of zones a small default 'nothing here'\r\n# reply is built-in.  Query traffic is thus blocked.  If you\r\n# wish to serve such zone you can unblock them by uncommenting one\r\n# of the nodefault statements below.\r\n# You may also have to use domain-insecure: zone to make DNSSEC work,\r\n# unless you have your own trust anchors for this zone.\r\n# local-zone: \"localhost.\" nodefault\r\n# local-zone: \"127.in-addr.arpa.\" nodefault\r\n# local-zone: \"1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.\" nodefault\r\n# local-zone: \"home.arpa.\" nodefault\r\n# local-zone: \"resolver.arpa.\" nodefault\r\n# local-zone: \"service.arpa.\" nodefault\r\n# local-zone: \"onion.\" nodefault\r\n# local-zone: \"test.\" nodefault\r\n# local-zone: \"invalid.\" nodefault\r\n# local-zone: \"10.in-addr.arpa.\" nodefault\r\n# local-zone: \"16.172.in-addr.arpa.\" nodefault\r\n# local-zone: \"17.172.in-addr.arpa.\" nodefault\r\n# local-zone: \"18.172.in-addr.arpa.\" nodefault\r\n# local-zone: \"19.172.in-addr.arpa.\" nodefault\r\n# local-zone: \"20.172.in-addr.arpa.\" nodefault\r\n# local-zone: \"21.172.in-addr.arpa.\" nodefault\r\n# local-zone: \"22.172.in-addr.arpa.\" nodefault\r\n# local-zone: \"23.172.in-addr.arpa.\" nodefault\r\n# local-zone: \"24.172.in-addr.arpa.\" nodefault\r\n# local-zone: \"25.172.in-addr.arpa.\" nodefault\r\n# local-zone: \"26.172.in-addr.arpa.\" nodefault\r\n# local-zone: \"27.172.in-addr.arpa.\" nodefault\r\n# local-zone: \"28.172.in-addr.arpa.\" nodefault\r\n# local-zone: \"29.172.in-addr.arpa.\" nodefault\r\n# local-zone: \"30.172.in-addr.arpa.\" nodefault\r\n# local-zone: \"31.172.in-addr.arpa.\" nodefault\r\n# local-zone: \"168.192.in-addr.arpa.\" nodefault\r\n# local-zone: \"0.in-addr.arpa.\" nodefault\r\n# local-zone: \"254.169.in-addr.arpa.\" nodefault\r\n# local-zone: \"2.0.192.in-addr.arpa.\" nodefault\r\n# local-zone: \"100.51.198.in-addr.arpa.\" nodefault\r\n# local-zone: \"113.0.203.in-addr.arpa.\" nodefault\r\n# local-zone: \"255.255.255.255.in-addr.arpa.\" nodefault\r\n# local-zone: \"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa.\" nodefault\r\n# local-zone: \"d.f.ip6.arpa.\" nodefault\r\n# local-zone: \"8.e.f.ip6.arpa.\" nodefault\r\n# local-zone: \"9.e.f.ip6.arpa.\" nodefault\r\n# local-zone: \"a.e.f.ip6.arpa.\" nodefault\r\n# local-zone: \"b.e.f.ip6.arpa.\" nodefault\r\n# local-zone: \"8.b.d.0.1.0.0.2.ip6.arpa.\" nodefault\r\n# And for 64.100.in-addr.arpa. to 127.100.in-addr.arpa.\r\n<\/pre>\n<p>As you can see <code>d.f.ip6.arpa.<\/code> is blocked by default, so just had to add this line to unblock it:<\/p>\n<pre>\r\nlocal-zone: \"d.f.ip6.arpa.\" nodefault\r\n<\/pre>\n","protected":false},"excerpt":{"rendered":"<p>Today I tried to configure a stub-zone on a unbound resolver. This was for the reverse resolution of some private IPv6. In unbound.conf, it looks something like this: stub-zone: name: X.X.X.X.X.X.d.f.ip6.arpa. stub-addr: {authoritative-server-ip} But trying a reverse resolution on any &hellip; <a href=\"https:\/\/hauweele.net\/~gawen\/blog\/?p=2799\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[1189,164,571,1188,729,726,517],"class_list":["post-2799","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-d-f-ip6-arpa","tag-ipv6","tag-private","tag-ptr","tag-reverse","tag-stub-zone","tag-unbound"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/hauweele.net\/~gawen\/blog\/index.php?rest_route=\/wp\/v2\/posts\/2799","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/hauweele.net\/~gawen\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hauweele.net\/~gawen\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hauweele.net\/~gawen\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/hauweele.net\/~gawen\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2799"}],"version-history":[{"count":0,"href":"https:\/\/hauweele.net\/~gawen\/blog\/index.php?rest_route=\/wp\/v2\/posts\/2799\/revisions"}],"wp:attachment":[{"href":"https:\/\/hauweele.net\/~gawen\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2799"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hauweele.net\/~gawen\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2799"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/hauweele.net\/~gawen\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2799"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}