Subject: [DNSOP] reverse-mapping issue 18: RFC 1912

From: Andrew Sullivan <[email-masked]>
Date: Mon, 25 Jun 2007 15:08:00 -0400

Issue 18: The draft should refer to RFC 1912

Discussion: RFC 1912 suggests that every A record should have a
corresponding PTR.  

Proposed resolution: add the following text to section 2, as a new
paragraph, after "its use is codified in [RFC3596].":

           [RFC1912] suggests that it is an operational or
           configuration error not to have matching PTR and A records.

Absent any objections, I plan to make this adjustment for a -04
submission on 2007-06-28.

Best regards,
A

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
jabber: [email-masked]                 +1 416 646 3304 x4110

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

---

From: Mark Andrews <[email-masked]>
Date: Tue, 26 Jun 2007 14:44:41 +1000

> submission on 2007-06-28.

	Every address should have a PTR which gives the cannonical name
	of the host which in turn has a matching address record.

	It is a bad idea to say for the to be a PTR for every ownername
	of a address record.  It doesn't take too many A records, which
	all have the same address, before you exceed the DNS protocol
	limits with multiple PTR records.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 26 Jun 2007 14:44:41 +1000

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 26 Jun 2007 10:45:01 -0400

> 	limits with multiple PTR records.

The proposed text is intended to go in section 2, which is background
for the document.  I believe that the draft is actually a softening of
the language in RFC1912, partly for the reasons you state.  There is
text consitent with what you are saying in section 3.3:

   It is possible for there to be multiple PTRs at a single reverse tree
   node.  In extreme cases, these multiple PTRs could cause a DNS
   response to exceed the UDP limit, and fall back to TCP.  Such a case
   could be one where the advantages of reverse mapping are exceeded by
   the disadvantages of the additional burden.  This may be of
   particular significance for "mass virtual hosting" systems, where
   many hostnames are associated with a single IP.

Now that I look at this, however, it's not really correct, given
EDNS0.  So, I have two questions: 

1. Does the text from section 3.3 address your concerns about the
   proposed additional text in section 2 ("Background")?

2. Can you (or anyone else) suggest a better way of phrasing the
   "multiple PTR" paragraph to account for EDNS0 as well?

Thanks,
A

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 26 Jun 2007 10:45:01 -0400

Thanks,
A

---

From: Dean Anderson <[email-masked]>
Date: Wed, 27 Jun 2007 09:01:34 -0400 (EDT)

> 	of the host which in turn has a matching address record.

The above requirement has been previously demonstrated untenable for
both technical reasons (not every address _can_ have a PTR record to an
A record which has a matching IP Adddress) and for operational reasons
(even if it is possible, it is not always desirable to do that).

Such 'requirement' is the essense of the 'in-addr-required' claims that
have been rejected on this group for 7+ years.  I think the arguments of
the past 7+ years do not need to keep being repeated. Rather, I think
the authors and the proponents should have some evidence the WG has
changed its mind.

I have recently asked Ed Lewis, a reviewer of Sullivan's draft to give 
some assurances:

  Ed, having reviewed the document, can you assure us that it doesn't
  contain any language that might be understood as implying that reverse
  DNS records are somehow required?

  Can you assure us that it doesn't contain any language that might be
  understood as implying that using reverse DNS for security is anything 
  but a crock'? (as Ted Lemon wrote)

  Can you assure us that Mr. Sullivan, despite his advocacy of making
  in-addr required, despite his advocacy of using reverse DNS for
  security, and despite his advocacy of irrational decision-making
  processes (cf discussion on DNSOP February & March '07), hasn't used
  this draft as a platform to obtain an the IETF RFC credential to 
  promote discredited practices and thereby mislead people about reverse 
  DNS?

While Mr. Lewis did not reply, it seems now quite clear that no such
assurance can be given, and that Mr. Sullivan remains intent on putting
such language into the draft, despite 7+ years of rejections. This is
another reason to support draft-anderson-reverse-dns-status-00 instead.  
My draft doesn't have this nonsense.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Dean Anderson <[email-masked]>
Date: Wed, 27 Jun 2007 09:01:34 -0400 (EDT)

--Dean

---

From: Mark Andrews <[email-masked]>
Date: Wed, 27 Jun 2007 23:40:49 +1000

>    "multiple PTR" paragraph to account for EDNS0 as well?

	EDNS really doesn't change it.  You can still exceed the
	limits of what can be put into EDNS/UDP packets.   You
	can also exceed what can be put into a {E}DNS/TCP message.
	I've seen the later occur plenty of times.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 27 Jun 2007 23:40:49 +1000