Subject: Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

From: "John Levine" <[email-masked]>
Date: 1 Nov 2014 20:51:01 -0000

>I entirely agree ... the fact that reverse DNS works as a heuristic (and
>not an especially key heuristic) for IPv4 is not a reason for the
>considerable effort required to try and make it work as a an equally
>flawed heuristic on IPv6.

There is a heuristic that says any host which is intended to act as a
server visible to hosts on the public Internet should have matching
forward and reverse DNS.  (It does not say the converse; the presence
of DNS doesn't mean a host is good, the absence means it's bad.)  This
seems to me to be perfectly relevant in IPv6.

A rather significant difference between v4 and v6 is that you can
create static generic rDNS for even a fairly large v4 allocation using
something like $GENERATE, and it's well within the abilities of normal
name servers to handle it.  For v6, you need a stunt server or other
kludge, with the kludges getting pretty intense if you want DNSSEC to
work.  So let's not bother.  Yes, we have ways for hosts to install
DNS entries for the addresses they're using, but they're not widely
adopted, and I have bad feelings about their security characteristics.
(Hostile or buggy botware does an address hopping DDoS on your DNS
infrastructure, for example.)

>Beside the cost of creating the data and fetching it, there's the cost
>of caching it when people change the IP for every email sending attempt

Although I think I was one of the first people to propose that, I still
think that anyone who sends mail that way deserves what they get.

R's,
John

---

From: Paul Wouters <[email-masked]>
Date: Sat, 1 Nov 2014 18:11:37 -0400 (EDT)

> seems to me to be perfectly relevant in IPv6.

Which at the current deployment levels, is only valid for IPv4, not
IPv6. Yet the anti-spammers have adopted it for IPv6.

> adopted, and I have bad feelings about their security characteristics.

Are you saying now that the IPv6 reverse checks should be dropped? I'm
confused.

> think that anyone who sends mail that way deserves what they get.

Anti-spam measures should make it harder for spammers to send email, not
for legitimate users. While there are trade-offs the current deployment
of IPv6 is such that people are currently very limited in options to
obtain native v6, and it often comes without reverse.

If we want secure decentralised email, we should work on making it
easier for people to run their own mailservers, not harder. Currently,
the anti-spammers are causing a "I gave up and use gmail" wave of users.

Really. There is one ISP in Canada offering native v6, and it does not
come with delegations for reverse. I'm pretty sure Canada is not an
isolated case. Blocking all IPv6 without reverse on smtp is simply an
out of proportion meassure causing more harm than good.

Doubly ironic since my email goes out with DKIM and is DNSSEC signed, you
really don't need the reverse to check the validity of my email. Yes it
will increase the load on your email server when you cannot blanket-block
most of IPv6 outside the core. But is it really that prohibitive that
you cannot afford to chain your anti-spam meassures appropriately and
put DKIM before reverse DNS checks that are known to come with a high
false positive rate?

Paul

---

From: "John R Levine" <[email-masked]>
Date: 1 Nov 2014 18:32:19 -0400

> IPv6. Yet the anti-spammers have adopted it for IPv6.

I talk to a lot of people who run large mail systems at MAAWG, including 
some of the largest ones in Canada.  Their experience with the v6 mail 
they send and receive is quite the opposite -- real mail hosts have real 
DNS, whether on v4 or v6.

If your connection is over a consumer broadband network, your provider 
probably considers it a feature that it's hard for you to send mail 
without going through a relay with a static address and rDNS, not a bug.

> Are you saying now that the IPv6 reverse checks should be dropped? I'm

No, I'm saying that hosts with static addresses that are intended to be 
servers or mail clients should have DNS, for other hosts on random 
addresses, there's no point.  If you want your hosts to be visible to your 
friends, you can use something like dyndns, and since they already know 
you, the absence of rDNS shouldn't matter.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 01 Nov 2014 16:31:07 -0700

> John Levine <mailto:[email-masked]>
> Saturday, November 01, 2014 1:51 PM
> ... So let's not bother.  Yes, we have ways for hosts to install
john, richard, (others,) i've now heard from our friends in the last
mile industry that the new york times web site won't serve web content
to client IP's that lack PTR's. i havn't tested this, but hear me out.
there is no RFC saying when PTR's are recommended and when not. john's
formulation, <<There is a heuristic that says any host which is intended
to act as a server visible to hosts on the public Internet should have
matching forward and reverse DNS.  (It does not say the converse; the
presence of DNS doesn't mean a host is good, the absence means it's
bad.)  This seems to me to be perfectly relevant in IPv6>>, suits me
just fine.

if there were an RFC (let's be charitable and assume it would have to be
an FYI due to lack of consensus) that gave reasons why PTR's would be
needed and reasons why the absence might be better (so, internet access
vs. internet service), then that RFC might give our last-mile industry
buddies the air cover they need to be first movers in dropping PTR's for
both V6 and V4 "internet access" addresses. it'll mean visiting the NYT
tech team in person, no doubt, and then similar outreach to other
smaller players. hard as it will be, dropping PTR for "internet access"
addresses is at least "thinkable", unlike, say, universal Source Address
Validation.

john, you're fast-good-and-cheap when it comes to whipping up
sole-purpose RFC's. let us know which 25 of us you would like to list as
co-authors, and we'll get you our "authors addresses" text blobs.

-- 
Paul Vixie

---

From: Paul Ebersman <[email-masked]>
Date: Sat, 01 Nov 2014 21:08:21 -0600

vixie> if there were an RFC (let's be charitable and assume it would
vixie> have to be an FYI due to lack of consensus) that gave reasons why
vixie> PTR's would be needed and reasons why the absence might be better
vixie> (so, internet access vs. internet service), then that RFC might
vixie> give our last-mile industry buddies the air cover they need to be
vixie> first movers in dropping PTR's for both V6 and V4 "internet
vixie> access" addresses.

Hate to rain on your parade but this isn't going to happen. The problem
is not one example, like NYT. It's that we have 20+ years of sloppy
habits and people making golden calves of PTR records. As a last mile
provider, customer screams are way more expensive than just whipping out
garbage PTRs that mean nothing and are of no security/validation use but
mean I don't get calls.

I don't even know how many broken sites there are and I don't care to
waste valuable staff time tilting at this windmill. I just want to avoid
customer calls by suddenly deciding after decades that PTR records
deserve to be cleaned up.

My current expecation is somewhat like the following:

  - all routers/network interfaces will have PTRs so my traceroutes are
    of some use to my NOC
  - all service machines will have legit forward and reverse that match
    so that I can keep track of my own stuff and other folks will have
    less reason to ditch my email traffic
  - will probably get our DNS server folks to do lie on the fly v6 PTRs
    for any customer addrs, with sign on the fly so they do at least
    DNSSEC validate

Folks using PTRs for insane uses like as part of VPN validation, to get
web content or similar things that were useless in v4 will get the same
delusional warm fuzzies they get now.

Folks that find the current $GENERATE v4 stuff evil and untrustworthy
will find the v6 stuff no better.

Folks trying limit spam will hopefully figure out something that doesn't
involve reputation by IPv6 addr, 'cause at 18 quadrillion per /64, that
won't scale...

---

From: Paul Vixie <[email-masked]>
Date: Sat, 01 Nov 2014 20:52:02 -0700

> Paul Ebersman <mailto:[email-masked]>
> Saturday, November 01, 2014 8:08 PM
> ...
>
> Hate to rain on your parade but this isn't going to happen.

that's what folks told me about source address validation when they
heard about SAC004. my quest continues.

> waste valuable staff time tilting at this windmill. ...

no worries. meanwhile i'm going to try to build an internet that can
grow for 200 more years. that's not going to happen if all we ever do is
add layers and complexity. if PTR's are silly, then we have a
responsibility to say so in writing, with an RFC number to point at, and
we should begin what may be the several-lifetimes-long task of getting
people to pay attention differently. i have little or no use for the
world as it is, and i never have had.

> involve reputation by IPv6 addr, 'cause at 18 quadrillion per /64, that

ain't it great? a lot of servers are going to demand PTR's for V6. this
will force the number of SMTP senders to be small. i don't love the
mechanism, but i can't quibble with the social impact.

but, separately from that, if PTR's have high and low uses, we should
document that, so that NYT (or whomever) can get some official guidance
from the putative grownups. guidance which is sorely lacking on this
topic today. the lack of such guidance being one of the reasons that the
world is as we find it.

-- 
Paul Vixie

---

From: "John Levine" <[email-masked]>
Date: 2 Nov 2014 15:11:49 -0000

>document that, so that NYT (or whomever) ...

Can whoever mentioned the NY Times offer more clues about what they're
rejecting?  My cable connection happens to have IPv6 with no rDNS, and
I can't even find a v6 address at the Times to try to connect to.  As
far as I can tell, they're all v4.

