date:20240627

RE: SERVFAIL error during the evening

2024-06-27 Thread sami . rahal

Hello 
Thank you for these suggestions and advice. I will start by updating BIND to 
version 9.18, then monitor the situation and provide feedback

Regards

-Message d'origine-
De : bind-users  De la part de 
bind-users-requ...@lists.isc.org
Envoyé : jeudi 27 juin 2024 02:04
À : bind-users@lists.isc.org
Objet : bind-users Digest, Vol 4497, Issue 1

--
CAUTION : This email originated outside the company. Do not click on any links 
or open attachments unless you are expecting them from the sender.

ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez pas 
sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre 
l'expéditeur.
--

Send bind-users mailing list submissions to
bind-users@lists.isc.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/bind-users
or, via email, send a message with subject or body 'help' to
bind-users-requ...@lists.isc.org

You can reach the person managing the list at
bind-users-ow...@lists.isc.org

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of bind-users digest..."


Today's Topics:

   1. Re: rolling my own hints file (Greg Choules)
   2. Re: SERVFAIL error during the evening (Michael Batchelder)


--

Message: 1
Date: Wed, 26 Jun 2024 20:46:46 +0100
From: Greg Choules 
To: "Cuttler, Brian R (HEALTH)" 
Cc: David Farje , bind-users
,  "Hefner, Joseph (HEALTH)"

Subject: Re: rolling my own hints file
Message-ID:

Content-Type: text/plain; charset="utf-8"

Hi Brian.
Ni problem. The server may tell the client (dig; please not nslookup) 
information about where the answer came from, if 'minimal-responses' is set to 
"no". Usually clients don't need to know that, so please take a look at how m-r 
works:
https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-minimal-responses

Cheers, Greg

On Wed, 26 Jun 2024 at 17:55, Cuttler, Brian R (HEALTH) < 
brian.cutt...@health.ny.gov> wrote:

>
>
> Greg, David,
>
>
>
> Thanks, much easier than what I thought it would be.
>
> I have two ?root? servers so I went with this format, allowing a round 
> robin selection.
>
> Essentially this, sorry trying to be vague on the IPs.
>
>
>
> @ 518400   IN A xx.yy.zz..7
>
> @ 518400   IN A xx.yy.zz..8
>
> .   518400IN NS @
>
>
>
> Server reloaded fine and I am able to resolve non-domain information.
> Is there a flag someplace in dig or nslookup to show what root server 
> I?m hitting? I don?t see that in any of the named log files, I may 
> need to add an ACL to log the traffic in a router to verify.
> Then again ? my FW is not seeing queries to any of the normal root 
> servers, so that is in fact a good sign.
>
>
>
> New root servers are managed by my parent organization and my manager 
> asked me to send these queries through them. Wouldn?t be performing 
> this exercise otherwise.
>
>
>
> Thank you ? I think you?ve given me exactly what was needed.
>
>
>
> Brian
>
>
>
> *From:* Greg Choules 
> *Sent:* Wednesday, June 26, 2024 12:29 PM
> *To:* Cuttler, Brian R (HEALTH) 
> *Cc:* bind-users 
> *Subject:* Re: rolling my own hints file
>
>
>
> You don't often get email from gregchoules+bindus...@googlemail.com. 
> Learn why this is important 
> 
>
> *ATTENTION: This email came from an external source. Do not open 
> attachments or click on links from unknown senders or unexpected 
> emails.*
>
>
>
> Hi Brian.
>
> Yes, you can define your own hint zone and tell BIND to use it. The 
> contents (I called the file "db.root" but the name is your choice) 
> could be as simple as:
>
>
>
> @ 300 IN A 127.0.0.3
> @ 300 IN NS @
>
>
>
> which says for this zone (which will be called ".", coming next) the 
> NS is the same name and its IP is 127.0.0.3, which happens to be 
> another instance of BIND I have running. Your file would contain the 
> names and IPs of your internal roots.
>
>
>
> In the config, define the hint zone like this:
>
>
>
> zone "." {
> type hint;
> file "db.root";
> };
>
>
>
> That should be all you need.
>
> Cheers, Greg
>
>
>
> On Wed, 26 Jun 2024 at 15:58, Cuttler, Brian R (HEALTH) via bind-users 
> < bind-users@lists.isc.org> wrote:
>
> Running Bind 9.18.18 on Ubuntu 22.04
>
>
>
> We would like to use root servers within our organization rather than 
> the actual root servers.
> I updated the hints file with the names and IPs of our servers, but we 
> seem to still access the official root servers.
>
> Wondering how I ignore the internal/build-in hints and have my own file.
>
> Wondering if replacing the IP addresses in the db.cache file with a 
> round-rob

forward option in dns server

2024-06-27 Thread Renzo Marengo

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

Re: forward option in dns server

2024-06-27 Thread Greg Choules via bind-users

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

Re: tryisc.com is not an isc.org domain

2024-06-27 Thread Victoria Risk

Update: 

This was not the fraud we thought it was 

We have learned that emails we originally identified as abuse were sent by an 
external contractor engaged by ISC to conduct a focussed and short-term lead 
generation campaign. We have instructed the vendor to halt that campaign.

