ipv6, was: Re: Question About Recursion ...

[Chuck Aurora]

On 2020-04-17 11:40, Tim Daneliuk wrote:

On 4/17/20 10:17 AM, julien soula wrote:

On Fri, Apr 17, 2020 at 09:56:21AM -0500, Tim Daneliuk wrote:

On 4/17/20 9:50 AM, Bob Harold wrote:



'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.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: "lame-servers: info: no valid RRSIG resolving ..."

[btb via bind-users]

thanks-

we're running 9.14.8, courtesy of the isc ubuntu ppa 
[https://launchpad.net/~isc]:

>named -v
BIND 9.14.8-Ubuntu (Stable Release) 

>dpkg -s bind9
Package: bind9
Status: install ok installed
Priority: optional
Section: net
Installed-Size: 872
Maintainer: Debian DNS Team 
Architecture: amd64
Version: 1:9.14.8-1+ubuntu19.10.1+isc+1
Replaces: bind (<< 1:9.13.6~)
[...]
Homepage: https://www.isc.org/downloads/bind/

does that mean in theory the version we're running would be new enough we 
shouldn't be seeing that particular symptom?

thanks

> On Apr 17, 2020, at 19.01, Mark Andrews  wrote:
> 
> They are almost certainly the result of running an older version of named and 
> packet loss
> causing named to fallback to plain DNS which doesn’t return DNSSEC records.  
> Newer versions
> of named don’t fallback to plain DNS on packet loss.
> 
> 5029.   [func]  Workarounds for servers that misbehave when queried
>with EDNS have been removed, because these broken
>servers and the workarounds for their noncompliance
>cause unnecessary delays, increase code complexity,
>and prevent deployment of new DNS features. See
>https://dnsflagday.net for further details. [GL #150]
> 
> BIND 9.14.0 is the first non development version with this behaviour.
> 
> Mark
> 
>> On 18 Apr 2020, at 01:24, btb via bind-users  
>> wrote:
>> 
>> hi-
>> 
>> i'm seeing what i'm wondering if is a lot of "lame-servers: info: no valid 
>> RRSIG resolving ..." messages in the logs [on average ~500 messages per 
>> day].  a small snippet:
>> 
>> 15-Apr-2020 18:11:46.057 lame-servers: info: no valid RRSIG resolving 
>> 'jwplayer.com/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:11:46.150 lame-servers: info: no valid RRSIG resolving 
>> 'tranet.net/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:11:47.559 lame-servers: info: no valid RRSIG resolving 
>> 'inboxsdk.com/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:11:49.146 lame-servers: info: no valid RRSIG resolving 
>> 'basis.net/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:11:58.474 lame-servers: info: no valid RRSIG resolving 
>> 'starfinancial.com/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:11:59.665 lame-servers: info: no valid RRSIG resolving 
>> 'vice.com/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:12:09.501 lame-servers: info: no valid RRSIG resolving 
>> 'lithium.com/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:12:09.756 lame-servers: info: no valid RRSIG resolving 
>> 'sc-static.net/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:12:10.004 lame-servers: info: no valid RRSIG resolving 
>> 'snapchat.com/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:12:12.638 lame-servers: info: no valid RRSIG resolving 
>> 'yimg.com/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:12:16.823 lame-servers: info: no valid RRSIG resolving 
>> 'transamerica.com/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:12:16.932 lame-servers: info: no valid RRSIG resolving 
>> 'quantummetric.com/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:12:17.129 lame-servers: info: no valid RRSIG resolving 
>> 'tealiumiq.com/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:12:17.171 lame-servers: info: no valid RRSIG resolving 
>> 'bounceexchange.com/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:12:22.971 lame-servers: info: no valid RRSIG resolving 
>> 'mwefinancial.com/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:12:23.248 lame-servers: info: no valid RRSIG resolving 
>> 'redditmedia.com/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:12:23.869 lame-servers: info: no valid RRSIG resolving 
>> 'imtwjwoasak.com/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:12:25.189 lame-servers: info: no valid RRSIG resolving 
>> 'b.com/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:12:25.313 lame-servers: info: no valid RRSIG resolving 
>> 'jquery.com/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:12:26.555 lame-servers: info: no valid RRSIG resolving 
>> 'forter.com/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:12:29.008 lame-servers: info: no valid RRSIG resolving 
>> 'quovadisoffshore.com/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:12:29.029 lame-servers: info: no valid RRSIG resolving 
>> 'quovadisglobal.com/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:12:29.974 lame-servers: info: no valid RRSIG resolving 
>> 'mixpanel.com/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:12:35.786 lame-servers: info: no valid RRSIG resolving 
>> 'spotify.com/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:12:36.982 lame-servers: info: no valid RRSIG resolving 
>> 'freeform.com/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:12:38.295 lame-servers: info: no valid RRSIG resolving 
>> 'edgedatg.com/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:12:58.190 lame-servers: info: no valid RRSIG resolving 
>> 'footprintdns.com/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:13:01.282 lame-servers: info: no valid RRSIG resolving 
>> 'qualifiedaddress.com/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 18:13:01.744 lame-servers: info: no valid RRSIG resolving 
>> 'dc-msedge.net/DS/IN': 192.5.6.30#53
>> 15-Apr-2020 