I certainly get my share of v6 connection strangeness, but all of the
ones I've been able to track down appear due to T-W's sometimes dodgy
internal routing.

R's,
John

---

From: Paul Ebersman <[email-masked]>
Date: Sun, 02 Nov 2014 08:55:12 -0700

ebersman> I don't even know how many broken sites there are and I don't
ebersman> care to waste valuable staff time tilting at this
ebersman> windmill. ...

vixie> no worries. meanwhile i'm going to try to build an internet that
vixie> can grow for 200 more years.

Suddenly being "socially responsible" with PTR use is going to save the
internet. Cool. :)

vixie> that's not going to happen if all we ever do is add layers and
vixie> complexity. if PTR's are silly, then we have a responsibility to
vixie> say so in writing, with an RFC number to point at, and we should
vixie> begin what may be the several-lifetimes-long task of getting
vixie> people to pay attention differently. i have little or no use for
vixie> the world as it is, and i never have had.

If you do really want to try to cure 20+ years of bad ideas and document
it, go for it. I'd speak against doing so in this draft, other than a
possible reference if said RFC ever happens. One of the big problems
with the whole v6 PTR discussion is that every time somone (including
me) has asked "so how are we using them in v4", noone has anything like
a definitive list of what we're doing now. That doesn't even touch
whether or not said uses are actually good ideas.

I think there is value in making recommendations now based on current
operational reality and detailing tradeoffs and real customer support
costs in doing PTRs in v6, which seems to be the goal of this draft. If
this turns into an RFC and eventually becomes a quaint bit of history,
we can retire it.

ebersman> Folks trying limit spam will hopefully figure out something
ebersman> that doesn't involve reputation by IPv6 addr, 'cause at 18
ebersman> quadrillion per /64, that won't scale...

vixie> ain't it great? a lot of servers are going to demand PTR's for
vixie> V6. this will force the number of SMTP senders to be small. i
vixie> don't love the mechanism, but i can't quibble with the social
vixie> impact.

So your grand scheme is to limit who can get v6 PTRs and that will be
the new standard of whether or now you're tall enough to send email with
the big boys? How's that worked out so far in v4 in the last few years?

How about we admit that PTRs as a measure of trust and reputation is
broken to begin with and won't scale or magically work better for v6
than v4? Let's come up with a better solution(s).

---

From: Paul Vixie <[email-masked]>
Date: Sun, 02 Nov 2014 11:04:38 -0800

> Sunday, November 02, 2014 7:55 AM
> ...
> So your grand scheme is
decorum?
>  ... to limit who can get v6 PTRs and that will be
> the big boys?
yes.
> How's that worked out so far in v4 in the last few years?
thanks to steve's <http://www.enemieslist.com/> by which i "whiteout"
the PTR's manufactured by last mile providers, and behave exactly as i
would if these PTR's were not present -- it's working pretty well. seems
like a lot of extra complexity though.
> than v4? Let's come up with a better solution(s).
i think we're on the same page, actually. where we're still far apart is
in our understandings of how things work today, in other words, what
status quo are we living with; and also, whether and in what direction
we can change it.

-- 
Paul Vixie

---

From: Paul Ebersman <[email-masked]>
Date: Sun, 02 Nov 2014 12:20:39 -0700

ebersman> So your grand scheme is

vixie> decorum?

No objections here if you succeed. :)

ebersman> ... to limit who can get v6 PTRs and that will be the new
ebersman> standard of whether or now you're tall enough to send email
ebersman> with the big boys?

vixie> yes.

Well, for my $DAYJOB, that's certainly something we support. As someone
who runs my own mail server and knows other small businesses who do as
well, I'm still hoping we can come up with a better system that lets
some of the smaller players in too.

ebersman> How about we admit that PTRs as a measure of trust and
ebersman> reputation is broken to begin with and won't scale or
ebersman> magically work better for v6 than v4? Let's come up with a
ebersman> better solution(s).

vixie> i think we're on the same page, actually. where we're still far
vixie> apart is in our understandings of how things work today, in other
vixie> words, what status quo are we living with; and also, whether and
vixie> in what direction we can change it.

I'm happy to be educated or corrected by hard facts. And I agree we
probably ultimately want the same thing: email that is more signal than
noise to mail servers.

Getting back to this draft, I think there is enough value in enumerating
the challenges and tradeoffs of doing some kind of v6 PTRs to try to get
the draft out soon. Plenty of folks (including $DAYJOB) want something
short term that doesn't break anything and looks/smells somewhat like
what we already have in v4. No argument that a better solution here long
term would be welcome too; I just don't want folks to have another
excuse not to roll out v6 now.

As for a grander scheme to clean up the PTR space, do you agree that
breaking that out into a separate draft is more productive?

It does seem to make sense to mention that folks doing the $GENERATE
equiv will get the same short shrift from the anti-spam folks that the
v4 PTRs get currently.

Any other comments/additions to this draft?

---

From: George Michaelson <[email-masked]>
Date: Mon, 3 Nov 2014 04:36:54 +0000

knowing its not the root issue, I would like to remind people the RIR
system for rDNS delegation is almost entirely automatic from our various
portals, and WHOIS based nserver mechanisms. Its not hard to do the top
part. We're not roadblocking.

We don't have any failure to delegate the parent blocks facing down: Its
people's willingness to invest energy on the various different approaches
to the sub-delegation engines inside your own block management, be it
embedded in the NMS or some kind of customer facing provisioning web portal
or whatever.

What we don't do, (noting 6to4 reverse as a very specific counter-case) is
permit 'hop over' in the delegation chain because its got issues regarding
'who said you could do that' we don't want to prod. The delegation sequence
really has to be top down if you have sub-delegation state.

Personally, and it is only my personal view, I like some of the older ideas
for semi-machine generated and wildcarded reverse I saw presented at the
RIPE ROME meeting. And I see some value in sign-on-the-fly work.

I think rDNS remains potential for big value. I can't verbalize it well,
but it has qualities about trust which for me could be useful. Its
volountarist nature is a huge counter argument as you've all exposed here:
can't depend on it. coverage is low.

-G

On Sun, Nov 2, 2014 at 7:20 PM, Paul Ebersman <[email-masked]> wrote:

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

---

From: Terry Manderson <[email-masked]>
Date: Tue, 4 Nov 2014 00:32:05 +0000

Hi George, and all.

I've just caught up on this thread, and it strikes me that there is (it
seems) an operational gap with the omission of the problem statement.

On 3/11/2014 2:36 pm, "George Michaelson" <[email-masked]> wrote:

[snip]

>embedded in the NMS or some kind of
> customer facing provisioning web portal or whatever.

Problem 1: Operator unwillingness to invest energy to the sub-delegation
engines

[snip]

>
>Personally, and it is only my personal view, I like some of the older
>ideas for semi-machine generated and wildcarded reverse I saw presented
>at the RIPE ROME meeting. And I see some value in sign-on-the-fly work.

Problem 2: uniform generation of PTR (with the presumption that they are
useful in some form)

>volountarist nature is a huge counter argument as you've all exposed
>here: can't depend on it. coverage is low.

Problem 3: The non-specific non-commital approach (or lack thereof) to
coverage by operators.

Problem 4: The inability to document 'big value' or trust qualities in
reverse DNS.

I see the use of reverse DNS as various forms of blacklisting/whitelisting
or similarly adjudicating the reputation of a TCP connection (SMTP or
otherwise) an interesting approach to remove a level of pain (where pain
levels are individually variable). I don't necessarily believe this
evolution has legs, but I don't believe they are very long.

Suffice to say that I've used that as a pain fix in past, but now question
its scale going forward for IPv6. I don't mind the concept of stable
services addresses having stable and well formed reverse. However in a
customer realm, see Problem 1 closely followed by problem 3.

As to utility? I've stopped looking at reverse DNS, as a quality, and as
an information source. Really, if I want to get a sense of who and where I
tend to look toward whois/rdap and a sh ip bgp <blah> and look to the ASN.

So as a sales job trying to sell reverse DNS IPv6 to the masses, and that
isn't the IETF's job IMHO, we won't be living well on the commission.

As to the IETF's job of documenting the problem, and then a possible
solution for the operational aspects - I think that worth putting cycles
toward, however I don't see that it will be at all easy. If this thread is
any indication.

Cheers
Terry

---

From: George Michaelson <[email-masked]>
Date: Tue, 4 Nov 2014 05:28:20 +0000

I think thats pretty well completely fair Terry. I think you capture the
qualities well.

But if you put DNSSEC back in the equation, add sufficient value to the
assertive-trust side of what would be said inside it, and the
follows-the-delegation-chain aspect, I think it has potential to have more
value.

