>Isn't it time to upgrade? Yes, it is. In fact, adding these statements to the options clause is in preparation for our migration to a later version. It seems from my testing that while BIND 9.4 was very passive about these type of records, and would load a zone despite "illegal chars", later versions of BIND would actually fail to start. This is a fundamental difference between BIND 9.4 and 9.7.3, for example. I am dealing with about 14 BIND servers so the more preparation steps I can take prior to cutover, the better.
> bind 9.4 has also "check-names response"; Ok, I'm reading up on that now. Should I be able to suppress the logging using: "check-names response ignore;" ? Thanks -----Original Message----- Date: Wed, 17 Apr 2013 17:58:30 +0200 From: Matus UHLAR - fantomas <uh...@fantomas.sk> To: bind-users@lists.isc.org Subject: Re: BIND 9.4.x and check-names Message-ID: <20130417155830.ga14...@fantomas.sk> Content-Type: text/plain; charset=us-ascii; format=flowed On 17.04.13 06:39, Ben-Eliezer, Tal (ITS) wrote: >Subject: BIND 9.4.x and check-names Isn't it time to upgrade? >I recently implemented a change in our DNS environment with the >intention of suppressing the log events related to AD-integrated >zones, and their Non-RFC compliant nature. > >check-names slave ignore; >check-names master ignore; bind 9.4 has also "check-names response"; >However, I still see these entries appear in the logs. Could someone >please chime in and let me know if my expectation or implementation >was incorrect? Many thanks!! > >default.log:12-Apr-2013 00:45:37.447 general: warning: zone >****************/IN: gc._msdcs.************/A: bad owner name >(check-names) >default.log:12-Apr-2013 00:45:37.447 general: warning: zone >****************/IN: gc._msdcs.************/A: bad owner name >(check-names) Hmm, aren't those supposed to be SRV records? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Windows found: (R)emove, (E)rase, (D)elete ------------------------------ Message: 2 Date: Wed, 17 Apr 2013 09:02:44 -0700 From: Chris Buxton <cli...@buxtonfamily.us> To: Matus UHLAR - fantomas <uh...@fantomas.sk> Cc: bind-users@lists.isc.org Subject: Re: BIND 9.4.x and check-names Message-ID: <9a8b8bf0-e675-4959-97ac-c9cf2007a...@buxtonfamily.us> Content-Type: text/plain; charset=us-ascii On Apr 17, 2013, at 8:58 AM, Matus UHLAR - fantomas wrote: > On 17.04.13 06:39, Ben-Eliezer, Tal (ITS) wrote: >> default.log:12-Apr-2013 00:45:37.447 general: warning: zone >> ****************/IN: gc._msdcs.************/A: bad owner name (check-names) >> default.log:12-Apr-2013 00:45:37.447 general: warning: zone >> ****************/IN: gc._msdcs.************/A: bad owner name (check-names) > > Hmm, aren't those supposed to be SRV records? No, they are the addresses of the global catalog servers. If they were SRV records, check-names would not complain. Chris Buxton ------------------------------ Message: 3 Date: Wed, 17 Apr 2013 12:07:07 -0400 From: Barry Margolin <bar...@alum.mit.edu> To: comp-protocols-dns-b...@isc.org Subject: Re: “Foreign” name in the reverse lookup zone Message-ID: <barmar-c85efa.12070717042...@news.eternal-september.org> In article <mailman.146.1366210213.20661.bind-us...@lists.isc.org>, PAVLOV Misha <misha.pav...@socgen.com> wrote: > Folks, > > Wonder if someone can kindly confirm that there is nothing wrong with having > a PTR record in one of the subnet zone file (we are authorative for) with PTR > to the name owned by another office (domain). A server > exchange.north.our.company (owned and registered in north.our.company domain) > installed here, on the same network as all local south.our.company machines. > We own, are authorative and maintain the db.1.2.3 subnet reverse zone, but > not the north.our.company name registered far away. There's nothing wrong with it, and it's done all the time. Consider the case where www.company.com server is hosted at a third party. The A record will be in the company's domain, but the PTR record will be in the hosting service's reverse domain. Just make sure that there is a corresponding A record. Some software will check for this before believing the PTR record. This is mostly done in software that uses reverse lookups in security checks; for instance, if a hosts.allow file allows access from *.company.com, it can't just believe the PTR record because anyone can put "<some-addr> PTR foo.company.com." in their reverse zone. -- Barry Margolin Arlington, MA ------------------------------ _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users End of bind-users Digest, Vol 1502, Issue 1 ******************************************* _______________________________________________ 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