Re: "lame-servers: info: no valid RRSIG resolving ..."

[Mark Andrews]

They are almost certainly the result of running an older version of named and 
packet loss
causing named to fallback to plain DNS which doesn’t return DNSSEC records.  
Newer versions
of named don’t fallback to plain DNS on packet loss.

5029.   [func]  Workarounds for servers that misbehave when queried
with EDNS have been removed, because these broken
servers and the workarounds for their noncompliance
cause unnecessary delays, increase code complexity,
and prevent deployment of new DNS features. See
https://dnsflagday.net for further details. [GL #150]

BIND 9.14.0 is the first non development version with this behaviour.

Mark

> On 18 Apr 2020, at 01:24, btb via bind-users  wrote:
> 
> hi-
> 
> i'm seeing what i'm wondering if is a lot of "lame-servers: info: no valid 
> RRSIG resolving ..." messages in the logs [on average ~500 messages per day]. 
>  a small snippet:
> 
> 15-Apr-2020 18:11:46.057 lame-servers: info: no valid RRSIG resolving 
> 'jwplayer.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:11:46.150 lame-servers: info: no valid RRSIG resolving 
> 'tranet.net/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:11:47.559 lame-servers: info: no valid RRSIG resolving 
> 'inboxsdk.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:11:49.146 lame-servers: info: no valid RRSIG resolving 
> 'basis.net/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:11:58.474 lame-servers: info: no valid RRSIG resolving 
> 'starfinancial.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:11:59.665 lame-servers: info: no valid RRSIG resolving 
> 'vice.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:09.501 lame-servers: info: no valid RRSIG resolving 
> 'lithium.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:09.756 lame-servers: info: no valid RRSIG resolving 
> 'sc-static.net/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:10.004 lame-servers: info: no valid RRSIG resolving 
> 'snapchat.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:12.638 lame-servers: info: no valid RRSIG resolving 
> 'yimg.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:16.823 lame-servers: info: no valid RRSIG resolving 
> 'transamerica.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:16.932 lame-servers: info: no valid RRSIG resolving 
> 'quantummetric.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:17.129 lame-servers: info: no valid RRSIG resolving 
> 'tealiumiq.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:17.171 lame-servers: info: no valid RRSIG resolving 
> 'bounceexchange.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:22.971 lame-servers: info: no valid RRSIG resolving 
> 'mwefinancial.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:23.248 lame-servers: info: no valid RRSIG resolving 
> 'redditmedia.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:23.869 lame-servers: info: no valid RRSIG resolving 
> 'imtwjwoasak.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:25.189 lame-servers: info: no valid RRSIG resolving 
> 'b.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:25.313 lame-servers: info: no valid RRSIG resolving 
> 'jquery.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:26.555 lame-servers: info: no valid RRSIG resolving 
> 'forter.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:29.008 lame-servers: info: no valid RRSIG resolving 
> 'quovadisoffshore.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:29.029 lame-servers: info: no valid RRSIG resolving 
> 'quovadisglobal.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:29.974 lame-servers: info: no valid RRSIG resolving 
> 'mixpanel.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:35.786 lame-servers: info: no valid RRSIG resolving 
> 'spotify.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:36.982 lame-servers: info: no valid RRSIG resolving 
> 'freeform.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:38.295 lame-servers: info: no valid RRSIG resolving 
> 'edgedatg.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:58.190 lame-servers: info: no valid RRSIG resolving 
> 'footprintdns.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:13:01.282 lame-servers: info: no valid RRSIG resolving 
> 'qualifiedaddress.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:13:01.744 lame-servers: info: no valid RRSIG resolving 
> 'dc-msedge.net/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:14:54.009 lame-servers: info: no valid RRSIG resolving 
> 'facebook.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:16:20.039 lame-servers: info: no valid RRSIG resolving 
> 'pphosted.com/DS/IN': 192.5.6.30#53
> 
> a number of these [most?] are zones that are signed, and some don't even 
> exist, so i'm curious about seeing these messages.  what am i not 
> understanding, and/or what can i do to troubleshoot further?
> 
> thanks!
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 

