Subject: Re: [DNSOP] Draft on rDNS for IPv6: draft-howard-isp-ip6rdns-00

From: Shane Kerr <[email-masked]>
Date: Tue, 01 Sep 2009 18:21:21 +0200

Mark,

On Tue, 2009-09-01 at 11:52 +1000, Mark Andrews wrote:
> If you deploy BCP 38 to the customer level TCP is a good enough
> authenticator for updating a reverse zone via UPDATE.

As I mentioned at the IETF, this is simply not true. All because I let
someone on my network doesn't mean I want them to be able to update the
DNS. It *might* be true.

> Since this is IPv6 give each customer their own address block and
> corresponding reverse zone.  You don't need a single big machine
> to do this.

Feel free to do that with networks you operate. This is a huge cost, if
you compare it to a zone file with a $RANGE statement, which is what we
have today.

Perhaps it makes sense to have two documents:

     1. A document which says "you won't be able to pre-populate in IPv6
        reverse like you do in IPv4 - don't worry about it".
     2. A document which says "if you want to provide IPv6 reverse for
        some reason, here are a plethora of ways to do it".

Which is basically Doug's document, split into two. I think having two
makes sense, because otherwise we are confounding the pre-populating
issue with the issue of how to provide reverse in the brave, new IPv6
world.

--
Shane

---

From: Doug Barton <[email-masked]>
Date: Tue, 01 Sep 2009 10:34:56 -0700

> issue with the issue of how to provide reverse in the brave, new IPv6

FYI, it's not my document, I was simply bringing it to the attention
of those who (like me) were not at IETF75.

That said I think that your idea of splitting into 2 topics is a good
idea. I personally would also like to see less "political" commentary
on the value of rDNS.

Doug

---

From: Doug Barton <[email-masked]>
Date: Tue, 01 Sep 2009 11:03:45 -0700

Mark Andrews wrote:
> In message <[email-masked]>, Doug Barton writes:
>> Mark Andrews wrote:
>>
>>> This was on the adgena for DNSOP at the last IETF 75.  There was
>>> much discussion. 
>> Sorry if I'm rehashing this unnecessarily. I did (an admittedly
>> cursory) search of my list archive and didn't see anything similar.
>>
>>> Not all of use agree with the analysis in that
>>> document though I think there was consensus that ISP's shouldn't
>>> need to per-populate reverse IPv6 zones.
>> Yeah, that more or less sums up my feelings as well, although ....
>>
>> I did read recently about the idea of using DLZ for this. Any
>> reasonably sized relational database ought to be able to handle the
>> load here. I plan to look at scripting something for this purpose as
>> soon as I get the requisite number of round 'tuits.
>>
>> Doug
> 
> You don't need a database.  The number of machines involved doesn't
> magically explode so you don't magically need lots more PTR records.
> Typical households have a handful of machines.  All that's really
> needed is a agreed method to populate the reverse name space.

I was actually thinking along the lines of "what would it take to
actually populate a reverse zone of size /N?" where N would take
various flavors like 64, 60, 56, etc. as an interesting experiment. I
am not suggesting that anyone would actually use something like this
in production, although I suppose that there are people who are
$ADJECTIVE enough to do it. :)

> authenticator for updating a reverse zone via UPDATE.

True. I guess I'll have to polish up my GSS fu.

> If you don't do BCP 38 to the customer level, e.g. there is shared
> media involved that allows spoofing to occur for customers on that
> media, then TSIG will work and is scaleable at the ISP level for
> UPDATE.

I seriously doubt that anyone who is not got their defecation
consolidated sufficiently to do BCP 38 is really going to care enough
about rDNS to set up TSIG, but that's just me. :)

Doug

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Tue, 1 Sep 2009 12:14:09 -0600

> various flavors like 64, 60, 56, etc. as an interesting experiment.

Doug,
You will need 4 billion disks with a capacity of 400 Gig each just to
get 100 bytes for each PTR in a /64.

/Stephan

----------------------------------------------------------------------
Stephan Lagerholm
Senior DNS Architect
Secure64 Software Corporation
Cell: 469-834-3940

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Doug Barton
Sent: Tuesday, September 01, 2009 1:04 PM
To: Mark Andrews
Cc: dnsop
Subject: Re: [DNSOP] Draft on rDNS for IPv6: draft-howard-isp-ip6rdns-00

Doug
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Douglas Otis <[email-masked]>
Date: Tue, 01 Sep 2009 11:18:18 -0700

> idea. I personally would also like to see less "political" commentary

This issue is largely about email acceptance policies.

Saying IPv6 reverse DNS is not considered a practical means to determine 
legitimate IP address use needs to be either stated or refuted.  DNS 
timeouts already consume a large portion of MTA resources when 
attempting to discover reverse DNS entries.  When IPv6 forces use of 
positive reputations, reverse DNS entries become superfluous.  Negative 
reputations within the IPv6 address space also seems impractical, 
largely due to the scale of the space involved.

-Doug

---

From: Doug Barton <[email-masked]>
Date: Tue, 01 Sep 2009 11:55:27 -0700

Douglas Otis wrote:

> legitimate IP address use needs to be either stated or refuted. 

Well, the draft seems focused on the idea of rDNS for ISPs who hand
out addresses to customers (this is another area where the draft could
use more focus and/or specification).

That said, I don't think the issues with rDNS for _infrastructure_
hosts such as mail servers, name servers, etc. are any different than
that in IPv4. Adding these records should not be difficult, and is a
reasonable expectation.

The relative value of these records as a form of authentication for
things like mail remains a hotly contested topic in IPv4, and I don't
see that getting any better in IPv6. My personal feeling (which I
state in the interest of full disclosure, not to persuade anyone) is
that yes, rDNS is useful in these circumstances.

> DNS timeouts already consume a large portion of MTA resources when
> attempting to discover reverse DNS entries. 

Yep, that's part of the cost of doing business. I used to maintain the
resolvers for the Yahoo! Mail product, so I know whereof I speak. :)

> When IPv6 forces use of
> positive reputations, reverse DNS entries become superfluous. 

I'm sorry, I have no idea what this is supposed to mean. Could you
elaborate?