But only potential. Its very very latent.

-G

---

From: 神明達哉 <[email-masked]>
Date: Wed, 5 Nov 2014 10:19:59 -0800

At Sat, 01 Nov 2014 16:31:07 -0700,
Paul Vixie <[email-masked]> wrote:

> both V6 and V4 "internet access" addresses. [...]

I guess
https://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06
(also in the references section of draft-howard-dnsop-ip6rdns-00, but
doesn't seem to be actually referenced from the draft body) tried to
become this kind of RFC (ignoring subtle implication differences).
Unfortunately the draft was dead in a lot of controversy, and I think
we're seeing the same type of varied opinions on this thread.  I
personally think if we can agree on the content this time, such a
document will be very useful, but we should carefully learn from the
previous failure so we won't repeat it.

--
JINMEI, Tatuya

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 5 Nov 2014 13:50:26 -0500

> previous failure so we won't repeat it.

I'd be willing to try again if people really think it's worth doing,
but the discussion just in this thread suggests to me that the result
would be the same.

For those who managed to miss the last round of this, that document
ended up saying, "There is a reverse tree; some people maintain it and
some don't.  Some people like to rely on it, but it is important to be
aware that not everyone maintains it.  If someone relies on the
reverse tree and you don't maintain it for your site, you might have
surprising results."

At the time, I believed I had watered down the draft so thoroughly
that it would be impossible for anyone to disagree with it.  I was
evidently wrong.

If we're going to bring that thing back up (in any sense you like),
then I think it needs to get a spine.  Perhaps also my willingness to
try to find consensus has declined in the intervening years: I just
don't think there _is_ a consensus on this.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Wed, 05 Nov 2014 12:50:42 -0800

> Andrew Sullivan <mailto:[email-masked]>
> Wednesday, November 05, 2014 10:50 AM
> ... I believed I had watered down the draft so thoroughly that it
> would be impossible for anyone to disagree with it. I was evidently
> wrong. If we're going to bring that thing back up (in any sense you
> like), then I think it needs to get a spine. Perhaps also my
> willingness to try to find consensus has declined in the intervening
> years: I just don't think there _is_ a consensus on this.
the lack of consensus means it can't be a proposed standard, not that it
can't be an FYI, BCP or similar, right?

the fact of the network is, without a PTR you will have a hard time
originating TCP/25. we should say that.

another fact is, not everyone who should be able to (non-maliciously)
access your web service will have a PTR. we should say that, too.

those aren't opinions and they shouldn't be controversial.

-- 
Paul Vixie

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 5 Nov 2014 15:59:00 -0500

> can't be an FYI, BCP or similar, right?

AFAIK we were planning only for informational.  The chairs called
WGLC, it ran, there was some ranting, then some months later one of
the chairs told me that they weren't sure what to do.  To publish
something as a WG document, you still need consensus to get it out of
the group.
 
> originating TCP/25. we should say that.

You'd think.  Here's the fully-watered text on that topic that the WG
still couldn't agree to:

   Some anti-spam systems use the reverse tree to verify existing
   reverse mapping, or to check for matching reverse mapping.  Some mail
   servers have the ability to perform such checks at the time of
   negotiation, and to reject mail from hosts that do not have matching
   reverse mappings for their hostnames.  These PTR checks sometimes
   include databases of well-known conventions for generic names (for
   example, PTR records for dynamically-assigned hostnames and IP
   addresses), and may allow complicated rules for quarantining or
   filtering mail from unknown or suspect sources.  Even some very large
   ISPs are reported to refuse mail from hosts without a reverse
   mapping.  Often, the reverse map check is not used on its own, but is
   used as part of a scoring system in an attempt to indicate the
   probability that a given email message is spam.
 
> access your web service will have a PTR. we should say that, too.

Again, fully watered-down:

   Especially in the absence of strong anti-spoofing mechanisms, like
   the DNS Security Extensions, a check for matching reverse DNS mapping
   should be regarded as an extremely weak form of authentication.  

[…]

   Reverse mapping tests can give the administrator a false sense of
   security.  There is little evidence that a reverse mapping test
   provides much in the way of security (see above), and may make
   troubleshooting in the case of DNS failure more difficult.
[…]

   Applications should not rely on reverse mapping for proper operation,
   although functions that depend on reverse mapping will obviously not
   work in its absence.  Operators and users are reminded that the use
   of the reverse tree, sometimes in conjunction with a lookup of the
   name resulting from the PTR record, provides no real security, can
   lead to erroneous results and generally just increases load on DNS
   servers. Further, in cases where address block holders fail to
   properly configure reverse mapping, users of those blocks are
   penalized.

Re-reading it today, it seems to me the text was altogether milquetoast.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 06 Nov 2014 08:00:20 +1100

Or we could stop debating whether we should maintain it and assume
that if we give people tools that will allow it to be automatically
maintained they will eventually deploy them.

A lot of the issue is that the tools aren't out there yet.

Document what a node should do to register itself in the reverse
tree and to cleanup when its address changes.  Write some code to
do it.

e.g.

Add a PTR record and a KEY record using TCP and the source address
as the authenticator.  The KEY record lets the node cleanup after
itself when the address changes by using SIG(0) as the authenticator.

We already have nameservers which can completely support these
clients.

We can add delayed automatic cleanup to the DNS.  Nameservers already
do lots of automatic zone maintainance for DNSSEC.  Cleaning out
records when a timer goes off is no more difficult than regenerating
RRSIG when timers go off.  Yes, this would require nodes to refresh
their REMOVE records periodically to keep the PTR and KEY records
alive.  Windows already does this sort of thing but on a whole of
zone basis.

	1.1.1.1.in-addr.arpa REMOVE PTR <time>
	1.1.1.1.in-addr.arpa REMOVE KEY <time>

Where time is a 32 bit time stamp like those in RRSIG records.

The client would fetch the REMOVE records and send back a updated
set of REMOVE records periodicaly.  When a REMOVE record is triggered
it is automatically removed from the set of REMOVE records.

A nameserver could automaticall add REMOVE records and put upper
bounds on the time field as a matter of policy if desired.

You would then end up with a set of records like this optionally
signed.

	1.1.1.1.in-addr.arpa PTR <name>
	1.1.1.1.in-addr.arpa KEY <key>
	1.1.1.1.in-addr.arpa REMOVE PTR <time>
	1.1.1.1.in-addr.arpa REMOVE KEY <time>

The nameserver then has all the data it needs to re-establish the
timers on startup within the zone.

The next step is automatic reverse tree delegation along with prefix
delegation as well as cleanup with the delegation expires.  We have
drafts for how to do this.

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Nov 2014 16:06:28 -0500

> something as a WG document, you still need consensus to get it out of

Consensus in a case like this would mean "is there something in the document that is not correct," not "does everybody think we should publish the document."   It is up to the chairs to determine consensus, and I think Pete's document (informative though it may be) on consensus is a perfectly valid guide for the chairs to follow in making that determination.

---

From: "John Levine" <[email-masked]>
Date: 5 Nov 2014 21:48:34 -0000

>Re-reading it today, it seems to me the text was altogether milquetoast.

I agree.  The points that Vixie notes are entirely true, and it's hard
to imagine a good reason not to document them for the benefit of
people who want to, you know, interoperate.

R's,
John

---

From: Paul Ebersman <[email-masked]>
Date: Wed, 05 Nov 2014 14:55:47 -0700

marka> Or we could stop debating whether we should maintain it and
marka> assume that if we give people tools that will allow it to be
marka> automatically maintained they will eventually deploy them.

For providers with millions or tens of millions of end customers, any
system that just lets any customer scribble in DNS is unlikely to be
employed for security or stability reasons.

marka> Document what a node should do to register itself in the reverse
marka> tree and to cleanup when its address changes.  Write some code to
marka> do it.

And of course all CPE vendors put out quality products with these
advances in code and never put out cheap crap. And consumers always
upgrade their CPEs based on this improved code immmediately.

Heh.

The reality is that this will take decades and in the meantime,
consumers will have problems doing what they want and they will complain
to their service provider, who won't have a good solution.

This document tries to lay out the challenges and tradeoffs of not
having PTRs or not having "clean" PTRs. We should be sure it makes those
tradeoffs clear, along with the problems service providers will see if
they do or don't pick one of the solution sets. If there are issues or
tradeoffs not in the document, suggest a text change.

The "just do it right and folks will roll it out" argument doesn't solve
the problem in any useful timeframe and doesn't let folks who do have to
support millions of customers make informed operational decisions.

And automating at the scale we'll see with real IPv6 deployment is going
to be very hard. Add in that embedded devices are some of the least
likely to be current, clean or remotely upgradeable as we learn of
mistakes and you'll wind up with more boxes doing it wrong than right.

---

