So here is a theory if a client asks a query and bind goes out for that
query and the reply is delayed but you get the answer then for what ever
reason the reply to the client from bind is delayed more! So the quicker
the answer the quicker the answer to the client.
Why? I have no idea?
--
and this from dig maybe a routing iusse why it take so long for me?
C:\Program Files\ISC BIND 9\bin>dig @213.227.191.1
router14.teamviewer.com +norecurs
; <<>> DiG 9.16.45 <<>> @213.227.191.1 router14.teamviewer.com +norecurs
; (1 server found)
;; global options: +cmd
;; Got answer:
;;
This is the thing the setup works for many site fast just this
Teamviewer and their DNS servers are a problem and bind does reply to
192.168.53.19 all be it 26 seconds later! but Teamviewer trys over and
over then it connects yet the for the WAN side took under 4 seconds to
get the answer WAN
Have you checked the routeing table on this server?
Without any other evidence, this looks to me like packets are going places
you aren't expecting.
In the first screenshot the query goes to 213.227.191.1 and apparently a
response doesn't come back until 4s later. When I try it using dig I get an
This might show the problem even more on two interfaces WAN side and LAN
you can see 192.168.53.19 ask for routerpool8 #60 then bind goes out #62
gets a answer # 75 and no reply back to 192.168.53.19
https://ufile.io/v8oob3jg
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to
On starting Teamviewer it can say no connection when bind does the
lookup with this delay it cause bind to not reply LAN side sometimes
which causes the app to fail yet with a bind on Ubuntu there is no problem.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
I'm just using bind to do my DNS look ups with no forwarders thats all
Teamviewer app uses DNS to find its servers from what I can tell it can
take over 4000ms to get a answer.
The following seems to help in bind
resolver-retry-interval 5000;
I think if I can then find a setting in windows
Hi there.
Can you send some information, for those unfamiliar with what you're trying
to do?
- Full BIND config
- IP addresses of relevant things, like interfaces of the servers on which
you are running BIND and of Teamviewer.
- What does Teamviewer need from DNS? What kinds of queries is it
Now its not working fast again! I don't know now must be Teamviewer DNS
delaying replies causing windows bind to fail in some way.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support
So more tests and the problem has come back but I think I know why
thinking internet sharing was the problem I found a way to disable it
because it bind shared access for port 53 on 0.0.0.0 so that the problem
I think now after testing with it on.
For any interested MS has made it really hard
I'm by no means an expert in DNS or how it fully works so I can't be of
any more help about this problem then I already have. But it seems
Teamviewer have rebooted their DNS servers and now windows bind allows
the Teamviewer to load faster
--
Visit
to reply outside your normal working hours.
> On 19. 11. 2023, at 19:40, legacyone via bind-users
> wrote:
>
>
> I don't know if this will be fixed before EOL for windows bind but here is
> the problem
> Teamviewer (and maybe other sites too) when you do the recursion wh
I don't know if this will be fixed before EOL for windows bind but here
is the problem
Teamviewer (and maybe other sites too) when you do the recursion when no
answer under 1000ms it tries again which is trigged by client windows
(not the one running bind) which also tries again for a answer
On Wed, Jan 25, 2023 at 10:23:16AM -, David Carvalho wrote:
> Will there be any inconvenient setting minimal-responses to no? Having
> that default behaviour when using "dig" can be useful.
No, it's quite harmless. Minimal-repsonses saves a bit of time when
processing a query, but unless
It helps a lot!!
I think I understand now.
Have a great day!
Regards
David
From: Greg Choules
Sent: 25 January 2023 10:34
To: David Carvalho
Cc: bind-users@lists.isc.org
Subject: Re: recursion yes/no?
Hi David.
With "minimal-responses", usually I would set it to "n
just like real users. If you
*want* to see all the Authority and Additional data then add "+norecurse"
to your dig command, which causes it to set RD=0. Your server is then not
being asked to do recursion, so it will just reply with everything (if
anything) it has.
Hope that helps.
Greg
t
Sent: 24 January 2023 20:12
To: David Carvalho
Cc: bind-users@lists.isc.org
Subject: Re: recursion yes/no?
On Tue, Jan 24, 2023 at 04:48:34PM -, David Carvalho via bind-users wrote:
> Hello.
>
> I hope someone could help to understand the following.
>
> I have "my.
Good morning and thank you so much!
Now I understand. My servers are not pure authoritative, so I’ll have to keep
the recursion enabled.
As for the answers in Authority and Additional sections, after setting
minimal-responses to no, now I get the usual output when querying.
For what I
On Tue, Jan 24, 2023 at 04:48:34PM -, David Carvalho via bind-users wrote:
> Hello.
>
> I hope someone could help to understand the following.
>
> I have "my.domain.pt" and a master and slave server for the "my" part. I
> have been using "recurs
Hi David.
"recursion yes;" tells named that it can (if it has to) make queries to
other places if it needs more information in order to answer a client
query. Pure authoritative servers shouldn't need it and should have
"recursion no;". So the first question is, do your serv
Hello.
I hope someone could help to understand the following.
I have "my.domain.pt" and a master and slave server for the "my" part. I
have been using "recursion yes" in both named.conf, as I want them to be
both authoritative and cache for my clients.
Last week
Mark Andrews wrote:
> Unless you are pointing recursive clients directly at your
> authoritative servers there is no need. The recursive servers will
> lookup the CNAME target themselves. Additionally recursive servers just
> process the CNAME and ignore the rest of the response
ke him to answer
> > the full CNAME and A like in 9.11.5 (thanks to additional-from-auth
> > AFAIK) :
> >> $ host www.Z.com 1.2.3.4
> >> www.Z.com is an alias for www.A.com.
> >> www.A.com has address 10.10.10.1
> >
> > Now, with 9.16.27 my answer is on
for both domains :
>> $ host www.Z.com 1.2.3.4
>> www.Z.com is an alias for www.A.com.
>
> Is there any chance I can have the same behavior as before ?
> if I enable recursion it works of course, but I don't want my server
> to be a public resolver.
> I tried to play
the CNAME record, not
the A record despite being authoritative for both domains :
> $ host www.Z.com 1.2.3.4
> www.Z.com is an alias for www.A.com.
Is there any chance I can have the same behavior as before ?
if I enable recursion it works of course, but I don't want my server
to be a publi
On 04/01/2022 21:12, Grant Taylor via bind-users wrote:
Yep. This is where I have settled. But I don't feel I can defend
it when asked. Hence my seeking to better understand.
There are categories of bugs that specifically affect recursion, and in
BIND these are _much_ more common than
On 1/4/22 4:37 AM, Ray Bellis wrote:
Better yet, use BIND's mirror zones feature so that the zone is also
DNSSEC validated.
Completely agreed. I think the type of authoritative information is
somewhat independent of the fact that any authoritative information exists.
IMHO, the strictures
On 04/01/2022 03:52, Grant Taylor via bind-users wrote:
If I'm allowing recursion and authoritative on the same server, I'd have
the recursive + authoritative server do secondary zone transfers off of
the internal MS-DNS / AD server. That way the clients can get the info
off of the first
On 1/3/22 10:57 AM, John Thurston wrote:
It must have a 'forward' zone defined on it for each of those stupid
domains. And yes, you are right . . at that point it is no longer only
performing recursion.
;-)
But there is no other way to do it. Even in a combined
recursive/authoritative
On 1/3/22 12:15 AM, Borja Marcos wrote:
If you separate the roles it is much simpler to implement an
effective access control.
On 03.01.22 10:35, Grant Taylor via bind-users wrote:
The problem I have with separating recursive and authoritative servers
has to do with internal LANs and things
a 'forward' zone defined on it for each of those stupid
domains. And yes, you are right . . at that point it is no longer only
performing recursion.
But there is no other way to do it. Even in a combined
recursive/authoritative design, your server would have no way to resolve
names in those
On 1/3/22 12:15 AM, Borja Marcos wrote:
If you separate the roles it is much simpler to implement an effective
access control.
The problem I have with separating recursive and authoritative servers
has to do with internal LANs and things like Microsoft Active Directory
on
> On 30 Dec 2021, at 09:07, Danilo Godec via bind-users
> wrote:
>
> The source is a security audit report, claiming that using a single server
> for both authoritative (for public use) and recursive (limited to internal
> clients by means of 'allow-recursion' directiv
t; > > > I have an authoritative DNS server for a domain, but I was also going to
> > > > use the same server as a recursive DNS for my internal network, limiting
> > > > recursion by the IP. Apparently, this is a bad idea that can lead to
> > > > ca
gt; > > use the same server as a recursive DNS for my internal network, limiting
> > > recursion by the IP. Apparently, this is a bad idea that can lead to
> > > cache poisoning...
> > In short, no, this configuration with a BIND 9 server does not
> > increas
network, limiting
recursion by the IP. Apparently, this is a bad idea that can lead to
cache poisoning...
In short, no, this configuration with a BIND 9 server does not
increase your risk of cache poisoning any more than running your local
server in pure recursive mode. I'm curious to hear more from
On 29. 12. 21 19:24, tale wrote:
On Wed, Dec 29, 2021 at 5:31 AM Danilo Godec via bind-users
wrote:
I have an authoritative DNS server for a domain, but I was also going to
use the same server as a recursive DNS for my internal network, limiting
recursion by the IP. Apparently, this is a bad
On Wed, Dec 29, 2021 at 5:31 AM Danilo Godec via bind-users
wrote:
> I have an authoritative DNS server for a domain, but I was also going to
> use the same server as a recursive DNS for my internal network, limiting
> recursion by the IP. Apparently, this is a bad idea that can lead t
Danilo Godec via bind-users wrote:
>
> I have an authoritative DNS server for a domain, but I was also going to
> use the same server as a recursive DNS for my internal network, limiting
> recursion by the IP. Apparently, this is a bad idea that can lead to
> cache poisoning...
Hello,
I have an authoritative DNS server for a domain, but I was also going to
use the same server as a recursive DNS for my internal network, limiting
recursion by the IP. Apparently, this is a bad idea that can lead to
cache poisoning...
After watching a Computerphile Youtube video
Define an explicit forward-zone on the recursive server for
private.dns.com In the zone definition, put the addresses of the
servers which can answer for private.dns.com.
--
Do things because you should, not just because you can.
John Thurston907-465-8591
john.thurs...@alaska.gov
Hello All.
I have a recursion via forwarder question. Consider the following scenario:
- A client sends a query to an internal recursive DNS server for the
following A record: 'a.b.c.private.dns.com'
- The Recursive DNS server is unaware of this domain and sends
.
I think more correct would be setting more specific zones of e164.arpa
configured with only one forwarder.
Regards,
Petr
On 9/29/21 09:21, Sonal Pahuja wrote:
>
> Hi All,
>
>
>
> Is there any option to set recursion =1 in named.conf file for the
> zone. I just want bind9
Maybe a little confused here, but BIND won’t try another server if it gets
an answer. It will only try another forwarder if the query fails.
On Wed, Sep 29, 2021 at 12:21 AM Sonal Pahuja
wrote:
> Hi All,
>
>
>
> Is there any option to set recursion =1 in named.conf file for the
Hi All,
Is there any option to set recursion =1 in named.conf file for the zone. I just
want bind9 to do recursion only once.
If bind9 receives answer from one of the forwarders then it should not do
recursion (forward query) to any other forwarder IP.
Below is my snapshot of my named.conf
a bind-users wrote:
>
>
> My situation is due to a security requirement. We have DNS servers at our
> site running BIND that allow recursion, but I’ve been requested to set up
> some additional DNS servers for another project that is expected to *
> *only** access the data
On 4/14/2021 12:44 AM, Sebby, Brian A. via bind-users wrote:
My situation is due to a security requirement. We have DNS servers at
our site running BIND that allow recursion, but I’ve been requested to
set up some additional DNS servers for another project that is
expected to **only
. We have DNS servers at our site
running BIND that allow recursion, but I’ve been requested to set up some
additional DNS servers for another project that is expected to *only* access
the data that we’re authoritative for. And of course …. there’s a chance that
it might need to look up one
Mark Andrews wrote:
> > On 8 Apr 2021, at 00:37, Tony Finch wrote:
> >
> > Forward zones require the upstream server to be recursive too.
>
> More correctly, the upstream server has to serve the entire namespace being
> forwarded if it does not off recursion t
n replying, please edit your Subject line so it is more specific
> than "Re: Contents of bind-users digest..."
>
>
> Today's Topics:
>
>1. Re: forwarding zone setup from a BIND slave (without
> recursion?) (Chuck Aurora)
>2. Re: forwarding zone setup
Subject line so it is more specific
> than "Re: Contents of bind-users digest..."
>
>
> Today's Topics:
>
> 1. forwarding zone setup from a BIND slave (without recursion?)
> (RK K)
>2. Re: forwarding zone setup from a BIND slave (without
> re
> On 8 Apr 2021, at 00:37, Tony Finch wrote:
>
> Chuck Aurora wrote:
>>
>> A stub or static-stub zone would not require recursion. In that case
>> named is asking for authoritative data from upstream. But type
>> forward zones indeed cannot work if recur
Chuck Aurora wrote:
>
> A stub or static-stub zone would not require recursion. In that case
> named is asking for authoritative data from upstream. But type
> forward zones indeed cannot work if recursion is disabled.
Be careful in this kind of situation to be very clear about
On 2021-04-07 03:59, Marki wrote:
To elaborate a little bit on that... Indeed that is how it works,
unfortunately. When you start using forwarders or stubs, recursion
needs to be enabled because you're no longer looking for your own
authoritative data only.
A stub or static-stub zone would
Hello,
On 4/7/2021 10:35 AM, Matus UHLAR - fantomas wrote:
On 06.04.21 22:47, RK K wrote:
In this scenario, in-order for the secondary server to forward the DNS
query to an external DNS server, is it required to enable the
recursion in
the global options on the secondary servers?
yes
On 06.04.21 22:47, RK K wrote:
We have a set of BIND primary servers (MASTERs) and a set of secondary
servers (slaves to the MASTERs).
The secondary BIND DNS servers disabled recursion ( with "*recursion no;" *)
in the global options.
All the applications/systems do use secondary D
All,
We have a set of BIND primary servers (MASTERs) and a set of secondary
servers (slaves to the MASTERs).
The secondary BIND DNS servers disabled recursion ( with "*recursion no;" *)
in the global options.
All the applications/systems do use secondary DNS servers for name
resolu
Hammers and nails...
On Tue, 16 Mar 2021, Marki wrote:
On 3/13/2021 12:11 AM, Tony Finch wrote:
Marki wrote:
But if you need granular filtering, that could become a lot of views...
Yes, I think RPZ is really designed to be a ban hammer [...]
Standard DNS server software (not only Bind)
On 3/13/2021 12:11 AM, Tony Finch wrote:
Marki wrote:
But if you need granular filtering, that could become a lot of views...
Yes, I think RPZ is really designed to be a ban hammer for dealing with
abuse, rather than a general-purpose access control mechanism. If you need
to get really fancy
Marki wrote:
>
> But if you need granular filtering, that could become a lot of views...
Yes, I think RPZ is really designed to be a ban hammer for dealing with
abuse, rather than a general-purpose access control mechanism. If you need
to get really fancy then you should look at dnsdist which
On 3/9/2021 10:21 PM, Tony Finch wrote:
Marki wrote:
I'm not sure about the flexibility of RPZ; it doesn't seem that I can
have rules like "client 1.2.3.4 is allowed to look up example.com but
client 1.2.3.5 is not".
You can have multiple response-policy zones, which are matched in the
order
Marki wrote:
>
> Concerning static-stub: Using a (bogus) forwarder together with "forward
> first" (default) seems to work (Note: using "forward only" gives SERVFAIL).
> All outside requests get a SERVFAIL even with "forward first" but that's an
> esthetic problem.
Yes, SERVFAIL is ugly - I
.
[ The distinction is that auth-only servers expect to receive only RD=0
(recursion not desired) queries from recursive DNS servers and reply with
RA=0 (recursion not available), whereas recursive servers expect to
receive RD=1 (recursion desired) from stub resolvers and reply with RA=1
(recursion
CNAMEs.
[ The distinction is that auth-only servers expect to receive only RD=0
(recursion not desired) queries from recursive DNS servers and reply with
RA=0 (recursion not available), whereas recursive servers expect to
receive RD=1 (recursion desired) from stub resolvers and reply with RA=1
(recursion a
Where is it sending recursive queries if it owns the root?
On Sun, Mar 7, 2021 at 3:06 AM Marki wrote:
> I tried that. When you configure no global forwarders it's going to
> recurse because recursion needs to be enabled for the individual forwarded
> zones to work. You'd have to speci
I tried that. When you configure no global forwarders it's going to recurse
because recursion needs to be enabled for the individual forwarded zones to
work. You'd have to specify a fake global forwarder which looks like a hack.
On March 7, 2021 10:09:49 AM GMT+01:00, Crist Clark
wrote:
>
of that _plus_ be able to
>> make recursive queries to the internet (or use a global forwarder).
>> All hosts use the same DNS servers, this should not be made about the
>> clients but rather be configurable on the server.
>>
>> Now the problems are the following:
>>
ernet (or use a global forwarder).
All hosts use the same DNS servers, this should not be made about the
clients but rather be configurable on the server.
Now the problems are the following:
* Since I need forwarders I can't turn off recursion.
* Since I can't turn off recursion I
her be configurable on the server.
>
> Now the problems are the following:
> * Since I need forwarders I can't turn off recursion.
> * Since I can't turn off recursion I can't prevent it to go and try to
> resolve from root DNS.
>
> How do I do one (local authority
turn off recursion.
* Since I can't turn off recursion I can't prevent it to go and try to
resolve from root DNS.
How do I do one (local authority and forwarders) but not the other
(iterative lookups on the Internet)?
Thanks,
Marki
___
Please visit
olving './DNSKEY/IN':
208.67.222.222#53
---end---
Named.conf has the correct sources for queries;
---snip---
acl permit {
172.30.0.0/16 <http://172.30.0.0/16>;
---end---
Named.conf.options has the correct forwarders, recursion and query
statements (ignore syntax, pull
the correct forwarders, recursion and query
statements (ignore syntax, pulling partials);
---snip---
forwarders {
108.162.193.136;
172.64.33.136;
108.162.192.142
On Tue, 7 Jul 2020, Tony Finch wrote:
Brett Delmage wrote:
On Tue, 7 Jul 2020, Tony Finch wrote:
minimal-any yes;
Why only reduce and not eliminate?
The reason is a bit subtle. If an ANY query comes via a recursive
resolver, it is much better to give the resolver an answer so
Brett Delmage wrote:
> On Tue, 7 Jul 2020, Tony Finch wrote:
> >
> > minimal-any yes;
>
> Why only reduce and not eliminate?
The reason is a bit subtle. If an ANY query comes via a recursive
resolver, it is much better to give the resolver an answer so that it will
put an entry in its cache.
On 07 Jul 2020, at 12:06, Michael De Roover wrote:
> On 7/7/20 4:06 PM, Tony Finch wrote:
>
>> max-udp-size 1420;
>> https://dnsflagday.net/2020/
> Interesting, I wasn't aware of this campaign. I don't know if I'm
> knowledgeable enough on UDP to be able to make educated decisions on
On Tue, 7 Jul 2020, Shumon Huque wrote:
Cloudflare themselves now implement the "minimal any" behavior described
in this spec:
https://tools.ietf.org/html/rfc8482
cloudflare.com. 3789 IN HINFO "RFC8482" ""
Gee, that's a pretty minimal answer!
On Tue, Jul 7, 2020 at 2:21 PM Brett Delmage wrote:
> On Tue, 7 Jul 2020, Tony Finch wrote:
>
> > Reduce the size of responses to ANY queries, which are a favourite tool
> of
> > amplification attacks. There's basically no downside to this one, in my
> > opinion, but I'm biased because I
On Tue, 7 Jul 2020, Tony Finch wrote:
Reduce the size of responses to ANY queries, which are a favourite tool of
amplification attacks. There's basically no downside to this one, in my
opinion, but I'm biased because I implemented it.
minimal-any yes;
Why only reduce and not
On 7/7/20 4:06 PM, Tony Finch wrote:
An auth-only server can also be used for amplification attacks that use
its authoritative zones - these attacks don't have to use recursion.
There are a few ways to mitigate auth-only amplification attacks.
Response rate limiting is very effective. Start
@lbutlr wrote:
>
> > rate-limit { responses-per-second 10; };
>
> Does that apply to local queries as well (for example, a mail server may
> easily make a whole lot of queries to 127.0.0.1, and rate limiting it
> would at the very least affect logging and could delay mail if the MTA
> cannot
On 07 Jul 2020, at 08:06, Tony Finch wrote:
Excellent post, and a nice summary of some best practices.
I have a couple of questions.
> Response rate limiting is very effective. Start off by putting the
> following in your options{} section, and look in the BIND ARM for other
> directives you
rsive server. Out of the box, BIND has a recursion ACL that only
allows queries from directly connected networks, so you won't have this
problem without making an explicit configuration mistake. Normally for an
authoritative-only server, you should set `recursion no` to lock it down
more tightly.
cation attacks just because
> they allow recursion,
They're not vulnerable, this attack works by reflection (just like the
NTP attack you mentioned) so they are not the potential victims, they
could be used as helpers.
___
Please visit https://lists.isc.org
t least on the order of 100Gbps cumulatively, if not
more. If these would be vulnerable to amplification attacks just because
they allow recursion, wouldn't skids be jumping on this like there's no
tomorrow? It doesn't make any sense to me.
This seems to be not very well documented online (or mo
But...
> I used:
>
> view "a" {
> match-clients { 172.16.n.n/24; }
> allow-recursion { any; };
> zone "x.y.zzz" {
>type static-stub;
>server-addresses {
> 10.n.n.n;
> 10.n.n.m;
>};
> };
> };
>
> If the 10
Would adding the following to the zone config work?
forwarders {};
Regards,
Bob
___
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
On Fri, May 15, 2020 at 12:22 PM Chris Palmer via bind-users <
bind-users@lists.isc.org> wrote:
> Hi Ondřej
>
> At first glance your suggestion looked like what I had done. But...
> I used:
>
> view "a" {
>match-clients { 172.16.n.n/24; }
>allo
Hi Ondřej
At first glance your suggestion looked like what I had done. But...
I used:
view "a" {
match-clients { 172.16.n.n/24; }
allow-recursion { any; };
zone "x.y.zzz" {
type static-stub;
server-addresses {
10.n.n.n;
10.n.n.m;
};
};
Surý
ond...@isc.org
> On 15 May 2020, at 14:40, Chris Palmer wrote:
>
> Hi Ondřej
>
> That could work for eliminating the caching delay when the VPN comes up. I'd
> just have to get that into the VPN config so people didn't have to do it
> manually.
>
> Is ther
Hi Ondřej
That could work for eliminating the caching delay when the VPN comes up.
I'd just have to get that into the VPN config so people didn't have to
do it manually.
Is there any way to stop the recursion for that domain happening in the
first place though?
Thanks, Chris
On 15/05
Hi Chris,
when your vpn comes up, you need to issue:
rndc flushtree
command to the BIND 9 instance.
Ondrej
--
Ondřej Surý
ond...@isc.org
> On 15 May 2020, at 14:16, Chris Palmer via bind-users
> wrote:
>
> There is much discussion about recursion but I can't find anything tha
There is much discussion about recursion but I can't find anything that
matches this use case...
- In-house Bind-9.11.14 server, master for some local zones, recursion
enabled; not accessible from external networks
- Two views for in-house networks
- Intermittent VPN access from in-house
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:
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
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.
>
>>
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,
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
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,
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
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
1 - 100 of 304 matches
Mail list logo