Re: NAT and Question Section Mismatch

[Tony Finch]

John Wiles  wrote:
>
> I am running into a problem that I think is caused by either a
> misconfiguration in Bind9, our Cisco NAT, or perhaps both.
>
> When I am on our internal network, I am able to query both servers and
> get the appropriate external ip address. However, when I try to do the
> same thing externally I get "Question section mismatch: got
> 6.1.1.10.in-addr.arpa/PTR/IN."

I bet this is a PIX/ASA fixup fuxup.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Humber, Thames: Northeast 4 or 5, occasionally 6 until later in Thames.
Moderate, becoming slight later in Thames. Showers, mainly in Thames. Good,
occasionally moderate.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

NAT and Question Section Mismatch

[John Wiles]

Hello all,

I am running into a problem that I think is caused by either a misconfiguration 
in Bind9, our Cisco NAT, or perhaps both.

The scenario:

We host our own sites locally, including internal and external DNS. The 
external dns servers are delegated for reverse lookups. The NAT is a static one.

When I am on our internal network, I am able to query both servers and get the 
appropriate external ip address. However, when I try to do the same thing 
externally I get "Question section mismatch: got 6.1.1.10.in-addr.arpa/PTR/IN."

Some online tools will resolve the public ip to the appropriate hostname, but 
they will also show the ip as 10.1.1.6. Normally this wouldn't be an issue 
except that I think it is the reason for some emails not being delivered.

Any help or guidance is greatly appreciated.

John


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Try to figure a basic conf for BIND on Mac Catalina

[David Chandler]

Firewall was not enabled. The BIND service was not engaged nor would it engage 
with anything other than Caching. I have since given up on trying to do this on 
a Mac and installed Debian. It would appear that the variation used by Debian 
is more flexible and has less issues than the Mac version which again was only 
happy with a very basic configuration.

I did install this version thru Brew which may mean that the package there just 
has not caught up to the one that Debian has as Debian's layout of the 
named.conf files was very different. The location of the files was also 
different but that is always to be expected when working within any Apple O/S 
environment.
David





CONFIDENTIALITY NOTICE: This communication contains information intended for 
the use of the individuals to whom it is addressed and may contain information 
that is privileged, confidential or exempt from other disclosure under 
applicable law. If you are not the intended recipient, you are notified that 
any disclosure, printing, copying, distribution or use of the contents is 
prohibited. If you have received this in error, please notify the sender 
immediately by telephone or by returning it by return mail and then permanently 
delete the communication from your system. Thank you.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: "lame-servers: info: no valid RRSIG resolving ..."

[Sten Carlsen]

I see lots of lines like this. They all come from people trying to break into 
my SSH.

-- 
Best regards 
Sten Carlsen 


For every problem, there is a solution that
is simple, elegant, and wrong.
HL Mencken


