RE: About query response on a view

[Okan Bostan]

Hi,
Firstly thanks for all the responses, giving more details about our config:

Internal view: Internal DNS service for the internal clients. Accepts requests 
from internal IP, Recursion is on, forwarding the out of zone queries to our 
cache-only DNS servers. Also serves some zone information.
External view: Authoritative DNS service for our domain.  Accepts requests from 
external IP, No recursion,

Also we will consider to separate the recursive and authoritative servers, but 
separating them with views isn't a good solution?

@Eray Aslan, additional-from-cache and additional-from-auth settings did the 
trick, now server gives "query refused"

@Barry Finkel, yes I typed dig ww. At that point, every recursive query gives 
the same output. But thanks for the info.

@Mark Elkins,In our setup, we have one machine with 2 IP addresses. (option 3) 
We are planning to use DNNSEC, Could you give more information about the 
possible DNSSEC problem?
I fix the referral problem with Eray's solution.

@Kevin Darcy, (a) match-clients is a C class network address space. (b) I 
explained it above. Thanks for the detailed explanation and the note.

Regards,

Okan Bostan

From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Darcy Kevin (FCA)
Sent: Thursday, December 10, 2015 1:43 AM
To: bind-users@lists.isc.org <bind-us...@isc.org>
Subject: RE: About query response on a view

Well, there some things that are not clear from your message:

A) when you do your "dig", what is your source address, what is your 
destination address, and what is your match-clients ACL for the internal view? 
These values have a bearing on what view you're going to match. Seems like 
you're matching the wrong view - the external one, which has no recursion -- 
and getting a mere "referral" for www.google.com<http://www.google.com> (root 
nameservers) instead of an answer.
B) you say your internal view has "forwarders". Why? What's the purpose of 
that? To where are you forwarding? To public resolvers like Google? If you're 
forwarding to *yourself*, then either you created a forwarding loop, or (if you 
excluded your own IP in the match-clients ACL of the internal view) the 
forwarded query is matching the wrong view, without (as you show below) any 
allow-recursion exception, so, again, as expected you're getting a mere 
referral instead of an answer. Unless you're forwarding to an external entity 
that provides some added value (e.g. enhanced performance/availability, DNSSEC 
validation, blacklisting of known malicious domains, anti-forgery measures, 
etc.) consider just replacing the forwarder configuration with an appropriate 
"hints" zone definition in your internal view and letting it resolve names 
iteratively. You didn't say what platform you were migrating from, but if it 
was forwarding-centric, understand that forwarding is much less heavily used in 
the BIND world.

NOTE: if you want to publically post ACLs containing internal address ranges, 
it's fine to obfuscate those ranges, as long as you preserve their "essence", 
e.g. large-versus-small, public-versus-private-versus-localhost. It's only when 
folks obfuscate names and addresses that are publically-visible anyway, that 
the obfuscation sometimes gets in the way of diagnosing the problem and folks 
on this list get somewhat ornery. For the ultimate in Internet Engineering 
etiquette, use addresses based on the RFC 5737 "documentation only" ranges.



- Kevin

From: bind-users-boun...@lists.isc.org<mailto:bind-users-boun...@lists.isc.org> 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Okan Bostan
Sent: Wednesday, December 09, 2015 4:11 AM
To: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
Subject: About query response on a view

Hello List,

We are planning to migrate to Bind dns, I'm a bit newbie.

In our design we have two views; int and ext.
As internal view, recursion is on and we have our internal zones & forwarders. 
I have no problem with internal view.

In external view, recursion in no. Also have some zones. In testing external 
view, I can query the records in zones, thats not a problem also.

But when I try to query, for example www.google.com<http://www.google.com> it 
returns the root servers records by dig.

;; QUESTION SECTION:
;ww.IN  A

;; AUTHORITY SECTION:
.   518400  IN  NS  D.ROOT-SERVERS.NET.
.   518400  IN  NS  M.ROOT-SERVERS.NET.
.   518400  IN  NS  C.ROOT-SERVERS.NET.
.   518400  IN  NS  J.ROOT-SERVERS.NET.
. 

Re: About query response on a view

[Mark Andrews]