From: Paul Ebersman <[email-masked]>
Date: Wed, 05 Nov 2014 15:20:34 -0700

[...]

To put things another way, I think you're trying to optimize for a
problem most folks don't want solved.

Anti-spam folks *like* it that it's not trivial to get "correct"
rDNS/PTRs. It's easy to find consumer connections based on the ISP doing
bulk/lazy PTR generation and just reject SMTP traffic from them.

Large ISPs don't care about clean PTRs as long as no customers complain
and they don't care if end customers can't do SMTP without having to ask
for it in some special way. They do care about and probably don't want
complicated automated systems with all sorts of complicated behavior
when autogen'ed PTRs solve most customer problems.

While I as an individual may find it annoying to have to go to a web
page to get a port 25 block removed and I may have to find someone
better connected than me to get my email to "real" folks like google,
I'm not most of the internet. Not even a teeny weeny fraction of it.

And while I admit that I tend to disable auto-update on most of my
devices and do updates by hand, at $DAYJOB, it's a feature when we can
push new versions out to fix things and not wait for consumer gear to
spout smoke and get replaced in 3-5 years.

So for a large chunk of the providers out there, the recommendations in
this draft solve a real problem in a mostly non-painful way and I think
it's done a decent job of laying out the tradeoffs.

There have been some comments about making it clear that providers that
do bulk $GENERATE equivs in IPv6 will find that those addrs won't be
able to send email. Seems like a fine thing to point out.

What else in the way of tradeoffs is missing?

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 5 Nov 2014 18:12:14 -0500

> maintained they will eventually deploy them.

Yeah, that's worked so far!  No reason it shouldn't in this case!

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 06 Nov 2014 10:24:50 +1100

> Yeah, that's worked so far!  No reason it shouldn't in this case!

It requires the Chairs to actually act as chairs on this issue.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 06 Nov 2014 11:28:31 +1100

> employed for security or stability reasons.

For in-addr.arpa you already have a PTR records.  Allowing the end
user to set its content does not increase the amount of data you
are serving.  It does increase the amount of churn in the zone.  A
matching TCP source address is a good enough authenticator to permit
the update.  If you want to force a single PTR record that is
implementable policy.

1.2.3.4 can only set the PTR record at 4.3.2.1.in-addr.arpa.

	update-policy {
		permit * tcp-self * PTR;
	};

	to do singletons something like would work
	
	update-policy {
		permit * tcp-self-singleton * PTR;
	};

I don't see a real security issue here.

The occasional customer will add a offensive PTR record which won't
be seen by 99.99999% of the world.  It will occasionally be included
in logs.  The contents can already be checked to ensure that it is
a legal hostname (LDH) that is being added.  We see this sort of
thing in whois but it doesn't stop the host names being registered
there and there is no real reason to stop them here.

If we recommend that this is only done when a forward record is
also successfully added UPDATE + TSIG (yes, this does scale for
this use) you get rid of the PTR/A mis-match issues.

For ip6.arpa you delegate to the customer along with the prefix
delegation.  The customer has to deal with the space issues but
uses the same mechanisms to add the PTR records and cleanup.

> upgrade their CPEs based on this improved code immmediately.

So you implement the rest of the proposal to self clean and restore
defaults. Delayed additions are no harder than delayed removals. Yes
there are 3 records instead of one but no human needs to any
maintainence of the zone content.

	REMOVE PTR <time>
	ADD PTR <time> <default value>

You get the equivalent of $GENERATE with customer settable overrides
using UPDATE over TCP.

This is incrementally deployable.

	add-remove delay PTR; 
	add-remove delay KEY; 
	add-add delay PTR "dynamic-%1.%2.%3.%4.example.net"; 
	update-policy {
		permit * tcp-self-singleton * PTR KEY;
	};

Or if you don't like the ADD record.

	add-remove delay PTR; 
	add-remove delay KEY; 
	ptr-default "dynamic-%1.%2.%3.%4.example.net"; 
	update-policy {
		permit * tcp-self-singleton * PTR KEY;
	};

Technically this is 100% achievable.  It adds a couple of new record
types.  It requires nameservers to do the processing specified in
the new records as it falls due.

If you don't have PTR records by default you don't restore them on
deletion.

It can work with zones that synthesize missing PTR records on demand.
If there is no PTR record in the zone, create one.

> to their service provider, who won't have a good solution.

The reality is that this will give what is needed and is incrementally
deployable.  The only question is do you synthesize missing PTR
records and matching AAAA records or not for IPv6.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Thu, 06 Nov 2014 12:13:22 +1100

In message <[email-masked]>, Paul Ebersman
> problem most folks don't want solved.

You don't know that.  At the moment most people that would want
these records have give up because the barriers raised have been
to hard mostly because it requires a human to be in the loop and
there is no standarisation.

> bulk/lazy PTR generation and just reject SMTP traffic from them.

Which won't work in IPv6 unless you syntesize the records on demand.
They also have other databases so don't really need PTR records to
workout static vs dynamic.

> when autogen'ed PTRs solve most customer problems.

Except autogenerated PTR records don't solve the problem.
 
> I'm not most of the internet. Not even a teeny weeny fraction of it.

Getting a firewall block removed is a othogonal issue. 
 
> What else in the way of tradeoffs is missing?
 
That people want IP to name mappings for their internal networks.
With things like DNSSEC you need break DNSSEC trust chains at the
ISP level for this to work.

We also don't know what else will come along to use the reverse
namespace.  It is a good place to hang keying material which is
tied to IP address.

Having a well defined method to update this name space will be
useful.

There is a opportunity cost in not having the ability to do this
already deployed.  Remember it is just as easy to add a delegation
as it is a PTR record if the amount of material that needs to be
stored gets too big.

Mark

---

From: [email-masked]
Date: Thu, 06 Nov 2014 08:26:17 +0100 (CET)

> are serving.  It does increase the amount of churn in the zone.

Putting my ISP hat on, I'd have to agree with the security/stability
reasons (and several others I can think of). As of today, I have zero
incentive to let my residential customers create their own PTR records.
Better tools and systems may change this, but it would in any case be
*way* down on the priority list.

Steinar Haug, AS 2116

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 06 Nov 2014 17:05:59 +0900

>     should be regarded as an extremely weak form of authentication.

Considering that DNS Security Extension provides weak
security only blindly relying on untrustworthy TTPs,
it is better to say;

<     Especially in the absence of strong anti-spoofing mechanisms,
<     a check for matching reverse DNS mapping
<     should be regarded as a weak form of authentication.

					Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 06 Nov 2014 17:30:25 +0900

Mark Andrews wrote:

> the update.

It may be better to carry domain names in DHCP discover/request.

DHCP servers is less complicated than name servers that
it is safer to use it as the place to let end users
inject their information.

> *way* down on the priority list.

Considering that PTRs generated by ISPs are too often useless,
are you saying you won't provide PTRs?

						Masataka Ohta

---

From: [email-masked]
Date: Thu, 06 Nov 2014 09:38:30 +0100 (CET)

> are you saying you won't provide PTRs?

For our residential customers, we provide IPv4 PTRs which indicate
that this is a dynamic address. We *don't* plan to provide IPv6 PTRs
for those same customers.

Steinar Haug, AS 2116

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 06 Nov 2014 19:29:27 +0900

> for those same customers.

That's fine.

But, what we need is opinions of ISPs which are allowing customers
supply PTRs for IPv4, doesn't it?

						Masataka Ohta

---

From: Paul Ebersman <[email-masked]>
Date: Thu, 06 Nov 2014 08:24:35 -0700

marka> For in-addr.arpa you already have a PTR records.  Allowing the
marka> end user to set its content does not increase the amount of data
marka> you are serving.  It does increase the amount of churn in the
marka> zone.

This draft isn't talking about v4. And $GENERATE or equiv already works
in that most customers don't scream. I have no incentive to change to a
more risky and complicated and hard to maintain system for v4.

I'd contend that the folks who check v4 PTRs will have the same level of
trust with auto-gen'ed v6 that they do with v4. Folks that don't trust
it now still won't and those that find it acceptible in v4 will accept
it in v6.

marka> The occasional customer will add a offensive PTR record which
marka> won't be seen by 99.99999% of the world.
[...]
marka> If we recommend that this is only done when a forward record is
marka> also successfully added UPDATE + TSIG (yes, this does scale for
marka> this use) you get rid of the PTR/A mis-match issues.

And we're definitely not talking about allowing customers to do dynamic
updates of forward records in this draft.

If you want that currently, you get a business account or use one of the
many services that allows that. Yes, it costs money. But most folks
don't seem to miss it in the consumer world and those that do find
someone willing to do it.

marka> For ip6.arpa you delegate to the customer along with the prefix
marka> delegation.  The customer has to deal with the space issues but
marka> uses the same mechanisms to add the PTR records and cleanup.