> Negative

Are you saying that it's not going to be possible to keep track of bad
actors in IPv6?

Doug

---

From: Doug Barton <[email-masked]>
Date: Tue, 01 Sep 2009 11:57:11 -0700

> get 100 bytes for each PTR in a /64.

Thanks, I'll put in the requisition right away! :)

Doug

---

From: [email-masked]
Date: Wed, 02 Sep 2009 04:05:44 +0900 (JST)

> From: Mark Andrews <[email-masked]>
>    4.4) draft-howard-isp-ip6rdns-00.txt
> 	[Alain Durand][15 min][10:30]

At the IETF meeting, I had comments, but could not comment about this topic.

Same topic was discussed in Japanese comunity this March
and then, I  implemented prototype "On the Fly" DNS server.

  http://member.wide.ad.jp/~fujiwara/v6rev.html

This program works well. (performance problem may be solved by writing
new code by C language.)

This document says: 
> 3.4.  Dynamically Generate PTR When Queried ("On the Fly") 
> ...
> This method may not scale well in conjunction with DNSsec [RFC4035],
> ...
> this method is not recommended.

Now, I'm testing "On the Fly" generation of PTR and AAAA RRs and "On
the Fly" signing using perl + Net::DNS::SEC.

Please test 2001:200:132:6::/64 reverse zone. For example,
% dig @v6rev.dnslab.jp -x 2001:200:132:6::1111 +dnssec
% dig @v6rev.dnslab.jp 20010200013200060000000000001111.user.dnslab.jp. aaaa +dnssec

# I didn't implement non-existing case yet, but it can be implemented.
# I have an idea, but no time.

Performance problem will be solved by better code and new hardware.

In my opinion, "Dynamically Generate PTR When Queried" works well.

Regards,

--
Kazunori Fujiwara, JPRS <[email-masked]>

---

From: Edward Lewis <[email-masked]>
Date: Tue, 1 Sep 2009 16:35:26 -0400

>In my opinion, "Dynamically Generate PTR When Queried" works well.

I have to ask based on the experience I had with wildcards, how does 
this work with:

1) Zone transfers?

2) Dynamic update?

3) DNSSEC?

I think such synthesis is the way to go.  The problem is usually 
keeping a constellation of servers synchronized with respect to the 
synthesis rules, keeping up with changes, and signing the data.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 01 Sep 2009 14:28:57 -0700

On 9/1/09 11:55 AM, Doug Barton wrote:
>>> When IPv6 forces use of positive reputations, reverse DNS
>>> entries become superfluous.
>

We offer an email abuse tracking service that lists IPv4 addresses.
Defending this service requires an archival of evidence against listed
addresses.  Growth of abusive sources steadily continues.  Over the past
6 months, there has been more than a doubling of unique IP addresses
detected at emitting abuse.  Daily transitioning of abusive sources now
occurs in groups exceeding 5 million, out of 200 million longer term.
It is hard to believe that there are also about 200K of continuously
abusive sources as well.

Our listing and archival service has already been structured to handle
IPv6, however the growth of publishing and archival resources represents
an exponentially spiraling cost.  Due to the exponentially increasing
costs and resource consumption, negative reputations will cease being
practical in the near future.  Perhaps in one or two years.  Basing
email acceptance of IPv6 clients upon a lack of negative reputations
would further accelerate these costs.

A positive, rather than a negative listing, is likely the only method
that can accommodate continued growth of abusive sources and still
include IPv6 addresses.  The publishing billions of abusive sources can
be replaced by publishing millions of legitimate MTA IP addresses
instead.  With an external affirmation of an IP address as specifically
representing a legitimate MTA, the benefit of checking nebulous reverse
DNS records diminishes sharply, especially when this check otherwise
consumes rapidly diminishing MTA resources.

>>> Negative reputations within the IPv6 address space also seems
>>> impractical, largely due to the scale of the space involved.
>
> Are you saying that it's not going to be possible to keep track of
> bad actors in IPv6?

Anything is possible, but not everything is practical.  Keeping track of
good actors can endure exponential growth of bad actors _and_ permit
inclusion of IPv6 .

-Doug

---

From: bert hubert <[email-masked]>
Date: Wed, 2 Sep 2009 00:18:33 +0200

On Tue, Sep 1, 2009 at 10:35 PM, Edward Lewis<[email-masked]> wrote:
> I have to ask based on the experience I had with wildcards, how does this
> work with:

It works very well. One large country's incumbent telco has all of its
subscribers behind a scripted powerdns server synthesising PTRs, and
with exception of the large hardware cost savings (these were gigabyte
size zones), nobody noticed.

> 2) Dynamic update?

1 & 2 typically don't happen in such cases.

> 3) DNSSEC?

This will pretty much break, unless you also teach the system how to
synthesise NSEC(3).

   Bert

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Sep 2009 11:36:02 +1000

> you compare it to a zone file with a $RANGE statement, which is what we

How is it a huge cost?  Please tell me.  Most of the zones would
have 100 max records in them to cover a /56.  You mean ISP's can't
support a 100 records / customer?  You could have a policy which
says if you go over 150 records you need to run your own servers
which we will delegate to and we will warn you once you reach 100.

Traditional zones have a reasonably large over head in named.  DLZ
based one have a much lower overhead but it doesn't currently support
UPDATE.  There is no reason why it or something like it couldn't
support UPDATE.

Again where is the huge cost.  These are not pre-populated zones.
They get populated by the end user equipment.  Windows already does
this by default.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Shane Kerr <[email-masked]>
Date: Wed, 02 Sep 2009 09:14:33 +0200

Mark,

> which we will delegate to and we will warn you once you reach 100.

<snip/>

> They get populated by the end user equipment.  Windows already does

The cost is, as always:

     1. Building the system to handle this new service
     2. Maintaining the system for this service
     3. Customer support costs (training support staff, handling
        customer questions and problems, and so on)

Today the cost for all of these is effectively 0, because ISPs have to
run DNS anyway, and your entire functionality is that I see
"s5590c001.adsl.wanadoo.nl" when I ping my IP address. Adding a single
line to a zone file for each customer block to support this is extremely
cheap.