> On 17 Apr 2020, at 17.24, btb via bind-users  wrote:
> 
> hi-
> 
> i'm seeing what i'm wondering if is a lot of "lame-servers: info: no valid 
> RRSIG resolving ..." messages in the logs [on average ~500 messages per day]. 
>  a small snippet:
> 
> 15-Apr-2020 18:11:46.057 lame-servers: info: no valid RRSIG resolving 
> 'jwplayer.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:11:46.150 lame-servers: info: no valid RRSIG resolving 
> 'tranet.net/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:11:47.559 lame-servers: info: no valid RRSIG resolving 
> 'inboxsdk.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:11:49.146 lame-servers: info: no valid RRSIG resolving 
> 'basis.net/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:11:58.474 lame-servers: info: no valid RRSIG resolving 
> 'starfinancial.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:11:59.665 lame-servers: info: no valid RRSIG resolving 
> 'vice.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:09.501 lame-servers: info: no valid RRSIG resolving 
> 'lithium.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:09.756 lame-servers: info: no valid RRSIG resolving 
> 'sc-static.net/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:10.004 lame-servers: info: no valid RRSIG resolving 
> 'snapchat.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:12.638 lame-servers: info: no valid RRSIG resolving 
> 'yimg.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:16.823 lame-servers: info: no valid RRSIG resolving 
> 'transamerica.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:16.932 lame-servers: info: no valid RRSIG resolving 
> 'quantummetric.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:17.129 lame-servers: info: no valid RRSIG resolving 
> 'tealiumiq.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:17.171 lame-servers: info: no valid RRSIG resolving 
> 'bounceexchange.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:22.971 lame-servers: info: no valid RRSIG resolving 
> 'mwefinancial.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:23.248 lame-servers: info: no valid RRSIG resolving 
> 'redditmedia.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:23.869 lame-servers: info: no valid RRSIG resolving 
> 'imtwjwoasak.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:25.189 lame-servers: info: no valid RRSIG resolving 
> 'b.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:25.313 lame-servers: info: no valid RRSIG resolving 
> 'jquery.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:26.555 lame-servers: info: no valid RRSIG resolving 
> 'forter.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:29.008 lame-servers: info: no valid RRSIG resolving 
> 'quovadisoffshore.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:29.029 lame-servers: info: no valid RRSIG resolving 
> 'quovadisglobal.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:29.974 lame-servers: info: no valid RRSIG resolving 
> 'mixpanel.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:35.786 lame-servers: info: no valid RRSIG resolving 
> 'spotify.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:36.982 lame-servers: info: no valid RRSIG resolving 
> 'freeform.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:38.295 lame-servers: info: no valid RRSIG resolving 
> 'edgedatg.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:58.190 lame-servers: info: no valid RRSIG resolving 
> 'footprintdns.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:13:01.282 lame-servers: info: no valid RRSIG resolving 
> 'qualifiedaddress.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:13:01.744 lame-servers: info: no valid RRSIG resolving 
> 'dc-msedge.net/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:14:54.009 lame-servers: info: no valid RRSIG resolving 
> 'facebook.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:16:20.039 lame-servers: info: no valid RRSIG resolving 
> 'pphosted.com/DS/IN': 192.5.6.30#53
> 
> a number of these [most?] are zones that are signed, and some don't even 
> exist, so i'm curious about seeing these messages.  what am i not 
> understanding, and/or what can i do to troubleshoot further?
> 
> thanks!
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question About Recursion In A Split Horizon Setup

[Bob Harold]

On Fri, Apr 17, 2020 at 12:45 PM Tim Daneliuk  wrote:

> On 4/17/20 10:17 AM, julien soula wrote:
> > On Fri, Apr 17, 2020 at 09:56:21AM -0500, Tim Daneliuk wrote:
> >> On 4/17/20 9:50 AM, Bob Harold wrote:
> >>>
> >>> 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 tun...@tundraware.com
> 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
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Enabling/using ECS feature in BIND 9.16.1

[Dawood Sajjadi]

Hi everyone,

I have compiled successfully bind-9.16.1 from its source code
(bind-9.16.1.tar.xz) and configured to function as a DNS resolver by
following the instructions presented in
http://www.linuxfromscratch.org/blfs/view/svn/server/bind.html
---
[root@ bind]# named -V
BIND 9.16.1 (Stable Release) 
running on Linux x86_64 3.8.13-118.20.3.el7uek.x86_64 #2 SMP Fri Feb 23
13:52:32 PST 2018
built by make with '--prefix=/usr' '--sysconfdir=/etc'
'--localstatedir=/var' '--mandir=/usr/share/man' '--with-libtool'
'--disable-static'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-16.0.3)
compiled with OpenSSL version: OpenSSL 1.0.2k-fips  26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips  26 Jan 2017
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
threads support is enabled

default paths:
  named configuration:  /etc/named.conf
  rndc configuration:   /etc/rndc.conf
  DNSSEC root key:  /etc/bind.keys
  nsupdate session key: /var/run/named/session.key
  named PID file:   /var/run/named/named.pid
  named lock file:  /var/run/named/named.lock
---

the named configuration file that I am using is as follows:
---
options {
directory "/etc/named";
pid-file "/var/run/named.pid";
statistics-file "/var/run/named.stats";
allow-query { any; };
recursion yes;
};
zone "." {
type hint;
file "root.hints";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "pz/127.0.0";
};

