[dns-operations] fewer PTRs plz (Re: reverse DNS for DHCPV6 andPD's)

[Bob Paolucci]

So let me add context as to why I brought this question up in the first
place.

We began rolling out native V6 to our customers via DHCPV6 (single
addrs) and Prefix delegations also assigned via DHCP.

In the V4 world, we would apply custom expressions to generate a
hostname for a particular device that would contain said devices mac
address (or a combo of CPE mac and CM mac), which would then be sent off
to a hidden primary DNS via DDNS update, and propagated out to
secondary's.  We always ensure we do both forward and reverse.

1.  The records in our forward zones are used for billing purposes.  (I
know there are better ways of doing this but don't want to get into
that)
2.  The records are also used by OSS type tools, where there is a
predictable DNS name for any given device, which a tool can use to do a
DNS query and look up the IP of the deivce before addressing it.

In the V6 world, for DHCPV6 (single addr), its quite easy, we do the
same sort of thing, generate a hostname based on device DUID and / or
MAC address (in the case of a cable modem), and send the update off to
DNS.

Where we struggle is, should we bother with reverse entries for DHCPV6?
We have carved up a /32 into /64's to provision on our DHCP servers for
single addr assignment, should we do the same in DNS for reverse?  Have
them defined as /64s?  Or should we aggregate back to /32's.  Either
way, we're talking about HUGE zones.  Im leaning towards /64's for now,
I know that the number of records per /64 will be sparse at best, at
least it will prevent us from having all reverse records for DHCPV6 in
one reverse zone such as if we defined reverse as a /32.

Where the bigger issue appears to be is with PD's.  Right now we are
assigning PD's to customers as /64's, soon to move to /56's.  We are not
doing anything right now for PD's in forward or reverse zones (they just
don't exist).   I guess we could assign a customer device a PD and allow
said device to send DNS updates, but in my mind that just seems beyond
crazy to trust anything in the CPE space.  Or we could delegate to said
CPE and allow it to respond if such a device supported this.  We've also
thought about the idea of using wild cards to give some sort of response
for a forward / reverse query for something in a PD, but I don't believe
that sort of feature exists with our current vendor.

Thoughts / Comments really appreciated :)

(Again apologies for any warning attached to this email)

-----Original Message-----
From: dns-operations-bounces at lists.dns-oarc.net
[mailto:dns-operations-bounces at lists.dns-oarc.net] On Behalf Of Paul
Vixie
Sent: June-13-11 1:34 AM
To: dns-operations at lists.dns-oarc.net
Subject: [dns-operations] fewer PTRs plz (Re: reverse DNS for DHCPV6
andPD's)

fw at deneb.enyo.de (Florian Weimer) writes:

>> IOW, the network operations community should work with the email 
>> server operations community on this.
>
> Why?
>
> If it's a mandatory protocol element, it presence does not carry any 
> information at all. 8-)

it wasn't mandatory until rick adams hacked ftp.uu.net to reject
connections from places that had no PTR.  that idea caught on, and then
some time later we got hundreds of millions of dsl/cable/mobile/etc
connected users, most of whom do not have useful PTR's
(201-41-169-85.ctaje701.dsl.brasiltelecom.net.br
is an example of what i mean by non-useful.)

i urge an end to autogenerated PTRs.  web servers won't care, e-mail
servers sometimes will, and nobody uses FTP much.  make a PTR part of a
"business
grade" service.   let the rest of us use the absence of a PTR as
evidence
that high valued services like reaching our tcp/25 server should not
work.

i say this knowing that a lot of folks are wondering what to do with
PTR's for IPv6, and i know we wrote RFC 2136 with this use in mind,
but... "don't."
just don't.  just leave the PTR space blank for consumer grade
connections.
--
Paul Vixie
KI6YSY
_______________________________________________
dns-operations mailing list
dns-operations at lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
-------------- next part --------------

This e-mail (and attachment(s)) is confidential, proprietary, may be subject to copyright and legal privilege and no related rights are waived. If you are not the intended recipient or its agent, any review, dissemination, distribution or copying of this e-mail or any of its content is strictly prohibited and may be unlawful. All messages may be monitored as permitted by applicable law and regulations and our policies to protect our business. E-mails are not secure and you are deemed to have accepted any risk if you communicate with us by e-mail. If received in error, please notify us immediately and delete the e-mail (and any attachments) from any computer or any storage medium without printing a copy.

Ce courriel (ainsi que ses pi?ces jointes) est confidentiel, exclusif, et peut faire l?objet de droit d?auteur et de privil?ge juridique; aucun droit connexe n?est exclu. Si vous n??tes pas le destinataire vis? ou son repr?sentant, toute ?tude, diffusion, transmission ou copie de ce courriel en tout ou en partie, est strictement interdite et peut ?tre ill?gale. Tous les messages peuvent ?tre surveill?s, selon les lois et r?glements applicables et les politiques de protection de notre entreprise. Les courriels ne sont pas s?curis?s et vous ?tes r?put?s avoir accept? tous les risques qui y sont li?s si vous choisissez de communiquer avec nous par ce moyen. Si vous avez re?u ce message par erreur, veuillez nous en aviser imm?diatement et supprimer ce courriel (ainsi que toutes ses pi?ces jointes) de tout ordinateur ou support de donn?es sans en imprimer une copie.