In message <1449745839.4651.50.ca...@posix.co.za>, Mark Elkins writes:
>
> On Thu, 2015-12-10 at 08:53 +, Okan Bostan wrote:
> > Hi,
> > Firstly thanks for all the responses, giving more details about our
> > config:
> >
> > Internal view: Internal DNS service for the internal clients. Accepts
> > requests from internal IP, Recursion is on, forwarding the out of zone
> > queries to our cache-only DNS servers. Also serves some zone
> > information.
> > External view: Authoritative DNS service for our domain.  Accepts
> > requests from external IP, No recursion,
> >
> > Also we will consider to separate the recursive and authoritative
> > servers, but separating them with views isn’t a good solution?
> >
> > @Eray Aslan, additional-from-cache and additional-from-auth settings
> > did the trick, now server gives “query refused”
> >
> > @Barry Finkel, yes I typed dig ww. At that point, every recursive
> > query gives the same output. But thanks for the info.
> >
> > @Mark Elkins,In our setup, we have one machine with 2 IP addresses.
> > (option 3) We are planning to use DNNSEC, Could you give more
> > information about the possible DNSSEC problem?
>
> Resolver Problem:
> DNSSEC requires an appropriately configured recursive resolver that can
> chase answers and signatures down from the root. It should not also be
> authoritative (ie have Zones). To the best of my knowledge, answers from
> Zones that the Software instance is authoritative for will never be
> DNSSEC validated (AD bit set). This might not initially seem like a
> problem (you trust your own setup) but things like DANE will not work,
> ie DANE in an SMTP environment.

Only if the DANE client is broken.  In general client can't trust
AD (think coffee shop) so the DANE client needs to do validation
for itself.  Once a client is validating itself AD is irrelevent.

> Resolver Solution:
> Move the Internal Views of Authoritaive Data (Internal Zones) to a Third
> IP address.
> Run the Recursive Server on the "Resolver Only" IP address, perhaps use
> UNBOUND (I like BIND - but multiple instances of BIND is going to become
> administratively painful). 

Absolute hogwash.  It's easy enough to configure a single instance
of named to provide authoritative services on on address and recursive
services on a second address.

As for running multiple instances we do that all the time when
testing and it really isn't that hard.

controls { inet address ...; };
option {
listen-on { address; };
query-source address;
notify-source address;
transfer-source address;
pid-file "/var/run/named-address/named.pid";
 or
pid-file "/var/run/named/named-address.pid";
};

