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