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

From: Mwendwa Kivuva <[email-masked]>
Date: Thu, 23 Oct 2014 14:23:01 +0300

Refering to the draft by Lee Howard
https://tools.ietf.org/html/draft-howard-dnsop-ip6rdns-00

and given the weakness of the Reverse DNS access for security purposes,
what problem is this draft trying to solve? If we need to find the host
that has sent an email associated with an address, would we better let DKIM
address that without a separate lookup in the receiving server? DKIM
detects email spoofing by using digital signature allowing receiving mail
exchangers to check that incoming mail from a domain is authorized by that
domain's administrators.

Is there a better way to approach the problem?

______________________
Mwendwa Kivuva, Nairobi, Kenya

---

From: Hosnieh Rafiee <[email-masked]>
Date: Thu, 23 Oct 2014 11:59:03 +0000

and given the weakness of the Reverse DNS access for security purposes, what problem is this draft trying to solve? If we need to find the host that has sent an email associated with an address, would we better let DKIM address that without a separate lookup in the receiving server? DKIM detects email spoofing by using digital signature allowing receiving mail exchangers to check that incoming mail from a domain is authorized by that domain's administrators. 

I do not claim it is a best way but I think CGA-TSIG can easily handle many similar scenarios.
You can check the old version here
http://datatracker.ietf.org/doc/draft-rafiee-intarea-cga-tsig/
and upcoming version here
<http://editor.rozanak.com/show.aspx?u=AZCDD03D4DBABD14DA80CDTAM  >

Hosnieh

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Oct 2014 10:02:36 -0400

> and given the weakness of the Reverse DNS access for security purposes, what problem is this draft trying to solve? If we need to find the host that has sent an email associated with an address, wo…

For me at least the main values of the reverse DNS are:

- answers the question "what host is contacting me" in situations where I am _not_ under attack, which is really useful in logs and other debugging and network management settings.
- provides place to hang information relating to a host's IP address

DKIM is a solution that is applicable only to a specific protocol, so it can't address this in a general way.   Like you I would like to see the end of the use of reverse lookups for "security," but reverse lookups are still useful.

---

From: Lee Howard <[email-masked]>
Date: Thu, 23 Oct 2014 11:18:55 -0400

From:  Mwendwa Kivuva <[email-masked]>
Date:  Thursday, October 23, 2014 7:23 AM
To:  dnsop <[email-masked]>
Subject:  [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

> and given the weakness of the Reverse DNS access for security purposes, what
> problem is this draft trying to solve?

There is a common expectation that ISPs will populate PTR records for their
customers.

In my opinion, that is an unreasonable expectation, since ISPs do not have
host names for customers, so they usually make up a name. That seems pretty
useless to me. However, I don't think that is a consensus opinion, so it's
not what the draft says.

The problem I'm trying to solve is how to do that in IPv6. I think the
recommendations do represent consensus: try to get host names and reverse
zone under the same authority (whether home or ISP), or have the authority
inform the other.  If you can't do that, making something up is better than
nothing, but not strictly required.

>  If we need to find the host that has sent an email associated with an
> address, would we better let DKIM address that without a separate lookup in
> the receiving server? DKIM detects email spoofing by using digital signature
> allowing receiving mail exchangers to check that incoming mail from a domain
> is authorized by that domain's administrators.

Absolutely!
It may be reasonable to say that all legitimate mail servers will have a PTR
record that matches an A/AAAA record; that alone is not enough to decide
that a sender is safe.
The only mention in the draft is this:
   For instance,
   most email providers will not accept incoming connections on port 25
   unless forward and reverse DNS entries match.  If they match, but
   information higher in the stack (for instance, mail source) is
   inconsistent, the packet is questionable.  These records may be
   easily forged though, unless DNSsec or other measures are taken.  The
   string of inferences is questionable, and may become unneeded if
   other means for evaluating trustworthiness (such as positive
reputations) become predominant in IPv6.
I didn't specifically call out DKIM as one of those "other means for
evaluating trustworthiness," but I could.

Use of reverse DNS in email is only one use case for reverse DNS, and I
agree that relying on it is, well, "questionable."

Lee

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

---

From: Paul Vixie <[email-masked]>
Date: Thu, 23 Oct 2014 10:50:41 -0700

> Ted Lemon <mailto:[email-masked]>
> Thursday, October 23, 2014 7:02 AM
>
> - answers the question "what host is contacting me" in situations
> where I am _not_ under attack, which is really useful in logs and
> other debugging and network management settings.
> DKIM is a solution that is applicable only to a specific protocol, so
> it can't address this in a general way. Like you I would like to see
> the end of the use of reverse lookups for "security," but reverse
> lookups are still useful.

william simpson was right in 1996. we should have moved "get host name
corresponding to IP" to ICMP. the problems described by lee howard's
draft are proof that our whole model is wrong.

-- 
Paul Vixie

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Oct 2014 14:16:06 -0400

On Oct 23, 2014, at 1:50 PM, Paul Vixie <[email-masked]> wrote:
> william simpson was right in 1996. we should have moved "get host name corresponding to IP" to ICMP. the problems described by lee howard's draft are proof that our whole model is wrong.

Right, 'cuz there's nothing at all difficult about getting ICMP to work... :)

