[SOLVED] Problem with recursive name server
Mike Hoskins
michoski at cisco.com
Sun Jun 10 17:54:18 UTC 2012
glad you got this resolved -- rfc2317 delegation usually always trips
folks up the first time around. it's almost always good to ask your isp
for the exact zone definitions they delegate so you can match things up.
your server is in fact responsible for the full subnet that was delegated
to you by your isp. "213.191.95.0/27" is a cidr subnet containing 32 (30
usable) addresses.
http://www.oav.net/mirrors/cidr.html
ipv4 provides 32-bit network addresses, 27 bits reserved for the network,
32-27=5, 2^5=32. :-)
-----Original Message-----
From: Mike Bobkiewicz <bind-list at commobil.de>
Date: Sunday, June 10, 2012 5:37 AM
To: <bind-users at lists.isc.org>
Subject: Re: [SOLVED] Problem with recursive name server
>Dear Mark,
>thanks for the help, now we are up and running. Because of some very bad
>things the Apple Admin Interface did to the PTR-file preventing it from
>being loaded AND not reporting this somewhere the times of OS X Server
>are over. But there is one last thing that puzzles me: to my
>understanding our nameserver is now master for the ip addresses
>213.191.95.0 - 27. Shouldn´t it be responsible for our complete subnet
>which is from 0-32? It´s no problem at this point because all the mail
>servers are in the lower region, but did we have to contact our isp about
>that?
>
>Best regards,
>
> Mike
>P.S. If you ever make it to Hamburg I owe you a beer...
>
>Mike
>
>Am 10.06.2012 um 06:58 schrieb Mark Andrews:
>
>>
>> In message <F98496E3-CA16-4C5C-8F04-18EE49D20FB7 at commobil.de>, Mike
>>Bobkiewicz
>> writes:
>>> HI all,
>>> first Eduardo:
>>> I did an upgrade with the mentioned package to 9.9.1 P1, it=B4s now up
>>>and =
>>> running but doesn=B4t fix the problem.
>>> I have to correct one thing: It=B4s not a 10.6 client system it=B4s a
>>>10.7.=
>>> 4 Server system, this is important because the client running this
>>>server d=
>>> oes configure bind with Apple=B4s Admin Tools. When something
>>>doesn=B4t wor=
>>> k he calls me and I log in via ssh and try to figure out what=B4s
>>>wrong. Te=
>>> lling the truth: I like vi very much...
>>>
>>> Am 08.06.2012 um 22:13 schrieb Chuck Swiger:
>>>
>>>> Hi--
>>>> =
>>>
>>>> On Jun 8, 2012, at 1:08 PM, Mike Bobkiewicz wrote:
>>>>> we are running an authorative name server for some domains. After
>>>>>some t=
>>> ime our ISP has now delegated the reverse name lookups to our server.
>>>We ar=
>>> e running bind 9.7.3 on Mac OS X 10.6 and are not able to bring the
>>>reverse=
>>> name lookups to life. The master db-file is loaded and we to set the
>>>allo=
>>> w-recursive { any; }; option in the named.conf but it still doesn=B4t
>>>work.=
>>> We are getting RFC 1912 2.1 with some mail servers which is the
>>>biggest pr=
>>> oblem. Which additional options must be set in the named.conf to make
>>>the r=
>>> everse name lookups for our domains work?
>>>> =
>>>
>>>> Mailservers doing a double-reverse lookup try to validate that your
>>>>IP ha=
>>> s a PTR record which returns a name that a normal forward lookup
>>>finds, and=
>>> gives back the original IP.
>>>> =
>>>
>>>> Give us an example of a bad hostname or IP, and we can probably tell
>>>>you =
>>> what aspect isn't working right...
>>>> =
>>>
>>> Sorry, was late last night for me so here are some parts of the
>>>configurati=
>>> on:
>>> /etc/named.conf
>>> include "/etc/rndc.key";
>>> options {
>>> directory "/var/named";
>>> listen-on-v6 port 53 {
>>> "none";
>>> };
>>> allow-recursion {
>>> any;
>>> };
>>> allow-transfer {
>>> none;
>>> };
>>> };
>>> controls {
>>> inet 127.0.0.1 port 54 allow {
>>> "any";
>>> } keys {
>>> "rndc-key";
>>> };
>>> };
>>> acl "com.apple.ServerAdmin.DNS.public" {
>>> any;
>>> };
>>> logging {
>>> channel _default_log {
>>> file "/Library/Logs/named.log";
>>> severity info;
>>> print-time yes;
>>> };
>>> category "default" {
>>> "_default_log";
>>> };
>>> };
>>> view "com.apple.ServerAdmin.DNS.public" {
>>> zone "0.0.127.in-addr.arpa" IN {
>>> type master;
>>> file "named.local";
>>> allow-update {
>>> none;
>>> };
>>> };
>>>
>>> ... around 15 working master zones
>>>
>>> zone "95.191.213.in-addr.arpa" IN {
>>> type master;
>>> file "db.95.191.213.in-addr.arpa";
>>> allow-transfer {
>>> com.apple.ServerAdmin.DNS.public;
>>> };
>>> allow-update {
>>> none;
>>> };
>>> };
>>> };
>>> };
>>
>> The ISP has delegated "0/27.95.191.213.in-addr.arpa" not
>> "95.191.213.in-addr.arpa" to you. You need to be serving
>> "0/27.95.191.213.in-addr.arpa".
>>
>> You should be slaving "95.191.213.in-addr.arpa" so that you have
>> the CNAME records available locally for when the external link is
>> down and have "0/27.95.191.213.in-addr.arpa" as a master.
>>
>> zone 95.191.213.in-addr.arpa {
>> type slave;
>> file "db.95.191.213.in-addr.arpa";
>> masters { 213.191.73.65; 213.191.74.20; };
>> };
>>
>> zone 0/27.95.191.213.in-addr.arpa {
>> type master;
>> file "db.0.95.191.213.in-addr.arpa";
>> };
>>
>>> The lines of question in the db-file:
>>> 10800 IN NS ns1.hektor.de.
>>> 10800 IN NS ns2.hansenet.de.
>>> 3.95.191.213.in-addr.arpa. 10800 IN PTR
>>>mailserver.hektor.d=
>>> e.
>>>
>>> The name of the server is ns1.hektor.de.
>>> Trying to send an email to a server trying to get the PTR record the
>>>sender=
>>> receives an "Undelivered Mail..." mail with this:
>>> 550 inconsistent or
>>> no DNS PTR record for 213.191.95.3 (see RFC 1912 2.1) (in reply to
>>>RCPT =
>>> TO
>>> command)
>>>
>>> Hope this helps to clear out the problem
>>>
>>> Best regards,
>>>
>>> Mike
>>> =
>>>
>>>> Regards,
>>>> -- =
>>>
>>>> -Chuck
>>>> =
>>>
>>>
>>> _______________________________________________
>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>>>unsubscri=
>>> be from this list
>>>
>>> bind-users mailing list
>>> bind-users at 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: marka at isc.org
>
>_______________________________________________
>Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>unsubscribe from this list
>
>bind-users mailing list
>bind-users at lists.isc.org
>https://lists.isc.org/mailman/listinfo/bind-users
More information about the bind-users
mailing list