> It MUST be the only Port 53 application on
> that 3rd IP address. Basically, copy the root KSK into a file owned by
> unbound and tell unbound to use that file.
> # cd /etc/unbound  (whatever)
> # dig . dnskey | grep 257 > root-anchors.txt
> # chown unbound: root.anchors.txt
> ...then add "auto-trust-anchor-file: root.anchors.txt" to unbound.conf
> (Confirm the authenticity of the root dnskey/KSK from
> https://dnssec.co.za and other sources)
> 
> DNSSEC Signing your Zones is easy enough but I've never tried to sign an
> Internal and External version of the same Zone. Why complicate life.
> You'll have to hand-roll a solution.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@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: About query response on a view

[Eray Aslan]

On Thu, Dec 10, 2015 at 08:53:52AM +, Okan Bostan wrote:
> Also we will consider to separate the recursive and authoritative
> servers, but separating them with views isn't a good solution?

Not really, no.  They serve different purposes and hence require
different settings.  You can munge it for a while but shouldn't for any
serious use.  Since you are setting up a new infrastructure, do the
right thing and make them seperate.  For further info try searching the
archives.

Unbound is also a populer choice for a resolver.

-- 
Eray Aslan 
___
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: About query response on a view

[Mark Elkins]

On Thu, 2015-12-10 at 08:53 +, Okan Bostan wrote:
> Hi,
> Firstly thanks for all the responses, giving more details about our
> config:
> 
> Internal view: Internal DNS service for the internal clients. Accepts
> requests from internal IP, Recursion is on, forwarding the out of zone
> queries to our cache-only DNS servers. Also serves some zone
> information. 
> External view: Authoritative DNS service for our domain.  Accepts
> requests from external IP, No recursion, 
> 
> Also we will consider to separate the recursive and authoritative
> servers, but separating them with views isn’t a good solution?
> 
> @Eray Aslan, additional-from-cache and additional-from-auth settings
> did the trick, now server gives “query refused”
> 
> @Barry Finkel, yes I typed dig ww. At that point, every recursive
> query gives the same output. But thanks for the info. 
> 
> @Mark Elkins,In our setup, we have one machine with 2 IP addresses.
> (option 3) We are planning to use DNNSEC, Could you give more
> information about the possible DNSSEC problem?

Resolver Problem:
DNSSEC requires an appropriately configured recursive resolver that can
chase answers and signatures down from the root. It should not also be
authoritative (ie have Zones). To the best of my knowledge, answers from
Zones that the Software instance is authoritative for will never be
DNSSEC validated (AD bit set). This might not initially seem like a
problem (you trust your own setup) but things like DANE will not work,
ie DANE in an SMTP environment.

Resolver Solution:
Move the Internal Views of Authoritaive Data (Internal Zones) to a Third
IP address.
Run the Recursive Server on the "Resolver Only" IP address, perhaps use
UNBOUND (I like BIND - but multiple instances of BIND is going to become
administratively painful). It MUST be the only Port 53 application on
that 3rd IP address. Basically, copy the root KSK into a file owned by
unbound and tell unbound to use that file.
# cd /etc/unbound  (whatever)
# dig . dnskey | grep 257 > root-anchors.txt
# chown unbound: root.anchors.txt
...then add "auto-trust-anchor-file: root.anchors.txt" to unbound.conf
(Confirm the authenticity of the root dnskey/KSK from
https://dnssec.co.za and other sources)

DNSSEC Signing your Zones is easy enough but I've never tried to sign an
Internal and External version of the same Zone. Why complicate life.
You'll have to hand-roll a solution.


> I fix the referral problem with Eray’s solution.
> 
> @Kevin Darcy, (a) match-clients is a C class network address space.
> (b) I explained it above. Thanks for the detailed explanation and the
> note. 
> 
> Regards,
> 
> Okan Bostan
> 
>  
> 
> From: bind-users-boun...@lists.isc.org
> [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Darcy Kevin
> (FCA)
> Sent: Thursday, December 10, 2015 1:43 AM
> To: bind-users@lists.isc.org <bind-us...@isc.org>
> Subject: RE: About query response on a view
> 
> 
>  
> 
> Well, there some things that are not clear from your message:
> 
>  
> 
> A) when you do your “dig”, what is your source address, what is your
> destination address, and what is your match-clients ACL for the
> internal view? These values have a bearing on what view you’re going
> to match. Seems like you’re matching the wrong view – the external
> one, which has no recursion -- and getting a mere “referral”
> forwww.google.com (root nameservers) instead of an answer.
> 
> B) you say your internal view has “forwarders”. Why? What’s the
> purpose of that? To where are you forwarding? To public resolvers like
> Google? If you’re forwarding to *yourself*, then either you created a
> forwarding loop, or (if you excluded your own IP in the match-clients
> ACL of the internal view) the forwarded query is matching the wrong
> view, without (as you show below) any allow-recursion exception, so,
> again, as expected you’re getting a mere referral instead of an
> answer. Unless you’re forwarding to an external entity that provides
> some added value (e.g. enhanced performance/availability, DNSSEC
> validation, blacklisting of known malicious domains, anti-forgery
> measures, etc.) consider just replacing the forwarder configuration
> with an appropriate “hints” zone definition in your internal view and
> letting it resolve names iteratively. You didn’t say what platform you
> were migrating from, but if it was forwarding-centric, understand that
> forwarding is much less heavily used in the BIND world.
> 
>  
> 
> NOTE: if you want to publically post ACLs containing internal address
> ranges, it’s fine to obfuscate those ranges, as long as you preserve
> their “essence”, e.g. large-versus-small,
> public-versus-private-versus-localhost. It’s only when folks obfuscate
> 

About query response on a view

[Okan Bostan]

Hello List,

We are planning to migrate to Bind dns, I'm a bit newbie.

In our design we have two views; int and ext.
As internal view, recursion is on and we have our internal zones & forwarders. 
I have no problem with internal view.

In external view, recursion in no. Also have some zones. In testing external 
view, I can query the records in zones, thats not a problem also.

But when I try to query, for example www.google.com it 
returns the root servers records by dig.

;; QUESTION SECTION:
;ww.IN  A

;; AUTHORITY SECTION:
.   518400  IN  NS  D.ROOT-SERVERS.NET.
.   518400  IN  NS  M.ROOT-SERVERS.NET.
.   518400  IN  NS  C.ROOT-SERVERS.NET.
.   518400  IN  NS  J.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  L.ROOT-SERVERS.NET.
.   518400  IN  NS  F.ROOT-SERVERS.NET.
.   518400  IN  NS  K.ROOT-SERVERS.NET.
.   518400  IN  NS  A.ROOT-SERVERS.NET.
.   518400  IN  NS  B.ROOT-SERVERS.NET.
.   518400  IN  NS  E.ROOT-SERVERS.NET.

And status: NOERROR

also in nslookup:

Name:www.google.com
Served by:
- E.ROOT-SERVERS.NET

- F.ROOT-SERVERS.NET

- J.ROOT-SERVERS.NET

- G.ROOT-SERVERS.NET

- D.ROOT-SERVERS.NET

- C.ROOT-SERVERS.NET

- A.ROOT-SERVERS.NET


But in our existing DNS enviroment, I get  status: SERVFAIL to same query.

Is this a normal behaviour ? How can I disable this Authority section with root 
server NS records?

My external view:

view "EXTERNAL" {

match-clients {"any";};
allow-query-on {ext_ip; };

recursion  no;
allow-recursion { none;};


#Include SLAVE zones
include "slave.zones";

#Include REVERSE zones
include "reverse.zones";



};// view EXTERNAL

Regards,

Okan.
___
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: About query response on a view

[Eray Aslan]

On Wed, Dec 09, 2015 at 09:11:28AM +, Okan Bostan wrote:
> As internal view, recursion is on and we have our internal zones &
> forwarders. I have no problem with internal view.

Do try and separate authoritative and recursive servers in your
environment.

> But in our existing DNS enviroment, I get  status: SERVFAIL to same
> query.

I am assuming status: REFUSED is the desired output.

> Is this a normal behaviour ? How can I disable this Authority section
> with root server NS records?

Check additional-from-cache and additional-from-auth settings and
consider upgrading if you are using an old version.

-- 
Eray Aslan 
___
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: About query response on a view

[Barry S. Finkel]

 Okan Bostan  wrote:

Hello List,

We are planning to migrate to Bind dns, I'm a bit newbie.

In our design we have two views; int and ext.
As internal view, recursion is on and we have our internal zones & forwarders. 
I have no problem with internal view.

In external view, recursion in no. Also have some zones. In testing external 
view, I can query the records in zones, thats not a problem also.

But when I try to query, for examplewww.google.com  it 
returns the root servers records by dig.

;; QUESTION SECTION:
;ww.IN  A

;; AUTHORITY SECTION:
.   518400  IN  NS  D.ROOT-SERVERS.NET.
.   518400  IN  NS  M.ROOT-SERVERS.NET.
.   518400  IN  NS  C.ROOT-SERVERS.NET.
.   518400  IN  NS  J.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  L.ROOT-SERVERS.NET.
.   518400  IN  NS  F.ROOT-SERVERS.NET.
.   518400  IN  NS  K.ROOT-SERVERS.NET.
.   518400  IN  NS  A.ROOT-SERVERS.NET.
.   518400  IN  NS  B.ROOT-SERVERS.NET.
.   518400  IN  NS  E.ROOT-SERVERS.NET.

And status: NOERROR

also in nslookup:

Name:www.google.com
Served by:
- E.ROOT-SERVERS.NET

- F.ROOT-SERVERS.NET

- J.ROOT-SERVERS.NET

- G.ROOT-SERVERS.NET

- D.ROOT-SERVERS.NET

- C.ROOT-SERVERS.NET

- A.ROOT-SERVERS.NET


But in our existing DNS enviroment, I get  status: SERVFAIL to same query.

Is this a normal behaviour ? How can I disable this Authority section with root 
server NS records?

My external view:

view "EXTERNAL" {

 match-clients {"any";};
 allow-query-on {ext_ip; };

 recursion  no;
 allow-recursion { none;};


 #Include SLAVE zones
 include "slave.zones";

 #Include REVERSE zones
 include "reverse.zones";



};// view EXTERNAL

Regards,

Okan.


Something got lost in "translation".

> But when I try to query, for example
> www.google.com

Did you really type "dig www.google.com"?

> ;; QUESTION SECTION:
> ;ww.IN  A

According to dig, you queried "ww.".
And the output of dig is correct - there is no DNS entry
with that name, and the authority section contains the
root servers, as it is those servers which would have
contained the zone, had it existed.

You did not give us the unedited output of "dig".

--Barry Finkel
___
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: About query response on a view

[Darcy Kevin (FCA)]

Well, there some things that are not clear from your message:

A) when you do your "dig", what is your source address, what is your 
destination address, and what is your match-clients ACL for the internal view? 
These values have a bearing on what view you're going to match. Seems like 
you're matching the wrong view - the external one, which has no recursion -- 
and getting a mere "referral" for www.google.com<http://www.google.com> (root 
nameservers) instead of an answer.
B) you say your internal view has "forwarders". Why? What's the purpose of 
that? To where are you forwarding? To public resolvers like Google? If you're 
forwarding to *yourself*, then either you created a forwarding loop, or (if you 
excluded your own IP in the match-clients ACL of the internal view) the 
forwarded query is matching the wrong view, without (as you show below) any 
allow-recursion exception, so, again, as expected you're getting a mere 
referral instead of an answer. Unless you're forwarding to an external entity 
that provides some added value (e.g. enhanced performance/availability, DNSSEC 
validation, blacklisting of known malicious domains, anti-forgery measures, 
etc.) consider just replacing the forwarder configuration with an appropriate 
"hints" zone definition in your internal view and letting it resolve names 
iteratively. You didn't say what platform you were migrating from, but if it 
was forwarding-centric, understand that forwarding is much less heavily used in 
the BIND world.