---

From: Paul Vixie <[email-masked]>
Date: Thu, 23 Oct 2014 11:27:54 -0700

> Thursday, October 23, 2014 11:16 AM
>

understood. but that's part of what makes this a good solution. systems
need to learn to live with hosts whose names they cannot guess. icmp
even when it gets through can be spoofed either by the remote system or
any intermediate system. that exactly matches the confidence and
dependency levels that hostname-depending programs should have.

internet service and internet access should be thought of differently.

william simpson's icmp idea came with the observation that only a host
can reliably report its own name, and only while it's up, because it
might have a new name from time to time.

the impedance mismatch between the understood and the possible in
today's PTR system led to the creation of <http://enemieslist.com/>
which allows those of us who want to know when a PTR was
machine-generated and that the host's actual name is "amnesia" and
should not be able to do the things that real hosts which actually have
names should do, can undo all the $GENERATE complexity that internet
access providers use to "jump through the hoops" of pretending that
their internet access IP addresses actually have host names, when in
reality, they don't and oughtn't.

-- 
Paul Vixie

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 24 Oct 2014 08:48:12 +0900

Paul Vixie wrote:

> william simpson was right in 1996. we should have moved "get host 
> name corresponding to IP" to ICMP. the problems described by lee 
> howard's draft are proof that our whole model is wrong.

Wrong. What's wrong is SLAAC, which is stateful in the worst
possible fashion with distributed state maintenance, which is
why extra overhead of DAD is mandated.

The proper solution is to ban SLAAC or, better, entire ND, which
purposelessly depends on multicast, complexity of which is
causing a lot of problems.

> william simpson's icmp idea came with the observation that only a
> host can reliably report its own name, and only while it's up,
> because it might have a new name from time to time.

You are right if we need reverse look up only.

However, as "it might have a new name from time to time" means
that the host must interact with DNS for updating forward look
up, an additional interaction (with different authority, in
general) for reverse look up is not bad.

It should be noted that, with DHCP, if a host is up, its DHCP
server, which have the authority for host's address, is
almost certainly up.

						Masataka Ohta

---

From: P Vixie <[email-masked]>
Date: Thu, 23 Oct 2014 19:52:07 -0400

Ohta-san, like you I would like to see stateless address auto configuration for ipv6 (SLAAC) die in a fire. Sadly this outcome is beyond our powers. Let's start from where we are, no matter how unpleasant that place may be. Vixie
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 25 Oct 2014 06:43:49 +0900

P Vixie wrote:

> Ohta-san, like you I would like to see stateless address auto 
> configuration for ipv6 (SLAAC) die in a fire. Sadly this outcome is 
> beyond our powers.

Not necessarily.

> Let's start from where we are, no matter how unpleasant that place
> may be. Vixie

>From where we are, fix broken part of the stack, not elsewhere, never.

						Masataka Ohta

---

From: Lee Howard <[email-masked]>
Date: Thu, 30 Oct 2014 17:26:08 -0400

On 10/23/14 5:17 PM, "Mark Andrews" <[email-masked]> wrote:

>
>In message <[email-masked]>, Lee Howard writes:
>> 
>> > and given the weakness of the Reverse DNS access for security
>>purposes, wha
>> t
>But it is not unreasonable to delegate a zone or to accept DNS UPDATE
>requests
>from the host you have just assigned a IP address to over TCP.

Not sure of the antecedent of "you."  If "you" are a DHCPv6 server, you
are not necessarily a DNS server authoritative for the ip6.arpa zone in
question and capable of accepting DNS updates. Especially if "you" are a
DHCPv6 server on a home router.

You (Mark Andrews, not the servers) have proposed mechanisms for
facilitating that communication; that would help.

