PTR record handling in a subnetted network

[Bob Vance]

Thanks for the input, Mathias !
You raise some interesting points (although I might disagree :)


>Most of the advantages are those of easier understanding.
>No confusing new admins of the fwd zones with PTR records in there etc.

Hmm.
OK.  Then, maybe, no real *technical* reasons?  :)

I would say that the operative word here is "understanding".
Once there is real understanding then there should be no confusion.
Yes.  You might have to spend 5 extra minutes with a new admin
explaining how it works.  But, you're probably already explaining how
the other way works, anyway.  This admin will the be better for this
newfound knowledge :)

Of course, if you've left the company, you wouldn't have the luxury of
explaining it to him ;>)
So, be sure to leave the URL for this list !! (or documentation)


>No need to fiddle with a forward zone when reverse zones are modified
>(renumebering)

Well, now.  What's the difference between fiddling with a forward zone
as opposed to fiddling with a reverse zone?
If he is renumbering, then the end-user would have *two* zones to
change and reload, while with the PTR-in-forward-zone setup, he'd only
have one, plus the two records to change could be right next to each
other so the change would be clearer and easier to make.

It seems to me that it would be better for the body DNS to have fewer
delegations if possible.
But, maybe not.  Or maybe no advantage to it.
I certainly am not experienced enough to know.
I just throw ideas on the table -- others are free to swipe them into
the trash :)


>No need to remember to redelegate/change the CNAMES if the customer's
>fwd zone changes.

This seems closest to a valid technical reason.
If the customer *changed* his domain name, then, yes, the ISP would have
to make a change, whereas in the other way (reverse zone sub-zone), he
would not.
Of course, in any case, he'll only have a single $GENERATE to change.
However, this *would* require a reload of the zone and its attendant
propagation.

But, how often would this really occur for a customer to just change the
name of the domain?
   (Of course, you could argue,
    "Exactly!.  It's so rare, that it would be likely that the ISP
     admin would *forget* to make the change!
    "
   )  :)
If the customer were to leave for a new ISP, then the delegation of the
reverse sub-zone would have to change anyway.
Is that easier than just modifying a single $GENERATE ?


>It just keeps a clearer picture.

I guess we can agree to disagree on this point.
My mindset was that the fact that we're talking about a partial
delegation means that we're typically talking about only a few entries
and only for the external presentation of the domain.
I think it's clearer and simpler to have the single zone with the
PTRs and As side by side.
But others certainly might disagree.

However, as I think about it, I suppose that it could be an issue on the
inside as well, where non-octet subnetting might be going on.
Here it might be clearer to have the separate zones.


Thanks, again.

-------------------------------------------------
Tks        | <mailto:BVance at sbm.com>
BV         | <mailto:BobVance at alumni.caltech.edu>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430           11455 Lakefield Dr.
Fax 770-623-3429           Duluth, GA 30097-1511
=================================================





-----Original Message-----
From: Mathias Körber [mailto:mathias at koerber.org]
Sent: Tuesday, March 06, 2001 1:11 AM
To: bobvance at alumni.caltech.edu; bind-users at isc.org
Subject: RE: PTR record handling in a subnetted network


> All the discussions seem to focus on this delegation some sub-zone of
> z.y.x.in-addr.arpa. , rather than simply using CNAMEs into the
> already-existing forward zone.
>
> What I was saying is that the latter seems to me to be a better and
> simpler solution and no one has said differently or given any
drawbacks
> to this solution.  If the advantages are there and there aren't any
> drawbacks, then why isn't this solution promulgated more on this list?

Most of the advantages are those of easier understanding. No need to
fiddle with
a forward zone when reverse zones are modified (renumebering)
No need to remember to redelegate/change the CNAMES if the customer's
fwd zone changes.
No confusing new admins of the fwd zones with PTR records in there etc.
It just keeps a clearer picture.