Search Again:

Re: Reverse DNS

From: Larry Scott Hastings
Date: Monday, February 21, 2005
Time: 10:37:27 am

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