Because the mythical grandmother wants to deal with their own address
space. Right...

Most customers don't even know what DNS is, much less PTRs. They want to
get content, send emails and pictures of cats. As an ISP, it's our job
to make sure this works. $GENERATE in v4 does work. Auto-gen'ed PTRs in
v6 works as well as $GENERATE, no better, no worse.

marka> You get the equivalent of $GENERATE with customer settable
marka> overrides using UPDATE over TCP.

And I want 10s of millions of users doing TCP to my auth servers? I
think not. Certainly not for something of so little gain to my
customers.

ebersman> Anti-spam folks *like* it that it's not trivial to get
ebersman> "correct" rDNS/PTRs. It's easy to find consumer connections
ebersman> based on the ISP doing bulk/lazy PTR generation and just
ebersman> reject SMTP traffic from them.

marka> Which won't work in IPv6 unless you syntesize the records on
marka> demand.

And that's the plan, at least for $DAYJOB. And sign on the fly for those
of us signing our zones.

ebersman> Large ISPs don't care about clean PTRs as long as no customers
ebersman> complain and they don't care if end customers can't do SMTP
ebersman> without having to ask for it in some special way.

marka> Except autogenerated PTR records don't solve the problem.

How not? Works fine for v4 right now. Customers that want to do their
own email usually have to make a special request to their ISP but can
do it. Biz connections are allowed to do their own PTRs at most ISPs,
assuming the customers want and need it. And if they do "clean" PTRs as
part of this, the anti-spam folks are happy.

ebersman> What else in the way of tradeoffs is missing?

marka> That people want IP to name mappings for their internal networks.

Get a biz connection or a service to allow this.

marka> With things like DNSSEC you need break DNSSEC trust chains at the
marka> ISP level for this to work.

Even our biz customers mostly don't do or want DNSSEC on PTRs. As this
changes, we'll figure out how to do this as a service. But all the work
of getting in DS and doing clean zone cut and delegation has nothing to
do with this draft either.

marka> We also don't know what else will come along to use the reverse
marka> namespace.  It is a good place to hang keying material which is
marka> tied to IP address.

So you're volunteering to work on a draft mentioned documenting how
folks are using PTR space? Thanks!

marka> Having a well defined method to update this name space will be
marka> useful.

Another draft. But not this one. If such a method did already exist,
worked and had at least reference implementations, it would certainly be
worth mentioning in this draft.

---

From: Evan Hunt <[email-masked]>
Date: Thu, 6 Nov 2014 17:03:02 +0000

> And that's the plan, at least for $DAYJOB. And sign on the fly for those

I'm going to take the risk of embarrassing myself in public and ask the
stupid thing I've been wondering:  Is there a reason not to use wildcard
PTRs?

        $ORIGIN 6.7.6.2.7.6.7.0.1.0.0.2.ip6.arpa.
        *       604800  IN      PTR     home-ipv6-customer.isp.net.

This way, a PTR would exist for every address, so broken sshd and similar
daemons will work.  It's easy to grep for, so antispam folks should be
content.  The wildcard record can be signed, which is trickier to do with
on-demand PTR synthesis.  If you want to sell a customer their own PTR
or delegated reverse zone, you still can.

You don't end up with a unique PTR for each address, and you'll get 
answers for addresses that aren't in use... but those kind of seem like
features, not bugs.  Also, it's cheap.

So, are there technical reasons not to do this, or is it just conceptual
inertia from the use of $GENERATE for v4?

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: joel jaeggli <[email-masked]>
Date: Thu, 06 Nov 2014 09:23:18 -0800

> can't be an FYI, BCP or similar, right?

BCP requires consensus after a fashion very similar to a standards track
document.

something with no-consensus basis would probably go to the ISE. Some
that people do not oppose publication of even if they disagree with it
might be informational.

but this is all jail-house lawyering, if the w.g. can't build a
consensus then it doesn't advance as a w.g. document.

---

From: "John Levine" <[email-masked]>
Date: 6 Nov 2014 17:33:10 -0000

>        *       604800  IN      PTR     home-ipv6-customer.isp.net.

This turns out to be a Well Known Bad Idea (WKBI).

Most PTR checks look up the name to be sure there's a matching forward
(AAAA in this case) record, and ignore them if there isn't.  You can't
do that with wildcard PTRs unless you have some way of serving 2^64
AAAA records in a single response.

R's,
John

PS to the literal minded: yes, I know that's impossible.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 6 Nov 2014 09:41:57 -0800

On Nov 6, 2014, at 9:33 AM, John Levine <[email-masked]> wrote:
> (AAAA in this case) record, and ignore them if there isn't.  

I think Evan was proposing that home-ipv6-customer.isp.net would also exist, so a PTR check that looked for *existence* would succeed, but one that looked for *matching* would fail for most of those addresses.

Do we know whether typical PTR checks look for existence or matching?

--Paul Hoffman

---

From: Evan Hunt <[email-masked]>
Date: Thu, 6 Nov 2014 17:46:54 +0000

> (AAAA in this case) record, and ignore them if there isn't.

I see.  Too bad.  Is it any more feasible to adjust expectations for v6 in
this respect than it was when we were talking about not providing PTR for
v6 in the first place?

For whatever it's worth I've been running with a wildcard PTR for my
hurricane-tunnel v6 network at home for more than four years.  It's only a
dozen or so addresses, but I haven't hit any obvious problems.

---

From: "John Levine" <[email-masked]>
Date: 6 Nov 2014 17:48:16 -0000

>I think Evan was proposing that home-ipv6-customer.isp.net would also exist, so a PTR check that looked for
>*existence* would succeed, but one that looked for *matching* would fail for most of those addresses.
>

The ones I know all look for matching.  

It's too easy for a malicious or negligent provider (typically in
eastern Europe or Asia) to stick in PTRs like mail.google.com.

R's,
John

---

From: Paul Vixie <[email-masked]>
Date: Thu, 06 Nov 2014 09:52:23 -0800

> Paul Hoffman <mailto:[email-masked]>
> Thursday, November 06, 2014 9:41 AM
>
> ...
>

in postfix, it's matching.

-- 
Paul Vixie

---

From: Evan Hunt <[email-masked]>
Date: Thu, 6 Nov 2014 17:54:10 +0000

> Do we know whether typical PTR checks look for existence or matching?

Matching could work, too, if they were able to compare prefixes rather
than full addresses, but that's obviously a bigger leap.

I suspect John is correct and the idea isn't practical. Alas. Thanks
for the education, carry on.

---

From: "John Levine" <[email-masked]>
Date: 6 Nov 2014 17:56:20 -0000

>this respect than it was when we were talking about not providing PTR for

Considering the security issues involved, I sure hope not.

>dozen or so addresses, but I haven't hit any obvious problems.

I see a lot of v4 PTRs that don't forward resolve when doing header
analysis for spam reports.  The majority just seem sloppy, but a fair
number are malicious and try to impersonate someone.

R's,
John

---

From: Paul Vixie <[email-masked]>
Date: Thu, 06 Nov 2014 10:01:55 -0800

> Evan Hunt <mailto:[email-masked]>
> Thursday, November 06, 2014 9:46 AM
>

sadly, ipv6 isn't deployed enough that a v6-only end host can get real
work done, but ipv6 is however deployed just well enough that we can't
change what PTR means at this point. see also:

http://www.circleid.com/posts/20110607_two_stage_filtering_for_ipv6_electronic_mail/

noting that in 2011 it was already too late for foundational
recommendations on ipv6.

-- 
Paul Vixie

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 6 Nov 2014 13:09:09 -0500

> Do we know whether typical PTR checks look for existence or matching?

It depends.  (We covered this to some extent in that failed
reverse-tree draft.)

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Ebersman <[email-masked]>
Date: Thu, 06 Nov 2014 12:57:52 -0700

phoffman> Do we know whether typical PTR checks look for existence or
phoffman> matching?

johnl> The ones I know all look for matching.  

For MX/spam and for VPNs, seems to want matching. For more "fringe" uses
like NYT web, seems to just want a non-NXDOMAIN response.

I'd be nervous about wildcard more because there seems to be a fair
amount of variation in implementations (or folks who don't read RFCs but
play with DNS...).

---

From: Mark Andrews <[email-masked]>
Date: Fri, 07 Nov 2014 09:35:15 +1100

> it now still won't and those that find it acceptible in v4 will accept

And why can't we improve IPv4 at the same time using the same
mechanisms?

Also the examples are easier to type into a 80 column window.  The
only difference between IPv4 and IPv6 on the client node is the
name of the PTR record.

> updates of forward records in this draft.

With IPv4 most ISPs supply both fake/generic forward and reverse
zones for those that check PTR records with A lookups.