NOTE: if you want to publically post ACLs containing internal address ranges, 
it's fine to obfuscate those ranges, as long as you preserve their "essence", 
e.g. large-versus-small, public-versus-private-versus-localhost. It's only when 
folks obfuscate names and addresses that are publically-visible anyway, that 
the obfuscation sometimes gets in the way of diagnosing the problem and folks 
on this list get somewhat ornery. For the ultimate in Internet Engineering 
etiquette, use addresses based on the RFC 5737 "documentation only" ranges.



- Kevin

From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Okan Bostan
Sent: Wednesday, December 09, 2015 4:11 AM
To: bind-users@lists.isc.org
Subject: About query response on a view

Hello List,

We are planning to migrate to Bind dns, I'm a bit newbie.

In our design we have two views; int and ext.
As internal view, recursion is on and we have our internal zones & forwarders. 
I have no problem with internal view.

In external view, recursion in no. Also have some zones. In testing external 
view, I can query the records in zones, thats not a problem also.

But when I try to query, for example www.google.com<http://www.google.com> it 
returns the root servers records by dig.

;; QUESTION SECTION:
;ww.IN  A

;; AUTHORITY SECTION:
.   518400  IN  NS  D.ROOT-SERVERS.NET.
.   518400  IN  NS  M.ROOT-SERVERS.NET.
.   518400  IN  NS  C.ROOT-SERVERS.NET.
.   518400  IN  NS  J.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  L.ROOT-SERVERS.NET.
.   518400  IN  NS  F.ROOT-SERVERS.NET.
.   518400  IN  NS  K.ROOT-SERVERS.NET.
.   518400  IN  NS  A.ROOT-SERVERS.NET.
.   518400  IN  NS  B.ROOT-SERVERS.NET.
.   518400  IN  NS  E.ROOT-SERVERS.NET.