Note that I said the cost is huge COMPARED to current practice. While
the cost of putting together your magic DNS system may only be a few
hundred dollars of time, this is still a lot of money compared to 0.
(And likely the minimum cost would be thousands of dollars of time, even
for small ISPs - the ones who can afford to spend it the least.)

Again, nobody is arguing to deprecate reverse DNS for IPv6 here. Instead
the idea is that it should be clear that since current BCP for IPv4
reverse doesn't work, please don't worry about it for IPv6.

--
Shane

---

From: Ted Lemon <[email-masked]>
Date: Wed, 2 Sep 2009 08:05:20 -0400

The frustrating thing about this discussion is that Shane is right.  
Personally I think rdns is useful, but there is no market pressure to  
do it right, and doing it wrong isn't that useful.

Fundamentally the problem is that the ISP owns the rdns delegation,  
and they have no reason to set up a system that few of their customers  
will even be able to use.   I'm not confident this problem is fixable,  
but if it is, that is where the trouble lies, and that is what  
probably has to be fixed.

---

From: Shane Kerr <[email-masked]>
Date: Wed, 02 Sep 2009 14:36:27 +0200

Ted,

> do it right, and doing it wrong isn't that useful.

I think the idea of IP address to name mapping is useful.

> probably has to be fixed. 

When I talk to network engineers they love the idea that the reverse DNS
is not in the hands of the end user. In fact, they consider it an
affront when I propose moving the address-to-name mapping out of the DNS
(which they control) into something closer to the user (which they do
not).

I vaguely recall someone proposing a simple protocol where you ask a
host for it's name. I am very fond of this idea. In IPv6, you could even
secure it if CGA were used. 

It is another way to do the same thing - and DNS has properties you
could not duplicate (no caching, no chain of trust, it depends on host
reachability, and so on). From that point of view, it is bad. But it
would accomplish the main uses of reverse DNS (traceroute, ping, and
"who"), with a very small fraction of the infrastructural cost.

Does it make sense to pursue such a protocol? If so, where would this
work best be done?

--
Shane

---

From: Edward Lewis <[email-masked]>
Date: Wed, 2 Sep 2009 09:03:12 -0400

>This will pretty much break, unless you also teach the system how to

"It works very well"? - From your response it sounds like it 
*doesn't* work with the things I mentioned.  This is a good idea, a 
good start.  It just needs further development.

Without zone transfers, this approach lacks interoperability.  The 
master and slaves have to be the same make.  Sure, you can achieve 
all this with one implementation that shares a database backend - but 
the DNS protocol doesn't have a standard way to plug in any database 
to any name server.

Without dynamic update this approach is limited functionality in an 
enterprise network.  Dynamic update has a much higher profile in 
operations than is discussed in the protocol fora.  Serving static 
data is easy and DNS scales real well doing that, but no so much when 
it comes to changing data.  Just about all the current hiccups I see 
relate to incremental edits to zones.

And without DNSSEC, we don't have security for the answers and more 
importantly makes me wonder if this new mechanism will grow with the 
protocol.  An aspect of DNSSEC development is that in just going 
through the motions we uncovered a lot of errors in the protocol and 
common implementations.  Whenever I hear of an extension that does 
not meld well with DNSSEC, I get concerned, wondering if the change 
is a good architectural road to take.

I think there is a latent need to extend the DNS protocol to include 
an answer synthesis mechanism that is more flexible than RFC 4592. 
It's easy to come up with partial solutions, we need one that has all 
the features or the current protocol.

---

From: "Jeremy C. Reed" <[email-masked]>
Date: Wed, 2 Sep 2009 09:01:03 -0500 (CDT)

> the Fly" signing using perl + Net::DNS::SEC.