> someone willing to do it.

Actually it is often impossible to find a ISP "willing + same or
better speed" let alone for a reasonable price.  Sometimes you can't
get it for any price at any speed because the end point of the
connection is in a residence and the only ISP's servicing the area
won't sell a "business class" connection to the address.

So no, "get a business account" is *not* a viable alternative.

I'm and sick and tired of "Were the phone company and you just have to
lump it" which is all this alternative is.

> think not. Certainly not for something of so little gain to my

Well I can also do a solution which uses KEY's submitted via DHCP and
works over UDP.

TCP happens to work well for SLAAC in the home but it is conceptually
trivial to send KEY rdata via DHCP and have the DHCP server add the
record so that the DNS update can be done over UDP for those using
DHCP.  Yes, I have written a draft on how to do this with PD but
similar logic works for a single address.

DHCP servers already do dynamic updates of reverse zones so this
is just adding a different record compared to the PTR record they
currently do.  I would expect it would take about a day to add the
logic to do this once a code point for the DHCP option is assigned.

Nameservers already support updating of records based on self
referential KEY records for the name alone or the name and subzone
beneath it.  We have shipped one which does this for over a decade
now.

	update-policy {
		grant <dhcp-server-key> subzone * ANY;
		grant * self * PTR KEY;	// explict list of type updatable
		// grant * self * ANY;	// all types except NSEC and NSEC3
		// grant * self *;	// all types except RRSIG, NS, SOA,
					// NSEC and NSEC3
		// grant * selfsub *;   // Allow the key name and anything
					// under it.
	};

The KEY record is in the zone so it is already trusted.  This doesn't
require the zone to be signed.

The rest of the cleanup logic still works.

One could simulate this today with just named and nsupdate.

Simulate DHCP server add/update of KEY record (I'm using in-addr.arpa
because it is easier to type).

	nsupdate -k Kdhcp-server-key
	update add 4.3.2.1.in-addr.arpa 3600 IN KEY ...
	send
	
Simulate node update

	nsupdate -k K4.3.2.1.in-addr.arpa
	update add 4.3.2.1.in-addr.arpa 3600 IN PTR ....
	send

> And that's the plan, at least for $DAYJOB. And sign on the fly for those

Then you are telling me that you intend to break reverse lookups
done by home users that setup ip6.arpa zones for the address space
delegated to them with PD.  Or are you telling me that you customers
are not allowed to even setup PTR records within the home for the
address space delegated to them?

> do with this draft either.

But it has to be considered.
 
> worth mentioning in this draft.

	update-policy tcp-self exists and is available in millions
	of servers today.  It just needs to be turned on.

	I've implemented

---

From: Tony Finch <[email-masked]>
Date: Fri, 7 Nov 2014 13:14:42 +0000

> The ones I know all look for matching.

My understanding is that mail servers will often just do existence checks
because the matching check causes too much trouble for legitimate mail.
(My servers don't enforce these checks so I don't have first-hand
experience.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southeast Iceland: Cyclonic 5 or 6, becoming northerly gale 8 to storm 10
later. Rough becoming very rough or high. Occasional rain. Moderate or poor.

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 7 Nov 2014 09:11:45 -0500

Joel,

Thanks for this clarification on the process, I was on a plane :-)

> consensus then it doesn't advance as a w.g. document.

This is the important point. I tend to think we should have a topic/question/issue and a consensus to work on it before we get too concerned about a document status; it's an important detail, especially if we want a document status that requires IETF consensus for publication (standard or BCP), but finalizing it can be part of finalizing the document.

In this particular discussion, I've heard multiple positions stated on the technical/operational issues and multiple opinions on where a consensus could be, if any. The extent and thoughtfulness of the discussion suggest there's indeed work to do for us here.

Personally, I'd like to see us attempt to document the landscape, including consensus where we have it and description where we don't, but I understand the reason for skepticism.

Suzanne

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 9 Nov 2014 18:36:01 +0100

On Thu, Nov 06, 2014 at 08:26:17AM +0100,
 [email-masked] <[email-masked]> wrote 

> incentive to let my residential customers create their own PTR records.

Putting my customer hat on: I want PTR for my machines (many hosters
allow it, like Linode or Gandi). Is it sufficient incentive for a
provider? "N customers want it, with N > 0"

---

From: [email-masked]
Date: Sun, 09 Nov 2014 19:05:44 +0100 (CET)

> provider? "N customers want it, with N > 0"

Business customers can already have static IPv6 PTRs, no problem.

Residential customers and the proposed scheme of dynamically creating/
updating PTRs: N would have to be "sufficiently large", or there would
have to be other reasons (e.g. competitive pressure). Even if these
conditions were fulfilled, it would still be prioritized against many
other requirements.

In other words: Don't hold your breath.

Steinar Haug, AS 2116

---

From: Paul Ebersman <[email-masked]>
Date: Sun, 09 Nov 2014 12:01:32 -1000

To step back up a level again.

Most ISPs and most email/spam folks find the current v4 pointer usage to
be functional. I'm not saying that we all think it's not somewhat
broken, couldn't be better, etc. However, it solves the problems it's
supposed to solve in a functional way and doesn't generate lots of
customer complaints.

This draft basically outlines how to get more or less the same level of
functionality and trust that exists in v4 in v6. The techniques being
described in the draft are in use or being implemented soon and there is
value in having an IETF draft that documents what is being done and what
the operational tradeoffs are.

Describing current state of operations and operational tradeoffs is the
DNSOP bailiwick.

There have been several comments about wanting to clean up PTR usage,
either doing better in v6, or in both v4 and v6. There were also several
folks observing that documenting how PTRs are actually being used would
be handy.

I think both a "how are PTRs currently used" and a "how to do better
with PTRs" are both useful but should be separate drafts from this
one.

I'd even push that the "how to do better" talk about v4 and v6. As an
operator, I'm not sure when or if I'd ever be allowed to spend resources
to clean things up. However, if we can document what will actually break
and how and why to better and there's some business problem solved or
business opportunity created, I might have a fighting chance of getting
resources to do this.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 9 Nov 2014 12:08:28 -1000

On Nov 9, 2014, at 12:01 PM, Paul Ebersman <[email-masked]> wrote:
> be functional.

This assertion with respect to spam at least does not seem to match what's actually been said on the list by people who are in a position to know.

---

From: Ralf Weber <[email-masked]>
Date: Sun, 9 Nov 2014 16:54:13 -0600

Moin!

Read this draft on the way to the IETF and while saw there was a lot of discussion around it I didn't read all of it, so forgive me if stuff has been said before.

First I think it is good to have a draft that captures what you can do and what the challenges for IPv6 reverse are. However as the discussion on what is the best way to do will never come to an end as people have strong opinions on that we should leave that or the recommendations section out of the draft and just publish it as informational. You could if you want to leave that section in just say that there is no clear way to recommend anything as there are different scenarios that apply to different operators and that everybody has to pick their own poison ;-).

One thing I would like to see added is delegating reverse and corresponding forward to CPE (homenet router), but serving it out of the service providers name servers as described in https://tools.ietf.org/html/draft-mglt-homenet-front-end-naming-delegation-04 (full disclosure I am co-author of this). While I like the idea of delegating the naming responsibility to the end user/home I personally don't think it is a good thing for the Internet to generate millions of DNS servers on CPE devices as we already have enough problems with that (http://openresolverproject.org granted different kind of dns server/proxy but I assume hackers will find way to abuse these also).

So long
-Ralf
---
Ralf Weber
e: [email-masked]

---

From: P Vixie <[email-masked]>
Date: Sun, 09 Nov 2014 15:19:42 -0800

On November 9, 2014 2:08:28 PM PST, Ted Lemon <[email-masked]> wrote:
>This assertion with respect to spam at least does not seem to match
>what's actually been said on the list by people who are in a position
>to know.

Indeed not. We currently have to maintain a large and complex distributed registry of ipv4 ptr patterns which are meaningless and must therefore be filtered out before making policy decisions about the presence/absence and match/doesn't of a ptr record and it's associated a record.

V6 should attempt to be better than v4 in this regard. In fact v4 should attempt to improve in this regard.

Functional at high cost and risking complexity collapse every day and twice on Sunday is not a status quo to love, not to copy from v4 to v6.

Vixie
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Paul Ebersman <[email-masked]>
Date: Sun, 09 Nov 2014 15:28:40 -1000

vixie> Indeed not. We currently have to maintain a large and complex
vixie> distributed registry of ipv4 ptr patterns which are meaningless
vixie> and must therefore be filtered out before making policy decisions
vixie> about the presence/absence and match/doesn't of a ptr record and
vixie> it's associated a record.

You are already doing this, correct? Not good, has pain, but at least in
place?

