Hi Greg again! :)
> 1) This should help you understand the difference between recursive and
non-recursive queries.
I read about recursive and iterative query but I think A.B.C.D server
should be as recursive server for domain controllers, I ask myself the same
question to root servers? Or Bind9 server should have to make iterative
queries to root servers ?
> I hope this server is behind a good firewall?
Yes
>Do you only have one BIND server?
>I would recommend two at least, in case you need to take one down for
maintenance or it fails for some reason.
Yes only one server
>> Your "allow-..." statements should look like this, with IP addresses,
not domain names.
Oh yes, this one was to explain you what servers I inserted into this list.
I have another doubt, /etc/resolv.conf in bind server is used only from
client services ? E.g. ping tool
I think bind9 dns service doesn't contact any /etc/resolv.conf, right?
Il giorno ven 28 giu 2024 alle ore 08:46 Greg Choules <
gregchoules+bindus...@googlemail.com> ha scritto:
> Hi Renzo.
> You're welcome.
> 1) Correct. You don't need forwarding for a simple resolver. Take a look
> at the meaning of the RD flag in the BIND protocol header. This should help
> you understand the difference between recursive and non-recursive queries.
> 2) No. See 1)
> 3) Yes. For a standard resolver facing the Internet you do not need a hint
> zone.
>
> Some more thoughts occurred to me:
> - I hope this server is behind a good firewall?
> - Do you only have one BIND server? I would recommend two at least, in
> case you need to take one down for maintenance or it fails for some reason.
> - Your "allow-..." statements should look like this, with IP addresses,
> not domain names.
> allow-... {127.0.0.1; <query_source_IP_address_of_DC1>;
> <query_source_IP_address_of_DC2>; <any_other_source_addresses...>;}; You do
> not need to include this server in the list.
>
> Any changes you make should be done on a test server first, so you can be
> comfortable understanding what effect those changes have and only move them
> to production when you are certain.
>
> Cheers, Greg
>
> On Fri, 28 Jun 2024 at 07:14, Renzo Marengo <buckroger2...@gmail.com>
> wrote:
>
>> Hi greg,
>> I thank you again for your suggestions.
>>
>> >A.B.C.D is the address of this server?
>> yes, It's the Bind server
>>
>> I read several documents about DNS architecture
>> My questions is about this configuration of bind:
>>
>> 1- according to your opinion my bind makes queries ro root server if is
>> set no 'forwarders' option? I'll verify It by tcpdump as you suggested
>> 2- Do you suggest to set some "forwarders" ?
>> 3-- This bind version has root server built-in? If I removed 'named.ca'
>> reference, Bind would use root server built-in?
>>
>> thanks
>>
>> Il giorno ven 28 giu 2024 alle ore 07:51 Greg Choules <
>> gregchoules+bindus...@googlemail.com> ha scritto:
>>
>>> Hi Renzo.
>>>
>>> Thank you for that. The hints look OK. A bit old, but they will work.
>>>
>>> The first thing I would advise you to do as a matter of priority is to
>>> upgrade BIND.
>>> 9.11 has been end-of-life for a few years and there have been many
>>> security fixes since then. 9.18.27 is the current version.
>>> You could install that directly, or upgrade RHEL and obtain a more
>>> recent packaged version.
>>>
>>>
>>> You can check what BIND is doing by using "tcpdump". For example:
>>> sudo tcpdump -n -i <interface> -c 1000 port 53 and host A.B.C.D
>>>
>>> I am making some assumptions:
>>> A.B.C.D is the address of this server?
>>> <interface> is the name of the interface the server will use for
>>> outbound queries, according to its routeing table. I am guessing this is
>>> the interface with address A.B.C.D?
>>> -c stops the capture after 1000 packets. This is just a safety
>>> precaution.
>>> port 53 and host A.B.C.D limits the capture to only packets with port 53
>>> (DNS) AND with the address of this interface, so you don't capture any SSH
>>> or HTTPS etc.
>>>
>>> A fresh (recently restarted) DNS resolver - any one, not just BIND -
>>> will make queries to the root to start with. It does this to learn where to
>>> go next. It stores the results of those queries in its cache so that it
>>> doesn't have to make them again for some time.
>>>
>>> There are many good books and articles available online to explain the
>>> basics of DNS. The BIND ARM (distributed with BIND and also available
>>> online) is the reference manual for BIND itself.
>>>
>>> I hope that helps.
>>> Greg
>>>
>>> On Fri, 28 Jun 2024 at 05:57, Renzo Marengo <buckroger2...@gmail.com>
>>> wrote:
>>>
>>>> Hi Greg,
>>>> he info you required:
>>>>
>>>> 1) BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.2 (Extended Support
>>>> Version) on running on Linux x86_64 3.10.0-1160.2.2.el7.x86_64
>>>> 2) named.ca if file which contains root servers
>>>> named.ca
>>>> ----
>>>> . 518400 IN NS a.root-servers.net.
>>>> . 518400 IN NS b.root-servers.net.
>>>> . 518400 IN NS c.root-servers.net.
>>>> . 518400 IN NS d.root-servers.net.
>>>> . 518400 IN NS e.root-servers.net.
>>>> . 518400 IN NS f.root-servers.net.
>>>> . 518400 IN NS g.root-servers.net.
>>>> . 518400 IN NS h.root-servers.net.
>>>> . 518400 IN NS i.root-servers.net.
>>>> . 518400 IN NS j.root-servers.net.
>>>> . 518400 IN NS k.root-servers.net.
>>>> . 518400 IN NS l.root-servers.net.
>>>> . 518400 IN NS m.root-servers.net.
>>>>
>>>> ;; ADDITIONAL SECTION:
>>>> a.root-servers.net. 518400 IN A 198.41.0.4
>>>> b.root-servers.net. 518400 IN A 199.9.14.201
>>>> c.root-servers.net. 518400 IN A 192.33.4.12
>>>> d.root-servers.net. 518400 IN A 199.7.91.13
>>>> e.root-servers.net. 518400 IN A 192.203.230.10
>>>> f.root-servers.net. 518400 IN A 192.5.5.241
>>>> g.root-servers.net. 518400 IN A 192.112.36.4
>>>> h.root-servers.net. 518400 IN A 198.97.190.53
>>>> i.root-servers.net. 518400 IN A 192.36.148.17
>>>> j.root-servers.net. 518400 IN A 192.58.128.30
>>>> k.root-servers.net. 518400 IN A 193.0.14.129
>>>> l.root-servers.net. 518400 IN A 199.7.83.42
>>>> m.root-servers.net. 518400 IN A 202.12.27.33
>>>> a.root-servers.net. 518400 IN AAAA 2001:503:ba3e::2:30
>>>> b.root-servers.net. 518400 IN AAAA 2001:500:200::b
>>>> c.root-servers.net. 518400 IN AAAA 2001:500:2::c
>>>> d.root-servers.net. 518400 IN AAAA 2001:500:2d::d
>>>> e.root-servers.net. 518400 IN AAAA 2001:500:a8::e
>>>> f.root-servers.net. 518400 IN AAAA 2001:500:2f::f
>>>> g.root-servers.net. 518400 IN AAAA 2001:500:12::d0d
>>>> h.root-servers.net. 518400 IN AAAA 2001:500:1::53
>>>> i.root-servers.net. 518400 IN AAAA 2001:7fe::53
>>>> j.root-servers.net. 518400 IN AAAA 2001:503:c27::2:30
>>>> k.root-servers.net. 518400 IN AAAA 2001:7fd::1
>>>> l.root-servers.net. 518400 IN AAAA 2001:500:9f::42
>>>> m.root-servers.net. 518400 IN AAAA 2001:dc3::35
>>>> ----
>>>>
>>>> I didn't know some Bind versions had the Internet root hints built-in.
>>>> About my configuration I understand that bind makes always queries to
>>>> root servers ? Right?
>>>> I'd like to re-check configuration of bind
>>>>
>>>>
>>>> Il giorno gio 27 giu 2024 alle ore 22:15 Greg Choules <
>>>> gregchoules+bindus...@googlemail.com> ha scritto:
>>>>
>>>>> Hi Renzo.
>>>>> Ah OK, I had it the wrong way round. AD DNS needs to resolve names in
>>>>> the Internet on behalf of its clients, so it forwards to BIND.
>>>>>
>>>>> In that case, two questions:
>>>>> 1) What version of BIND are you running? You can get this with "named
>>>>> -V"
>>>>> 2) What is in the file "named.ca"?
>>>>> For a long time (which is why I need to know the version) BIND has had
>>>>> the Internet root hints built in, so you don't need a hint zone anymore.
>>>>> Unless you are defining different roots for some reason. Hence why I need
>>>>> to know the contents of that file.
>>>>>
>>>>> Thanks, Greg
>>>>>
>>>>>
>>>>>
>>>>> On Thu, 27 Jun 2024 at 18:06, Renzo Marengo <buckroger2...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> Hi Greg,
>>>>>>
>>>>>> thank you very much for your explanation.
>>>>>>
>>>>>> Let’s supposte AD domain was ‘my domain.it’ and I have 6000
>>>>>> computers of government institute.
>>>>>>
>>>>>> Here my bind configuration:
>>>>>>
>>>>>>
>>>>>> named.conf
>>>>>>
>>>>>> ———
>>>>>>
>>>>>> include “…. named.conf.options" ;
>>>>>>
>>>>>> zone "." IN {
>>>>>>
>>>>>> type hint;
>>>>>>
>>>>>> file "named.ca";
>>>>>>
>>>>>> };
>>>>>>
>>>>>> include “…. named.rfc1912.zones";
>>>>>>
>>>>>> include “…. named.root.key";
>>>>>>
>>>>>> ———
>>>>>>
>>>>>>
>>>>>>
>>>>>> named.conf.options
>>>>>>
>>>>>> ———
>>>>>>
>>>>>> logging {
>>>>>>
>>>>>> channel named_debug {
>>>>>>
>>>>>> syslog local6;
>>>>>>
>>>>>> severity debug 1;
>>>>>>
>>>>>> print-category yes;
>>>>>>
>>>>>> print-severity yes;
>>>>>>
>>>>>> print-time yes;
>>>>>>
>>>>>> };
>>>>>>
>>>>>> category default { named_debug; };
>>>>>>
>>>>>> };
>>>>>>
>>>>>>
>>>>>> options {
>>>>>>
>>>>>> auth-nxdomain no; # conform to RFC1035
>>>>>>
>>>>>> allow-recursion {127.0.0.1; A.B.C.D; dc1.mydomain.it; dc2.mydomain.it;
>>>>>> ….. } ;
>>>>>>
>>>>>> allow-query {127.0.0.1; A.B.C.D; dc1.mydomain.it;
>>>>>> dc2.mydomain.it; ….. } ;
>>>>>>
>>>>>> recursive-clients 3000;
>>>>>>
>>>>>> allow-query-cache {127.0.0.1; A.B.C.D; dc1.mydomain.it;
>>>>>> dc2.mydomain.it; ….. } ; ;
>>>>>>
>>>>>>
>>>>>> listen-on port 53 { 127.0.0.1; A.B.C.D; };
>>>>>>
>>>>>> directory “….. named";
>>>>>>
>>>>>> dump-file “….. cache_dump.db";
>>>>>>
>>>>>> statistics-file “….. named_stats.txt";
>>>>>>
>>>>>> memstatistics-file “…. named_mem_stats.txt";
>>>>>>
>>>>>> recursing-file “… named.recursing";
>>>>>>
>>>>>> secroots-file “… named.secroots";
>>>>>>
>>>>>> recursion yes;
>>>>>>
>>>>>> dnssec-enable no;
>>>>>>
>>>>>> dnssec-validation no;
>>>>>>
>>>>>>
>>>>>> bindkeys-file "….. named.iscdlv.key";
>>>>>>
>>>>>> managed-keys-directory "….. dynamic";
>>>>>>
>>>>>> pid-file "….. named.pid";
>>>>>>
>>>>>> session-keyfile "….. session.key";
>>>>>>
>>>>>> ———
>>>>>>
>>>>>>
>>>>>>
>>>>>> >Thirdly, I would not forward to AD DNS, unless the AD servers also
>>>>>> recurse and can provide >resolution for delegated names below the AD
>>>>>> domain
>>>>>>
>>>>>> >that are not hosted on the AD servers themselves.
>>>>>>
>>>>>>
>>>>>> There is no forward option to AD DNS. Forward is enable from AD DNS
>>>>>> to A.B.C.D. bind9 server.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> All clients are using AD DNS infact every query, about name of ‘
>>>>>> mydomain.it,’ is resolved from AD DNS.
>>>>>>
>>>>>> When client asks an external domain, e.g. www.google.it, AD server
>>>>>> forward query to A.B.C.D. server. (Forward option is set on every domain
>>>>>> controller)
>>>>>>
>>>>>> Only AD DNS make queries to A.B.C.D server and it’s necessary only
>>>>>> to solve external domains.
>>>>>>
>>>>>> A.B.C.D. server never makes queries to AD server. A.B.C.D. is next
>>>>>> dns server which partecipates when it’s necessary to resolve an external
>>>>>> domain
>>>>>>
>>>>>>
>>>>>> I hope to have explained right.
>>>>>>
>>>>>> I thought A.B.C.D server made query to root server because into
>>>>>> configuration there is no reference to forward option, because I thought
>>>>>> to
>>>>>> set as DNS forward a government dns of my country. What do you think?
>>>>>>
>>>>>> I have doubts about recursive and iterative queries options too.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>
>>>>>> Il giorno gio 27 giu 2024 alle ore 13:24 Greg Choules <
>>>>>> gregchoules+bindus...@googlemail.com> ha scritto:
>>>>>>
>>>>>>> Hi Renzo.
>>>>>>> Firstly, please can we see your BIND configuration and have the
>>>>>>> actual AD domain name.
>>>>>>>
>>>>>>> Secondly, BIND, or any other recursive DNS server, does not
>>>>>>> 'forward' to the root servers, unless you have configured it explicitly
>>>>>>> to
>>>>>>> do so, which would be a bad idea and not work anyway. It will recurse
>>>>>>> (paradoxically, perform non-recursive aka iterative queries) to the
>>>>>>> roots
>>>>>>> and other authoritative servers. It is an important distinction to be
>>>>>>> aware
>>>>>>> of.
>>>>>>>
>>>>>>> Thirdly, I would not forward to AD DNS, unless the AD servers also
>>>>>>> recurse and can provide resolution for delegated names below the AD
>>>>>>> domain
>>>>>>> that are not hosted on the AD servers themselves. Personally I would
>>>>>>> use a
>>>>>>> stub or static-stub zone in BIND to refer to the AD domain.
>>>>>>>
>>>>>>> In general, decide which DNS is going to do the resolving and make
>>>>>>> that the control point, fetching data from wherever it needs to (e.g. AD
>>>>>>> DNS) - using non-recursive queries - and using that data to construct
>>>>>>> answers for its clients.
>>>>>>>
>>>>>>> I hope that helps.
>>>>>>> Cheers, Greg
>>>>>>>
>>>>>>> On Thu, 27 Jun 2024 at 12:02, Renzo Marengo <buckroger2...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I have Active Directory domain ( 'mydomain.it' ) with 8 domain
>>>>>>>> controllers to manage 8000 computers. Every Domain controller acts as
>>>>>>>> dns
>>>>>>>> service and resolve internal domain names while forward queries about
>>>>>>>> external domains to another server, which Bind9 dns server (It's
>>>>>>>> inside my
>>>>>>>> company)
>>>>>>>> I'm checking this Bind9 configuration (Centos server) and I see no
>>>>>>>> forward servers so I think It makes bind9 forward queries directly to
>>>>>>>> root
>>>>>>>> servers. What do you think ?
>>>>>>>> According your opinion this Bind9 server should have to forward
>>>>>>>> requests to one or more dns server by forward option?
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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