I notice it creates a new signature for same look up everytime. So the 
inception and expiration is increased immediately. Would it make sense to 
possibly attempt to cache these generated signatures for the most 
frequent requests? Or is it better to just have a caching server in front 
of the "On the Fly" DNS server? Or just rely on others to cache (since we 
assume that won't hit the authoritative again for same query).

Also any benchmarks on how fast it can sign on the fly?

It would be great if you can make the newer script available too (the one 
using Net::DNS::SEC).

Thanks

---

From: [email-masked]
Date: Thu, 03 Sep 2009 02:13:31 +0900 (JST)

>From: "Jeremy C. Reed" <[email-masked]>
> inception and expiration is increased immediately.

It creates a new signature for every query.

> Would it make sense to 
> frequent requests?

Many resolvers don't send the same query while the RRSet is in their
cache. The RRSet can be validated in each server.

Each resolver may have same PTR and different signature.
What problem exist?

> Or is it better to just have a caching server in front of the "On
> the Fly" DNS server?

This approach is one solution of performance problem.

> Or just rely on others to cache (since we 

I tested using queryperf with existing name and type,
using 1024bit RSASHA1 ZSK (which is generated by dnssec-keygen),
When DO=0, about 541 queries/sec
When DO=1, about 193 queries/sec

I run it on Xeon 2.8GHz, FreeBSD 7.2 box.

> It would be great if you can make the newer script available too (the one 

I put the script on my page as is.

  http://member.wide.ad.jp/~fujiwara/v6rsec-dnslab.pl

I run it as 2001:200:132:6::/64 reverse mapping DNS server.

It is very limited prototype. It does not have many necessary functions.
It does not have non-existing case (generating NSEC).
It copies OPT RR (doesn't check EDNS0 buffer length, I think).

# NSEC may be generated because next owner name is next IPv6 address
# and type bitmap have PTR only.

Regards,

---

From: [email-masked]
Date: Thu, 03 Sep 2009 02:34:25 +0900 (JST)

> From: Edward Lewis <[email-masked]>

Zone transfer is not required, not defined on my idea.

If I need multiple servers, I run same program with same DNSSEC key
file on each server.

Each server generates same PTRs and different RRSIG (different
Signature Inception, Signature Expiration).

> 2) Dynamic update?

Generated hostname is fixed for each IPv6 address on my idea.
All IPv6 address have reverse mapped hostname.
Dynamic update is not used.

> 3) DNSSEC?

NSEC may be generated because next owner name is next IPv6 address and
type bitmap have PTR only.

Then, if the server has private keys, then RRSIG is easily generated.

Problems are ...
 - No good code  (writing better code solves this problem.)
 - Performance   (better code and new hardware solve this problem.)
 - Private keys are shared on each authoritative server.

---

From: bert hubert <[email-masked]>
Date: Wed, 2 Sep 2009 22:17:14 +0200

>> size zones), nobody noticed.
(...)
> "It works very well"? - From your response it sounds like it *doesn't* work
> with the things I mentioned.  This is a good idea, a good start.  It just
> needs further development.

DNS can be seen as two things - one is about actual zones, and
distributing them over AXFR, and supporting things like dynamic
updates etc.

The other DNS is about answering questions in a valid way, without
being interested in the backend, since it is out of sight.

In this second sense, scripting answers works very well, and powers
autogenerated PTR records, but also interesting forms of
(geographical) load balancing.

So for most people, it really works very well - even if there is no
zone that can be transferred, or updated using dynamic updates.

> and slaves have to be the same make.  Sure, you can achieve all this with
> one implementation that shares a database backend - but the DNS protocol
> doesn't have a standard way to plug in any database to any name server.

The protocol may not, but several implementations do.

> I think there is a latent need to extend the DNS protocol to include an
> answer synthesis mechanism that is more flexible than RFC 4592. It's easy to
> come up with partial solutions, we need one that has all the features or the
> current protocol.

Dunno - I don't hear any users clamoring for it. They typically think
of DNS in the second sense.

   Bert

---

From: Edward Lewis <[email-masked]>
Date: Wed, 2 Sep 2009 17:19:30 -0400

>zone that can be transferred, or updated using dynamic updates.

If "you can think of DNS as strictly a query-response protocol on 
port 53" and discard the the notions of zones, name server 
synchronization, etc., you can get a solution that works over the 
short haul or in a confined environment.  But if you count on this 
for a long-range strategy, you will suffer for your myopia.

Answering from a script/algorithm and not a zone-file or 
zone-in-a-data-structure is fine.  But if you ignore the other 
elements of the DNS protocol, the solution is not long for the world. 
The reason is that is much more expensive to operate "oddball" 
devices than to stick with compliant devices.  Staff retire, go on 
vacation, etc.  We can't have warts, or many of them, in a data 
center.

The WG sputters so much about middleboxes, proxies, etc. that 
implement a curbed version of DNS and cry that they are the root of 
many ills (UDP fragmentation, capping port 53 traffic to 512 bytes). 
Then we turn around and say it's okay to put a hobbled DNS on port 53.

>of DNS in the second sense.

Of course you don't.  You hear users clamoring for populating a IPv6 
reverse map zone - they don't say how because they expect the DNS 
implementations to take care, provide a quality solution.  If you do 
a disposable solution, fine, you'll have a quick solution.  But it 
won't last.

There's no reason we can't derive a generalized synthesis 
(generalized with respect to RFC 4592) if one would be beneficial to 
the protocol.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Mark Andrews <[email-masked]>
Date: Thu, 03 Sep 2009 07:36:06 +1000

> (which they control) into something closer to the user (which they do

Which is clearly NOT what was intended when IN-ADDR.ARPA was designed.

IANA pass naming rights to the RIRs when they lease address blocks.
RIRs pass naming rights to the ISPs when they lease address blocks.
ISPs often pass naming rights to the customers when they lease
address blocks.  It's just residential customers they don't usually
do it too.

The reason it wasn't done in IPv4 was that the address blocks where
not stable to residential customers.  With IPv6 the address blocks
should be stable to ALL customers.
 
ISPs should stop giving residential customers the finger.  This is not
hard to do.

---

From: David Conrad <[email-masked]>
Date: Wed, 2 Sep 2009 21:07:33 -0400

On Sep 2, 2009, at 5:36 PM, Mark Andrews wrote:
> With IPv6 the address blocks should be stable to ALL customers.

Buy stock in memory manufacturers for routing vendors.

Sorry, wrong list.

Regards,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Thu, 03 Sep 2009 12:11:29 +1000

In message <[email-masked]>, David Conrad
> Buy stock in memory manufacturers for routing vendors.

People don't move house very often.  A new address block when
changing house is reasonable.  People accept land line numbers
changing when they move house or pay monthly to have the number
redirected.  I fail to see how this will cause the route explosion
you seem to be worried about.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 03 Sep 2009 12:27:07 +1000

> you seem to be worried about.

ISP's don't split POPs very often either.

Residential cable and ADSL are essentially static today unless the
ISP goes out of its way to make the address change.  I see no reason
why IPv6 won't be the same in this respect.  The difference between
residential and commercial is one is guaranteed static and the other
isn't.  Address changes are co-orinated if they have to occur with
one and unannounced with the other.

---

From: "Lee Howard" <[email-masked]>
Date: Thu, 3 Sep 2009 11:58:07 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mark
> Andrews
> Sent: Monday, August 31, 2009 9:53 PM
> To: Doug Barton
> Cc: dnsop
> Windows already attempts to do UPDATE. It just does it over UDP.
> Switching to TCP for the UPDATE message should be trivial.

I guess that's for them to decide, but certainly the protocols are there.
I think I said that in the draft, too.

> corresponding reverse zone.  You don't need a single big machine

Would you delegate the reverse zone to CPE, or support updates on
your servers?	Hm, need to filter at the edge, make sure customer's
don't update each other's records.  Some rate limiting, maybe.
Is a matching forward zone required, too?
Education needed:  how do you tell a residential user what server
will accept their dynamic PTR updates?  

Lee

---

From: Edward Lewis <[email-masked]>
Date: Thu, 3 Sep 2009 12:06:40 -0400

At 11:49 -0400 9/3/09, Lee Howard wrote:
>>  From: [email-masked] ... On Behalf Of Edward Lewis

>>  1) Zone transfers?
>
>Is this a requirement for IP6.ARPA zones used for residential users?

Kind of.

To achieve a sufficient number "9's" of availabilty (that is "99.9" 
or "99.999") more than one source of data is needed.  That is, you 
could have just one server for an IPv6 range but then it is a single 
point of failure.  Most DNS zones are on at least 2 servers - deep in 
the tree.  The root zone is on 100's (13 visible at any one place at 
a a time), TLDs usually about a half-dozen (visible plus anycast).