>
>	zone "ip6.arpa" {
>		update-policy { grant * tcp-self * ptr; };
>	};
>
>	reverse=`arpaname ${ip_address}`
>	hostname=`hostname`

And residential hosts only know hostname, not domain name; is
"myMacBook.local" useful as a PTR?  I haven't checked with users of PTRs
to see what they think.

Lee

---

From: Warren Kumari <[email-masked]>
Date: Thu, 30 Oct 2014 17:47:42 -0400

On Thu, Oct 30, 2014 at 5:26 PM, Lee Howard <[email-masked]> wrote:
> "myMacBook.local" useful as a PTR?

How about  '() { :; }; nc -e /bin/bash localhost 666;' or
'TimeWarnerCableSux.local' or 'bigbank.net'

Allowing users to publish this may end poorly...

W

>  I haven't checked with users of PTRs
> to see what they think.
>
>
> Lee
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Doug Barton <[email-masked]>
Date: Thu, 30 Oct 2014 15:05:18 -0700

Lee,

I don't see any discussion in your draft about why rDNS is needed in 
this space. IME there are typically 2 uses cases:

1. "Residential" users, or more specifically, those who will not 
be/should not be running services on their addresses

2. "Commercial" users, who may be running things like mails servers

Obviously (and yes, I am being facetious since there is still 
controversy on this point in some quarters) the latter need the ability 
to run proper rDNS so that at minimum their mail servers can pass 
industry-standard (and arguably best practice) forward/reverse 
verification. Hopefully the solutions for that are obvious to the 
participants on this list.

However, for users that are not running services the primary desire 
(that I'm aware of) is to have an easy way to flag that those are ranges 
that we would not expect mail to come from. The guidelines for flagging 
"dynamic" addresses in the mailop community are well known for IPv4, but 
I don't see any mention of that in your draft (although admittedly, I 
only skimmed it).

So while on the one hand documenting that there are options for actually 
providing valid rDNS for end users probably has value (the "How") I 
don't see enough discussion about "Why?" to give me a good feeling about 
this draft. Particularly I would like to see some discussion about why a 
wildcard set at a high level for your "dynamic" range isn't a valid 
solution.

Doug

---

From: Mark Andrews <[email-masked]>
Date: Fri, 31 Oct 2014 10:01:14 +1100

> "myMacBook.local" useful as a PTR?  I haven't checked with users of PTRs

Which is basically because home users have been treated as second
class citizen on the Internet.  They couldn't get permanent addresses
as they had to be re-used just to keep the net working.  This is
no longer true with IPv6.

Lots of home users do actually have registered domainnames.   If you
make it simpler lots more will.

If you don't have a domain add a PTR record that points to <name>.itself
with a A / AAAA record which corresponds.

myMacBook.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa
is a legal hostname.  You could also strip it back to the /64 or /48.

myMacBook.1.0.168.192.in-addr.arpa is a legal hostname.  

1.0.168.192.in-addr.arpa PTR myMacBook.1.0.168.192.in-addr.arpa
myMacBook.1.0.168.192.in-addr.arpa A 192.168.0.1

The ISP could have a "home" and customers could have a name delegated
from it as part of their package.   myMacBook.name.example.com

There are lots of ways to get a name.

ICANN could open up ".home" to residential customers.

Australia has "id.au" which is designed for low cost / zero cost delegations. 
I have andrews.wattle.id.au for $0.

There days there really is no reason not to run servers at home.
I would bet that over 50% of households already run servers at home though
not all of these would be currently open to the world.  I expect that
number to increase.

I also expect homes with registered domains to increase as the
automation in the home increases.  There is something nice about
being able to tell airconditioners etc. to turn on when you leave
work so the room is a reasonable temperature.

There is something nice about being able to stream movies from your
home video system regardless of where you are in the world.

I'm sure lots of other things will come along to make use of homes having
registered domains in the future.

Mark
-- 
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: Thu, 30 Oct 2014 21:02:07 -0400

On Oct 30, 2014, at 6:05 PM, Doug Barton <[email-masked]> wrote:
> 1. "Residential" users, or more specifically, those who will not be/should not be running services on their addresses

This is not a value judgment the IETF should be making.

---

From: Doug Barton <[email-masked]>
Date: Thu, 30 Oct 2014 21:00:31 -0700

> This is not a value judgment the IETF should be making.

Of course not, but it is one that the ISP makes, and that distinction is 
useful to the anti-spam folks.

Doug

---