And if I used a generation method for v6 that exactly matched v4, I'd
just get caught in exactly the same filters, right?

I know you want to make things better but does adding v6 records with
the same format make things worse or just no better? If the current v4
is so fragile, it will break at any minute, you're already at risk. If
what I produce in v6 adds no new checks, it should add no new risks;
only the risk you have in v4 already.

vixie> V6 should attempt to be better than v4 in this regard. In fact v4
vixie> should attempt to improve in this regard.

It's a nice thought. But considering how little we've converged on SLAAC
vs DHCPv6, random assignment vs eui-64 vs static for host ID, RFC 6106
vs DHCPv6 DNS, etc. (and I won't even start on how many IPv6 transition
techs there are), any consensus on "better" is going to be a fascinating
trick.

I have already mentioned that you and others are interested in some PTR
usage solution that is better for both v4 and v6. And having actual real
data on what is using PTRs in v4 and how as a second draft. I'd love to
have real data to make an informed choice.

I'm just suggesting that doing so is two drafts and significant effort
on their own.

paul> Functional at high cost and risking complexity collapse every day
paul> and twice on Sunday is not a status quo to love, not to copy from
paul> v4 to v6.

And what's the plan for v4 if collapse is imminent? Who's working on it?
And I sure hope it isn't that v6 will just replace v4, if time is of the
essence.

Large providers, including my $DAYJOB, are already looking at
what/where/how we should do PTRs in v6. Going back to management and
saying that we need to completely redo v4 (which they view as already
working) and do v6 in some complicated way isn't something they're going
to buy into without solid business case for cost savings and/or new
income stream. So far, I haven't heard anything like those, for this
draft or in potential new drafts.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 10 Nov 2014 12:35:21 +1100

In message <[email-masked]>, Ralf Weber writes:
> Moin!
> 
> Read this draft on the way to the IETF and while saw there was a lot of discu
> ssion around it I didn't read all of it, so forgive me if stuff has been said
>  before.
> 
> First I think it is good to have a draft that captures what you can do and wh
> at the challenges for IPv6 reverse are. However as the discussion on what is 
> the best way to do will never come to an end as people have strong opinions o
> n that we should leave that or the recommendations section out of the draft a
> nd just publish it as informational. You could if you want to leave that sect
> ion in just say that there is no clear way to recommend anything as there are
>  different scenarios that apply to different operators and that everybody has
>  to pick their own poison ;-).
> 
> One thing I would like to see added is delegating reverse and corresponding f
> orward to CPE (homenet router), but serving it out of the service providers n
> ame servers as described in https://tools.ietf.org/html/draft-mglt-homenet-fr
> ont-end-naming-delegation-04 (full disclosure I am co-author of this). While 
> I like the idea of delegating the naming responsibility to the end user/home 
> I personally don't think it is a good thing for the Internet to generate mill
> ions of DNS servers on CPE devices as we already have enough problems with th
> at (http://openresolverproject.org granted different kind of dns server/proxy
>  but I assume hackers will find way to abuse these also).

For the home user CPE you use DNS COOKIES / SIT or push to TCP.  These should
be low volume authoritative server.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 9 Nov 2014 18:25:51 -1000

> techs there are), any consensus on "better" is going to be a fascinating

This is not an accurate representation of the situation.   There are some people who see DHCPv6 versus SLAAC as an ideological problem rather than a choice between features, but this is completely orthogonal to the DNS issue.   There is real work going on on the DNS problem, and while it's not clear everyone will want to deploy a nice solution, I don't think there's any serious argument within the IETF that such a solution should not be deployed, nor is there serious contention over how to do it (although there are several options).   I don't _think_ there are any ideological disputes; the question is simply which solution is best for any particular use case.   And, of course, actually getting the documents done that describe the several different ways of approaching the problem.

---

From: "John Levine" <[email-masked]>
Date: 10 Nov 2014 08:59:35 -0000

>just get caught in exactly the same filters, right?

No.  There are a zillion formats for generic v4 rDNS names.  Most of
them embed some version of four octets of the IP address, so for v6 it
would of necessity be different.

Also keep in mind that doing generic rDNS for v6 requires awful
kludges of some sort.  For v4 you can generate it statically and
forget about it but for v6 you need a stunt server that synthesizes
names on the fly, or a hack in the router that inserts entries into
the reverse zone when it sees traffic from a host, or something.  The
kludges add no value, so let's not.

My preference is that hosts that are supposed to be globally visible
servers or mail clients should have static addresses with static
forward and reverse DNS.  Other hosts use SLAAC and have neither.

R's,
John

---

From: [email-masked]
Date: Mon, 10 Nov 2014 10:16:54 +0100 (CET)

> just get caught in exactly the same filters, right?

If you assume that IPv6 mail servers have static PTRs, there is zero
added value (and a bit of work) in creating/synthesizing IPv6 PTRs for
residential customers. Much better to simply not do it in the first
place.

Steinar Haug, AS 2116

---

From: Paul Ebersman <[email-masked]>
Date: Sun, 09 Nov 2014 23:31:44 -1000

sthaug> If you assume that IPv6 mail servers have static PTRs, there is
sthaug> zero added value (and a bit of work) in creating/synthesizing
sthaug> IPv6 PTRs for residential customers. Much better to simply not
sthaug> do it in the first place.

I'm in agreement that "legitimate", well run mail servers will have
static forward and reverse in v6.

My concern is random folks who currently accept any v4 PTR regardless of
format (but caring if there is no PTR at all) will do something equally
bad in v6. i.e. NYT web content and similar pointless cruft. Putting in
an auto-gen'ed v6 PTR would satisfy that level of check.

---

From: Paul Ebersman <[email-masked]>
Date: Sun, 09 Nov 2014 23:57:24 -1000

ebersman> It's a nice thought. But considering how little we've
ebersman> converged on SLAAC vs DHCPv6, random assignment vs eui-64 vs
ebersman> static for host ID, RFC 6106 vs DHCPv6 DNS, etc. (and I won't
ebersman> even start on how many IPv6 transition techs there are), any
ebersman> consensus on "better" is going to be a fascinating trick.

TLemon> This is not an accurate representation of the situation.   There
TLemon> are some people who see DHCPv6 versus SLAAC as an ideological
TLemon> problem rather than a choice between features, but this is
TLemon> completely orthogonal to the DNS issue.

Sorry. Unclear analogy. Not conflating v6 and DNS, just pointing out
that reaching consensus when we have non-compatible operational views
and requirements tends to not lead to a solution in any real time frame.

Proponents of SLAAC vs DHCPv6 tend to have different pain points and
biases based on how they run their networks and we aren't likely to come
to a meeting of the minds any time soon due to those differing needs.

Not saying either network design is wrong or bad either. Just saying
that different needs means we won't get a "one size fits all" solution.

TLemon> There is real work going on on the DNS problem, and while it's
TLemon> not clear everyone will want to deploy a nice solution, I don't
TLemon> think there's any serious argument within the IETF that such a
TLemon> solution should not be deployed, nor is there serious contention
TLemon> over how to do it (although there are several options).  I don't
TLemon> _think_ there are any ideological disputes; the question is
TLemon> simply which solution is best for any particular use case.  And,
TLemon> of course, actually getting the documents done that describe the
TLemon> several different ways of approaching the problem.

I'd agree that we all would like the option of a "nice" use of PTRs. It
does seem like there are two sets of conflicting pain points for which
it's not clear to me there is a compromise in what we're talking about
in this draft.

The two groups with obvious pain points are:

  - service providers who want a way to avoid breaking things for
    customers while not being operationally complicated/insane

  - mail/spam folks who seem to be saying that the current v4 method is
    a time bomb that will explode any minute, is unmaintainable and
    doing v6 the same way is untenable to them

Doing autogen'd PTRs in v6 violates the anti-spam folks' needs. Not
having any PTR at all for consumers potentially violates the ISP needs.

Things I don't know that anyone knows for sure but make it hard to reach
consensus on a solution:

  - what are the various interesting/crazy/insane uses PTRs in v4 now
    (beyond the mail req of forward/reverse existing and matching),
    i.e. what will break now and in the future if there are no v6 PTRs
    for consumer IPs if content providers do the same uses in v6

  - how much is the current v4 autogen being done by ISPs truly breaking
    mail/spam, how/when/how-soon will it explode and how much additional
    stress/breakage would doing v6 autogen add

---

From: Ted Lemon <[email-masked]>
Date: Mon, 10 Nov 2014 06:29:17 -1000

> an auto-gen'ed v6 PTR would satisfy that level of check.

