Re: separation of authoritative and recursive functions on internal networks

On 02/07/2016 04:12 PM, Reindl Harald wrote: Warn SOA MNAME entry WARNING: SOA MNAME (tncsrv06.tnetconsulting.net) is not listed as a primary nameserver at your parent nameserver! I know that this is a late reply, but I just ran across something that relates to this: Per section 6.8

Re: separation of authoritative and recursive functions on internal networks

On 02/07/2016 04:12 PM, Reindl Harald wrote: define OK Will it cause any problems if the slave server is not listed as an NS? for internal use NS records don't matter at all because the only thing which matters is that the machines listed in /etc/resolv.conf respond correctly I think I

Re: separation of authoritative and recursive functions on internal networks

I know that this is an older thread, but I've been holding onto it for a while with the intent of asking a related question. On 08/10/2015 12:12 PM, Mark Andrews wrote: Authoritative servers (listed in NS records) shouldn't be recursive. I'm taking this to mean servers that have zones

Re: separation of authoritative and recursive functions on internal networks

Am 08.02.2016 um 00:06 schrieb Grant Taylor: Does being a slave for a zone imply that a server is also listed as an NS? Or is it considered "okay" for a server to slave a zone without publishing that it does so? define OK - for internal use NS records don't matter at all because the only

Re: separation of authoritative and recursive functions on internal networks

In message <56b7cdfb.5070...@tnetconsulting.net>, Grant Taylor writes: > I know that this is an older thread, but I've been holding onto it for a > while with the intent of asking a related question. > > On 08/10/2015 12:12 PM, Mark Andrews wrote: > > Authoritative servers (listed in NS records)

Re: separation of authoritative and recursive functions on internal networks

On 02/07/2016 05:54 PM, Reindl Harald wrote: why? (I believe I answered your question in the subsequent paragraph. If not let me know and I'll try again.) that's not a reason for not list one of them as SOA None of the slaves are the SOA. (Further, I'm not aware of them having been

Re: separation of authoritative and recursive functions on internal networks

On 02/07/2016 04:55 PM, Mark Andrews wrote: This proves robustness in the presence of link failures. Faster than ttl expiry of local zone changes (provided that notify messages are sent). I presume you are referring to the slave zone expiration timer, not normal record TTLs. No, I mean

Re: separation of authoritative and recursive functions on internal networks

Am 08.02.2016 um 01:35 schrieb Grant Taylor: On 02/07/2016 04:55 PM, Mark Andrews wrote: .local doesn't have servers. Um Please forgive me while I look at many Small Business Server / poorly configured networks. That being said, I'll give you that it's not an official TLD. (Last I

Re: separation of authoritative and recursive functions on internal networks

Am 08.02.2016 um 01:00 schrieb Grant Taylor: On 02/07/2016 04:12 PM, Reindl Harald wrote: define OK Will it cause any problems if the slave server is not listed as an NS? no for internal use NS records don't matter at all because the only thing which matters is that the machines listed

Re: separation of authoritative and recursive functions on internal networks

> On Jan 29, 2016, at 3:58 PM, Darcy Kevin (FCA) > wrote: > > Data obtained from the recursive function will never outrank authoritative > data of a master or a slave. Kevin, That's true, but authoritative servers also sometimes serve up referrals, sometimes

Re: separation of authoritative and recursive functions on internal networks

In message <23f8b4f8-b0ea-436d-a700-87ac63248...@nau.edu>, Mathew Ian Eis writes: > Howdy Mark, > > Can you please clarify the best practice for this? > > > Recursive servers (honouring RD=1) however can be authoritative for > > zones. > > In this context of "authoritative", do you mean that

Re: separation of authoritative and recursive functions on internal networks

Howdy Mark, Can you please clarify the best practice for this? > Recursive servers (honouring RD=1) however can be authoritative for zones. In this context of "authoritative", do you mean that they can be fully functional slaves and have a complete copy of the zone information? I would

RE: separation of authoritative and recursive functions on internal networks

Why not? Data obtained from the recursive function will never outrank authoritative data of a master or a slave. See the "Data Ranking" section of RFC 2181. AFAICT, it's been a *very* long time since BIND, or any other DNS implementation, has accidentally got those ranking rules wrong and given

Re: separation of authoritative and recursive functions on internal networks

On 2015-08-10 13:12, Mark Andrews wrote: Authoritative servers (listed in NS records) shouldn't be recursive. This prevents leakage of cache data. This provide consistent answers. The server also doesn't have to decide what type of answer to give (recursive vs authoritative). Glue doesn't

Re: separation of authoritative and recursive functions on internal networks

On Wed, Aug 5, 2015 at 10:18 AM, Gary Carr garycarr...@gmail.com wrote: Overall, is breaking this function out - internally - really worth it? I can offer a personal testimonial on the management aspects of this: A couple of years back, we made the switch from combined authoritative/recursive

Re: separation of authoritative and recursive functions on internal networks

Authoritative servers (listed in NS records) shouldn't be recursive. This prevents leakage of cache data. This provide consistent answers. The server also doesn't have to decide what type of answer to give (recursive vs authoritative). Glue doesn't get overridden by answers, etc. Recurive

RE: separation of authoritative and recursive functions on internal networks

Separate authoritative and recursive functions is really a simplistic approach to a complex challenge. I think a better approach is to make both the published-authoritative function and the recursive-resolution functions robust enough *in*and*of*themselves* so that there is no value to an