We clearly suffered some communications failures here. Our communication with 
the vendor should have made it clear that we would not be comfortable with the 
approach they adopted. Plus, our internal communication failed as we lacked 
sufficient awareness of the campaign to respond in a more appropriate fashion 
when we received questions about the emails.

We have been assured by the vendor that this was not a bulk unsolicited email 
campaign. We affirm our stance that bulk unsolicited email is counter to our 
mission in support of Internet infrastructure.

We apologize for any inconvenience or disruption this event may have caused. We 
promptly canceled our abuse complaint concerning the domain name, and we ask 
any of you who have taken any filtering or blocking or complaint action against 
the domain name or the originating IP addresses to do the same. We appreciate 
the outpouring of sympathy from our community, many of whom have emailed us 
with helpful suggestions. We thank you for your continued support.

> On Jun 25, 2024, at 10:42 AM, Victoria Risk  wrote:
> 
> BIND-users,
> 
> Someone is sending emails from tryisc.com, pretending to be from Internet 
> Systems Corporation, and offering information about undisclosed BIND software 
> vulnerabilities. These emails are NOT from ISC, the authors of BIND, and they 
> are not authorized by ISC.
> 
> If you feel you have received illegitimate communications from someone 
> purporting to be an ISC staff member, please report it 
> (https://www.isc.org/security-report/). If someone other than ISC.org is 
> offering to provide software vulnerability information about ISC software, 
> this is suspicious and probably fraudulent. ISC does offer professional 
> support services, which includes advance notification of security 
> vulnerabilities in our software but we have not authorized anyone else to 
> disclose that information prior to public disclosure.
> 
> Be safe out there, and check the domain name if you are not sure about the 
> sender. ISC.org  is signed, so you can also validate it 
> (since you are all operating resolvers, right?).
> 
> Vicky Risk (working at the actual ISC.org )
> 

-- 
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: forward option in dns server

2024-06-27 Thread Renzo Marengo

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 
> 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/con

Re: forward option in dns server

2024-06-27 Thread Greg Choules via bind-users

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

Re: forward option in dns server

2024-06-27 Thread Renzo Marengo

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  2001:503:ba3e::2:30
b.root-servers.net. 518400  IN  2001:500:200::b
c.root-servers.net. 518400  IN  2001:500:2::c
d.root-servers.net. 518400  IN  2001:500:2d::d
e.root-servers.net. 518400  IN  2001:500:a8::e
f.root-servers.net. 518400  IN  2001:500:2f::f
g.root-servers.net. 518400  IN  2001:500:12::d0d
h.root-servers.net. 518400  IN  2001:500:1::53
i.root-servers.net. 518400  IN  2001:7fe::53
j.root-servers.net. 518400  IN  2001:503:c27::2:30
k.root-servers.net. 518400  IN  2001:7fd::1
l.root-servers.net. 518400  IN  2001:500:9f::42
m.root-servers.net. 518400  IN  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 
> 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 “….. c

Re: forward option in dns server

2024-06-27 Thread Greg Choules via bind-users

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  -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?
 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  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  2001:503:ba3e::2:30
> b.root-servers.net. 518400  IN  2001:500:200::b
> c.root-servers.net. 518400  IN  2001:500:2::c
> d.root-servers.net. 518400  IN  2001:500:2d::d
> e.root-servers.net. 518400  IN  2001:500:a8::e
> f.root-servers.net. 518400  IN  2001:500:2f::f
> g.root-servers.net. 518400  IN  2001:500:12::d0d
> h.root-servers.net. 518400  IN  2001:500:1::53
> i.root-servers.net. 518400  IN  2001:7fe::53
> j.root-servers.net. 518400  IN  2001:503:c27::2:30
> k.root-servers.net. 518400  IN  2001:7fd::1
> l.root-servers.net. 518400  IN  2001:500:9f::42
> m.root-servers.net. 518400  IN  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

Re: forward option in dns server

2024-06-27 Thread Renzo Marengo

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  -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?
>  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 
> 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  2001:503:ba3e::2:30
>> b.root-servers.net. 518400  IN  2001:500:200::b
>> c.root-servers.net. 518400  IN  2001:500:2::c
>> d.root-servers.net. 518400  IN  2001:500:2d::d
>> e.root-servers.net. 518400  IN  2001:500:a8::e
>> f.root-servers.net. 518400  IN  2001:500:2f::f
>> g.root-servers.net. 518400  IN  2001:500:12::d0d
>> h.root-servers.net. 518400  IN  2001:500:1::53
>> i.root-servers.net. 518400  IN  2001:7fe::53
>> j.root-servers.net. 518400  IN  2001:503:c27::2:30
>> k.root-servers.net. 518400  IN  2001:7fd::1
>> l.root-servers.n

Re: forward option in dns server

2024-06-27 Thread Greg Choules via bind-users

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; ;
; ;}; 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  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  -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?
>>  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 
>> 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.

RE: SERVFAIL error during the evening

forward option in dns server

Re: forward option in dns server

Re: tryisc.com is not an isc.org domain

Re: forward option in dns server

Re: forward option in dns server

Re: forward option in dns server

Re: forward option in dns server

Re: forward option in dns server

Re: forward option in dns server

10 matches

Site Navigation

Mail list logo

Footer information