Re: Problem looking up domain dryfire.com

[Reindl Harald]

Am 16.08.2016 um 11:04 schrieb Eivind Olsen:

I'm seeing some odd problems where BIND (9.10.4-P2) has issues resolving
getsurfed.com. This is when using the "510 Software Group" BIND 9.10 for
RHEL/CentOS/Fedora.


why do you use a 3rd party package?

no problem here with bind-9.10.4-1.P2.fc24.x86_64 from the Fedora repos


I can do manual lookups of the domain with "dig" and point it to their
servers (dns0.getsurfed.com, dns1.getsurfed.com) but it fails for me if
I go through my BIND installation.

The named.run log contains lines like this:

16-Aug-2016 10:48:40.693 lame-servers: info: 17 unexpected RCODE
resolving 'dryfire.com/NS/IN': 213.162.97.178#53
16-Aug-2016 10:48:40.749 lame-servers: info: 17 unexpected RCODE
resolving 'dryfire.com/NS/IN': 213.162.97.177#53

A search for "17 unexpected RCODE" seems to indicate this might be
caused by incompatibility between SIT/DNS cookies and older versions of
NSD. Is this also what's happening in my case here?


;; ANSWER SECTION:
dryfire.com.21600   IN  A   109.109.232.98

;; ANSWER SECTION:
dryfire.com.21595   IN  NS  dns0.getsurfed.com.
dryfire.com.21595   IN  NS  dns1.getsurfed.com.



signature.asc
Description: OpenPGP digital 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

Re: DNS views setup help

[project722]

That is correct, as I have not setup the TSIG keys yet.

Also, I am still a bit confused on how this code should be implemented in
my conf file. In the example you posted that refers back to the link, where
would I place it in the context of my views on the master? Do I only need
that one stanza on the master and why in the linked doc does it show it
listed under the internal view? If that's the designated external key
should that be placed in the external view and not the internal? And why
does the internal view in the linked doc show both the external key and a
"mykey" in the internal view while only showing one for the external view?
Exactly how many keys do I need here?

Lets say my master server IP is 25.25.25.25 and my slave is 26.26.26.26.
Using my config from my first email and your code from your reply (lets use
only the part from the linked doc you wrote) can you provide a modified
view for internal and external for both the master and slave server?

Sorry for all the questions, its just that I'm very new to this view thing,
as you might have guessed:)

On Thu, Aug 18, 2016 at 9:50 PM, Mathew Ian Eis  wrote:

> I think you are pretty close. One detail that you appear to be missing are
> is in the linked document:
>
>
>
> server 10.0.1.1 {
>
> /* Deliver notify messages to external view. */
>
> keys { external-key; };
>
> };
>
>
>
> Your slaves should have a similar statement in each view with the IP of
> the master and the relevant key for that view.
>
>
>
> Two other things we have learned in deploying this:
>
>
>
> * It is helpful to change your allow-transfer section to be key-based
> per-view instead of IP based to save you from accidental zone transfers
> when other configuration errors are made.
>
> * The match-clients rule can be prepended with a key/!key set to prevent
> accidental communication on that view when using keys; e.g.
>
>
>
> match-clients {
>
> # key matching rules
>
> key admin-internal;
>
> !key admin-external;
>
> key slave-internal;
>
> !key slave-external;
>
> # ip/acl matching rules
>
> internal-ips;
>
> };
>
>
>
>
>
> Regards,
>
>
>
> Mathew Eis
>
> Northern Arizona University
>
> Information Technology Services
>
>
>
> *From: *bind-users  on behalf of Brian
> Pugh 
> *Date: *Thursday, August 18, 2016 at 7:15 PM
> *To: *"bind-users@lists.isc.org" 
> *Subject: *DNS views setup help
>
>
>
> I am running bind 9.8.2 on a pair of RHEL 6 DNS servers.. One server is
> the master, one is the slave. My goal is to setup 2 views so that our
> internal folks can resolve hostnames to internal IP's while still allowing
> our external customers to resolve from the outside. Both of these servers
> are external facing and have only one public IP each. First of all I would
> like to know if what I am trying to achieve is even possible with my
> current setup. What we have are internal users that are trying to access
> internal resources via a domain name that only exist in our external DNS.
> We do not have an internal zone for this domain or a inside DNS server that
> we can point them to in order to get a result for the query. So that leaves
> us looking at views for the solution.
>
> To be more precise, this is what is happening now.
>
> Internal client > looks up host that's actually on the internal network
> but resolves to an external IP. The problem with this is 2 fold.
>
> 1) DNS returns an external IP
>
> 2) Since the resource is internal, the traffic flow to the outside and
> back in happens on the same outside interface, which results in a hairpin,
> which we do not allow.
>
> Now, what I was told is that a DNS view type solution would not be
> applicable to the hairpin. My understanding is that internal clients query
> the server already to get results for external IP, so if we had a zone file
> in a view that had internal mappings, this would work and the internal user
> could access the resource since they are now being pointed to an internal
> IP.
>
> So what I want to do is setup an "internal" view for the zone in question
> that points to a db file with the internal IP of that host, and an external
> view for everyone else.
>
>
>
> My questions is:
>
> 1) Would DNS views work for my use case now that my server layout has been
> described?
>
> If so I need help in setting up TSIG because in my test lab everything
> seems to work except that on my slave server my zone in "view A" is being
> updated with the data from the master server from "view B". And view B
> seems to be in sync on both servers, although it seems when I update zone
> files I have to restart instead of a reload to get the zones to update.
> Even then, that does not always work. There is a link I found online that
> says TSIG would be the solution for this but it gives very 

