BIND 9.4.x and check-names

Thu Apr 18 12:35:00 UTC 2013

>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 <uhlar at fantomas.sk>
To: bind-users at lists.isc.org
Subject: Re: BIND 9.4.x and check-names
Message-ID: <20130417155830.GA14058 at 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, uhlar at 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 <clists at buxtonfamily.us>
To: Matus UHLAR - fantomas <uhlar at fantomas.sk>
Cc: bind-users at lists.isc.org
Subject: Re: BIND 9.4.x and check-names
Message-ID: <9A8B8BF0-E675-4959-97AC-C9CF2007A01A at 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 <barmar at alum.mit.edu>
To: comp-protocols-dns-bind at isc.org
Subject: Re: “Foreign” name in the reverse lookup zone
Message-ID: <barmar-C85EFA.12070717042013 at news.eternal-september.org>

In article <mailman.146.1366210213.20661.bind-users at lists.isc.org>,
 PAVLOV Misha <Misha.Pavlov at 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 at lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

End of bind-users Digest, Vol 1502, Issue 1
*******************************************