From: Paul Vixie <[email-masked]>
Date: Thu, 30 Oct 2014 22:28:05 -0700

> Doug Barton <mailto:[email-masked]>
> Thursday, October 30, 2014 9:00 PM
>
>
> Of course not, but it is one that the ISP makes, and that distinction
> is useful to the anti-spam folks.
IETF should not be making judgements as to what an ISP will value,
because not all ISP's behave as you described.

also, it's useless to the anti-spam folks. right now the massively faked
and manufactured PTR RR's coming from almost all last-mile providers for
about half of all the IPv4 address space that's reachable, has to be
laboriously cataloged so that it can be ignored.

that is, the lack of a PTR suggests that a device ought not be
initiating TCP/25 outside its local network. (this is an observation of
how the anti-spam folks, including myself, behave; it is not a
recommendation.) knowing this, last-mile providers foolishly and
bizarrely create hundreds of millions of PTR RR's that have no value
whatsoever since they simply encode the IP address in ASCII and add the
ISP's ".foo.net" suffix. knowing this, the anti-spam folks make lists of
these manufactured patterns so that (and ONLY so that) they can pretend
they do not exist.

i suggest an efficiency improvement: don't manufacture these PTR's in
the first place. let last-mile devices be PTR-free. signal to anti-spam
folks, such as myself, by this method, that these are not real "hosts"
and should not be participating in what were once considered end-to-end
protocols, such as off-network SMTP.

internet service != internet access. can we make that taxonomy explicit,
and stop equivocating?

Oct 31 00:59:29 ss postfix/postscreen[3912]: NOQUEUE: reject: RCPT from
[59.55.248.215]:2294: 550 5.7.1 Service unavailable; client
[59.55.248.215] blocked using b.barracudacentral.org;
from=<[email-masked]>, to=<[email-masked]>, proto=ESMTP,
helo=<yahoo.com>

215.248.55.59.in-addr.arpa. 69668 IN    PTR    
215.248.55.59.broad.ja.jx.dynamic.163data.com.cn.
;; Received 106 bytes from 202.101.226.68#53(ns.jxjjptt.net.cn) in 162 ms

-- 
Paul Vixie

---

From: Bob Harold <[email-masked]>
Date: Fri, 31 Oct 2014 09:02:59 -0400

On Fri, Oct 31, 2014 at 1:28 AM, Paul Vixie <[email-masked]> wrote:

> ...
>
> i suggest an efficiency improvement: don't manufacture these PTR's in the
> first place. let last-mile devices be PTR-free. signal to anti-spam folks,
> such as myself, by this method, that these are not real "hosts" and should
> not be participating in what were once considered end-to-end protocols,
> such as off-network SMTP.
>
> ...
> --
> Paul Vixie
>
>
I recall running into applications that refused to accept connections (or
took a very long time) if the reverse DNS lookup was not found.  If memory
serves, telnet and ssh on some hosts.  Do we know if there are still
applications like that?   If so, then we (home users) need the reverse PTR.

-- 
Bob Harold
(Speaking personally, not for my employer)

---

From: Andreas Gustafsson <[email-masked]>
Date: Fri, 31 Oct 2014 15:23:04 +0200

Bob Harold wrote:
> applications like that?

Ubuntu has a long-standing bug that causes a 5-second delay in any
reverse lookup that yields NXDOMAIN:

  https://bugs.launchpad.net/ubuntu/+source/nss-mdns/+bug/94940

> If so, then we (home users) need the reverse PTR.

Personally, I would prefer to see Ubuntu, and any other software
broken in similar ways, fixed.
-- 
Andreas Gustafsson, [email-masked]

---

From: Paul <[email-masked]>
Date: Fri, 31 Oct 2014 09:50:20 -0400

Not sure why Paul Vixie wants to relegate my IPv6 address to third class citizen that's not good enough to be a peer on the Internet for port 25. I'd ask him, but his mail server refuses my email due to my ISPs lack of reverse IPv6 :p

I'm all for anti-spam heuristics, but checking the reverse is simply a method that's causing too many false positives, on top of punishing "early" adopters of IPv6

Sent from my iPhone