If there is no zone transfer, an admin would have to manually get the 
multiple sources to be in sync some other way.  The admin could use 
things like RSYNC, but that means that the constellation is running 
in a "special mode" and if the admin is on vacation it might be hard 
to fix.

It's safest to always have zone transfer defined for any DNS 
extension as this is the only means to provide interoperability and 
"in-band" maintenance of the system.

Kind of - in the sense that it is a really good idea and is strongly 
encouraged.

>>  2) Dynamic update?
>
>Mutually exclusive per zone.  For any given zone, you can either generate
>on the fly, or support dynamic updates.  If you want both, you'll have to
>number them out of different scopes, which may not be as bad as it sounds.

This is a question more based on things like Active Directory.  This 
is not so vital, but given that "incrementalism" is growing in 
importance it would be a desired feature.  In this case, I'd like to 
be able to add new synthesis rules on the fly (as opposed to DHCP 
lease information).

>I'd like to see more on this topic.

Me too.  I don't mean to shoot down what Fujiwara-san has suggested. 
I am shooting down the notion that "what we have now is good enough." 
Perhaps this is the next major incremental addition to the DNS 
protocol - a more general synthesis mechanism.  (I envision something 
involving NAPTR...it has the seeds we need.)

---

From: "Lee Howard" <[email-masked]>
Date: Thu, 3 Sep 2009 12:07:42 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Douglas
> Otis
> Sent: Tuesday, September 01, 2009 2:18 PM
> To: Doug Barton
> Cc: dnsop; Shane Kerr

It would probably devolve into a debate of "legitimate."  
Maybe we could try the reverse:  "IPv6 is a practical means to determine
useful information."  What useful information is expected?   I'm trying 
to describe the best current practice. 

> DNS

I agree.  Is there documentable consensus on that point?

Lee

---

From: Ted Lemon <[email-masked]>
Date: Thu, 3 Sep 2009 13:05:23 -0400

> will accept their dynamic PTR updates?

I think this is an unnecessarily difficult answer.   Maintaining the  
zones at the ISP is a recipe for DoS attacks, bad configuration, angry  
phone calls from end users, and, frankly, ISPs simply not doing it  
because it's too hard.   The problem of authenticating the DNS updates  
is another dozen miles of bad road on top of that.   It's better to  
delegate to the customer, and it's not that hard to do.

Residential gateways are, in practice, almost always configured using  
DHCP.   For DHCPv6 prefix delegation, it would be a fairly simple  
matter to set up a DNS delegation for the zone containing PTR records  
for that prefix.   The delegation could be to an IP address designated  
by the residential gateway, which would typically be its own IP  
address.   The residential gateway could also present DNSSEC  
information in its DHCP messages for insertion into the parent zone if  
that was considered valuable.

This sounds like a security problem, but it's not: if the residential  
gateway is getting its configuration through the DHCP server, then it  
is permitted both to use the delegated prefix and to control the zone  
documenting the contents of that prefix.   As long as the DHCPv6  
transaction is acceptably secure, so is the zone delegation.

There is existing technology for populating PTR records via DHCP, and  
this would work for the next-hop address to the prefix - the outward  
facing IP address of the home gateway, which would be allocated via  
DHCPv6.   AFAIK this functionality already works on several commercial  
and at least one open source DHCP implementation, and support in  
DHCPv4 clients is widespread, so it's not unreasonable to think that  
DHCPv6 clients would have support for it as well.   I haven't checked  
the Microsoft client, but I'd be surprised if it didn't do this.

Following this plan, end users who care about the reverse tree will  
spend the extra money to run gateways that support the delegation; end  
users who do not would have no reverse DNS.   This seems like a  
winning solution to me, since the incentives and effort are all placed  
on the interested parties.   There would be some minimal effort  
required by the ISP to set this up, but it really would be pretty  
minimal - for instance, it's a lot easier to get right than the  
routing for prefix delegation.

Of course, this solution doesn't work for ISPs that use static  
allocation, but they've bought a whole manual process anyway, so the  
additional expense for them of doing this is minimal, and existing  
ISPs that allocate IP addresses this way (e.g., Speakeasy in the U.S.)  
in practice support maintaining the DNS this way anyway - the big  
change here would be that rather than maintaining the customer's  
reverse tree for them, they'd be able to delegate it.

For ISPs that do neither manual allocation nor DHCPv6, implementation  
is problematic, but I don't know of any.   I'd be curious to know if  
anybody is aware of any alternativees for doing this that would work  
in practice.

---

From: "Lee Howard" <[email-masked]>
Date: Thu, 3 Sep 2009 11:49:55 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Edward
> Lewis
> Sent: Tuesday, September 01, 2009 4:35 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [DNSOP] Dynamically Generated PTR, was Re: ... rDNS for IPv6...
> 

 

Lee

> that they're not getting traction.

We're running out of swamp.  When we get to the edge, the tractors will
move with increasing speed.

---

From: David Conrad <[email-masked]>
Date: Thu, 3 Sep 2009 16:00:05 -0400

Mark,

On Sep 2, 2009, at 10:27 PM, Mark Andrews wrote:
> People don't move house very often.
...
> ISP's don't split POPs very often either.

Regardless of whether these assertions are true or relevant, the  
statement that "the address blocks should be stable to ALL customers"  
is pretty much the definition of end user assignment of provider  
independent addresses.

However, this really is the wrong list to discuss this.  Apologies for  
the outburst of cynicism.

Regards,
-drc

---

From: Edward Lewis <[email-masked]>
Date: Thu, 3 Sep 2009 16:27:56 -0400

At 16:08 -0400 9/3/09, Lee Howard wrote:

>You can AXFR, or you can use the same algorithm:

That's the issue, keeping the zone's contents coherent (AXFR) or the 
zone's synthesis coherent (copying the algorithm from A to B).

>generate on the fly--seems to be common practice already.  It doesn't
>seem like PTR records need to be static just so transfers will work.

