Alright, I'm guessing everyone understood the PTR/A record issue, so I'll
just explain the reasons behind why I wrote what I did!
Say I run a Class C network block of 200.100.50.0 to 200.100.50.255, 0
and 255 reserved accordingly. I have Microsoft's DNS Server running with
several registered domains and the appropriate Reverse Zone of
50.100.200.IN-ADDR.ARPA that contains all of the PTR records in my block.
My upstream, UP-A, has my network block registered under their
administration, but their blocks (and mine as well) also reside within a
larger block provided by their upstream, UP-B. This is commonly the case
and looks just fine because, ultimately, UP-B is the highest backbone
provider so they, of course, own all of the network blocks they pass
down. The only Reverse DNS registration falls under UP-B (which you can
see via ARIN's whois), pointing all reverse query information for ALL of
their Class C and Class B and Class A networks to their (UP-B) NS's. Make
sense so far? You can register names for blocks and administrative
responsibility, but only one block under a any single registration can
hold reverse DNS records on ARIN.
NS-B is UP-B's primary name server, which points reverse DNS information
to NS-A, UP-A's primary name server, for all of the blocks passed to
UP-A. NS-A then passes reverse DNS information for MY block to NS-ME, my
primary name server. NS-A is also one of my secondary name servers, so it
is updated on every expiration (set through the primary, authoritative,
server). However, NS-A is not a secondary to NS-B, so it does NOT get
updated even though it controls all of the reverse information. This part
MUST be done by all three parties correctly and must be maintained, it is
not automatically accomplished. Below is a conservative explanation of a
query process from a user in San Diego, CA.:
RELIABILITY
---------------------------------------------
Request comes into ARIN (yes it does, no matter if you see it or not) to
resolve the IP 200.100.50.25 to a name, much like many mail servers will
do. ARIN, without notification, shuvs that request to NS-B because that
is who is listed for reverse DNS. NS-B then says, "Look, this is destined
for one of the blocks I have assigned to NS-A.", and sends it down to
NS-A for resolution. NS-A then says, "Look, this is destined for one of
the blocks I have assigned to NS-ME.", and sends it down my T1 link to my
name server, NS-ME. NS-ME finally resolves the IP to bad.way.com and
sends the response back to the user in San Diego. NS-B goes off-line for
an entire month, what happens? You lose all reverse resolution and so
does your upstream, over then entire IP Block assignments. Your customers
get angry because they cannot download some software from a company that
requires IP's to be resolved to names, if any. Your upstream's customers
get angry for the same reason, but on a larger scale because your
upstream has more customers! The lack of reverse DNS to UP-B customers
doesn't matter, because that will happen anyway. NS-B comes back on-line
and NS-A falls off-line, what happens? Reverse DNS to UP-B customers is
restored, but you and all of UP-A customers are still **** out of luck.=20
Even though you STILL rely on two other companies to supply your
internet link service, by housing routers and networks, you are relying
on them to also supply two other pieces of equipment, the name servers.
If anyone can tell me the point to relying on someone to supply a
"bridge", entirely unnecessary and resource consuming, is a good idea
then please do! I think most everyone understands that the more you have
to rely on that you *cannot* control, increases the risk factor.
CONVENIENCE
------------------------------------------
The scenario is inconvenient for the same reasons it is unreliable; you
cannot control what your upstream and their upstream does. Most of time
it is nearly impossible to get them to do anything because UP-B ends up
being a large telephone company that doesn't understand what they are
doing in the first place (that is not a stab). They can make changes
without telling you...after all, you are not UP-B's customer, you are
UP-A's customer. UP-B rarely gives a whoop about you, you are negligible
compared to a customer that buys five(5) OC3 links from them. They will
do as they please and they can. If you wish to change registration AND
IP's of your name servers, you have to notify ARIN and InterNIC, as well
as UP-A who then has to notify ARIN and InterNIC, as well as UP-B who
then has to notify ARIN and InterNIC. What a complete and unorganized
mess! How often does this go according to plan? I'm open to
stories...maybe it is different outside of the Mid-west and West-coast
areas where I have done this.
Make things simple, people. Simplicity always outperforms and is more
reliable than complexity (it's a proven theory); simplicity has no regard
to quality or form. If UP-B lets you register your own network block,
thus bypassing UP-B and UP-A, you can house all reverse DNS information
and can change it whenever the heck you feel like changing your
registration. Queries no longer hit NS-B and NS-A, it routes directly to
NS-ME by say, two consecutive Cisco 7513's. Also, if you happen to pass
that specific Class C off to one of YOUR customers, you give them
registration rights, eliminating your maintenance costs and personel and
responsibility to provide DNS (unless of course that is part of what you
do). If you need a couple names of a few other professionals to back this
up, I'll supply that information in response to a private request, but I
doubt they wish to be publicly accessible in this type of setting. If you
want specific scenarios, I can supply those as well. Registering of
blocks is PRECISELY why InterNIC and ARIN exist, USE THEM!
Regards,
Mitch Wagers
Network Operations Manager
OCS Software, Inc.
At 03:15 PM 3/17/98 -0500, you wrote:=20
>>>>
<excerpt><smaller>Actually, if you don't mind, I would appreciate a
lengthier explanation.
</smaller> =20
=20
<excerpt> <bold><fontfamily><param>Arial</param><smaller>-----Original
Message-----
From:
</smaller></fontfamily></bold><fontfamily><param>Arial</param><smaller>Mitch=
ell
B. Wagers <<<<mailto:mwagers@ocsnet.net>mwagers@ocsnet.net>
<bold>To: </bold><<mailto:ntisp@emerald.iea.com>ntisp@emerald.iea.com
<<<<mailto:ntisp@emerald.iea.com>ntisp@emerald.iea.com>
<bold>Date: </bold>Tuesday, March 17, 1998 2:17 PM
<bold>Subject: </bold>Re: Reverse DNS using Microsoft DNS
</smaller></fontfamily>If you don't have it create the PTR file when you
FIRST make the A record, it won't happen, you will have to do it
manually. If you delete an A record, it will not automatically delete the
PTR record. You do have the ZONES for the Reverse DNS, correct? You will
also need whoever handles your SWIP registration to point to your
servers, which should be a one-to-one, not a trickle-down syndrome most
providers use, see below:
-InterNIC/ARIN designates DNS to IP's
-Your upstream's upstream carries the Reverse Authority, pointed to your
upstream.
-Your upstream points Reverse Authotiry to you.
That is a trickle-down approach, very inconvenient and unreliable. I have
heard that "you can't register just one class C for reverse DNS." That is
incorrect, you can and it should be done, unless you carry more than a
class C all your own. They should be registered in the largest blocks
appropriate.
Sorry if I just confused anyone, I can write a longer explanation if need
be...
</excerpt></excerpt>