// Bind 9 now logs by default through syslog (except debug).
// These are the default logging rules.

logging {
category default { default_syslog; default_debug; };
category unmatched { null; };
  channel default_syslog {
  syslog daemon;  // send to syslog's daemon
  // facility
  severity info;  // only send priority info
  // and higher
  };
  channel default_debug {
  file "named.run"  versions 3;   // write to named.run in
  // the working directory
  // Note: stderr is used instead
  // of "named.run"
  // if the server is started
  // with the '-f' option.
  severity dynamic;   // log at the server's
  print-time yes; // current debug level
  };
  channel default_stderr {
  stderr; // writes to stderr
  severity info;  // only send priority info
  // and higher
  };
  channel null {
  null;   // toss anything sent to
// this channel
  };
};
---
The main reason that I am trying to use bind 9.16.1 is using EDNS Client
Subnet (ECS) feature to pass the DNS client subnet information to an
authoritative DNS or DNS server with geoip-enabled feature. To test this, I
run the following command on my server, but the response it not what I
expected. However, when I replace 127.0.0.1 with google's resolver
(8.8.8.8), it returns the correct answer.

$ dig +short +subnet=81.169.181.179/24 -t txt whereami.geotest2.XX.net.
@127.0.0.1

I was wondering is there anything that might be missed during the
compile/build process or setting the parameters in the named configuration
file? Any help would be appreciated.

Regards,
Dawood
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question About Recursion In A Split Horizon Setup

[Timothe Litt]

On 17-Apr-20 10:56, Tim Daneliuk wrote:
> On 4/17/20 9:50 AM, Bob Harold wrote:
>> 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. 



signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question About Recursion In A Split Horizon Setup

[Tim Daneliuk]

On 4/17/20 10:17 AM, julien soula wrote:
> On Fri, Apr 17, 2020 at 09:56:21AM -0500, Tim Daneliuk wrote:
>> On 4/17/20 9:50 AM, Bob Harold wrote:
>>>
>>> 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 tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND-9.16.1 memory leak?

[Anand Buddhdev]

On 17/04/2020 17:02, Karl Pielorz wrote:

Hi Karl,

> I seem to remember we got 'bitten' by large memory use when moving from
> a previous version of bind - do you have 'max-cache-size' set in your
> config?

It's an authoritative-only server, so there is (almost) no caching involved.

Anand
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND-9.16.1 memory leak?

[sthaug]

>> We have what appears to be a significant memory leak in BIND-9.16.1.
...
> I seem to remember we got 'bitten' by large memory use when moving
> from a previous version of bind - do you have 'max-cache-size' set in
> your config?

Yes. Set to 1G. In reality it shouldn't need a cache at all, since
this is a purely authoritative server (recursion no).

So this doesn't appear to be the problem. But thanks for the
suggestion!

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

"lame-servers: info: no valid RRSIG resolving ..."

[btb via bind-users]

hi-

i'm seeing what i'm wondering if is a lot of "lame-servers: info: no valid 
RRSIG resolving ..." messages in the logs [on average ~500 messages per day].  
a small snippet:

