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 +0000, 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
mje at posix.co.za       Tel: +27.128070590  Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5667 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20151209/a2c858c5/attachment.bin>