Re: DNS views setup help

[Mathew Ian Eis]

I think you are pretty close. One detail that you appear to be missing are is 
in the linked document:

server 10.0.1.1 {
/* Deliver notify messages to external view. */
keys { external-key; };
};

Your slaves should have a similar statement in each view with the IP of the 
master and the relevant key for that view.

Two other things we have learned in deploying this:

* It is helpful to change your allow-transfer section to be key-based per-view 
instead of IP based to save you from accidental zone transfers when other 
configuration errors are made.
* The match-clients rule can be prepended with a key/!key set to prevent 
accidental communication on that view when using keys; e.g.

match-clients {
# key matching rules
key admin-internal;
!key admin-external;
key slave-internal;
!key slave-external;
# ip/acl matching rules
internal-ips;
};


Regards,

Mathew Eis
Northern Arizona University
Information Technology Services

From: bind-users  on behalf of Brian Pugh 

Date: Thursday, August 18, 2016 at 7:15 PM
To: "bind-users@lists.isc.org" 
Subject: DNS views setup help

I am running bind 9.8.2 on a pair of RHEL 6 DNS servers.. One server is the 
master, one is the slave. My goal is to setup 2 views so that our internal 
folks can resolve hostnames to internal IP's while still allowing our external 
customers to resolve from the outside. Both of these servers are external 
facing and have only one public IP each. First of all I would like to know if 
what I am trying to achieve is even possible with my current setup. What we 
have are internal users that are trying to access internal resources via a 
domain name that only exist in our external DNS. We do not have an internal 
zone for this domain or a inside DNS server that we can point them to in order 
to get a result for the query. So that leaves us looking at views for the 
solution.

To be more precise, this is what is happening now.
Internal client > looks up host that's actually on the internal network but 
resolves to an external IP. The problem with this is 2 fold.
1) DNS returns an external IP
2) Since the resource is internal, the traffic flow to the outside and back in 
happens on the same outside interface, which results in a hairpin, which we do 
not allow.
Now, what I was told is that a DNS view type solution would not be applicable 
to the hairpin. My understanding is that internal clients query the server 
already to get results for external IP, so if we had a zone file in a view that 
had internal mappings, this would work and the internal user could access the 
resource since they are now being pointed to an internal IP.
So what I want to do is setup an "internal" view for the zone in question that 
points to a db file with the internal IP of that host, and an external view for 
everyone else.

My questions is:
1) Would DNS views work for my use case now that my server layout has been 
described?
If so I need help in setting up TSIG because in my test lab everything seems to 
work except that on my slave server my zone in "view A" is being updated with 
the data from the master server from "view B". And view B seems to be in sync 
on both servers, although it seems when I update zone files I have to restart 
instead of a reload to get the zones to update. Even then, that does not always 
work. There is a link I found online that says TSIG would be the solution for 
this but it gives very little details on what the config is doing, so I do not 
know how to make TSIG work in my environment. This is the link I found:

https://kb.isc.org/article/AA-00295/0/How-do-I-share-a-dynamic-zone-between-multiple-views-.html
Here are the relavent parts to my config as it stands now from the master.

acl internal {
1.2.3.4; // public IP coming from the inside users
};

acl external {
5.6.7.8; // everyone else
9.10.11.12;; // everyone else
};