That's not where (static PTRs) I was going.  If my rule is like

       s/^3ffe:cafe:cafe:\(.*\)$/$1.customer.isp.tld/
      (I.e., mapping like 3ffe:cafe:cafe::8001 to ::8001.customer.isp.tld)

then I just need to ship that rule around.

It looks simple with one rule, but if there are many, I'd like see it 
automated.

>I don't understand.

In a non-ISP environment, say a large enterprise, the situation is a 
little more dynamic.  The solution should work for that too.

>Go on...

If I wasn't busy with "work."  Just thinking of when I worked with ENUM stuff.

---

From: "Lee Howard" <[email-masked]>
Date: Thu, 3 Sep 2009 16:37:07 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ted Lemon
> Sent: Thursday, September 03, 2009 1:05 PM
> To: Lee Howard
> Cc: 'dnsop'
> Subject: [DNSOP] A practical solution for ISP-level support of the reverse
DNS tree for
> IPv6
> is another dozen miles of bad road on top of that.   

I agree that I don't like this answer, and I think I said that in the draft,
for exactly those reasons.  If this draft is worth pursuing but you think
section 3 is unclear, could you help me improve it?

But, do those problems get better if you delegate to the user?  Isn't
the user potentially susceptible to DoS attacks, bad configuration, and
getting fed up and calling their ISP?

>It's better to

In theory, but I don't know of any residential gateways that have this
support, and I don't know that end users would be willing to pay for
it.  
 
> There is existing technology for populating PTR records via DHCP, and

Pointer?  I'm not following you.  PTR is sent in DHCP messages?
Or  do you mean that when a device requests a Prefix Delegation, the
DHCPv6 server notifies the DNS server to delegate the zone to that
device?    If that, then  when the gateway assigns addresses to hosts in
the home, they send dynamic updates to it.  

> the Microsoft client, but I'd be surprised if it didn't do this.

I'm just not sure I'm following you, so thanks in advance.

Lee

---

From: "Lee Howard" <[email-masked]>
Date: Thu, 3 Sep 2009 16:08:54 -0400

Edward
> Lewis
> Sent: Thursday, September 03, 2009 12:07 PM
> To: Lee Howard
> Cc: [email-masked]; 'Edward Lewis'
> Subject: Re: [DNSOP] Dynamically Generated PTR, was Re: ... rDNS for
IPv6...
> or "99.999") more than one source of data is needed.  That is, you

In the "on the fly" scenario, you have the same level of availability if
multiple authoritative servers provide the same response to a PTR query.
You can AXFR, or you can use the same algorithm: any query for
1...8.b.d.0.1.0.0.2.ip6.arpa will always return
"1...1.0.0.2.customer.example.com."

> "in-band" maintenance of the system.

I agree with you in principle.  And I agree with you in specific cases,
where DNS is updated dynamically, or reverse zones are
prepopulated (i.e., any time the PTR records point to something
actually useful).  But most ISPs just put in placeholder records or
generate on the fly--seems to be common practice already.  It doesn't
seem like PTR records need to be static just so transfers will work.

I don't understand.

Go on...

Lee

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 04 Sep 2009 06:41:32 +0900

> Is this a requirement for IP6.ARPA zones used for residential users?

Even if it were, you can use notify and IXFR.

But, as availability of dynamic update of DNS is not very high
(there is only one master server), don't mind so many 9s.

> Mutually exclusive per zone.

Right. As dynamic generation of PTRs is a form of dynamic update,
there is no point to have another form of dynamic update.

>>I think such synthesis is the way to go.

The way to go is to ignore both IPv6 and DNSSEC, neither of which
are useful.

							Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Sep 2009 08:21:48 +1000

In message <002701ca2caf$549d3bd0$fdd7b370$@org>, "Lee Howard" writes:
> your servers?

I would expect ISP's would accept updates on their own servers but
may support a delegation being added.

> Hm, need to filter at the edge, make sure customer's don't update
> each other's records.

A ISP should be doing this anyway for lots of reasons.  
 
> Some rate limiting, maybe. 

> Is a matching forward zone required, too?

Eventually.  IPv6 is a paradigm shift.

> will accept their dynamic PTR updates?  

You can send to any nameserver listed for the zone with a preference
for the one that matched the SOA MNAME.

You can find the zone by doing a query for SOA <name of record to
be added> I have a expired draft which says to make the response
to this have a 0 ttl if it would be a NXDOMAIN so you use any cache
and not have the search poison the cache with a long lived NXDOMAIN
response.  The SOA's owner in the authority section will match the
zone's name.  From that you can get the zoness NS records etc.

It authoritative servers don't do RFC2308 you just stip the left
and label and try again.  You will get a SOA when you reach the
zone apex.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Sep 2009 09:37:44 +1000

In message <[email-masked]>, Ted Lemon writes
> delegate to the customer, and it's not that hard to do.

First what DoS that doesn't exist today?  Updates already get sent
to the ISP's {IN-ADDR,IP6}.ARPA servers.

Secondly of CPE equipement can automate this so can a ISP so there
isn't a bad configuration issue.

Thirdly I've already presented two different authentication methods
both of which have working implementations.  A third is to define
how to use the public key associated with a CGA's to sign a update.
This shouldn't be too hard.
 
> that was considered valuable.

Delegating to the CPE leads to a single point of failure.  If the
ISP automatically slaved the zones it delegates to the CPE this
problem would go away.  This would require the ability to tell the
CPE what other nameservers to put in the NS RRset.  The CPE device
would process the UPDATEs and the ISP would provide the redunancy
required.
 
> reverse tree for them, they'd be able to delegate it.

Static is just long term dynamic.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Sep 2009 09:55:15 +1000

> If I wasn't busy with "work."  Just thinking of when I worked with ENUM stuff

	Pre-population by ISP's was a workaround when there wasn't
	technology to do the right thing.  There is no need to pull
	this kludge into IP6.ARPA.

	Mark

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 Sep 2009 17:53:15 -0400

No hat of any kind.  Not even my boater, which I will soon be sad to
put away again.

> People don't move house very often.

Speak for yourself!

