Search Again:

Re: Reverse DNS

From: Men & Mice Support
Date: Monday, February 21, 2005
Time: 2:47:51 pm

As already discussed in private, for the benefit of the audience...

You can use the also-notify statement inside either your options
statement block (/var/named/conf/options) or inside the zone
statement block for a particular zone
(/var/named/conf/zoneopt/zone.name.opt). The syntax is as follows:

also-notify { ip-addr; [...] };

In other words, between the { and the }, enter one or more IP
addresses, with a ; after each one.

Chris Buxton
Men & Mice - Making DNS Easy

At 12:37 PM -0600 2/21/05, Larry Scott Hastings wrote:
>Here's an update, with a question to follow:
>
>Turns out (once again) my ISP changed the servers used for zone
>transfers to servers different than those used as secondary servers
>(for resolution), and didn't tell anyone. I had restricted zone
>transfers to the secondary servers, so updates never made it to the
>secondary servers for resolution.
>
>I've updated my transfer restriction option on dns.hastings.com to
>"any". I'll lock it down to the new zone transfer servers, once I'm
>sure it's working.
>
>As I write this, the new zone transfer servers haven't picked up on
>changes to my reverse zone. I checked the log available in
>QuickDNS, and it shows that it notified the _secondary_ servers.
>That by itself does me no good, as those aren't the servers my ISP
>is using for zone transfers from the master server.
>
>I assume that eventually (based on TTLs), their servers will notice
>my master server's info has changed, do a zone transfer/update and
>update the info on the secondaries.
>
>In the meantime, is there a way in QuickDNS (4.0) to tell my server
>explicitly which server(s) to notify of a zone change? If not, is
>there a change in a conf file I can make?
>
>On Feb 19, 2005, at 10:12 AM, Men & Mice Support wrote:
>
>>At 1:42 PM -0600 2/18/05, Larry Scott Hastings wrote:
>>>Sorry for the delayed response.
>>>
>>>Thanks, Chris. Lots of helpful info there.
>>>
>>>In regard to restarting the name server: Yes I have restarted the
>>>server, same results.
>>>
>>>Although my server is the primary master server, I've not listed
>>>it in the zone files as one of the name servers. Could that be
>>>causing all or some of these problems (failing reverse lookups,
>>>incorrect SOA info on secondaries, possible corrupted cache)?
>>
>>No. That's a strategy called "hidden master". Perfectly normal.
>>
>>You should ask xspedius.net to fix their configuration so that
>>they're using your server as master instead of having their own
>>copy of the zone.
>>
>>Chris Buxton
>>Men & Mice - Making DNS Easy
>>
>>>On Feb 15, 2005, at 9:03 AM, Men & Mice Support wrote:
>>>
>>>>The difference in 'host' command output is caused by the fact
>>>>that I'm querying from the outside - my machine ends up finding
>>>>the delegation records and returning them as the answer. You're
>>>>querying your own server, which returns the authority records
>>>>from your reverse zone.
>>>>
>>>>Here's the output of a 'dig +trace' command:
>>>>
>>>>$ dig +trace ns 208.253.216.in-addr.arpa
>>>>
>>>>; <<>> DiG 9.3.0 <<>> +trace ns 208.253.216.in-addr.arpa
>>>>;; global options: printcmd
>>>>. 65795 IN NS G.ROOT-SERVERS.NET.
>>>>. 65795 IN NS H.ROOT-SERVERS.NET.
>>>>. 65795 IN NS I.ROOT-SERVERS.NET.
>>>>. 65795 IN NS J.ROOT-SERVERS.NET.
>>>>. 65795 IN NS K.ROOT-SERVERS.NET.
>>>>. 65795 IN NS L.ROOT-SERVERS.NET.
>>>>. 65795 IN NS M.ROOT-SERVERS.NET.
>>>>. 65795 IN NS A.ROOT-SERVERS.NET.
>>>>. 65795 IN NS B.ROOT-SERVERS.NET.
>>>>. 65795 IN NS C.ROOT-SERVERS.NET.
>>>>. 65795 IN NS D.ROOT-SERVERS.NET.
>>>>. 65795 IN NS E.ROOT-SERVERS.NET.
>>>>. 65795 IN NS F.ROOT-SERVERS.NET.
>>>>;; Received 244 bytes from 217.151.171.21#53(217.151.171.21) in 207 ms
>>>>
>>>>216.in-addr.arpa. 86400 IN NS chia.ARIN.NET.
>>>>216.in-addr.arpa. 86400 IN NS dill.ARIN.NET.
>>>>216.in-addr.arpa. 86400 IN NS BASIL.ARIN.NET.
>>>>216.in-addr.arpa. 86400 IN NS henna.ARIN.NET.
>>>>216.in-addr.arpa. 86400 IN NS indigo.ARIN.NET.
>>>>216.in-addr.arpa. 86400 IN NS epazote.ARIN.NET.
>>>>216.in-addr.arpa. 86400 IN NS figwort.ARIN.NET.
>>>>;; Received 193 bytes from 128.63.2.53#53(H.ROOT-SERVERS.NET) in 802 ms
>>>>
>>>>253.216.in-addr.arpa. 86400 IN NS dns1.xspedius.net.
>>>>253.216.in-addr.arpa. 86400 IN NS dns2.xspedius.net.
>>>>253.216.in-addr.arpa. 86400 IN NS dns3.xspedius.net.
>>>>;; Received 111 bytes from 192.35.51.32#53(dill.ARIN.NET) in 901 ms
>>>>
>>>>208.253.216.in-addr.arpa. 7200 IN NS dns1.xspedius.net.
>>>>208.253.216.in-addr.arpa. 7200 IN NS dns2.xspedius.net.
>>>>208.253.216.in-addr.arpa. 7200 IN NS dns3.xspedius.net.
>>>>;; Received 159 bytes from 207.191.50.10#53(dns1.xspedius.net) in 975 ms
>>>>
>>>>
>>>>After that, I went looking for a more detailed response:
>>>>
>>>>$ dig +norec soa 208.253.216.in-addr.arpa @dns1.xspedius.net
>>>>
>>>>; <<>> DiG 9.3.0 <<>> +norec soa 208.253.216.in-addr.arpa
>>>>@dns1.xspedius.net
>>>>;; global options: printcmd
>>>>;; Got answer:
>>>>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2936
>>>>;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
>>>>
>>>>;; QUESTION SECTION:
>>>>;208.253.216.in-addr.arpa. IN SOA
>>>>
>>>>;; ANSWER SECTION:
>>>>208.253.216.in-addr.arpa. 7200 IN SOA
>>>>dns1.xspedius.net. domain.xspedius.net. 2005010801 3600 1800
>>>>1209600 3600
>>>>
>>>>;; AUTHORITY SECTION:
>>>>208.253.216.in-addr.arpa. 7200 IN NS dns3.xspedius.net.
>>>>208.253.216.in-addr.arpa. 7200 IN NS dns1.xspedius.net.
>>>>208.253.216.in-addr.arpa. 7200 IN NS dns2.xspedius.net.
>>>>
>>>>;; ADDITIONAL SECTION:
>>>>dns1.xspedius.net. 7200 IN A 207.191.50.10
>>>>dns2.xspedius.net. 7200 IN A 207.191.1.10
>>>>dns3.xspedius.net. 7200 IN A 206.222.97.50
>>>>
>>>>;; Query time: 371 msec
>>>>;; SERVER: 207.191.50.10#53(dns1.xspedius.net)
>>>>;; WHEN: Tue Feb 15 06:52:50 2005
>>>>;; MSG SIZE rcvd: 202
>>>>
>>>>
>>>>Notice the SOA record's mname field (the name of the primary
>>>>master server). It doesn't show your server. Also notice that the
>>>>response is marked authoritative (flag aa). This tells me that
>>>>they're not acting as slaves for your copy of the zone - they
>>>>have their own copy of the zone, and they're ignoring your
>>>>version.
>>>>
>>>>Here's the same query, sent to your server:
>>>>
>>>>$ dig +norec soa 208.253.216.in-addr.arpa @dns.hastings.com
>>>>
>>>>; <<>> DiG 9.3.0 <<>> +norec soa 208.253.216.in-addr.arpa @dns.hastings.com
>>>>;; global options: printcmd
>>>>;; Got answer:
>>>>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60246
>>>>;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
>>>>
>>>>;; QUESTION SECTION:
>>>>;208.253.216.in-addr.arpa. IN SOA
>>>>
>>>>;; ANSWER SECTION:
>>>>208.253.216.in-addr.arpa. 86400 IN SOA dns.hastings.com.
>>>>scott.hastings.com. 2005021413 28800 7200 604800 86400
>>>>
>>>>;; AUTHORITY SECTION:
>>>>208.253.216.in-addr.arpa. 86400 IN NS dns1.xspedius.net.
>>>>208.253.216.in-addr.arpa. 86400 IN NS dns2.xspedius.net.
>>>>208.253.216.in-addr.arpa. 86400 IN NS dns3.xspedius.net.
>>>>
>>>>;; ADDITIONAL SECTION:
>>>>dns1.xspedius.net. 101458 IN A 207.191.50.10
>>>>dns2.xspedius.net. 100073 IN A 207.191.1.10
>>>>dns3.xspedius.net. 114930 IN A 206.222.97.50
>>>>
>>>>;; Query time: 387 msec
>>>>;; SERVER: 216.253.208.2#53(dns.hastings.com)
>>>>;; WHEN: Tue Feb 15 06:55:46 2005
>>>>;; MSG SIZE rcvd: 217
>>>>
>>>>
>>>>Given the fact that a query for a PTR record (to your server)
>>>>gets back an indication that the class B subnet reverse is
>>>>handled by the IANA blackhole servers, I'm guessing either your
>>>>server's cache is corrupted or some intervening agent has
>>>>corrupted cache records; the class B subnet reverse zone is quite
>>>>clearly delegated to xspedius.net (as shown in the trace above).
>>>>
>>>>Have you tried restarting the DNS service on your server?
>>>>
>>>>Chris Buxton
>>>>Men & Mice - Making DNS Easy
>>>>
>>>>At 3:13 PM -0600 2/14/05, Larry Scott Hastings wrote:
>>>>>OK, seems my ISP changed the names of their secondary servers on
>>>>>me. I updated those in my zone file for the reverse domain.
>>>>>
>>>>>I still have basically the same question/problem: A lookup for
>>>>>a PTR record for my mail server fails. I'm having trouble
>>>>>sending some emails as a result.
>>>>>
>>>>>The reverse zone is there. The PTR records are there. Why
>>>>>can't a reverse lookup find them? How do I fix this in QuickDNS?
>>>>>
>>>>>On Feb 14, 2005, at 12:51 PM, admin@gippy.net wrote:
>>>>>
>>>>>>On Mon, 14 Feb 2005 12:35:40 -0600
>>>>>> Larry Scott Hastings <lshastings@mac.com> wrote:
>>>>>>>From what I can see, the reverse zone _is_ delegated to us. I
>>>>>>>did the same host lookup as Chris, and I show my server and
>>>>>>>the secondaries. I also called my ISP and confirmed that I am
>>>>>>>primary for the reverse domain for our class C.
>>>>>>>
>>>>>>>> host -t ns 208.253.216.in-addr.arpa
>>>>>>>>208.253.216.in-addr.arpa name server ns2.espire.net.
>>>>>>>>208.253.216.in-addr.arpa name server ns3.espire.net.
>>>>>>>>208.253.216.in-addr.arpa name server dns.hastings.com.
>>>>>>>>208.253.216.in-addr.arpa name server ns1.espire.net.
>>>>>>
>>>>>>>>$ host -t ns 208.253.216.in-addr.arpa
>>>>>>>>208.253.216.in-addr.arpa name server dns2.xspedius.net.
>>>>>>>>208.253.216.in-addr.arpa name server dns3.xspedius.net.
>>>>>>>>208.253.216.in-addr.arpa name server dns1.xspedius.net.
>>>>>>
>>>>>>
>>>>>>I just did the same command above from my system:
>>>>>>
>>>>>>host -t ns 208.253.216.in-addr.arpa
>>>>>>208.253.216.in-addr.arpa name server dns3.xspedius.net.
>>>>>>208.253.216.in-addr.arpa name server dns1.xspedius.net.
>>>>>>208.253.216.in-addr.arpa name server dns2.xspedius.net.
>>>>>>
>>>>>>Same thing returned as what Chris got.
>>>>>>
>>>>>>Just as an FYI.
>>>>>>
>>>>>>Nevin Lyne
>>>>>>Gippy's Internet Solutions
>>>>>>http://www.gippy.net/
>>>>
>>>>
>>>>
>>>Thanks!
>>>--Scott Hastings lshastings@mac.com


Messages In This Thread:


Return to Digital Point Solutions' Home Page

home
products
services
support
email lists
optigold isp
optigold isp news
home inspection
inspectrix
java companion
oracle
quickdns pro
search engine
veterinary
tips
employees
free tools
portfolio
jobs
contact

Sales:
888/4-DPOINT

Support:
858/452-3696


Search:
Add this to your site