view "insideview" {
  match-clients { internal; };

  zone"example.com" IN {
  type master;
  file "/var/named/db.exampleinside.com"; // 
this db file will be shown to the clients in the internal ACL and map back to 
internal IP's
};
};

view "extview" {
  match-clients { external; };

zone"example.com" IN {
  type master;
  file "/var/named/db.exampleoutside.com";
};
The conf from the slave is identical to the above. Can anyone help me by 
showing me what a TSIG config would look like for my environemnt?











___
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

DNS views setup help

[Brian Pugh]

I am running bind 9.8.2 on a pair of RHEL 6 DNS servers.. One server is the
master, one is the slave. My goal is to setup 2 views so that our internal
folks can resolve hostnames to internal IP's while still allowing our
external customers to resolve from the outside. Both of these servers are
external facing and have only one public IP each. First of all I would like
to know if what I am trying to achieve is even possible with my current
setup. What we have are internal users that are trying to access internal
resources via a domain name that only exist in our external DNS. We do not
have an internal zone for this domain or a inside DNS server that we can
point them to in order to get a result for the query. So that leaves us
looking at views for the solution.

To be more precise, this is what is happening now.

Internal client > looks up host that's actually on the internal network but
resolves to an external IP. The problem with this is 2 fold.

1) DNS returns an external IP
2) Since the resource is internal, the traffic flow to the outside and back
in happens on the same outside interface, which results in a hairpin, which
we do not allow.

Now, what I was told is that a DNS view type solution would not be
applicable to the hairpin. My understanding is that internal clients query
the server already to get results for external IP, so if we had a zone file
in a view that had internal mappings, this would work and the internal user
could access the resource since they are now being pointed to an internal
IP.

So what I want to do is setup an "internal" view for the zone in question
that points to a db file with the internal IP of that host, and an external
view for everyone else.

My questions is:

1) Would DNS views work for my use case now that my server layout has been
described?

If so I need help in setting up TSIG because in my test lab everything
seems to work except that on my slave server my zone in "view A" is being
updated with the data from the master server from "view B". And view B
seems to be in sync on both servers, although it seems when I update zone
files I have to restart instead of a reload to get the zones to update.
Even then, that does not always work. There is a link I found online that
says TSIG would be the solution for this but it gives very little details
on what the config is doing, so I do not know how to make TSIG work in my
environment. This is the link I found:

https://kb.isc.org/article/AA-00295/0/How-do-I-share-a-dynamic-zone-between-multiple-views-.html

Here are the relavent parts to my config as it stands now from the master.

acl internal {
1.2.3.4; // public IP coming from the inside users
};

acl external {
5.6.7.8; // everyone else
9.10.11.12;; // everyone else
};

view "insideview" {
  match-clients { internal; };

  zone"example.com" IN {
  type master;
  file "/var/named/db.exampleinside.com"; // this db file will be shown
to the clients in the internal ACL and map back to internal IP's
};
};

