Hi to everyone. Missed this post - and its answer? Did you find the
answer to this. Let me know 
Much obliged
Thanks, Sian N.H.
Hi Sean,
Maybe you are not looking for this, but have you tried the
local-data-ptr: “2001:DB8::1234 myserver.example.com”
entry for unbound.conf? That creates and IPv6 PTR record for you server when this instance of unbound is queried for it. You should set the IPv6 address and name for your server.
An implicit local-zone is created when you do this, that covers the data element in a local-zone, you can set one explicitly so you can set the type of the local-zone if you want different processing, of, eg. other data for that zone. That means how other ip6 addresses are resolved, for example ‘static’ (NXDOMAIN for others) or transparent (look upstream). This is what that looks like:
local-zone: “8.b.d.0.1.0.0.2.ip6.arpa.” transparent
Best regards, Wouter
Thanks,
I can see how that would work. I have a pointer in a number of places now for the ipv6, so I will try this.
The current ptr is pointing to my provider’s dns, even though I’m sure my iov6 is unique to my server interface. I’m probably wrong though !
Robert Chalmers
So I’m pretty sure I’ve set this up right, but how do I check?
local-data-ptr: "2a02:c7f:3a85:8b00:c069:e462:ce46:fe91 robert-chalmers.uk”
…
…
local-zone: "1.9.e.f.6.4.e.c.2.6.4.e.9.6.0.c.0.0.b.8.5.8.a.3.f.7.c.0.2.0.a.2.ip6.arpa.” transparent
thanks
Robert
Robert Chalmers via Unbound-users:
So I’m pretty sure I’ve set this up right, but how do I check?
$ dig -x @resolver robert-chalmers.uk
shoud answer with your IPv6
or
$ dig @resolver 1.9.e.f.6.4.e.c.2.6.4.e.9.6.0.c.0.0.b.8.5.8.a.3.f.7.c.0.2.0.a.2.ip6.arpa. ptr
should answer with the name
Thanks, but nope, all I get back is the ipv4 address.
So I’m doing something wrong.
robert
Hey Robert,
Yes, the advice was not quite right. dig -x takes an address as an argument, not a name. There’s a manual page which presumably isn’t installed if you’re using Linux, since who needs manual pages. You don’t need to specify the QTYPE with -x since it sets it to PTR for you; to get the IPv6 address you need to specify QTYPE=AAAA since otherwise dig defaults to A.
dig @resolver robert-chalmers.uk AAAA
should answer with your IPv6 address, if there is one, and
dig -x @resolver 2a02:…(etc)
should answer with the name, if there is one
Joe
Thanks Joe.
Ok, I should have known that. Looking better now.
Remembering that this machine is on a SKY Dynamic IP router port forwarded to the server, which is a Mac. OSX 10.14.2
It otherwise runs well, but some mail is falling over the issue of the PTR record pointing to the SKY server, not mine.
So it’s that I’m trying to solve - if at all possible.
I might add, that I’m fairly new to unbound. A novice indeed.
ok.
dig -x 2a02:c7f:3a85:8b00:c069:e462:ce46:fe91
is not returning an ;;ANSWER SECTION
but the one is ok.
dig @8.8.4.4 robert-chalmers.uk AAAA
;; ANSWER SECTION:
robert-chalmers.uk. 21599 IN AAAA 2a02:c7f:3a85:8b00:c069:e462:ce46:fe91
unbound-checkconf returns “no errors”
On unbound start up I get what seems to be an ok sequence...
Dec 18 12:41:09 unbound[6555:0] debug: module config: "validator iterator"
Dec 18 12:41:09 unbound[6555:0] notice: init module 0: validator
Dec 18 12:41:09 unbound[6555:0] notice: init module 1: iterator
Dec 18 12:41:09 unbound[6555:0] debug: target fetch policy for level 0 is 3
Dec 18 12:41:09 unbound[6555:0] debug: target fetch policy for level 1 is 2
Dec 18 12:41:09 unbound[6555:0] debug: target fetch policy for level 2 is 1
Dec 18 12:41:09 unbound[6555:0] debug: target fetch policy for level 3 is 0
Dec 18 12:41:09 unbound[6555:0] debug: target fetch policy for level 4 is 0
Dec 18 12:41:09 unbound[6555:0] debug: Forward zone server list:
Dec 18 12:41:09 unbound[6555:0] info: DelegationPoint<.>: 0 names (0 missing), 10 addrs (0 result, 10 avail) parentNS
Dec 18 12:41:09 unbound[6555:0] debug: Reading root hints from /var/lib/unbound/root.hints
Dec 18 12:41:09 unbound[6555:0] info: DelegationPoint<.>: 13 names (0 missing), 26 addrs (0 result, 26 avail) parentNS
Dec 18 12:41:09 unbound[6555:0] info: DelegationPoint<1.9.e.f.6.4.e.c.2.6.4.e.9.6.0.c.0.0.b.8.5.8.a.3.f.7.c.0.2.0.a.2.ip6.arpa.>: 0 names (0 missing), 1 addrs (0 result, 1 avail) parentNS
Dec 18 12:41:09 unbound[6555:0] info: DelegationPoint<15.0.168.192.in-addr.arpa.>: 0 names (0 missing), 1 addrs (0 result, 1 avail) parentNS
Dec 18 12:41:09 unbound[6555:0] info: DelegationPoint<robert-chalmers.uk.>: 0 names (0 missing), 1 addrs (0 result, 1 avail) parentNS
Dec 18 12:41:09 unbound[6555:0] debug: cache memory msg=295672 rrset=295672 infra=29984 val=296000
Dec 18 12:41:09 unbound[6555:0] info: start of service (unbound 1.8.1).
I’d like to include the unbound.conf here if I may. I am looking for any obvious mistakes, and of course any less obvious. The once section I”m a little confused about is the
# Stub zones.
I have both an IPv4 and IPv6 address for that name, but checkconf doesn’t like it.
#====================================== unbound.conf 18/12/2018 ==================
# The server clause sets the main parameters.
server:
logfile: "/private/var/log/unbound/unbound.log"
verbosity: 3
statistics-interval: 300
interface: 0.0.0.0
interface: ::0
interface: 192.168.0.15
interface: 2a02:c7f:3a85:8b00:c069:e462:ce46:fe91
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
access-control: 0.0.0.0/0 refuse
access-control: 2a02:c7d:5d8a:5800::/64 allow
access-control: 2a02:c7f:3a85:8b00::/64 allow
access-control: 127.0.0.0/8 allow
access-control: ::1 allow
access-control: ::ffff:127.0.0.1 allow
chroot: ""
directory: "/usr/local/etc/unbound"
use-syslog: no
log-time-ascii: yes
pidfile: "/usr/local/etc/unbound/unbound.pid"
root-hints: "/var/lib/unbound/root.hints"
prefetch-key: yes
auto-trust-anchor-file: "/usr/local/etc/unbound/root.key"
val-log-level: 2
local-zone: "1.9.e.f.6.4.e.c.2.6.4.e.9.6.0.c.0.0.b.8.5.8.a.3.f.7.c.0.2.0.a.2.ip6.arpa." transparent
local-data-ptr: "192.168.0.15 www.quantum-radio.net"
local-data-ptr: "2a02:c7d:5d62:8c00:aa86:ddff:fea5:2eeb www.quantum-radio.net"
local-data-ptr: "2a02:c7f:3a85:8b00:c069:e462:ce46:fe91 robert-chalmers.uk"
python:
# Script file to load
# python-script: "/usr/local/etc/unbound/ubmodule-tst.py"
# Remote control config section.
remote-control:
control-enable: yes
control-use-cert: yes
control-interface: 127.0.0.1
control-interface: ::1
control-port: 8953
server-key-file: "/usr/local/etc/unbound/unbound_server.key"
server-cert-file: "/usr/local/etc/unbound/unbound_server.pem"
control-key-file: "/usr/local/etc/unbound/unbound_control.key"
control-cert-file: "/usr/local/etc/unbound/unbound_control.pem"
# Stub zones.
stub-zone:
name: "robert-chalmers.uk"
stub-addr: "192.168.0.15"
stub-zone:
name: "15.0.168.192.in-addr.arpa"
stub-addr: "192.168.0.15"
#stub-zone:
# name: "robert-chalmers.uk"
# stub-addr: "2a02:c7f:3a85:8b00:c069:e462:ce46:fe91"
stub-zone:
name: "1.9.e.f.6.4.e.c.2.6.4.e.9.6.0.c.0.0.b.8.5.8.a.3.f.7.c.0.2.0.a.2.ip6.arpa."
stub-addr: "2a02:c7f:3a85:8b00:c069:e462:ce46:fe91"
forward-zone:
name: "."
forward-addr: 8.8.8.8 # Google Public DNS
forward-addr: 8.8.4.4 # Google Public DNS
forward-addr: 2001:4860:4860::8888 #Google Public DNS
forward-addr: 2001:4860:4860::8844 #Google Public DNS
forward-addr: 74.82.42.42 # Hurricane Electric
forward-addr: 77.88.8.8 # Yandex DNS
forward-addr: 77.88.8.1 # Yandex DNS
forward-addr: 4.2.2.4 # Level3 Verizon
forward-addr: 2620:0:ccc::2 # OpenDNS Sandbox
forward-addr: 2620:0:ccd::2 # OpenDNS Sandbox
Ah, then also bear in mind that the PTR record you've installed on unbound is only visible to people using that unbound instance in their resolver chain. The rest of the world won't see it. You need to ask Sky to install the PTR record you need (or to delegate a zone to your servers, somewhere else on the Internet). If the v6 address they assign to you is really dynamic (not just in theory, but in practical terms) then this might be a challenge.
However, I seem to remember drinking beer with v6 people from Sky in some European city or other at some point (Helsinki, maybe?) and I seem to think they will send you a static prefix over DHCPv6 if you request a prefix delegation. If you can get a /48 or /56 or whatever it is they hand out and number your mail server out of there, you will likely have more luck. You still need to talk to Sky to get the PTR record installed, though.
(Random advice found on Internet, in case it's useful: "sky's dhcp requires the router to initiate the prefix delegation request and not request an ip instead of waiting for a RA. next that on disconnection dhcp should "not" send a release otherwise the prefix will change on reconnection.")
I'll leave it to others in a better timezone to look at your Unbound-specific questions. I'm only two espressos into the day, here.
Joe