> On Oct 31, 2014, at 01:28, Paul Vixie <[email-masked]> wrote:
> 
> 
> 
>> 	Doug Barton	Thursday, October 30, 2014 9:00 PM
>> 
>> 
>> Of course not, but it is one that the ISP makes, and that distinction is useful to the anti-spam folks.
> IETF should not be making judgements as to what an ISP will value, because not all ISP's behave as you described.
> 
> also, it's useless to the anti-spam folks. right now the massively faked and manufactured PTR RR's coming from almost all last-mile providers for about half of all the IPv4 address space that's reachable, has to be laboriously cataloged so that it can be ignored.
> 
> that is, the lack of a PTR suggests that a device ought not be initiating TCP/25 outside its local network. (this is an observation of how the anti-spam folks, including myself, behave; it is not a recommendation.) knowing this, last-mile providers foolishly and bizarrely create hundreds of millions of PTR RR's that have no value whatsoever since they simply encode the IP address in ASCII and add the ISP's ".foo.net" suffix. knowing this, the anti-spam folks make lists of these manufactured patterns so that (and ONLY so that) they can pretend they do not exist.
> 
> i suggest an efficiency improvement: don't manufacture these PTR's in the first place. let last-mile devices be PTR-free. signal to anti-spam folks, such as myself, by this method, that these are not real "hosts" and should not be participating in what were once considered end-to-end protocols, such as off-network SMTP.
> 
> internet service != internet access. can we make that taxonomy explicit, and stop equivocating?
> 
> Oct 31 00:59:29 ss postfix/postscreen[3912]: NOQUEUE: reject: RCPT from [59.55.248.215]:2294: 550 5.7.1 Service unavailable; client [59.55.248.215] blocked using b.barracudacentral.org; from=<[email-masked]>, to=<[email-masked]>, proto=ESMTP, helo=<yahoo.com>
> 
> 215.248.55.59.in-addr.arpa. 69668 IN    PTR     215.248.55.59.broad.ja.jx.dynamic.163data.com.cn.

---

From: "John Levine" <[email-masked]>
Date: 31 Oct 2014 15:08:41 -0000

>Not sure why Paul Vixie wants to relegate my IPv6 address to third class citizen that's
>not good enough to be a peer on the Internet for port 25. I'd ask him, but his mail server
>refuses my email due to my ISPs lack of reverse IPv6 :p
>
>I'm all for anti-spam heuristics, but checking the reverse is simply a method that's
>causing too many false positives, on top of punishing "early" adopters of IPv6

I'd suggest that "mild inconvenience for you" is not a synonym for
"too many false positives."  I've been running IPv6 on my server for
quite a while via a tunnel from HE, which includes the ability to
manage my own reverse DNS.  (Thanks!)  When I look at the logs, I see
precious few inbound connections with no rDNS that plausibly could be
anything other than a spambot or yet another compromised web host.

Every mail system in the world is reachable via IPv4 and will be for a
long time.  If your v6 setup isn't ready for prime time, it really isn't
anyone else's job to help you experiment.

R's,
John

---

From: Paul Vixie <[email-masked]>
Date: Fri, 31 Oct 2014 08:32:50 -0700

> Bob Harold <mailto:[email-masked]>
> Friday, October 31, 2014 6:02 AM
>
> ...
>
> I recall running into applications that refused to accept connections
> (or took a very long time) if the reverse DNS lookup was not found. 
> If memory serves, telnet and ssh on some hosts.  Do we know if there
> are still applications like that?   If so, then we (home users) need
> the reverse PTR.
i do not know one way or the other.

but if there are such apps, they are wrongheaded, and, the only way to
get them fixed is, stop placating them.

-- 
Paul Vixie

---

From: Paul Vixie <[email-masked]>
Date: Fri, 31 Oct 2014 08:42:05 -0700

> Paul <mailto:[email-masked]>
> Friday, October 31, 2014 6:50 AM
> Not sure why Paul Vixie wants to relegate my IPv6 address to third
> class citizen that's not good enough to be a peer on the Internet for
> port 25.

your question is a nonsequitur. i have no such desire.

> I'd ask him, but his mail server refuses my email due to my ISPs lack
> of reverse IPv6 :p

if you have a business grade connection to the internet, you should be
able to establish a PTR for each real host.

if you have a consumer grade connection, and your ISP is manufacturing
PTR's at large scale, then your ISP's pattern for such manufacture is
likely to be listed at <http://www.enemieslist.com/> along with all the
other manufactured PTR patterns, and as such, my mailer would have
rejected your e-mail by the extra step of ignoring your manufactured PTR.

in other words i didn't relegate your address to third party status.
that bed was on fire when you laid down on it.
>
> I'm all for anti-spam heuristics, but checking the reverse is simply a
> method that's causing too many false positives, on top of punishing
> "early" adopters of IPv6