The status quo is that the ISP doesn't add a PTR record for a customer IPv6 address, nor delegate the zone.   Lots of IPv6 users are getting by just fine right this very moment (including me) without this.   So I think it's safe to say that we do not need to solve this problem: if there is damage, it has already been routed around.   So really all we need to talk about is whether there are features to add, not whether we need to fix something right now.   It's already too late for that.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 10 Nov 2014 06:33:49 -1000

On Nov 9, 2014, at 11:57 PM, Paul Ebersman <[email-masked]> wrote:

>    stress/breakage would doing v6 autogen add

So it's not clear to me that there is a problem reaching consensus on what we should do.   It's not even clear to me (as I explained in my previous message) that there is a problem or a pain point here for IPv6.   It's pretty clear to me that the only sensible thing the IETF could do would be to say "this isn't a problem, please don't add fake PTR records."   And then ISPs would do whatever they do, regardless of what we recommend.   My hope is that they would not _anticipate_ a problem that does not actually exist, and create complex wonderfulness in their DNS architecture purely to solve that possibly nonexistent problem.

---

From: Paul Ebersman <[email-masked]>
Date: Mon, 10 Nov 2014 08:32:11 -1000

ebersman> My concern is random folks who currently accept any v4 PTR
ebersman> regardless of format (but caring if there is no PTR at all)
ebersman> will do something equally bad in v6. i.e. NYT web content and
ebersman> similar pointless cruft. Putting in an auto-gen'ed v6 PTR
ebersman> would satisfy that level of check.

TLemon> The status quo is that the ISP doesn't add a PTR record for a
TLemon> customer IPv6 address, nor delegate the zone.   Lots of IPv6
TLemon> users are getting by just fine right this very moment (including
TLemon> me) without this.  So I think it's safe to say that we do not
TLemon> need to solve this problem: if there is damage, it has already
TLemon> been routed around.

This is a lovely thought. And I really hope it's true. I've thought
since the early 90s that most things we did with PTRs other than network
interfaces were questionable usefulness for pain that we're still
dealing with supporting.

However, I'm concerned that this (v6 working fine without already) is
just as much an unsupported assumption as that we must support PTRs for
content with no good data (other than various anecdotal stories) and no
idea of what would break if we didn't do them.

IPv6 is still in early adoption for broad general use and we don't know
what plans folks have for requiring PTRs.

TLemon> So really all we need to talk about is whether there are
TLemon> features to add, not whether we need to fix something right now.
TLemon> It's already too late for that.

I would still like to see:

  - actual data on how/where PTRs are being used and abused now (beyond
    the known mail filtering) to see if any of those folks are planning
    on continuing the bad idea into v6

  - suggestions on how/if we can clean PTR usage, v4 and v6

I'm not expecting anything I'll be able to use to clean up current v4
usage, but I'd love to be pleasantly surprised. If someone does come up
with a solid performance/efficiency improvement or a biz case for
keeping better track and use, I'd certainly take that to my mgmt.

As for the current draft, if it doesn't happen, I'll still need to cope
with customer breakage and vendors will produce solutions that customers
like me pay for. I'd much rather have a consistent approach across
vendors and guidance in the IETF I can point to but I will probably have
to do something about PTRs in the next year or two. And it will probably
be something icky but less icky than screaming customers...

---

From: [email-masked]
Date: Mon, 10 Nov 2014 19:55:20 +0100 (CET)

> idea of what would break if we didn't do them.

To me this is really simple: If many/most ISPs continue *not* adding
useless/artificial/synthesized PTRs, the content / server people will
have no choice - if they want their content to get out and their
services to be used by the large majority of IPv6 users, they'll have
to accept connections from IPv6 addresses without PTRs.

>     on continuing the bad idea into v6

Speaking only for myself: We're not planning to add useless IPv6 PTRs.

Steinar Haug, AS2116

---

From: Paul Ebersman <[email-masked]>
Date: Mon, 10 Nov 2014 09:50:39 -1000

sthaug> To me this is really simple: If many/most ISPs continue *not*
sthaug> adding useless/artificial/synthesized PTRs, the content / server
sthaug> people will have no choice - if they want their content to get
sthaug> out and their services to be used by the large majority of IPv6
sthaug> users, they'll have to accept connections from IPv6 addresses
sthaug> without PTRs.

One hopes... I would certainly love to not have to do (yet more) crap
PTRs. I'm just not as optomistic that stupid people aren't really really
persistent.

And I'd still love to get better data on how it's currently used. If I
could also stop doing the v4 crap and not have users screaming, that's a
large pain point gone.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 10 Nov 2014 10:52:09 -1000

> what plans folks have for requiring PTRs.

I apologize for picking and choosing from your response, but I think this sums it up perfectly: if we do not yet know what plans they have, then we need not care.   There is currently no support in any infrastructure of which I am aware for populating the reverse tree in IPv6 for customer IP addresses.   Lots of customers are using IPv6, and are not having issues.   It is indeed early days, but Comcast's deployment, and other deployments of which I am aware, are seeing real use by real users.

So if e.g. Comcast were coming to us right now and saying "we're getting a lot of phone calls because of foo," then we could talk about foo.   But that's not happening, as far as I can tell.   IOW, you are borrowing trouble.

Please don't borrow trouble.   At present we do not need to clean up the IPv6 reverse tree.   If we say anything about the reverse tree, it should be with the goal in mind of preserving that pleasant status quo.

---

From: Paul Ebersman <[email-masked]>
Date: Mon, 10 Nov 2014 11:10:12 -1000

ebersman> IPv6 is still in early adoption for broad general use and we
ebersman> don't know what plans folks have for requiring PTRs.

TLemon> I apologize for picking and choosing from your response, but I
TLemon> think this sums it up perfectly: if we do not yet know what
TLemon> plans they have, then we need not care.
[...]
TLemon> So if e.g. Comcast were coming to us right now and saying "we're
TLemon> getting a lot of phone calls because of foo," then we could talk
TLemon> about foo.

Comcast (or any large company/provider) does not move nimbly. The IETF
does not move nimbly. Vendors do not implement what the IETF specifies
energetically without beating/cash.

I'm sympathetic to the idea that I should avoid borrowing
trouble. However, I'd say that looking ahead and trying to be prepared
for things that seem likely is not borrowing trouble; it's being
prepared.

If I wait until I have screaming customers, I have months and months of
hell before I have any solution.

Hence why I'm suggesting that we document v4 PTR usage and make
recommendations on what we think are appropriate usage. If we can get a
better idea of what bad ideas are being done now and try to folks to not
do this, then we can indeed maintain the pleasant status quo in v6 PTRs.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 10 Nov 2014 11:24:18 -1000

> hell before I have any solution.

So deploy the solutions the IETF is already working on.   You are proposing we do something bad to solve a problem that demonstrably does not exist, when we are already pursuing a solution that would be good, not bad.

---

From: George Michaelson <[email-masked]>
Date: Tue, 11 Nov 2014 17:29:06 -1000

I'll take a dollar for every query in PTR we take at the ipv4  /8 and Ipv6
/12 level. Thats somewhere around 170,000/sec.

Luckily, you'll all stop before I have the entire western economy in my
pocket, but thats ok. I'll take the cents.. I'll take the millicents...

Seriously: the volume of query is not small. It may be pointless but by
golly its popular.

What do people do with it? I have no idea. But as long as people want to
query, the RIR are happy to anchor the domains.

-G

On Mon, Nov 10, 2014 at 11:24 AM, Ted Lemon <[email-masked]> wrote:

> So deploy the solutions the IETF is already working on.   You are
> proposing we do something bad to solve a problem that demonstrably does not
> exist, when we are already pursuing a solution that would be good, not bad.
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Nov 2014 17:36:14 -1000

On Nov 11, 2014, at 5:29 PM, George Michaelson <[email-masked]> wrote:
> What do people do with it? I have no idea. But as long as people want to query, the RIR are happy to anchor the domains.

I think that a lot of the queries are useful in theory, e.g., queries that present human readable names for legitimate hosts.   I think a lot are completely useless.   I personally think that making it possible to put accurate information in the reverse DNS is a really good idea; putting bogus data in the reverse DNS as a sacrifice to the line eater is not.

(If you don't get the reference to the line eater, think "ancient, stupid, obsolete bug.")

---

From: Paul Vixie <[email-masked]>
Date: Tue, 11 Nov 2014 22:27:36 -0800

> Ted Lemon <mailto:[email-masked]>
> Tuesday, November 11, 2014 7:36 PM
>
> I think that a lot of the queries are useful in theory, e.g., queries
> that present human readable names for legitimate hosts. I think a lot
> are completely useless. I personally think that making it possible to
> put accurate information in the reverse DNS is a really good idea;
> putting bogus data in the reverse DNS as a sacrifice to the line eater
> is not.

+1!
> (If you don't get the reference to the line eater, think "ancient,

:-)!

-- 
Paul Vixie