And status: NOERROR

also in nslookup:

Name:www.google.com<http://www.google.com>
Served by:
- E.ROOT-SERVERS.NET

- F.ROOT-SERVERS.NET

- J.ROOT-SERVERS.NET

- G.ROOT-SERVERS.NET

- D.ROOT-SERVERS.NET

- C.ROOT-SERVERS.NET

- A.ROOT-SERVERS.NET

But in our existing DNS enviroment, I get  status: SERVFAIL to same query.
Is this a normal behaviour ? How can I disable this Authority section with root 
server NS records?

My external view:

view "EXTERNAL" {

match-clients {"any";};
allow-query-on {ext_ip; };

recursion  no;
allow-recursion { none;};


#Include SLAVE zones
include "slave.zones";

#Include REVERSE zones
include "reverse.zones";



};// view EXTERNAL

Regards,

Okan.
___
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: About query response on a view

[Mark Elkins]

If you ever want to do DNSSEC - you are going to have a problem.

If possible - have two different servers, one for inside, one for
outside.

This could be:
(1) Two different machines
(2) One machine - virtualised - each of the two virtual machines
logically like (1)
(3) One machine with two IP addresses - one for an internal instance of
BIND (or UNBOUND or any recursive only software) - the other for
external - with BIND running Authoritatively only (or NSD or other
non-recursive system)