15-Apr-2020 18:11:46.057 lame-servers: info: no valid RRSIG resolving 
'jwplayer.com/DS/IN': 192.5.6.30#53
15-Apr-2020 18:11:46.150 lame-servers: info: no valid RRSIG resolving 
'tranet.net/DS/IN': 192.5.6.30#53
15-Apr-2020 18:11:47.559 lame-servers: info: no valid RRSIG resolving 
'inboxsdk.com/DS/IN': 192.5.6.30#53
15-Apr-2020 18:11:49.146 lame-servers: info: no valid RRSIG resolving 
'basis.net/DS/IN': 192.5.6.30#53
15-Apr-2020 18:11:58.474 lame-servers: info: no valid RRSIG resolving 
'starfinancial.com/DS/IN': 192.5.6.30#53
15-Apr-2020 18:11:59.665 lame-servers: info: no valid RRSIG resolving 
'vice.com/DS/IN': 192.5.6.30#53
15-Apr-2020 18:12:09.501 lame-servers: info: no valid RRSIG resolving 
'lithium.com/DS/IN': 192.5.6.30#53
15-Apr-2020 18:12:09.756 lame-servers: info: no valid RRSIG resolving 
'sc-static.net/DS/IN': 192.5.6.30#53
15-Apr-2020 18:12:10.004 lame-servers: info: no valid RRSIG resolving 
'snapchat.com/DS/IN': 192.5.6.30#53
15-Apr-2020 18:12:12.638 lame-servers: info: no valid RRSIG resolving 
'yimg.com/DS/IN': 192.5.6.30#53
15-Apr-2020 18:12:16.823 lame-servers: info: no valid RRSIG resolving 
'transamerica.com/DS/IN': 192.5.6.30#53
15-Apr-2020 18:12:16.932 lame-servers: info: no valid RRSIG resolving 
'quantummetric.com/DS/IN': 192.5.6.30#53
15-Apr-2020 18:12:17.129 lame-servers: info: no valid RRSIG resolving 
'tealiumiq.com/DS/IN': 192.5.6.30#53
15-Apr-2020 18:12:17.171 lame-servers: info: no valid RRSIG resolving 
'bounceexchange.com/DS/IN': 192.5.6.30#53
15-Apr-2020 18:12:22.971 lame-servers: info: no valid RRSIG resolving 
'mwefinancial.com/DS/IN': 192.5.6.30#53
15-Apr-2020 18:12:23.248 lame-servers: info: no valid RRSIG resolving 
'redditmedia.com/DS/IN': 192.5.6.30#53
15-Apr-2020 18:12:23.869 lame-servers: info: no valid RRSIG resolving 
'imtwjwoasak.com/DS/IN': 192.5.6.30#53
15-Apr-2020 18:12:25.189 lame-servers: info: no valid RRSIG resolving 
'b.com/DS/IN': 192.5.6.30#53
15-Apr-2020 18:12:25.313 lame-servers: info: no valid RRSIG resolving 
'jquery.com/DS/IN': 192.5.6.30#53
15-Apr-2020 18:12:26.555 lame-servers: info: no valid RRSIG resolving 
'forter.com/DS/IN': 192.5.6.30#53
15-Apr-2020 18:12:29.008 lame-servers: info: no valid RRSIG resolving 
'quovadisoffshore.com/DS/IN': 192.5.6.30#53
15-Apr-2020 18:12:29.029 lame-servers: info: no valid RRSIG resolving 
'quovadisglobal.com/DS/IN': 192.5.6.30#53
15-Apr-2020 18:12:29.974 lame-servers: info: no valid RRSIG resolving 
'mixpanel.com/DS/IN': 192.5.6.30#53
15-Apr-2020 18:12:35.786 lame-servers: info: no valid RRSIG resolving 
'spotify.com/DS/IN': 192.5.6.30#53
15-Apr-2020 18:12:36.982 lame-servers: info: no valid RRSIG resolving 
'freeform.com/DS/IN': 192.5.6.30#53
15-Apr-2020 18:12:38.295 lame-servers: info: no valid RRSIG resolving 
'edgedatg.com/DS/IN': 192.5.6.30#53
15-Apr-2020 18:12:58.190 lame-servers: info: no valid RRSIG resolving 
'footprintdns.com/DS/IN': 192.5.6.30#53
15-Apr-2020 18:13:01.282 lame-servers: info: no valid RRSIG resolving 
'qualifiedaddress.com/DS/IN': 192.5.6.30#53
15-Apr-2020 18:13:01.744 lame-servers: info: no valid RRSIG resolving 
'dc-msedge.net/DS/IN': 192.5.6.30#53
15-Apr-2020 18:14:54.009 lame-servers: info: no valid RRSIG resolving 
'facebook.com/DS/IN': 192.5.6.30#53
15-Apr-2020 18:16:20.039 lame-servers: info: no valid RRSIG resolving 
'pphosted.com/DS/IN': 192.5.6.30#53

a number of these [most?] are zones that are signed, and some don't even exist, 
so i'm curious about seeing these messages.  what am i not understanding, 
and/or what can i do to troubleshoot further?

thanks!
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question About Recursion In A Split Horizon Setup

[julien soula]

On Fri, Apr 17, 2020 at 09:56:21AM -0500, Tim Daneliuk wrote:
> On 4/17/20 9:50 AM, Bob Harold wrote:
> > 
> > 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
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question About Recursion In A Split Horizon Setup

[Bob Harold]

