Discussion:
Question About Recursion In A Split Horizon Setup
(too old to reply)
Tim Daneliuk
2020-04-16 23:16:04 UTC
Permalink
We have split horizon setup and enable our internal and trusted hosts
to do things as follows:

allow-recursion { trustedhosts; };
allow-transfer { trustedhosts; };

'trustedhosts' includes a number of public facing IPs as well as the
192.168.0/24 CIDR block. It also includes the IPs of the Master and
Slave bind servers.

So here's the part that has me wondering. If I do a reverse lookup of
an IP, it works as expected _except_ if I do it on either the Master
or Slave machines. They will not only look up reverses on our
own IPs, they won't do it for ANY IP and returns the warning:

WARNING: recursion requested but not available

This is replicable with 9.14 or 9.16 (or was until today's assert borkage)
running on FreeBSD 11.3-STABLE. Master is on a cloud server, Slave is
on a physical machine. Neither instance is jailed.

Ideas?
--
----------------------------------------------------------------------------
Tim Daneliuk ***@tundraware.com
PGP Key: http://www.tundraware.com/PGP/
Bob Harold
2020-04-17 12:26:52 UTC
Permalink
Post by Tim Daneliuk
We have split horizon setup and enable our internal and trusted hosts
allow-recursion { trustedhosts; };
allow-transfer { trustedhosts; };
'trustedhosts' includes a number of public facing IPs as well as the
192.168.0/24 CIDR block. It also includes the IPs of the Master and
Slave bind servers.
So here's the part that has me wondering. If I do a reverse lookup of
an IP, it works as expected _except_ if I do it on either the Master
or Slave machines. They will not only look up reverses on our
WARNING: recursion requested but not available
This is replicable with 9.14 or 9.16 (or was until today's assert borkage)
running on FreeBSD 11.3-STABLE. Master is on a cloud server, Slave is
on a physical machine. Neither instance is jailed.
Ideas?
--
----------------------------------------------------------------------------
PGP Key: http://www.tundraware.com/PGP/
Is 127.0.0.1 in the 'trustedhosts' list?
Are you telling 'dig' what server to use - dig @127.0.0.1
What servers are listed in /etc/resolv.conf? Do they resolve the reverse
zones?
Are local queries hitting the right 'view' (if you have multiple views) ?
--
Bob Harold
Tim Daneliuk
2020-04-17 14:33:42 UTC
Permalink
Post by Tim Daneliuk
We have split horizon setup and enable our internal and trusted hosts
    allow-recursion { trustedhosts; };
    allow-transfer  { trustedhosts; };
'trustedhosts' includes a number of public facing IPs as well as the
192.168.0/24 CIDR block.  It also includes the IPs of the Master and
Slave bind servers.
So here's the part that has me wondering.  If I do a reverse lookup of
an IP, it works as expected _except_ if I do it on either the Master
or Slave machines. They will not only look up reverses on our
    WARNING: recursion requested but not available
This is replicable with 9.14 or 9.16 (or was until today's assert borkage)
running on FreeBSD 11.3-STABLE.  Master is on a cloud server, Slave is
on a physical machine.  Neither instance is jailed.
Ideas?
--
----------------------------------------------------------------------------
PGP Key:         http://www.tundraware.com/PGP/
Is 127.0.0.1 in the 'trustedhosts' list?
Yes
No. But when I do, it works properly. Doesn't dig default to localhost (in this case the host running bind)?
Post by Tim Daneliuk
What servers are listed in /etc/resolv.conf?  Do they resolve the reverse zones?
There is no resolv.conf on these machines. They are the ones running the nameservers.
Post by Tim Daneliuk
Are local queries hitting the right 'view' (if you have multiple views) ?
Yes, IF I explicitly point dig to the right nameserver.


So ... what's going on is that dig appears to not be using localhost first to resolve reverses.
Post by Tim Daneliuk
-- 
Bob Harold
--
----------------------------------------------------------------------------
Tim Daneliuk ***@tundraware.com
PGP Key: http://www.tundraware.com/PGP/
Bob Harold
2020-04-17 14:50:55 UTC
Permalink
Post by Tim Daneliuk
Post by Tim Daneliuk
We have split horizon setup and enable our internal and trusted hosts
allow-recursion { trustedhosts; };
allow-transfer { trustedhosts; };
'trustedhosts' includes a number of public facing IPs as well as the
192.168.0/24 CIDR block. It also includes the IPs of the Master and
Slave bind servers.
So here's the part that has me wondering. If I do a reverse lookup
of
Post by Tim Daneliuk
an IP, it works as expected _except_ if I do it on either the Master
or Slave machines. They will not only look up reverses on our
WARNING: recursion requested but not available
This is replicable with 9.14 or 9.16 (or was until today's assert
borkage)
Post by Tim Daneliuk
running on FreeBSD 11.3-STABLE. Master is on a cloud server, Slave
is
Post by Tim Daneliuk
on a physical machine. Neither instance is jailed.
Ideas?
--
----------------------------------------------------------------------------
Post by Tim Daneliuk
PGP Key: http://www.tundraware.com/PGP/
Is 127.0.0.1 in the 'trustedhosts' list?
Yes
numerical links are often malicious:* 127.0.0.1 <http://127.0.0.1>
No. But when I do, it works properly. Doesn't dig default to localhost
(in this case the host running bind)?
Post by Tim Daneliuk
What servers are listed in /etc/resolv.conf? Do they resolve the
reverse zones?
There is no resolv.conf on these machines. They are the ones running the
nameservers.
Post by Tim Daneliuk
Are local queries hitting the right 'view' (if you have multiple views) ?
Yes, IF I explicitly point dig to the right nameserver.
So ... what's going on is that dig appears to not be using localhost first
to resolve reverses.
Agree, that's odd, and not what the man page says. Any chance that there
is some other DNS helper running, like resolved, nscd, dnsmasq, etc?
'dig' should tell you what address it used, at the bottom of the output -
what does it say?
--
Bob Harold
Post by Tim Daneliuk
Post by Tim Daneliuk
--
Bob Harold
--
----------------------------------------------------------------------------
PGP Key: http://www.tundraware.com/PGP/
Tim Daneliuk
2020-04-17 14:56:21 UTC
Permalink
Agree, that's odd, and not what the man page says.  Any chance that there is some other DNS helper running, like resolved, nscd, dnsmasq, etc?
Nope. This is vanilla FreeBSD with vanilla bind running.
'dig' should tell you what address it used, at the bottom of the output - what does it say?
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Apr 17 09:53:51 CDT 2020
;; MSG SIZE rcvd: 83


Does the SERVER line indicate it's trying to get to the local instance via
IPV6 or is this just standard notation? (This is an IPV4 only environment).
--
----------------------------------------------------------------------------
Tim Daneliuk ***@tundraware.com
PGP Key: http://www.tundraware.com/PGP/
Konstantin Stefanov
2020-04-17 15:02:50 UTC
Permalink
Post by Tim Daneliuk
Agree, that's odd, and not what the man page says.  Any chance that there is some other DNS helper running, like resolved, nscd, dnsmasq, etc?
Nope. This is vanilla FreeBSD with vanilla bind running.
Lately vanilla FreeBSD has unbound as caching and recursive DNS server.
Did you turn it off?
Post by Tim Daneliuk
'dig' should tell you what address it used, at the bottom of the output - what does it say?
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Apr 17 09:53:51 CDT 2020
;; MSG SIZE rcvd: 83
Does the SERVER line indicate it's trying to get to the local instance via
IPV6 or is this just standard notation? (This is an IPV4 only environment).
--
Konstantin Stefanov
julien soula
2020-04-17 15:17:58 UTC
Permalink
Post by Tim Daneliuk
Agree, that's odd, and not what the man page says.  Any chance that there is some other DNS helper running, like resolved, nscd, dnsmasq, etc?
Nope. This is vanilla FreeBSD with vanilla bind running.
'dig' should tell you what address it used, at the bottom of the output - what does it say?
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Apr 17 09:53:51 CDT 2020
;; MSG SIZE rcvd: 83
Does the SERVER line indicate it's trying to get to the local instance via
IPV6 or is this just standard notation? (This is an IPV4 only environment).
"::1" is locahost in IPv6. It is not the same as 127.0.0.1 . A least,
you should add this IP to trustedhosts to check if it works.

best regard,
--
Julien
Bob Harold
2020-04-17 15:18:01 UTC
Permalink
Post by Tim Daneliuk
Post by Bob Harold
Agree, that's odd, and not what the man page says. Any chance that
there is some other DNS helper running, like resolved, nscd, dnsmasq, etc?
Post by Tim Daneliuk
Nope. This is vanilla FreeBSD with vanilla bind running.
Lately vanilla FreeBSD has unbound as caching and recursive DNS server.
Did you turn it off?
Post by Tim Daneliuk
Post by Bob Harold
'dig' should tell you what address it used, at the bottom of the output
- what does it say?
Post by Tim Daneliuk
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Apr 17 09:53:51 CDT 2020
;; MSG SIZE rcvd: 83
Does the SERVER line indicate it's trying to get to the local instance
via
Post by Tim Daneliuk
IPV6 or is this just standard notation? (This is an IPV4 only
environment).
The server is using IPv6 locally, so you need to include "::1" in the
"trustedhosts"
and view match statements.
Or just create /etc/resolv.conf with: nameserver 127.0.0.1
So the man page was right, just not specific.
--
Bob Harold
--
Konstantin Stefanov
Tim Daneliuk
2020-04-17 16:40:43 UTC
Permalink
Post by julien soula
Post by Tim Daneliuk
Agree, that's odd, and not what the man page says.  Any chance that there is some other DNS helper running, like resolved, nscd, dnsmasq, etc?
Nope. This is vanilla FreeBSD with vanilla bind running.
'dig' should tell you what address it used, at the bottom of the output - what does it say?
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Apr 17 09:53:51 CDT 2020
;; MSG SIZE rcvd: 83
Does the SERVER line indicate it's trying to get to the local instance via
IPV6 or is this just standard notation? (This is an IPV4 only environment).
"::1" is locahost in IPv6. It is not the same as 127.0.0.1 . A least,
you should add this IP to trustedhosts to check if it works.
best regard,
Aha! That was it. What is curious to me is that bind uses this even in the absence
of any IPV6 in the environment.

Problem solved. Thanks all!
--
----------------------------------------------------------------------------
Tim Daneliuk ***@tundraware.com
PGP Key: http://www.tundraware.com/PGP/
Timothe Litt
2020-04-17 16:48:14 UTC
Permalink
Post by Tim Daneliuk
Agree, that's odd, and not what the man page says.  Any chance that there is some other DNS helper running, like resolved, nscd, dnsmasq, etc?
Nope. This is vanilla FreeBSD with vanilla bind running.
'dig' should tell you what address it used, at the bottom of the output - what does it say?
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Apr 17 09:53:51 CDT 2020
;; MSG SIZE rcvd: 83
Does the SERVER line indicate it's trying to get to the local instance via
IPV6 or is this just standard notation? (This is an IPV4 only environment).
You seem to be selecting views based on IP address.

If the host on which you are running dig is multi-homed, the OS may pick
a source
address other than what you intend.  Use -b to explicitly bind to a
particular interface.

(Or, if you use TSIG to match views, -k)


Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
Bob Harold
2020-04-17 17:03:15 UTC
Permalink
Post by julien soula
Post by Tim Daneliuk
Post by Bob Harold
Agree, that's odd, and not what the man page says. Any chance that
there is some other DNS helper running, like resolved, nscd, dnsmasq, etc?
Post by julien soula
Post by Tim Daneliuk
Nope. This is vanilla FreeBSD with vanilla bind running.
Post by Bob Harold
'dig' should tell you what address it used, at the bottom of the
output - what does it say?
Post by julien soula
Post by Tim Daneliuk
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Apr 17 09:53:51 CDT 2020
;; MSG SIZE rcvd: 83
Does the SERVER line indicate it's trying to get to the local instance
via
Post by julien soula
Post by Tim Daneliuk
IPV6 or is this just standard notation? (This is an IPV4 only
environment).
Post by julien soula
"::1" is locahost in IPv6. It is not the same as 127.0.0.1 . A least,
you should add this IP to trustedhosts to check if it works.
best regard,
Aha! That was it. What is curious to me is that bind uses this even in
the absence
of any IPV6 in the environment.
Problem solved. Thanks all!
--
----------------------------------------------------------------------------
PGP Key: http://www.tundraware.com/PGP/
As a separate issue: Check the logs to see if BIND is trying to use IPv6
to resolve queries. Look for messages like:
address not available resolving .... with some IPv6 address
I have to start named with the "-4" option on my servers that do not yet
have IPv6 connectivity.
--
Bob Harold
Chuck Aurora
2020-04-18 01:43:19 UTC
Permalink
Post by Tim Daneliuk
Post by julien soula
Post by Tim Daneliuk
Post by Bob Harold
'dig' should tell you what address it used, at the bottom of the
output - what does it say?
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Apr 17 09:53:51 CDT 2020
;; MSG SIZE rcvd: 83
Does the SERVER line indicate it's trying to get to the local
instance via IPV6 or is this just standard notation? (This is
an IPV4 only environment).
"::1" is locahost in IPv6. It is not the same as 127.0.0.1 . A least,
you should add this IP to trustedhosts to check if it works.
Aha! That was it. What is curious to me is that bind uses this even
in the absence of any IPV6 in the environment.
Problem solved. Thanks all!
What "absence" is this? You showed us that dig connected to ::1#53,
yes,
via ipv6. Not having external ipv6 routing is not the same as absence
of
ipv6. Your system DOES have ipv6 enabled.

As others have pointed out, you either need to put ::1 in your ACL, or
make a resolv.conf with "nameserver 127.0.0.1". Personally, I always
disable the ipv6 module in the OS kernel if there is no connectivity.
And Bob (I think it was) mentioned "named -4".

Since ipv6 is the future, it's generally the default protocol in many
OSs when it is enabled. That's why I suggest disabling it in your
kernel, to avoid this and many other problems; not just with dig &
named, but with other software as well.

Loading...