 |  |
At 3:28 PM -0600 2/23/05, Larry Scott Hastings wrote:
Re: Reverse DNS
From: Men & Mice Support
Date: Wednesday, February 23, 2005
Time: 3:50:29 pm
>The modified conf file solution worked great, and my reverse IP's
>are resolving just fine.
>
>First a quick question, then a summary of the final leg of this
>journey - with a twist at the end!
>
>My question: Now that I've modified my configuration file
>(/var/named/conf/options), what concerns should I have that changes
>to my configuration within QuickDNS will stomp on the modifications
>in the config file? There's a big, bold comment a the top of the
>config file warning against such modifications, to wit:
>
>//
>// This file was generated by QuickDNS from Men & Mice
>// WARNING: ** DO NOT EDIT **
>//
Right. Feel free to ignore that. Your changes will not be
overwritten. The same is true of all of the configuration files - as
long as what you change is a legal BIND statement, with a very few
exceptions, they will be preserved by QuickDNS when changes are made
to the file through QuickDNS. (The exceptions are all to do with new
BIND configuration options that have been added since the release of
version 4.6.1.)
In version 5, any syntactically-correct statement will be preserved
by our software, whether our software recognizes it or not.
>Now, here's what transpired... I modified the config file as
>suggested, adding the 4 servers that my ISP requires for zone
>transfers. I watched the log with satisfaction as the notifications
>went out, were accepted, and the zone transfers began. However, the
>reverse zone never transferred.
>
>I called my ISP, and asked why, and they while said they'd simply
>"delegated" the reverse lookups to me (dns.hastings.com) - it was my
>responsibility to provide secondary service. Basically, they were
>just sending all requests for reverse lookups within our class-C to
>dns.hastings.com. They weren't providing secondary service for
>reverse lookups. I said, "that's what I want -- I'm primary, and
>you're secondary - just like all my other domains!" She said they'd
>never done that before (!!!), and would have to get back to me.
>
>When she called back, things were clearer. They didn't delegate the
>reverse domain for the class-C to me; they never could. They own
>the class-C, and are the only ones who can provide authoritative
>responses for reverse lookups. They can refer lookups to me, but
>they can't be both authoritative and slaves for the same domain.
Yes they can. SBC does it all the time. They delegate a small
subnet's reverse records to a client, but they insist that their
servers must also act as slaves for the zone. They both delegate and
provide slave service, using the same two servers.
>Therefore they can't provide secondary service for my reverse lookup domain.
Yes they can. They either don't know how (it's very simple - just do
it!) or don't want to. I would guess it's the former.
Chris Buxton
Men & Mice - Making DNS Easy
>At this point, I had two options: 1) acquire my own secondary
>service providers (aside from my ISP), or 2) let them maintain the
>reverse domain themselves "As God Intended."
>
>I opted (for now) for #2.
>
>On Feb 21, 2005, at 4:46 PM, Men & Mice Support wrote:
>
>>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 |
888/4-DPOINTSupport:
858/452-3696