On Fri, Apr 17, 2020 at 11:03 AM Konstantin Stefanov 
wrote:

> On 17.04.2020 17:56, Tim Daneliuk wrote:
> > On 4/17/20 9:50 AM, Bob Harold wrote:
> >>
> >> 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?
>
> >
> >> '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).
>

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
>
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question About Recursion In A Split Horizon Setup

[Konstantin Stefanov]

On 17.04.2020 17:56, Tim Daneliuk wrote:

On 4/17/20 9:50 AM, Bob Harold wrote:


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?





'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
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND-9.16.1 memory leak?

[Karl Pielorz]

--On 17 April 2020 at 15:45:16 +0200 sth...@nethelp.no wrote:


We have what appears to be a significant memory leak in BIND-9.16.1.

...

Running a ps command for the named process every minute and logging
the result, I see the named virtual memory size (VSZ) increasing at
around 1.2 Mbyte/minute, and the resident size (RSS) increasing at
around 0.85 Mbyte/minute. No problems due to this so far, but pretty
obviously it's not viable in the long run.

I tried reading the CHANGES from 9.16.2, and didn't see anything which
suggested a fix for a memory leak problem.

Any suggestions?


Hi,

I seem to remember we got 'bitten' by large memory use when moving from a 
previous version of bind - do you have 'max-cache-size' set in your config?


As far as I can remember, the 'default' is to take 90% of the memory on the 
machine. This is great, unless the machine has lots of other stuff going on 
etc.  I think we noticed this during bind startup (i.e. from syslog output).


On our boxes we set it to "something sensible" - rather than using the 
default.


Might not be your problem - but thought it was worth mentioning / checking.

-Karl
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question About Recursion In A Split Horizon Setup

[Tim Daneliuk]

On 4/17/20 9:50 AM, Bob Harold wrote:
> 
> 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 tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question About Recursion In A Split Horizon Setup

[Bob Harold]

On Fri, Apr 17, 2020 at 10:34 AM Tim Daneliuk  wrote:

> On 4/17/20 7:26 AM, Bob Harold wrote:
> >
> > On Thu, Apr 16, 2020 at 7:17 PM Tim Daneliuk  > wrote:
> >
> > 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 tun...@tundraware.com  >
> > PGP Key: http://www.tundraware.com/PGP/
> >
> >
> > Is 127.0.0.1 in the 'trustedhosts' list?
>
> Yes
>
> > Are you telling 'dig' what server to use  - dig @*MailScanner warning:
> numerical links are often malicious:* 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)?
>
> > 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.
>
> > 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


> >
> > --
> > Bob Harold
> >
>
>
> --
>
> 
> Tim Daneliuk tun...@tundraware.com
> PGP Key: http://www.tundraware.com/PGP/
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question About Recursion In A Split Horizon Setup

[Tim Daneliuk]

On 4/17/20 7:26 AM, Bob Harold wrote:
> 
> On Thu, Apr 16, 2020 at 7:17 PM Tim Daneliuk  > wrote:
> 
> 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     tun...@tundraware.com 
> PGP Key:         http://www.tundraware.com/PGP/
> 
> 
> Is 127.0.0.1 in the 'trustedhosts' list?

Yes

> Are you telling 'dig' what server to use  - dig @*MailScanner warning: 
> numerical links are often malicious:* 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)?

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

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



> 
> -- 
> Bob Harold
> 


-- 

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

BIND-9.16.1 memory leak?

[sthaug]

We have what appears to be a significant memory leak in BIND-9.16.1.

Environment:
 FreeBSD 12.1-STABLE.
 BIND-9.16.1 installed from packages.
 Also uses libuv-1.35.0 installed from packages.
 Authoritative only.
 Around 800 zones of varying sizes. DNSSEC in use.

Running a ps command for the named process every minute and logging
the result, I see the named virtual memory size (VSZ) increasing at
around 1.2 Mbyte/minute, and the resident size (RSS) increasing at
around 0.85 Mbyte/minute. No problems due to this so far, but pretty
obviously it's not viable in the long run.

I tried reading the CHANGES from 9.16.2, and didn't see anything which
suggested a fix for a memory leak problem.

Any suggestions?

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question About Recursion In A Split Horizon Setup

[Bob Harold]

On Thu, Apr 16, 2020 at 7:17 PM Tim Daneliuk  wrote:

> 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 tun...@tundraware.com
> 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
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users