and yet, every proposal i've seen concerning IPv6 PTR screams silently,
"PTR is an old-internet concept which no longer applies." it's as if we
were trying to placate a bunch of apps that didn't understand classless
inter-domain routing (CIDR) with its variable length prefixes, and
rather than fix the apps, we're synthesizing acceptable metadata for
them, at great complexity cost, and zero information benefit.

-- 
Paul Vixie

---

From: Paul Wouters <[email-masked]>
Date: Fri, 31 Oct 2014 12:29:42 -0400 (EDT)

> able to establish a PTR for each real host.

Oh, you want me to pay an additional $2000/month to use IPv6 with email.

> that bed was on fire when you laid down on it.

So much priviledge, wow, very Postel :P

John Levin wrote:

> If your v6 setup isn't ready for prime time, it really isn't
> anyone else's job to help you experiment

Attitudes like this at least guarantees we keep drinking scotch. But
universal deployment of ipv6, not so much.

In the fight between being forcibly NAT'ed behind IPv4, or having IPv6
without a reverse, it would be really nice to try and make everyone
a full peer on the internet again using IPv6 :P

I guess soon only criminals with have IPv6 reverse, since they have more
budget to spend on this than I do :P

Paul

---

From: Paul Vixie <[email-masked]>
Date: Fri, 31 Oct 2014 09:43:07 -0700

> Paul Wouters <mailto:[email-masked]>
> Friday, October 31, 2014 9:29 AM

no, sir, and that's the second time you've attributed a desire to me
that i don't possess. (putting it in the form of a question makes it no
more palatable.)
> So much priviledge, wow, very Postel :P

people who want their mail to get through relay it through servers that
have PTR's. that's not news. you could:

1. pay $2000 (or whatever) for business-grade connectivity;
2. get a tunnel to sixxs or some other ipv6 tunnel broker;
3. buy a cheap virtual server in some cloud somewhere;
4. send me a 1U which i can host on my comcast business connection;
5. accept a free "bhyve" VM running freebsd on my personal "cloud".

note, #4 and #5 are only available to people i have drank beer with, so,
mr. wouters certainly qualifies.

if you want an option that's not on the menu, it's your job to define
it, and probably build it. if your preferred solution is that everyone
accepting e-mail stop looking for PTR's, then The Princess Bride has
this wisdom for you:

> Inigo Montoya: Who are you?
> Man in Black: No one of consequence.
> Inigo Montoya: I must know...
> Man in Black: Get used to disappointment.
> Inigo Montoya: 'kay. 

-- 
Paul Vixie

---

From: Richard Clayton <[email-masked]>
Date: Fri, 31 Oct 2014 17:47:22 +0000

In message <[email-masked]>, Paul Vixie <[email-masked]>
writes

>them, at great complexity cost, and zero information benefit.

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.

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

What recipients really wish to know when they receive a connection is
how much address space is controlled by the connecting entity so that a
consistent reputation can be applied to all connections from that space.

Whether they construct that reputation themselves or acquire it from a
broker is not relevant -- they want to apply it to all addresses that a
sender controls.

We approximate this in IPv4 by using /32s (since few people control more
than a /24 -- so we get within a factor of 250 -- and there are not all
that many /18s and above ... so we can manually inspect the traffic from
each one on its merits, and yes there's a gap there).

We just can't use the same approximations for IPv6, but the reverse DNS
system is one place where we could store attestations about delegation
of address space ...

... if we don't build such a system where this information can be stored
for anyone to access for free then we're all going to end up paying
another set of brokers for the data needed to provide the granularity
measures our reputation systems must use

- -- 
Dr Richard Clayton                         <[email-masked]>
                                  tel: 01223 763570, mobile: 07887 794090
                    Computer Laboratory, University of Cambridge, CB3 0FD

---

From: Mark Andrews <[email-masked]>
Date: Sat, 01 Nov 2014 07:36:11 +1100

In message <[email-masked]>, Richard Clayton writes:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

If you don't look it up it doesn't cost anything to cache.

Additionally a negative response is *bigger* and is more costly to
cache especially if it is a signed negative response.  If you are
worries about cache size you *want* PTR records to be returned.

> -----BEGIN PGP SIGNATURE-----
> Version: PGPsdk version 1.7.1
> 
> iQA/AwUBVFPLKuINNVchEYfiEQIjbgCbBQSyfmInlRaW8X497OyNAKytMGIAn1Js
> 63oOrwA48IfcFtAuTBpwupMV
> =awU9
> -----END PGP SIGNATURE-----
>