Reverse resolution ambiguities

2014-09-25 Thread Lars Hanke
I have a Bind9 infrastructure serving an internal network at .mytld. Since it may happen that .mytld becomes an official TLD in the future, I decided to migrate to .internal.my.official.tld, i.e. currently all machines are available with the same IP in both domains. Now we decided to move our

Re: Reverse resolution ambiguities

2014-09-25 Thread Chuck Anderson
On Thu, Sep 25, 2014 at 11:39:37AM +0200, Lars Hanke wrote: > Now we decided to move our authentication to a samba4 based AD. This > means that the AD runs yet another domain .ad.my.official.tld, which > introduces a third name for those systems, which joined the domain. > But not all systems are

Re: BIND NXDOMAIN {REP=5.1}

2014-09-25 Thread Mark Andrews
In message <01ce01cfd87b$0146fc00$03d4f400$@iprimus.com.au>, "Neil" writes: > That solution worked Mark , Thank you. > > One more question, is it possible perform the below, from the left to right > The below does not work on NXDOMAIN override. > > autodiscover.*. IN A 192.168.0

Re: Two domains reporting errors

2014-09-25 Thread LuKreme
On 10 Sep 2014, at 04:55 , /dev/rob0 wrote: > "@" refers to the current $ORIGIN. When a zone file is initially > loaded, $ORIGIN is implicitly set to the name of the zone. But you > changed that, it's now the root! So "@" here means ".", and no, a > zone file with "@" is not the same as a zo

RE: Two domains reporting errors

2014-09-25 Thread Stuart Browne
> > Note that there are only relative names in my example. This could > > load as any zone name. You might want to use some fully-qualified > > names on the RHS, such as "root.covisp.net." as the SOA RNAME. > > Wait a second, so the zone name comes from the named.conf? Yes. > I could have, f