But anyway, I think we have clearly crossed the Rubicon of folly if we
think that the IETF's beliefs about what is "sensible", "reasonable",
"sane", or even "fiscally responsible" will have one iota of effect on
what ISPs actually do.  

This is reputedly an _operations_ working group.  If we seriously
propose to try to tell the community of operators that they oughta do
$X if they know what's good for them, I suggest that participants here
need to spend some more time reading the lists of NANOG and friends.

I claim that we need to provide support for the network that people
are actually building.  That often includes things that we would not
do ourselves, and that we think would be better done otherwise.  But I
also claim that if we say, "You shouldn't do $CHEAPTHING, you should
do $OTHERTHING," we're going to lose.  We've lost every single time on
this.  Why is now different?  And if it's not, shouldn't we learn?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 7 Sep 2009 16:44:19 +0200

On Wed, Sep 02, 2009 at 09:03:12AM -0400,
 Edward Lewis <[email-masked]> wrote 
 a message of 67 lines which said:

> master and slaves have to be the same make.

No, they have "only" to use the same algorithm. One can be in C++ as a
PowerDNS back-end and another to be written completely in Perl's
Net::DNS.

On Wed, Sep 02, 2009 at 05:19:30PM -0400,
 Edward Lewis <[email-masked]> wrote 
 a message of 58 lines which said:

> many ills (UDP fragmentation, capping port 53 traffic to 512
> bytes). Then we turn around and say it's okay to put a hobbled DNS
> on port 53.

I'm not sure of the exact meaning of "hobbled" but I suspect it is
derogatory. You seem to imply that a "custom" DNS server (implementing
rules like s/^3ffe:cafe:cafe:\(.*\)$/$1.customer.isp.example/) are
always written from scractch, using the bits on the bare metal. Far
from it, they typically use a framework allowing the author to just
express his/her business rules while the software takes care of the
DNS details. Systems like PowerDNS or evldns work that way. Therefore,
a server written with them complies with the DNS protocol is certainly
not "hobbled" and absolutely not comparable with a broken middlebox.

There are deployment issues with these "custom" DNS servers but
no ressemblance to the problems exposed in RFC 5625.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 7 Sep 2009 10:24:59 -0500

> to the ISP's {IN-ADDR,IP6}.ARPA servers.

If you do prefix delegation, you're delegating typically 64 bits of  
address space.   If you allow your customer to do arbitrary DNS  
updates to the reverse tree for the entire /64, that could wind up  
being a tremendous amount of data.   So on the one hand, you're  
opening yourself up to the potential for a buggy client to cause  
operational problems.

And on the other hand, what makes DoS attacks work is that you have  
some resource that people really care about, and you are able to  
exhaust it by sending too many queries to it.   One really great  
defense against DoS is distribution of load.   So delegating the  
reverse tree for a customer's zone to the customer's equipment  
protects against DoS that way.

> isn't a bad configuration issue.

The problem is that I've never had an ISP that would actually populate  
the reverse tree based on hints from the client, despite the fact that  
this technology has existed for over a decade.   I know there are ISPs  
out there who do it, because I've worked with them in getting it  
working.   But in general, ISPs don't do this.

> This shouldn't be too hard.

I think CGA is a viable solution, but it's a *lot* harder to set up  
than just delegating the tree and insisting that the customer take  
care of it if they care to.

> would process the UPDATEs and the ISP would provide the redunancy

A single point of failure in this case isn't an issue: if your  
residential gateway dies, nobody's going to be querying your PTR  
records, because you're not going to be communicating with anyone.    
If we were talking about A records, I'd agree with you, but for PTR  
records this is really a non-issue.   I don't see ISP-based slaving of  
zones as a viable thing to do, for the same reason that I don't think  
ISPs will ever correctly maintain the PTR tree for clients.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 7 Sep 2009 10:39:34 -0500

> section 3 is unclear, could you help me improve it?

The problem with section 3 is that aside from section 3.2.3, it  
presumes that the customer will be updating the DNS using dynamic DNS  
updates, which does not match current practice, and is difficult to  
deploy due to the lack of shared authentication information that could  
be used to authenticate the updates.   Mark Andrews' suggestion of  
using CGA to authenticate the updates isn't bad, but as you also  
mention in section 3, DDNS from clients doesn't really scale well.

In practice, what works is DDNS from the DHCP server.   This is fairly  
widely deployed (although unfortunately no ISP I've ever had supports  
it).   It's as secure as the DHCP transaction, which for better or for  
worse is generally considered secure enough - if you got an IP address  
from the DHCP server, there's no harm in populating the PTR record for  
it.

My point is that this is a far, far better solution than what many  
large ISPs do now - populating the reverse tree with nonsense names.

> getting fed up and calling their ISP?

Yes.   However, it's very unlikely that the user will care, and thus  
very unlikely that they'll be making phone calls.   In most cases, the  
absence of a PTR record for a particular IP address has no effect on  
the end user - their web surfing is unaffected, their FTP downloads  
are unaffected, Skype works, streaming video works, VPN works, etc.    
The only situations where the lack of a PTR tree will actually affect  
the end user are when they are using (forgive me) ancient protocols  
with ancient implementations that still place trust in the PTR tree,  
which they should not, and in cases where they actually care about  
providing PTR information for debugging purposes.   This sort of  
customer will be very happy to get a PTR delegation, and will do the  
right thing with it.

> support, and I don't know that end users would be willing to pay for

The only end users who will care about it are people like you and me,  
and we will probably run OpenWRT or have a linux box as our  
residential gateway anyway.

> the home, they send dynamic updates to it.

Read RFC4701, 4702 and 4703 (don't panic - they're short).   The  
technologies described here work for DHCPv4 and DHCPv6.   The next-hop  
address can be populated using these techniques; we'd have to add  
something to support any sort of signaling or negotiation about  
delegation, although the default behavior of delegating to the next- 
hop address could work well enough.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 08 Sep 2009 05:56:04 +0800

On 9/5/09 5:53 AM, Andrew Sullivan wrote:
> do ourselves, and that we think would be better done otherwise.

There are valid reasons to formally make statements about a practice, 
whether that rules the day is a different matter.  There is a practice 
promoted, in respect to IPv4, where the dynamic nature of an IP address 
is to be divined by labels used in the reverse DNS PTR records.  While a 
large number of legitimate MTAs publish PTR records, there is also a 
number that do not.  This varies from region to region.

