Re: High memory consumption in bind 9.18.2
n,
>>>>>>> > >
>>>>>>> > > Gathering the output of named statschannel should be good enough
>>>>>>> > > for initial assessment (json please).
>>>>>>> > >
>>>>>>> > > For 9.18, make sure the jemalloc is being used at runtime.
>>>>>>> >
>>>>>>> > Here are commands you asked for:
>>>>>>> >
>>>>>>> > 1. when running ./configure, make sure the output at the end has this:
>>>>>>> >
>>>>>>> > Configuration summary:
>>>>>>> > ---
>>>>>>> > Optional features enabled:
>>>>>>> > Memory allocator: jemalloc
>>>>>>> >
>>>>>>> >
>>>>>>> > 2. Then, configure statistics channel in named.conf like this:
>>>>>>> >
>>>>>>> > statistics-channels {
>>>>>>> > inet 127.0.0.1 port 8080;
>>>>>>> > };
>>>>>>> >
>>>>>>> >
>>>>>>> > 3. With that in place you can grab stats from this URL:
>>>>>>> > http://127.0.0.1:8080/json/v1
>>>>>>> >
>>>>>>> > Configuration for v9.16 is the same, just skip the jemalloc part.
>>>>>>> >
>>>>>>> > 4. Bonus points for grabbing /proc//statm content at the same
>>>>>>> > time
>>>>>>> > as content of the JSON stats endpoint (if you are on Linux).
>>>>>>> >
>>>>>>> > I hope it helps.
>>>>>>> > Petr Špaček
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > >
>>>>>>> > > Ondrej
>>>>>>> > > --
>>>>>>> > > Ondřej Surý — ISC (He/Him)
>>>>>>> > >
>>>>>>> > > My working hours and your working hours may be different. Please do
>>>>>>> > > not feel obligated to reply outside your normal working hours.
>>>>>>> > >
>>>>>>> > >> On 18. 5. 2022, at 22:32, Klaus Darilion via bind-users
>>>>>>> > >> wrote:
>>>>>>> > >>
>>>>>>> > >> Can you please provide some commands whose output you are
>>>>>>> > >> interested? I want to collect the statistics for 9.16 before
>>>>>>> > >> updating to 9.18.
>>>>>>> > >> Thanks
>>>>>>> > >> Klaus
>>>>>>> > >>
>>>>>>> > >>> -Ursprüngliche Nachricht-
>>>>>>> > >>> Von: bind-users Im Auftrag von
>>>>>>> > >>> Petr
>>>>>>> > >>> Špacek
>>>>>>> > >>> Gesendet: Mittwoch, 18. Mai 2022 18:20
>>>>>>> > >>> An: bind-users@lists.isc.org
>>>>>>> > >>> Betreff: Re: AW: High memory consumption in bind 9.18.2
>>>>>>> > >>>
>>>>>>> > >>> I would be very interested in hearing more!
>>>>>>> > >>>
>>>>>>> > >>> In majority of our internal testing 9.16 has higher memory
>>>>>>> > >>> consumption
>>>>>>> > >>> than 9.18, especially when 9.18 is compiled with libjemalloc. And
>>>>>>> > >>> the
>>>>>>> > >>> differences are not small, for some configurations it can be even
>>>>>>> > >>> 2x or
>>>>>>> > >>> 3x more on 9.16 than it is on 9.18.
>>>>>>> > >>>
>>>>>>> > >>> If you encounter it again please get back to us so we can
>>>>>>> > >>> diagnose it.
>>>>>>> > >>>
>>>>>>> > >>> Thank you!
>>>>>>> > >>> Petr Špaček
>>>>>>> > >>>
>>>>>&
Re: Access denied Bind9
You might search the list archives, as I think this came up recently...
But I think the general consensus is that you shouldn't have a server that is
both authoritative AND that allows recursive queries. (Security reasons)
And if you do allow both, to limit recursive queries to internal
(semi-trusted/controlled) hosts only.
The options you'll be wanting to look at are:
allow-query
allow-recursion
allow-query-cache
See the docs.
something like;
allow-recursion { local-nets; };
Where local-nets are the local subnets you want to allow recursion for -
meaning you trust those hosts on those subnets more than the open internet.
> Just to be clear, the servers are authoritative
> On Tue, Mar 8, 2022 at 5:27 AM Ritah Mulinde wrote:
>> Thank you Mark
>> Iam abit new to this. How do i fix that??
>> On Tue, Mar 8, 2022 at 5:19 AM Mark Andrews wrote:
>>> Presumably you are making recursive queries and you are denying them.
On 8 Mar 2022, at 12:44, Ritah Mulinde wrote:
Hi Guys
Just got my primary and secondary name servers running.
However, when i reload rdnc and tail the syslogs all i get is
"(.xx.com): query (cache) '.xx.com/A/IN' denied"
Not sure why.
kindly asking for some pointers on where to start looking
Thank you
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support
subscriptions. Contact us at https://www.isc.org/contact/ for more
information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Forwarding zone, setup
>Are you loading the parent domain and trying to zone forward a child domain on
>the same DNS server? I.e. loading somedomain.local and trying to forward
>ab.somedomain.local
Yup, exactly.
That solution was suggested by Jeff Sumner yesterday, but it seemed a little
nuts to me (BIND behaving that way) - though your explanation makes that
behavior seem less crazy.
If I get a chance, I'll perhaps try that, just to see if it fixes it - though
someone at ISC might save me the work, confirming the behavior. (please do!)
And, if that's the case, then static-sub is the far superior option - since
it's much more simple and straight-forward.
Consider it solved.
If ISC can confirm that behavior for forwarding a child domain when the server
is also auth for the parent zone, that would be very nice!
Thanks to everyone, again, for the help!
> Are you loading the parent domain and trying to zone forward a child domain
> on the same DNS server? I.e. loading somedomain.local and trying to forward
> ab.somedomain.local
> If so an NS delegation is required in every instance I have done in my
> environment. The NS doesn't need to be "right" but it needs to exist. I don't
> know the internal BIND logic for that but I have always taken it as "I load
> the parent and I know the child doesn't exist because there isn't a
> delegation to make it exist so why would I forward something that doesn't
> exist".
> On Tue, Mar 1, 2022, 1:18 PM Gregory Sloop wrote:
>> Static-sub fixes the issue.
>>
>> Any idea why static-sub works when forwarder doesn't?
>>
>> (Again, the server is using recursion. Dig queries return the RA flag, so I
>> know it's actually offering recursion in reality.)
>>
>> I can live with static-sub just fine, since it works - but I'd really love
>> to understand why forwarder didn't - just so I can avoid getting bitten by
>> it in some other situation.
>>
>> Thanks Andrej!
>> -Greg
>>
>>> Is static-stub something you are looking for?
>>> Reference documentation:
>>> https://bind9.readthedocs.io/en/v9_18_0/reference.html?highlight=static-stub#zone-types
>>> And in human terms:
>>> https://jpmens.net/2011/01/25/binds-new-static-stub-zone-type/
>>> Ondrej
>>> --
>>> Ondřej Surý (He/Him)
>>> ond...@isc.org
>>> My working hours and your working hours may be different. Please do not
>>> feel obligated to reply outside your normal working hours.
>>>> On 28. 2. 2022, at 21:47, Gregory Sloop wrote:
>>>> So, I want to forward all queries for
>>>> *.ab.somedomain.local to some other internal DNS servers.
>>>> (Records in *.ab.somedomain.local actually are our active domain servers)
>>>>
>>>> (Yes, I know .local is reserved now, but we've been using it a long time
>>>> and changing would be rather painful. Unless there's some horrible
>>>> consequences, I think we'll just continue for now. We won't ever use mDNS.)
>>>>
>>>> zone "ab.somedomain.local" {
>>>> type forward;
>>>> forward only;
>>>> forwarders { 10.0.0.1; 10.0.0.2; 10.0.0.3; };
>>>> };
>>>> But this doesn't appear to do what I want.
>>>>
>>>> If I add the above to my regular BIND servers configuration, it doesn't
>>>> return results like it's forwarding them. (I get NXDOMAIN for
>>>> abc.ab.somedomain.local.)
>>>>
>>>> If I do a dig @10.0.0.1 abc.ab.somedomain.local from the BIND server, I
>>>> get a proper result. (force dig to use the AD name servers directly,
>>>> instead of relying on the forward.)
>>>>
>>>> (And yes the resolv.conf file has the ip addresses of the main internal
>>>> BIND servers in it, and those only.)
>>>> I've looked and while I think I'm doing it right, I'm not entirely sure.
>>>> I figured before I beat my head against the wall for too long, I'd ask the
>>>> real experts! :)
>>>>
--
Gregory Sloop, Principal: Sloop Network & Computer Consulting
Voice: 503.251.0452 x121
EMail: gr...@sloop.net
http://www.sloop.net
-
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Forwarding zone, setup
Static-sub fixes the issue.
Any idea why static-sub works when forwarder doesn't?
(Again, the server is using recursion. Dig queries return the RA flag, so I
know it's actually offering recursion in reality.)
I can live with static-sub just fine, since it works - but I'd really love to
understand why forwarder didn't - just so I can avoid getting bitten by it in
some other situation.
Thanks Andrej!
-Greg
> Is static-stub something you are looking for?
> Reference documentation:
> https://bind9.readthedocs.io/en/v9_18_0/reference.html?highlight=static-stub#zone-types
> And in human terms:
> https://jpmens.net/2011/01/25/binds-new-static-stub-zone-type/
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@isc.org
> My working hours and your working hours may be different. Please do not feel
> obligated to reply outside your normal working hours.
>> On 28. 2. 2022, at 21:47, Gregory Sloop wrote:
>> So, I want to forward all queries for
>> *.ab.somedomain.local to some other internal DNS servers.
>> (Records in *.ab.somedomain.local actually are our active domain servers)
>>
>> (Yes, I know .local is reserved now, but we've been using it a long time and
>> changing would be rather painful. Unless there's some horrible consequences,
>> I think we'll just continue for now. We won't ever use mDNS.)
>>
>> zone "ab.somedomain.local" {
>> type forward;
>> forward only;
>> forwarders { 10.0.0.1; 10.0.0.2; 10.0.0.3; };
>> };
>> But this doesn't appear to do what I want.
>>
>> If I add the above to my regular BIND servers configuration, it doesn't
>> return results like it's forwarding them. (I get NXDOMAIN for
>> abc.ab.somedomain.local.)
>>
>> If I do a dig @10.0.0.1 abc.ab.somedomain.local from the BIND server, I get
>> a proper result. (force dig to use the AD name servers directly, instead of
>> relying on the forward.)
>>
>> (And yes the resolv.conf file has the ip addresses of the main internal BIND
>> servers in it, and those only.)
>> I've looked and while I think I'm doing it right, I'm not entirely sure.
>> I figured before I beat my head against the wall for too long, I'd ask the
>> real experts! :)
>>
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Forwarding zone, setup
This got held up in moderation. Let me repost it, from my regular mail client...
> You didn’t share much of your configuration except the one forwarded zone,
> not a lot to go on.
Fair enough. (I guess I thought you could just infer all the needed
information! Oops!)
Let me try Ondrej's static-sub and see if that makes a difference.
As for more detail.
Yeah, it's a recursive resolver, used internally only.
It's also authoritative for the somedomain.local zone.
I simply want(ed) to pass queries for *.ad.somedomain.local to another
server(s), so thought the forwarder setup was the right way to do that.
Sorry for being so lame in not providing enough detail - I think I just figured
I must be doing something terribly wrong and the forwarder setup must be wrong
in some obvious detail I wasn't seeing.
That doesn't appear to be the case, so we'll look again, try static-sub and
then re-group if it doesn't work.
Thanks all!
> But one thing to check, you do have recursion enabled on the server?
> On Mon, Feb 28, 2022 at 6:34 PM Gregory Sloop wrote:
>> Wow. I hate to be the guy who looks the gift horse in the mouth - but that
>> just seems "wrong." :)
>> (Not the answer, but that that would be the way BIND wants it done.)
>>
>> So, now I've got two sets of NS and glue records?
>> Please tell me that's not the way BIND insists you do this!
>>
>> I guess I should try it, but dang.
>> Does anyone know for sure?
>>
>>
>>> Add Delegating NS records:
>>> ab.somedomain.local 3600 NS server1.ab.somedomain.local
>>> .
>>> .
>>> .
>>> And glue records
>>> server1.ab.somedomain.local 3600 A 10.0.0.1
>>> .
>>> .
>>> And see if it works. It’s got something to do with the way the record is
>>> matched (or not) before the forward statement is hit.
>>> J
>>>> On Feb 28, 2022, at 3:47 PM, Gregory Sloop wrote:
>>>> So, I want to forward all queries for
>>>> *.ab.somedomain.local to some other internal DNS servers.
>>>> (Records in *.ab.somedomain.local actually are our active domain servers)
>>>>
>>>> (Yes, I know .local is reserved now, but we've been using it a long time
>>>> and changing would be rather painful. Unless there's some horrible
>>>> consequences, I think we'll just continue for now. We won't ever use mDNS.)
>>>>
>>>> zone "ab.somedomain.local" {
>>>> type forward;
>>>> forward only;
>>>> forwarders { 10.0.0.1; 10.0.0.2; 10.0.0.3; };
>>>> };
>>>> But this doesn't appear to do what I want.
>>>>
>>>> If I add the above to my regular BIND servers configuration, it doesn't
>>>> return results like it's forwarding them. (I get NXOMAIN for
>>>> abc.ab.somedomain.local.)
>>>>
>>>> If I do a dig @10.0.0.1 abc.ab.somedomain.local from the BIND server, I
>>>> get a proper result. (force dig to use the AD name servers directly,
>>>> instead of relying on the forward.)
>>>>
>>>> (And yes the resolv.conf file has the ip addresses of the main internal
>>>> BIND servers in it, and those only.)
>>>> I've looked and while I think I'm doing it right, I'm not entirely sure.
>>>> I figured before I beat my head against the wall for too long, I'd ask the
>>>> real experts! :)
>>>> --
>> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
>> this list
>> ISC funds the development of this software with paid support subscriptions.
>> Contact us at https://www.isc.org/contact/ for more information.
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
--
Gregory Sloop, Principal: Sloop Network & Computer Consulting
Voice: 503.251.0452 x121
EMail: gr...@sloop.net
http://www.sloop.net
-
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Forwarding zone, setup
Wow. I hate to be the guy who looks the gift horse in the mouth - but that just
seems "wrong." :)
(Not the answer, but that that would be the way BIND wants it done.)
So, now I've got two sets of NS and glue records?
Please tell me that's not the way BIND insists you do this!
I guess I should try it, but dang.
Does anyone know for sure?
> Add Delegating NS records:
> ab.somedomain.local 3600 NS server1.ab.somedomain.local
> .
> .
> .
> And glue records
> server1.ab.somedomain.local 3600 A 10.0.0.1
> .
> .
> And see if it works. It’s got something to do with the way the record is
> matched (or not) before the forward statement is hit.
> J
>> On Feb 28, 2022, at 3:47 PM, Gregory Sloop wrote:
>> So, I want to forward all queries for
>> *.ab.somedomain.local to some other internal DNS servers.
>> (Records in *.ab.somedomain.local actually are our active domain servers)
>>
>> (Yes, I know .local is reserved now, but we've been using it a long time and
>> changing would be rather painful. Unless there's some horrible consequences,
>> I think we'll just continue for now. We won't ever use mDNS.)
>>
>> zone "ab.somedomain.local" {
>> type forward;
>> forward only;
>> forwarders { 10.0.0.1; 10.0.0.2; 10.0.0.3; };
>> };
>> But this doesn't appear to do what I want.
>>
>> If I add the above to my regular BIND servers configuration, it doesn't
>> return results like it's forwarding them. (I get NXOMAIN for
>> abc.ab.somedomain.local.)
>>
>> If I do a dig @10.0.0.1 abc.ab.somedomain.local from the BIND server, I get
>> a proper result. (force dig to use the AD name servers directly, instead of
>> relying on the forward.)
>>
>> (And yes the resolv.conf file has the ip addresses of the main internal BIND
>> servers in it, and those only.)
>> I've looked and while I think I'm doing it right, I'm not entirely sure.
>> I figured before I beat my head against the wall for too long, I'd ask the
>> real experts! :)
>> --
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Forwarding zone, setup
So, I want to forward all queries for
*.ab.somedomain.local to some other internal DNS servers.
(Records in *.ab.somedomain.local actually are our active domain servers)
(Yes, I know .local is reserved now, but we've been using it a long time and
changing would be rather painful. Unless there's some horrible consequences, I
think we'll just continue for now. We won't ever use mDNS.)
zone "ab.somedomain.local" {
type forward;
forward only;
forwarders { 10.0.0.1; 10.0.0.2; 10.0.0.3; };
};
But this doesn't appear to do what I want.
If I add the above to my regular BIND servers configuration, it doesn't return
results like it's forwarding them. (I get NXOMAIN for abc.ab.somedomain.local.)
If I do a dig @10.0.0.1 abc.ab.somedomain.local from the BIND server, I get a
proper result. (force dig to use the AD name servers directly, instead of
relying on the forward.)
(And yes the resolv.conf file has the ip addresses of the main internal BIND
servers in it, and those only.)
I've looked and while I think I'm doing it right, I'm not entirely sure.
I figured before I beat my head against the wall for too long, I'd ask the real
experts! :)
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Strange named freezing
Entorpy is not RAM or CPU. VM's or Jails can often have difficulty accessing truly good sources of random events, and thus have difficulty having enough available entropy to handle encryption/cryptography functions in a timely manner. See: https://www.google.com/search?q=entropy > More, than enough. During last freeze server has ~30Gb free RAM and ~ 2-3% > CPU load and more than 200Gb free storage space for this jail. DC jail dont > have any resources limitations. Its very strange, because during using > previously DC in the similar jail on this server I dont have this trouble. > 27.12.2021 11:07, Ondřej Surý пишет: >> Does the jail have enough entropy? That would be my first guess… >> -- >> Ondřej Surý — ISC (He/Him) >> My working hours and your working hours may be different. Please do not feel >> obligated to reply outside your normal working hours. >>> On 13. 12. 2021, at 7:18, Nikita Druba wrote: >>> What can be wrong here? How I can more localize the problem? > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Gregory Sloop, Principal: Sloop Network & Computer Consulting Voice: 503.251.0452 x121 EMail: gr...@sloop.net http://www.sloop.net ---___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: No more support for windows
This feels a lot like responding to trolls, but I'll instead assume that you're asking (or making a point) in good faith. So, we'll stipulate that - you're actually interested in truth and knowledge. So, it's easily compiled on Mac, Unix, FreeBSD, Linux, SunOS, RaspPi, etc. And it compiles on a huge range of hardware, CPU's etc. I'd consider that highly portable. You're welcome to disagree, but then someone else will complain it's not available in Amiga, Atari and under Dos and complain it isn't "portable" because there's no dos version. So how many platforms do you have to support, to call it portable? (I've always thought of "portable" code, in this context especially, as code that is kept open so it will fairly easily compile on any *nix/posix platform without too much drama. And I think that's a pretty universal understanding for *nix style code.) So, it seems you are tilting at windmills, complaining about Windows only. Yes, the fundamentals of Windows are *VERY* different than any Linux/Unix/Solaris etc based platform. As such, making it work across all those platforms is really quite a lot of work. (Making it work fine, even on the future supported platforms (*nix) isn't trivial - obviously adding Windows to the mix is far, far more!) And, it seems like no-one has stepped up to commit the $$$ needed to keep that support going. Even a cheap dev probably charges $100+ an hour. How many hours/dollars do you think, in aggregate, is committed to keeping Windows support? It's not going to be like buying a $3 app for your phone - since the market for Windows users is far smaller. And, I suspect, if we reach the end of the road for Windows support, and there's a half million users out there that want BIND supported on Windows, and they'll all pledge a buck a year, than I'd expect that Windows support will roll right out. But if instead there's 100 people willing to pledge even $100 a year, well I'd guess that's not likely to pay for it. ISC manages to pay the people who write code and do support through support contracts. Do you have one of those? So the last option is; You, or someone else to simply give away their time for free. You up for that? If you're not, or you don't have that skill set, then complaining bitterly seems a little hypocritical. ISC already releases a huge set of software that you almost certainly use every single day (DHCP server and clients, along with BIND) and they aren't charging you a dime for that use. They're not charging your ISP either, or a ton of other people. So, IMO, they've really done a ton of free work for the community already. But it seems like you think it's not enough. Sigh. What. Can. I. Say. ISC does a lot of really good work. IMO, this kind of a complaint is really misplaced. And to be clear, I won't engage in a bunch of back-and-forth arguing this position. You're welcome to agree or not. But *I* think you're obviously wrong, and I want everyone at ISC who does all that good work, developing great software that they let us use for free that I really appreciate their work. -Greg PC> What I find ironic is that here: PC> https://gitlab.isc.org/isc-projects/bind9/-/blob/main/README.md PC> the very first line says: PC> "BIND (Berkeley Internet Name Domain) is a complete, highly portable PC> implementation of the Domain Name System (DNS) protocol." PC> If this were truly the case, BIND would work on Windows (or any other PC> platform that doesn't have a "u" in it's name) with minimal effort PC> and would not require specific funding to adapt it to any particular PC> platform. PC> Can we please have a realistic definition of what BIND is and what PC> it's objectives are? PC> I for one would be more likely to contribute to the development of PC> a non-platform-specific, portable BIND than a single-platform-specific PC> one. PC> On the other hand, if it has already been decided that BIND can only PC> realistically be implemented in the *u* arena and will rely on PC> facilities only available in this arena, then shouldn't this be stated PC> clearly instead of also declaring that it is highly portable? PC> Regards, PC> Peter Coghlan. >> Do you understand how ironic is for you to complain about “subscription is >> not going to happen” while **every** email on the mailing list has this >> note in the footer: >> ISC funds the development of this software with paid support subscriptions. >> Contact us at https://www.isc.org/contact/ for more information. >> -- >> Ondřej Surý — ISC (He/Him) >> My working hours and your working hours may be different. Please do not feel >> obligated to reply outside your normal working hours. >>> On 4. 6. 2021, at 19:47, Peter via bind-users >>> wrote: >>> >>> On 04/06/2021 6:05 pm, John Thurston wrote: > On 6/4/2021 8:48 AM, Peter via bind-users wrote: > When people find out2024 is the year bind is no longer supported for > windows people aregoing to be
Re: Any interest in a write-up showing how to configure BIND 9.17x with DoH and LetsEncrypt?
It's not like there's been a paucity of "Yeah, I'm interested" messages, but I agree with the rest. +1000 I'd love to see it! DNS over HTTPS support appears to be steadily increasing and it looks like the next version of Windows 10, Windows 10 21H2, will including support for DoH at the operating system level. I spent a little time this weekend setting-up BIND 9.17.13 on Ubuntu 21.04 and configuring the system as a recursive resolver offering DNS over HTTPS using a LetsEncrypt certificate. Is there any interest in me writing this up as a web article, or has everyone whos interested in DoH already got it running comfortably in their test environment? Best. Richard. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND server; dig vs dig +trace on failing lookup.
Let me take a swing at it. If I'm wrong, someone correct me. 1) dig the name servers for the 1st level domain. (In this case, it's a .com.) # dig +short com. NS c.gtld-servers.net. f.gtld-servers.net. j.gtld-servers.net. l.gtld-servers.net. k.gtld-servers.net. d.gtld-servers.net. g.gtld-servers.net. i.gtld-servers.net. a.gtld-servers.net. e.gtld-servers.net. m.gtld-servers.net. b.gtld-servers.net. h.gtld-servers.net. --- 2) How, ask one of those name servers for the NS for the target domain. (cistus.com. in this case.) # dig +norec @i.gtld-servers.net. cistus.com. NS ; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> +norec @i.gtld-servers.net. cistus.com. NS ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49843 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;cistus.com.IN NS ;; AUTHORITY SECTION: cistus.com. 172800 IN NS srvns.pacifier.com. cistus.com. 172800 IN NS webns.pacifier.com. ;; ADDITIONAL SECTION: srvns.pacifier.com. 172800 IN A 216.65.128.5 webns.pacifier.com. 172800 IN A 216.65.128.1 --- 3) Finally, query the records in the additional section to see if they match the glue records. # dig srvns.pacifier.com. ; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> srvns.pacifier.com. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17445 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: d16ea0cbd520a81cea1154c1603ef7e13d586e8adc0e75f3 (good) ;; QUESTION SECTION: ;srvns.pacifier.com.IN A ;; ANSWER SECTION: srvns.pacifier.com. 85728 IN A 64.255.237.241 ;; AUTHORITY SECTION: pacifier.com. 172126 IN NS ns2.iinet.com. pacifier.com. 172126 IN NS ns4.iinet.com. pacifier.com. 172126 IN NS ns1.iinet.com. pacifier.com. 172126 IN NS ns3.iinet.com. (glue) srvns.pacifier.com. 172800 IN A 216.65.128.5 vs (regular lookup) srvns.pacifier.com. 85728 IN A 64.255.237.241 And they don't - so we know the glue is stale. Is that right? :) -Greg Would you mind showing me how you got there? [The answer is fab, obviously. But give a man a fish...and all that. :) ] -Greg MA> The COM servers have stale glue MA> srvns.pacifier.com. 172800 IN A 216.65.128.5 MA> webns.pacifier.com. 172800 IN A 216.65.128.1 MA> vs MA> srvns.pacifier.com. 86400 IN A 64.255.237.241 MA> webns.pacifier.com. 86400 IN A 64.255.237.240 MA> The later set of servers are what you query when you run dig +trace. MA> If you prime the cache the plain lookup should work. Report the out MA> of date glue to the zone administrator. MA> Mark >> On 3 Mar 2021, at 13:06, Gregory Sloop wrote: >> I've got a case, (and I see several other similar reports) where BIND is >> failing to find an A record for a domain. >> Yet a dig +trace does. >> (I'm doing the dig on the BIND server. It's set to be a root resolving >> server, not a forwarder.) >> As I understand this, +trace will also involve resolve.conf options. And in >> this case, I've got Google DNS as one of the resolve.conf entries. >> So, I can see how +trace would deliver different results than simply dig-ing >> - provided that +trace does involve resolve.conf. >> Here's a plain dig, using the BIND server itself - from the console. >> --- >> dig cistus.com @10.8.20.5 >> ; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> cistus.com @10.8.20.5 >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61786 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ; COOKIE: 13ec0c9b10770ea12426539e603957900a997f7258962cce (good) >> ;; QUESTION SECTION: >> ;cistus.com.IN A >> ;; Query time: 0 msec >> ;; SERVER: 10.8.20.5#53(10.8.20.5) >> ;; WHEN: Fri Feb 26 12:18:24 PST 2021 >> ;; MSG SIZE rcvd: 67 >> --- >> I could post the dig +trace, if it adds any information, but I suspect it >> doesn't. >> So, what methods or steps might I take to figure out why the above >> lookup/dig fails? >> [I intended +trace to do that, but since it's not doing the same thing a >> plain dig does, it's not very useful as a diagno
Re: BIND server; dig vs dig +trace on failing lookup.
Would you mind showing me how you got there? [The answer is fab, obviously. But give a man a fish...and all that. :) ] -Greg MA> The COM servers have stale glue MA> srvns.pacifier.com. 172800 IN A 216.65.128.5 MA> webns.pacifier.com. 172800 IN A 216.65.128.1 MA> vs MA> srvns.pacifier.com. 86400 IN A 64.255.237.241 MA> webns.pacifier.com. 86400 IN A 64.255.237.240 MA> The later set of servers are what you query when you run dig +trace. MA> If you prime the cache the plain lookup should work. Report the out MA> of date glue to the zone administrator. MA> Mark >> On 3 Mar 2021, at 13:06, Gregory Sloop wrote: >> I've got a case, (and I see several other similar reports) where BIND is >> failing to find an A record for a domain. >> Yet a dig +trace does. >> (I'm doing the dig on the BIND server. It's set to be a root resolving >> server, not a forwarder.) >> As I understand this, +trace will also involve resolve.conf options. And in >> this case, I've got Google DNS as one of the resolve.conf entries. >> So, I can see how +trace would deliver different results than simply dig-ing >> - provided that +trace does involve resolve.conf. >> Here's a plain dig, using the BIND server itself - from the console. >> --- >> dig cistus.com @10.8.20.5 >> ; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> cistus.com @10.8.20.5 >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61786 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ; COOKIE: 13ec0c9b10770ea12426539e603957900a997f7258962cce (good) >> ;; QUESTION SECTION: >> ;cistus.com.IN A >> ;; Query time: 0 msec >> ;; SERVER: 10.8.20.5#53(10.8.20.5) >> ;; WHEN: Fri Feb 26 12:18:24 PST 2021 >> ;; MSG SIZE rcvd: 67 >> --- >> I could post the dig +trace, if it adds any information, but I suspect it >> doesn't. >> So, what methods or steps might I take to figure out why the above >> lookup/dig fails? >> [I intended +trace to do that, but since it's not doing the same thing a >> plain dig does, it's not very useful as a diagnostic tool.] >> I've done some searching to see how to accomplish this, but it's a difficult >> question to frame without a ton of worthless hits. >> So, can someone point me at a good source for a how-to/walk-through? A >> previous list posting? >> Again, the question is; what methods or steps (best practices) might I take >> to figure out why the above lookup/dig fails? >> TIA >> -Greg >> ___ >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >> unsubscribe from this list >> ISC funds the development of this software with paid support subscriptions. >> Contact us at https://www.isc.org/contact/ for more information. >> 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 ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND server; dig vs dig +trace on failing lookup.
I've got a case, (and I see several other similar reports) where BIND is failing to find an A record for a domain. Yet a dig +trace does. (I'm doing the dig on the BIND server. It's set to be a root resolving server, not a forwarder.) As I understand this, +trace will also involve resolve.conf options. And in this case, I've got Google DNS as one of the resolve.conf entries. So, I can see how +trace would deliver different results than simply dig-ing - provided that +trace does involve resolve.conf. Here's a plain dig, using the BIND server itself - from the console. --- dig cistus.com @10.8.20.5 ; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> cistus.com @10.8.20.5 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61786 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 13ec0c9b10770ea12426539e603957900a997f7258962cce (good) ;; QUESTION SECTION: ;cistus.com.IN A ;; Query time: 0 msec ;; SERVER: 10.8.20.5#53(10.8.20.5) ;; WHEN: Fri Feb 26 12:18:24 PST 2021 ;; MSG SIZE rcvd: 67 --- I could post the dig +trace, if it adds any information, but I suspect it doesn't. So, what methods or steps might I take to figure out why the above lookup/dig fails? [I intended +trace to do that, but since it's not doing the same thing a plain dig does, it's not very useful as a diagnostic tool.] I've done some searching to see how to accomplish this, but it's a difficult question to frame without a ton of worthless hits. So, can someone point me at a good source for a how-to/walk-through? A previous list posting? Again, the question is; what methods or steps (best practices) might I take to figure out why the above lookup/dig fails? TIA -Greg___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How Zone Files Are Read
This isn't, IMO, very useful as a response to the OP. To sum up the response; "It's better to never fail!" Yes, that seems pretty obvious. It *would* be better to never fail. Way, way better. But the big problem in life is; We're always failing! Dammit! So, learning how to gracefully fail, and understanding what happens and why, when something fails, is pretty important to achieve the outcome of; "Not failing quite so catastrophically." So, while I don't have helpful knowledge to impart to the OP, I think I can say that giving the advice of "don't fail" doesn't seem very helpful. RH> Am 16.12.20 um 17:37 schrieb Tim Daneliuk: >> I ran into a situation yesterday which got me pondering something about bind. >> In this case, a single line in a zone file was bad. The devops automation >> had inserted a space in the hostname field of a PTR record. >> What was interesting was that - at startup - bind absolutely refused >> to load the zone file at all. I would have expected it to complain >> about the bad record and ignore it, but load the rest of the >> good records. >> Can someone please explain the rationale or logic for this? Not complaining, >> just trying to understand for future reference. RH> it's better not load a invalid zone on a single nameserver at all as you RH> are supposed to have at least two nameservers and the second one won't RH> get the failure via master/slave replication RH> if it has an error something is wrong RH> if the last version had no error that version is good RH> for the world *everything* still is good as long there is one slave - RH> subtle errors can lead to completly unexpected behavior RH> ___ RH> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
rndc valid key types
So, I've spent some time looking at the man pages and googling without any definitive answer. I'm generating some new rndc keys for my bind9 config. (9.11.3 in this particular case, if it matters.) rndc-confgen has quite a number of options for the key-type - but I'm not sure what BIND9 will handle for RNDC. I've seen reports that only HMAC-MD5 is the only valid key type. ... Just before posting this, I checked the RNDC man page and found this: [At least I saved myself some public embarrassment! :) ] --- rndc communicates with the name server over a TCP connection, sending commands authenticated with digital signatures. In the current versions of rndc and named, the only supported authentication algorithms are HMAC-MD5 (for compatibility), HMAC-SHA1, HMAC-SHA224, HMAC-SHA256 (default), HMAC-SHA384 and HMAC-SHA512. They use a shared secret on each end of the connection. This provides TSIG-style authentication for the command request and the name server's response. All commands sent over the channel must be signed by a key_id known to the server. --- Still, the root cause for my query Is there any (security) reason/implications to use something "better" than MD5? I'd lean toward something like HMAC-SHA256/384/512. Perhaps there's a discussion somewhere I haven't found - and I'd be glad to be pointed to that, instead of taking someone's time re-typing a bunch of details. But I can't seem to find anything. I assume it might be easier to forge an update for rndc with an MD5 key, right? Is there any reason not to select the strongest - HMAC-SHA512? Just wanting to be sure I understand the implications of any particular choice. TIA -Greg___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND Masters and slaves
This whole discussion seems so misguided. The TLDR; version, at least for me is; Does it really cost you that much to use language that's polite and kind to those around you, and change that language to live up to those ideals when you can? Sure you _have the right_ to run down the street and yell impolite/angry/mysoginistic epithets and racial insults at those around you. But rather than focusing on _your rights_, how about spending a few minutes considering how you'd feel if people did equally insensitive things to your mom, you sister, your wife, or your best friend. When viewed from that perspective, the "outrage" at not using/changing terms like master/slave in BIND seem, at least to my mind, kind of hyperbolic. You can call it politically correct, but I generally like to call it "being nice" or "polite" or "kind." When did it suddenly become so wrong to be gentle, kind and caring? [That's a rhetorical question, so no need to "answer" it.] The BIND and DHCP lists have historically been incredible lists for really polite and helpful people over the many years I've subscribed and participated. IME, these lists have been far superior to nearly any other lists I've been a part of. Super helpful. Really nice people> Super respectful. Totally awesome. I'm nearly always chuffed to see the behavior here. I hope that continues. MDR> Completely aside from the topic at hand, I often like to think that MDR> after a few years I mastered something. System administration, MDR> electronics, programming, whatever has piqued my interest for several MDR> years already and got me to invest in it. It is never true. The first MDR> profession I pursued was system administration and Linux in general. MDR> Even today I still learn so much on the daily. Mastery? I may be MDR> experienced with Linux but mastery is still far ahead... It's quite MDR> interesting how deep the rabbit hole can go. What matters is how deep we MDR> want it to go I guess. MDR> Crackerjack is an interesting name, if anything I'd just want it for MDR> shits and giggles :D MDR> On 6/15/20 9:07 PM, Brett Delmage wrote: >> After I feel I have mastered DNS and BIND after slaving over the docs >> and code for years (I'm not there yet, and I have not) how am I going >> to communicate this to people? >> How will I be able to master anything technical anymore? Should I just >> stop trying? >> Thesaurus.com suggests that one could call one type of DNS server the >> "crackerjack" server instead. I guess that's an improvement over >> "cracked". "Ace" server is a suggested alternative too, and it's >> nicely terse. >> https://www.thesaurus.com/browse/master?s=t___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Proposal to adopt a Code of Conduct for the list
That code of conduct is a good starting place, at minimum. Regardless of how it may be now, it may not always be a great a place - and setting out the expectations and standards expected is a good hedge against future tyrants. So, I applaud ISC for taking the steps to formally set out the standards they expect on the list. Far better to do it now in "fair" weather then when things are much worse. And on that note... I know I've said it before - but I really must take the time to thank the many posters here. I'd name names - but I'm sure I'd miss someone. I've been on a lot of forums and lists the last 30+ years, and I don't believe I've ever found one that has such great people who show such great knowledge and more importantly, to me at least, such grace and tactfulness and elegance when posting here. Other lists likemumblefreeradiusmumble have great technical skill present, but are regularly abrasive, and curt. They may offer good technical advice, but do it in such a way that it's not very pleasant. Other; both illiterate and tyrants or just nice illiterates. But THIS place, and these posters that we regularly see here are pretty awesome. The only downside is - I sometimes hesitate to post, since the other great posters are likely to crank out something so awesome, through and full of details I'll probably forget to put in, I'll feel like a worm. :) [But please don't stop on my account!] So, again - I'm always impressed with the posting tone, and technical quality - both here and on the BIND list. This is one of those lists I stay a member of simply because it's technically rewarding to read, and reminds me, often, that there ARE still nice people who post on the internet. Thanks! This list is a tremendously helpful and generous group that has provided really invaluable assistance to many new and experienced users. I would like to thank all of you who share your time and expertise with random users on the Internet, as well as giving feedback to ISC via this list. We had some discussion within ISC and there are mixed opinions about the need for and utility of adopting a Code of Conduct (CoC) to ensure that this list remains welcoming, useful and tolerant. We have considered statements used by other projects, lists and open source communities. We agreed that I would begin by reiterating a statement posted on this list back in 2016, asking for respect and civility, to see what people think of that as a code of conduct for this list. Here it is: https://lists.isc.org/pipermail/bind-users/2016-October/097925.html We should like to remind list users that irrespective of the basic levels of experience or knowledge of some of the posters here, that they are asking for community help and that advice should be given politely and with respect shown both towards the original poster and other contributors to a thread. The same courtesy and respect is also expected of list members towards others when discussing more advanced and complex topics. Please remember that: - English is not the first language for all - this can lead to misunderstandings - Beginners don't always 'get it' from the start (but with gentle guidance may become the experts of the future and surprise us all) If you disagree with another poster on a technical matter, please explain your position clearly, thoughtfully, and with appropriate support for your viewpoint. If you believe that you are the target of an insulting or inappropriate post, please alert the list administrators* rather than retaliating on the mailing list. If you have any other concerns about a poster, please bring them to the attention of the list administrators. Insulting and derogatory posts will not be tolerated and will result in future posts from those list members who are posting in this manner being held for moderation or suspended indefinitely from this community. Cathy Almond ISC Support * contact the list administrators directly by emailing to bind-users-ow...@lists.isc.org -- Victoria Risk Product Manager Internet Systems Consortium vi...@isc.org ___ 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: Bind9 stops responding for some clients
Thanks for the idea. I did resolve this a day or two ago. The story is; This server was a fairly recent replacement for an older Ubuntu setup. The new server as well as the old one are/were VM's - yet on different VM platforms. The old VM was turned off, and was marked never to start except unless manually started. [There were a few other things on the VM host that had yet to be migrated - so we didn't want it entirely off quite yet.] The problem happened again in the last day or two - and packet captures showed that no packets were even arriving at the new VM. Since there really wasn't anything that should be blocking that traffic, I checked the arp table on a problem client. The arp table showed an "incorrect" MAC address for the current BIND server. [The MAC in the arp table didn't match the MAC for the new VM.] While I didn't have the MAC address for the "old" deactivated server handy, it was the first obvious problem/solution to check. Sure enough, after connection to the VM hypervisor, I could see that the "old" BIND vm was active. I killed it, and service returned to normal. So, the "solution" was pretty routine. What made it more "interesting" and perhaps odd is how seemingly randomly the problem would crop up. And it would only impact some clients, not all. There was no pattern that seemed to explain why some got the current/correct BIND server and others didn't. [The arp poisoning certainly wasn't anywhere nearly universal.] And why was it so infrequent - it would go many days between issues. I have to assume the bad VM had been up for some time, at least since the problems started. There are quite a number of odd-ish other things too, but not worth detailing. Probably it's just one of those "undefined" situations where you can't anticipate some predictable order to what happens when you screw it up. Rather than burn additional time trying to grok what was going on - it's simply best to say "don't do that - bad things happen, though I can't say what bad things will happen and in which logical order. They just will - so DON'T DO THAT!" [And yeah, I obviously knew all about not doing that. But it happened anyway, in spite of specific steps to prevent it. I'm still not sure why.] In the end, it's a somewhat complicated story with a very obvious cause - but it wasn't so clear at the outset. TLDR version; Don't run your old and new bind servers on the same IP address - ether by accident or intentionally. Bad stuff will happen! It might be really odd, or it might be plain as day - but in either case it won't be good! :) Thanks all for the suggestions! Here's hoping I don't need to ask for BIND assistance for another 20 years! :) -Greg I just randomly spotted this post, and thought I would toss in 2¢ How many nics and how many it's are on the servers? Are the failing clients on the same subnet as the server? -- ___ 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: Bind9 stops responding for some clients
Ugh. Not wanting to packet capture. :) [Yeah, not that hard, but it always seems to suck up so much time - it's like the black hole for time, I think.] But, yeah, absent some other smoking gun, that's probably where we're headed. As for rate limiting - "rndc recursing" didn't show anything being rate limited. [No output. I assume that means there's nothing there. And ISC claims that rate limiting isn't turned on by default - I certainly haven't enabled anything related to rate limits.] There's no firewalling/filtering between any of the affected clients and the DNS servers. Without going into too much detail, the network's pretty flat. There are (4) /24 subnets, but they're all passing through a L3 switch for "routing." Essentially all filtering occurs at the border only, so, SPI or other stuff shouldn't be in the mix here. Sigh. As my colleague said... "Heh. How, um, fun?" -Greg Whilst you mentioned 150 seats and you mentioned 'no firewalls', you didn't mention the network topology at all, in particular is traffic passing through a commercial firewall/router (hardware or virtualized) to get to the DNS server? If there is, it may be worth checking what packet inspection is turned on for DNS traffic (Cisco, Juniper and Checkpoint have been known to have buggy inspection routines in the past). I might also be worthwhile to see what your open filehandles are like and whether there's any rate limiting configured in the distributed BIND configuration. Stuart From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of John W. Blue Sent: Friday, 31 May 2019 11:47 AM To: bind-users@lists.isc.org Subject: Re: Bind9 stops responding for some clients Good job on the amount of troubleshooting work done so far. Next steps should be to run tcpdump on the interface for port 53 to see what is happening when an outage is in progress. What you will be looking for specifically is the query packet in and the response packet out. Use the following command: tcpdump -n -i eth0 port domain and host 172.24.67.32 Swap out eth0 for whatever you have configured and the host IP address for a host that is having problems. John Sent from Nine From: Gregory Sloop Sent: Thursday, May 30, 2019 7:11 PM To: bind-users@lists.isc.org Subject: Bind9 stops responding for some clients So, this is a very odd situation and I'm kind of grasping at straws here. So, I've come to see if any of you have any good straws! The setup. --- Ubuntu 18.04 LTS is the distro we're running on. All software is packaged [from the distro] - not compiled from sources. Bind9 acting as a recursive resolver for a smallish network. 150 seats. They're also handling DHCP and Chrony/NTP requests. [I actually have a pair of these handling DNS/DHCP/NTP this is the master.] They are running on a Xen/XCP VM. The one I'm having problems is the master for several internal zones - the one that's working fine is the slave for those same zones. None of the zones are large. Intermittently, Bind9 simply stops handling queries from *some* hosts. Meaning, it simply times out for responses for those hosts. Yet BIND *is* working fine for lots of other machines on the same networks. It's working fine doing dig queries locally on the server, and handles dns queries fine for lots of other machines. Yet, again, some machines simply get time-outs. I can't find any pattern to which machines get timeouts and which don't. I've checked - no firewalls, fail2ban or the like that might be causing this. No selinux/apparmour. Hosts that can't do dns queries can ping the dns server fine. [So, there's at least some network pathway to the DNS machine.] Review of the logs for bind don't show anything that looks like a problem to me. [But I'm not sure what keywords I ought to be looking for, in an effort to find symptoms/problems.] Finally, the two bind/dhcp/ntp servers are currently running on the same Xen host, so if it's somehow host related, I'd expect both to have problems, but they don't. Top doesn't show any CPU distress. Processes look fine Memory in use is far below what allocated to the machine. [1G allocated, like <400M used.] Restart of BIND doesn't do anything, at least in the cases I've seen - which aren't all that many yet. A restart of the whole VM does appear to fix the issue immediately. These appear to occur every 3-5 days. Oh, and if you simply wait, it eventually starts handling queries for all hosts again - but it might be a couple+ hours. Any suggestions on things I might hunt for in the logs in an attempt to figure out what's happening? Other suggestions for things to look for/consider? TIA -Greg -- Gregory Sloop, Principal: Sloop Network & Computer Consulting Voice: 503.251.0452 x82 EMail: gr...@sloop.net http://www.sloop.net ---___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe fr
Bind9 stops responding for some clients
So, this is a very odd situation and I'm kind of grasping at straws here. So, I've come to see if any of you have any good straws! The setup. --- Ubuntu 18.04 LTS is the distro we're running on. All software is packaged [from the distro] - not compiled from sources. Bind9 acting as a recursive resolver for a smallish network. 150 seats. They're also handling DHCP and Chrony/NTP requests. [I actually have a pair of these handling DNS/DHCP/NTP this is the master.] They are running on a Xen/XCP VM. The one I'm having problems is the master for several internal zones - the one that's working fine is the slave for those same zones. None of the zones are large. Intermittently, Bind9 simply stops handling queries from *some* hosts. Meaning, it simply times out for responses for those hosts. Yet BIND *is* working fine for lots of other machines on the same networks. It's working fine doing dig queries locally on the server, and handles dns queries fine for lots of other machines. Yet, again, some machines simply get time-outs. I can't find any pattern to which machines get timeouts and which don't. I've checked - no firewalls, fail2ban or the like that might be causing this. No selinux/apparmour. Hosts that can't do dns queries can ping the dns server fine. [So, there's at least some network pathway to the DNS machine.] Review of the logs for bind don't show anything that looks like a problem to me. [But I'm not sure what keywords I ought to be looking for, in an effort to find symptoms/problems.] Finally, the two bind/dhcp/ntp servers are currently running on the same Xen host, so if it's somehow host related, I'd expect both to have problems, but they don't. Top doesn't show any CPU distress. Processes look fine Memory in use is far below what allocated to the machine. [1G allocated, like <400M used.] Restart of BIND doesn't do anything, at least in the cases I've seen - which aren't all that many yet. A restart of the whole VM does appear to fix the issue immediately. These appear to occur every 3-5 days. Oh, and if you simply wait, it eventually starts handling queries for all hosts again - but it might be a couple+ hours. Any suggestions on things I might hunt for in the logs in an attempt to figure out what's happening? Other suggestions for things to look for/consider? TIA -Greg___ 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