If you are currently running the same zone but the internal version
(view) has more information, that is - you are hiding "authoritative"
DNS information from the rest of the world - Consider why. Is it really
secret? is it on RFC1918 address space?

You could consider having a third machine (virtual or otherwise) for
that... there are multiple ways to have this working.

The purist in me says the External machine should be Authoritative only,
the Inside machine should contain No Authoritative info and that a Zone
can only have one set of information regardless of where its viewed
from.

(and never call a machine "secretproject.example.com")

Your conditions may not allow a purist solution.

And - I think the outside machine is providing a Referral to the Root in
reply to your query, which seems a reasonable thing to do.
 
On Wed, 2015-12-09 at 09:11 +, Okan Bostan wrote:
> Hello List,
> 
> We are planning to migrate to Bind dns, I’m a bit newbie. 
> 
> In our design we have two views; int and ext. 
> As internal view, recursion is on and we have our internal zones &
> forwarders. I have no problem with internal view.
> 
> In external view, recursion in no. Also have some zones. In testing
> external view, I can query the records in zones, thats not a problem
> also. 
> 
> But when I try to query, for example www.google.com it returns the
> root servers records by dig.
> 
>  
> 
> ;; QUESTION SECTION:
> 
> ;ww.IN  A
> 
>  
> 
> ;; AUTHORITY SECTION:
> 
> .   518400  IN  NS  D.ROOT-SERVERS.NET.
> 
> .   518400  IN  NS  M.ROOT-SERVERS.NET.
> 
> .   518400  IN  NS  C.ROOT-SERVERS.NET.
> 
> .   518400  IN  NS  J.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  L.ROOT-SERVERS.NET.
> 
> .   518400  IN  NS  F.ROOT-SERVERS.NET.
> 
> .   518400  IN  NS  K.ROOT-SERVERS.NET.
> 
> .   518400  IN  NS  A.ROOT-SERVERS.NET.
> 
> .   518400  IN  NS  B.ROOT-SERVERS.NET.
> 
> .   518400  IN  NS  E.ROOT-SERVERS.NET.
> 
>  
> 
> And status: NOERROR
> 
> 
> also in nslookup:
> 
> Name:www.google.com
> 
> Served by:
> 
> - E.ROOT-SERVERS.NET
> 
>  
> 
> - F.ROOT-SERVERS.NET
> 
>  
> 
> - J.ROOT-SERVERS.NET
> 
>  
> 
> - G.ROOT-SERVERS.NET
> 
>  
> 
> - D.ROOT-SERVERS.NET
> 
>  
> 
> - C.ROOT-SERVERS.NET
> 
>  
> 
> - A.ROOT-SERVERS.NET
> 
> 
> 
>  
> 
> But in our existing DNS enviroment, I get  status: SERVFAIL to same
> query.
> 
> 
> 
> Is this a normal behaviour ? How can I disable this Authority section
> with root server NS records?
> 
> My external view:
> 
> view "EXTERNAL" {
> 
>  
> 
> match-clients {"any";};
> 
> allow-query-on {ext_ip; };
> 
>  
> 
> recursion  no;
> 
> allow-recursion { none;};
> 
>
>   
> 
> #Include SLAVE zones
> 
> include "slave.zones";
> 
>  
> 
> #Include REVERSE zones
> 
> include “reverse.zones";
> 
>  
> 
> 
> 
>  
> 
> };// view EXTERNAL 
> 
> Regards, 
> 
> Okan.


-- 
Mark James ELKINS  -  Posix Systems - (South) Africa
m...@posix.co.za   Tel: +27.128070590  Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za


smime.p7s
Description: S/MIME cryptographic signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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