view "extview" {
  match-clients { external; };

zone"example.com" IN {
  type master;
  file "/var/named/db.exampleoutside.com";
};

The conf from the slave is identical to the above. Can anyone help me by
showing me what a TSIG config would look like for my environemnt?
___
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: OPenssl 1.1 and Bind

[Mark Andrews]

In message , The Doctor writes:
> Vin?cius Ferr?o  wrote:
> : OpenSSL 1.0 will continue to be supported. There's no rush to go to 1.1 rel
> ease.
> 
> : I can't see this as an issue.
> 
> Tell us that when openssl 1.0 starts to disappear.

It was mostly accessor functions were missing which I wasn't worried
about as I expected them to turn up which they have.  You then have
to recode everything to deal with all the structures being opaque.

There is also the issue of making a code base that will compile w/
OpenSSL 1.1 and OpenSSL 1.0 (and 0.9 despite it being EOL).  I
suspect we will have static versions of the OpenSSL 1.1 accessor
functions so we can build w/ OpenSSL 1.0 and not have too many
#if/#else/#endif.  Aim to have all the code be written for OpenSSL 1.1.

Need to figure out how GOST is now done.

PKCS11 will most probably not be via OpenSSL anymore.

Then there is the gssapi support libraries that also need to support
OpenSSL 1.1.

Mark

> : Sent from my iPhone
> 
> : > On Aug 17, 2016, at 23:38, The Doctor  wrote:
> : > 
> : >> On Thu, Aug 18, 2016 at 12:13:29PM +1000, Mark Andrews wrote:
> : >> 
> : >> In message , The Doctor writes:
> : >>> Question, Is Bind openssl 1.1 ready?
> : >> 
> : >> No.  OpenSSL 1.1 breaks the build.  They take things away with no
> : >> viable alternatives as of last - 1 snapshot.
> : > 
> : > Openssl is aiming for a 26 Aug 2016 release.
> : > 
> : > What then?
> : > 
> : >> Mark
> : >> -- 
> : >> Mark Andrews, ISC
> : >> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> : >> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> : > 
> : > -- 
> : > Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2
> k.ab.ca
> : > God,Queen and country!Never Satan President Republic!Beware AntiChrist ri
> sing! 
> : > http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
> : > Time for the USA to hold a referendum on its republic and vote to dissolv
> e!! 
> : > ___
> : > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubsc
> ribe from this list
> : > 
> : > bind-users mailing list
> : > bind-users@lists.isc.org
> : > https://lists.isc.org/mailman/listinfo/bind-users
> 
> -- 
> Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab
> .ca
> God,Queen and country!Never Satan President Republic!Beware AntiChrist rising
> ! 
> http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
> Time for the USA to hold a referendum on its republic and vote to dissolve!! 
> ___
> 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
-- 
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

Spurious DNSKEY records on slave

[Jim Fenton]

I recently switched from external signing of my zone to use of BIND 9.9
inline signing. While things went fairly smoothly on the master server,
my slave ended up with a bunch of spurious DNSKEY records that came from
my previous keys (I generated new keys when I went to inline signing).

The extra DNSKEY records were not present in the zone file of the master
server, so I reinitiated a zone transfer and this did not help. I
checked the signed zone file on the master with named-checkzone and only
the desired DNSKEY records were there.

Eventually I tried shutting down the slave server, deleting the zone
file (and .jnl file that was also there) and restarting and all was good
after that.

Hypothesis: The .jnl file was the culprit; I don't know what's there,
but it sounds like the intent is to allow incremental updates of zone
files. Following the "fix", there is no longer a .jnl file there. I'm
not sure where it came from in the first place.

Master is running 9.9.5-9+deb8u6-Debian 

Slave is running 9.8.4-rpz2+rl005.12-P1

(both obtained from Debian distribution)

Is this a known problem?

-Jim


___
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: Selective forwarding from an internal only name server

[Darcy Kevin (FCA)]

Well, the cost/benefits/risks of separating authoritative and recursive on 
different *servers* (as opposed to different NICs, views, or whatever) is 
actually a hotly-debated topic among experts. I know some non-DNS-expert 
opinions, from the InfoSec side of the house, consider hardware-level 
separation "ideal", but frankly, I don't think they understand the concepts of 
NIC- or view-level separation, and need to be edumacated. Personally, I prefer 
a larger number of multi-role boxes, with view separation. The larger number of 
boxes means more availability and resilience against, say, Denial of Service 
attacks, which can target recursive service *or* authoritative service *or* 
both.

By the way, the original poster never said that he was hosting any zones 
authoritatively to the Internet on NS1, so why would you assume that he is? He 
said only that it served "external clients", but those could be *recursive* 
clients, for all we know.

That having been said, I concur with your technical recommendations.

- Kevin



-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of S Carr
Sent: Thursday, August 18, 2016 4:31 AM
To: BIND Users
Subject: Re: Selective forwarding from an internal only name server

On 18 August 2016 at 01:04, anup albal  wrote:
> Does that mean I setup another forwarding zone called microsoft.com or 
> sharepoint.microsoft.com or both?

Ideally you should setup a completely separate caching/forwarding server and 
not be using the external DNS box (NS1) for this purpose.

On the box you are forwarding the queries to (NS1) you need to enable recursion 
and specify an ACL for recursion to limit it to only allowing recursion from 
the internal DNS1 box.

On the internal DNS box (DNS1) also make sure recursion is enabled and an ACL 
in place allowing your client subnets, and configure forward zones for 
sharepoint.com and microsoft.com zones (and any other zones needed by the 
sharepoint service) to point at the NS1 box.
___
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
___
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: Selective forwarding from an internal only name server

[Darcy Kevin (FCA)]

As I read it, you have to buy the "flattening" as an extra service from 
CloudFlare. Their default is to give CNAME at the apex, intentionally violating 
RFCs.

What a concept: charging extra for RFC-compliance.


- Kevin


-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Barry 
Margolin
Sent: Wednesday, August 17, 2016 9:08 PM
To: comp-protocols-dns-b...@isc.org
Subject: Re: Selective forwarding from an internal only name server

In article ,
 "Darcy Kevin (FCA)"  wrote:

> Barry,
>   Cloudflare has been doing this for a while, so that their customers 
> won't be "limited by the DNS specifications (RFCs)" . 
> Having done that, they were compelled to offer another service -- so-called 
> "CNAME flattening"
> -- to fix the brokenness that's caused by their base offering.
> 
> See
> https://support.cloudflare.com/hc/en-us/articles/200169056-CNAME-Flatt
> ening-RF C-compliant-support-for-CNAME-at-the-root
> 
> I think Akamai also offers something similar.

But these don't work by sending an actual CNAME record. The server that 
implements flattening looks ip the IP of the target, and returns it as an A 
record for the domain.

That's why Cloudflare's method is "RFC-compliant", but what MS is doing with 
sharepoint.com is not.

> 
>   - Kevin
> 
> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf 
> Of Barry Margolin
> Sent: Wednesday, August 17, 2016 4:34 PM
> To: comp-protocols-dns-b...@isc.org
> Subject: Re: Selective forwarding from an internal only name server
> 
> In article ,
>  "Darcy Kevin (FCA)"  wrote:
> 
> > Well, sharepoint.com is a CNAME to sharepoint.microsoft.com, so you 
> > might need to make arrangements for that to be resolvable as well.
> 
> That doesn't seem valid to begin with. The .COM zone has delegation NS 
> records for sharepoint.com. Having a CNAME record for the same name is wrong.
> 
> --
> Barry Margolin
> Arlington, MA
> ___
> 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

--
Barry Margolin
Arlington, MA
___
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
___
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: OPenssl 1.1 and Bind

[The Doctor]

Vin?cius Ferr?o  wrote:
: OpenSSL 1.0 will continue to be supported. There's no rush to go to 1.1 
release.

: I can't see this as an issue.

Tell us that when openssl 1.0 starts to disappear.


: Sent from my iPhone

: > On Aug 17, 2016, at 23:38, The Doctor  wrote:
: > 
: >> On Thu, Aug 18, 2016 at 12:13:29PM +1000, Mark Andrews wrote:
: >> 
: >> In message , The Doctor writes:
: >>> Question, Is Bind openssl 1.1 ready?
: >> 
: >> No.  OpenSSL 1.1 breaks the build.  They take things away with no
: >> viable alternatives as of last - 1 snapshot.
: > 
: > Openssl is aiming for a 26 Aug 2016 release.
: > 
: > What then?
: > 
: >> Mark
: >> -- 
: >> Mark Andrews, ISC
: >> 1 Seymour St., Dundas Valley, NSW 2117, Australia
: >> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
: > 
: > -- 
: > Member - Liberal International This is doctor@@nl2k.ab.ca Ici 
doctor@@nl2k.ab.ca
: > God,Queen and country!Never Satan President Republic!Beware AntiChrist 
rising! 
: > http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
: > Time for the USA to hold a referendum on its republic and vote to 
dissolve!! 
: > ___
: > 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

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Time for the USA to hold a referendum on its republic and vote to dissolve!! 
___
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: Selective forwarding from an internal only name server

[S Carr]

On 18 August 2016 at 01:04, anup albal  wrote:
> Does that mean I setup another forwarding zone called microsoft.com or
> sharepoint.microsoft.com or both?

Ideally you should setup a completely separate caching/forwarding
server and not be using the external DNS box (NS1) for this purpose.

On the box you are forwarding the queries to (NS1) you need to enable
recursion and specify an ACL for recursion to limit it to only
allowing recursion from the internal DNS1 box.

On the internal DNS box (DNS1) also make sure recursion is enabled and
an ACL in place allowing your client subnets, and configure forward
zones for sharepoint.com and microsoft.com zones (and any other zones
needed by the sharepoint service) to point at the NS1 box.
___
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: Selective forwarding from an internal only name server

[S Carr]

On 18 August 2016 at 02:07, Barry Margolin  wrote:
> That's why Cloudflare's method is "RFC-compliant", but what MS is doing
> with sharepoint.com is not.

Microsoft's DNS implementation allows CNAMEs at the zone apex, correct
it's not RFC compliant, but this is Microsoft...
___
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