Subject: Fwd: MARID use of reverse-DNS

From: Andrew Newton <[email-masked]>
Date: Fri, 2 Jul 2004 18:36:28 -0400

Paul Wilson and George Michaelson of APNIC sent us this note regarding  
the use of Reverse DNS for any MARID proposals.  APNIC is one of the  
four Regional Internet Registries (RIR), the entities responsible for  
the management of IP address allocation and delegation and management  
of the Reverse DNS space.

-andy

Begin forwarded message:

> From: Paul Wilson <[email-masked]>
> Date: July 2, 2004 2:00:28 AM EDT
> To: "Marshall T. Rose" <[email-masked]>, Andrew  
> Newton <[email-masked]>
> Cc: George Michaelson <[email-masked]>
> Subject: MARID use of reverse-DNS
>
> Marshall, Andy,
>
> We're emailing you as co-chairs of MARID to register the interest of
> RIRs in any outcome from MARID which defines a role for reverse-DNS  
> records.
>
> As you will know, administrative management of reverse DNS delegations
> vests in the RIRs, as a function of our overall role. We are both a
> registration/maintenance entry point, and a provider of the operational
> reverse DNS services related to address space under our management.
>
> We are aware of issues in the depth of coverage in reverse-DNS, in two  
> ways:
>
> Firstly, there is an ongoing 'lame' state for delegated address ranges
> (of the order 20%) which we are now actively managing through a
> (recently developed) lame DNS detection, reporting and cleanup process.
>
> Secondly, the participation rate in reverse-DNS is less than 100%,
> varying by country, age of network, and maturity of regional/local
> Internet/ISP coordination.
>
> These issues need to be considered within any MARID deployment  
> strategy,
> and in your analysis of the deployment outcomes for SMTP or other email
> delivery methods using reverse-DNS.
>
> The RIRs do have an interest in two or more domains of concern:
>
> 1) Operational Impacts
>
> If MARID relies on reverse-DNS, this will have implications for our
> management of service, and the services we provide to our
> members/customers to support their own use of the service.  There will
> be additional overheads for RIRs in terms of data management, and some
> software development will certainly be required.
>
> In terms of the operational DNS service provision, our current platform
> has been scaled progressively with growth in the absolute number of DNS
> lookups, and the scaling function to date has been essentially linear.
>
> Should MARID require each SMTP transaction to perform a reverse-DNS
> lookup, we would face an increased growth in traffic, in proportion to
> the rate of in both packets and bytes/sec served, and probably need to
> investigate changes to our deployment methodology in line with the root
> servers, such as use of anycast DNS, and improvements in DNS zone
> management to scale with the increased rate of change as the
> non-delegated reverse spaces (and lame reverse spaces) scramble to
> comply with SMTP delivery obligations.
>
> 2) Policy Impacts
>
> RIRs do not have an 'enforcement' role with respect to reverse-DNS, in
> terms of “completeness” of records; however we do take an active role
> (as mentioned above) to detect and correct certain specific cases of
> correctness of the records. The specific extent of our authority may
> need to be borne in mind in this standards development process.
>
> That said, the RIRs’ specific responsibilities and activities are the
> result of community consideration and consensus.  Any proposal to
> substantially revise any responsibility or activity is normally taken
> through an open policy process which can certainly accept such
> initiatives, but which may take 3-12 months to complete.
>
> Therefore we suggest that you consider providing advance notice to RIR
> communities of any future proposal, through informational presentations
> at future meetings.  In the case of APNIC, our next meeting will take
> place in Fiji between 31 August and 4 September 2004, and you would be
> welcome to take this opportunity to make such a presentation.
>
> George will be in San Diego for IETF-60, and interested to hear an  
> update on this.
>
>
> Thanks.
>
> Paul Wilson
> George Michaelson
> APNIC
>
>
> _______________________________________________________________________ 
> _
> Paul Wilson, Director-General, APNIC                       
> <[email-masked]>
> http://www.apnic.net                            ph/fx +61 7 3858  
> 3100/99
> ----------------------------------------------------------------------- 
> -
> See you at APNIC-18!                     Nadi, Fiji, 31 Aug - 3 Sep  
> 2004

---

From: "Jon Kyme" <[email-masked]>
Date: Sat, 03 Jul 2004 00:27:11 +0100

> the use of Reverse DNS for any MARID proposals.  
>

Interesting perspective... Are the co-chairs canvassing the other RIRs ?

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 2 Jul 2004 17:00:43 -0700 (PDT)

I've already commented that if RIRs consider it to much of an issue with 
adding new record into INADDR tree, we have an easy way out by checking 
some type of MARID record for corresponding PTR dns name. Currently major
ISPs (like AOL) already require valid PTR record for connecting hosts
and handling of PTR deligations is fairly well understood and documented 
by several RFCs.

I've talked about this with Meng and he included the info into unified SPF 
framework/proposal (please write that one up that proposal in more 
clear text then just online presentation). The only issue I had is that 
unified SPF did not provide syntax to delimiter PTR-only authorization 
records from some other type of SPF record, which required identity scope 
modifier and I think that was proposed as type of macro (although that 
would only be of use for redirects, right?). 

I do additionally note on the identity scope issue that nunber of identies 
is  likely to remain rather small. If you consider something other then 
macro and at the same time want to keep spf syntax small, then one 
modifier prefix symbol + one identify letter (i.e. two symbols) should be
be enough to add this info and not require multiple dns lookups. For 
example, lets say $ is a prefix symbol and identity symbols are:
m = envelope mail from, e = ehlo, p = ptr, s = submitter (rfc822 from)

Then spf syntax to use them might be:
  v=spf2 $sm?a/24 $p+ip4:192.168.0.0/16 $e+ptr $p~all -all
(note $sm means it applies to both submitter and mail from)

Additionally I think scoping in general, might be usefull. Could use "<" 
and ">" for that (maybe something else...), so here is another example:
  v=spf2 $sm<a/24 mx> $p<ip:192.168.0.0/16 ~all> $e+ptr -all

---
William Leibzon
Elan Networks
[email-masked]

---

From: Greg Connor <[email-masked]>
Date: Sat, 03 Jul 2004 10:40:41 -0700

Hi Andrew, thanks for posting that.

>> Internet/ISP coordination.

I am really glad someone is aware of this and working on it.  I don't think 
use of PTR will be core to MARID but lack of proper rDNS has plagued 
anti-spam efforts for quite some time

>> 1) Operational Impacts
...
>> comply with SMTP delivery obligations.

This concern kind of ignores that most MTAs already do a PTR lookup - 
Sendmail has had this in place for a long time.

We probably won't make PTR a key component (at least I don't think it is a 
key component in any of the input proposals).  Most of us are already aware 
of the poor support that many ISPs offer in terms of reverse lookups.  SPF 
has a ptr: mechanism, so those who have proper PTR records set up might 
choose to use them instead of listing all their ranges.

Speaking of scrambling to comply though, there is already pressure from 
other large ISPs on users with no PTR (or non-existent name in a PTR) to go 
cry to their ISP -- for example AOL has a published policy that they "may" 
deny service if your mailer has no PTR.

--
Greg Connor <[email-masked]>