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

Sat Jun 25 04:13:39 UTC 2011

Good draft on this topic that's worth reading:
http://tools.ietf.org/html/draft-howard-isp-ip6rdns-04

Frank

-----Original Message-----
From: dns-operations-bounces at lists.dns-oarc.net
[mailto:dns-operations-bounces at lists.dns-oarc.net] On Behalf Of Bob Paolucci
Sent: Monday, June 13, 2011 9:41 AM
To: dns-operations at lists.dns-oarc.net
Subject: Re: [dns-operations] fewer PTRs plz (Re: reverse DNS for DHCPV6
andPD's)
Importance: High

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