As a practical matter, does it make sense to continue this practice  for 
IPv6?  Our experience found that checking for these records has required 
much greater resources due to high levels of abuse and large numbers of 
reverse DNS timeouts delaying connection disposition.  While legitimate 
MTA often have PTR records, not all do.  Illegitimate MTA lacking an 
operational server in the reverse address space end up comprising the 
majority of traffic seen.

Keeping histories (persistent caches) about which MTAs offer which label 
type in their reverse entry can be handled in the IPv4 address space. 
As a practical matter, this is not easily done for IPv6.  Does it make 
sense from an operational standpoint for ISPs to differentiate between 
residential services by using "different" labels in the reverse zone?

-Doug

---

From: Mark Andrews <[email-masked]>
Date: Tue, 08 Sep 2009 09:52:49 +1000

In message <[email-masked]>, Ted Lemon writes
:
> address space. 

	/56 should be typical for homes
	/48 should be typical for businesses

> If you allow your customer to do arbitrary DNS  

	The size of the name space has NOTHING to do with it.  If
	I have 1 name I can add billions of records at that name.
	
> protects against DoS that way.

	Pure FUD.
 
> working.   But in general, ISPs don't do this.

	Which is basically because ISP's had to work around a problem
	before there was technology for a solution and they havn't
	rethought the problem since.  Additionall the solution was
	designed when residential customers dialed up over the PSTN
	so there was not stability in the reverse space.  The solution
	won't work for IPv6 without specialised servers so they MUST
	rethink the issue.

	ISP's do support customer generated reverse zones for their
	commercial customers.  It really isn't that hard to do it
	for all customers.  It's just inertia that has stopped it.
 
> care of it if they care to.

	All of these can be made very easy.
 
> records, because you're not going to be communicating with anyone.    

	Really?  Lots of log processing is done in batches.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Tue, 08 Sep 2009 11:15:52 +1000

> number that do not.  This varies from region to region.

Which was always a error prone practive.
 
> majority of traffic seen.

In theory there is nameserver for every address.  You should be
complaining to the RIR's / LIR's if the ISP's are not running
nameservers after requesting delegation.  All delegations are
requested.

Illegitimate MTA'a may not have a PTR but a server should still be
responding with a negative response.

Also I don't see what this has to do with populating the reverse
tree or not.  It may have to do with delegating only to CPE equipment
but that is a orthoganal issue.

Mark

---

From: Ted Lemon <[email-masked]>
Date: Mon, 7 Sep 2009 20:21:17 -0500

> 	/48 should be typical for businesses

I don't think this is germane to the discussion.   My point in  
mentioning /64 was simply that if you go narrower than that, important  
things break, so it's a pretty good number to assume as an absolute  
minimum.

> 	I have 1 name I can add billions of records at that name.

True, and with an IPv4 delegation I can have a filter that prevents  
you from adding names that don't make sense, stopping that particular  
failure mode.   But there is no filter that could similarly disallow  
an excessive number of names in an IPv6 delegation.

>> protects against DoS that way.

?

>> the reverse tree based on hints from the client,
>
> 	rethought the problem since.

No, that's not the case at all.   The technology I'm talking about  
predates the existence of most of the really big ISPs, and there are  
ISPs that have been doing DNS updates right for over a decade.   The  
problem is a lack of motivation to implement, not a lack of working  
technology.

> 	for all customers.  It's just inertia that has stopped it.

Do they do it with DDNS, or with web forms?   The only commercial  
support for the reverse tree that I know of for sub-class-C subnets is  
done with web forms.

> 	Really?  Lots of log processing is done in batches.

Sure, and PTR queries can always fail.   There is no way to guarantee  
that PTR queries will succeed when processing logs, no matter what  
solution an ISP implements.   An auditing mechanism that depends on  
the PTR tree is not valid.   Any mechanism necessary for  
interoperation that fails in the absence of a PTR record is invalid.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 08 Sep 2009 11:45:28 +1000

In message <[email-masked]>, Ted Lemon writes
> problem is a lack of motivation to implement, not a lack of working  

Residential was basically dialup for a long time.  This has shifted
to cable, dsl and wireless which are essentially always on technologies.

> support for the reverse tree that I know of for sub-class-C subnets is  

Which is a matter of tools which is what we are talking about
developing.  It isn't that hard to make a update tool that works
with RFC 2317 style delegations but you don't really need have a
delegation if you are doing dynamic updates in the first place.

nsupdate was designed to allow the CNAME to be removed.  A slightly
different tool is needed to follow the CNAME and construct a PTR
using the CNAME's rdata as the ownername.  This can be done outside
of nsupdate by whatever is translating the IP address into the
in-addr.arpa/ip6.arpa name.  DNAME's are likely to be in the ip6.arpa
which have the same issues.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 09 Sep 2009 13:59:52 +0800

On 9/8/09 9:15 AM, Mark Andrews wrote:
> In message<[email-masked]>, Douglas Otis writes:

Mark,

> Which was always a error prone practice.

By Error Prone, you mean divining whether an IP address is dynamic by 
discovering whether the reverse PTR record:

1) Exists
2) Host specific
3) Does not contain labels inferring dynamic assignment

Perhaps suggesting this practice not be continued with IPv6 could be 
sound advice.

> nameservers after requesting delegation.  All delegations are

Engineering is about dealing with existing situations and providing 
advice in how to avoid making problems worse.  Reverse DNS timeouts have 
been persistent.  Suggesting that people complain represents a political 
solution out of place within a WG document or even likely to be effective.

> responding with a negative response.

This describes ideal DNS management.  It seems unlikely that after 
introducing IPv6 into email, represented by regions notorious for poorly 
maintained reverse DNS, that this problem will improve, despite complaints.

> but that is a orthogonal issue.

Advise regarding the reliability of the reverse DNS space might temper 
insistence that reverse DNS labels be used to designate whether address 
assignment is dynamic.  The sheer scale of this space makes mitigation 
efforts aimed at identifying problematic addresses impractical.

-Doug