[166551] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Reverse DNS RFCs and Recommendations

daemon@ATHENA.MIT.EDU (Leo Bicknell)
Wed Oct 30 13:36:22 2013

From: Leo Bicknell <bicknell@ufp.org>
In-Reply-To: <20131030165536.GC525@dyn.com>
Date: Wed, 30 Oct 2013 12:36:03 -0500
To: Andrew Sullivan <asullivan@dyn.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org


--Apple-Mail=_789EF05F-F3DF-49F7-9B4F-0653548C106E
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii


On Oct 30, 2013, at 11:55 AM, Andrew Sullivan <asullivan@dyn.com> wrote:

> As I think I've said before on this list, when we tried to get
> consensus on that claim in the DNSOP WG at the IETF, we couldn't.
> Indeed, we couldn't even get consensus on the much more bland
> statement, "Some people rely on the reverse, and you might want to
> take that into consideration when running your services."  

It's taking all of my willpower to avoid an IETF rant. :)

The "SHOULD" here is one way.  A PTR record should point to a valid
forward name that resolves to the same IP address.  To quote RFC 1034,
a PTR is "a pointer to another part of the domain name space".  If the
RHS of a PTR is not a valid domain name, that's just not true.

But rather than some pedantic rant about standards there's a practical
purpose here.  Tools that receive IP addresses will generate names
using reverse lookups, those names should then work.  For instance if
trace route gives a name, "ping <name>" should then work.

But the opposite is not true.  Many forward records may point to the
same IP address, and there is no need for reverses to match.

(in shorthand)

10.0.0.1 PTR webhosting.foo.com
webhosting.foo.com A 10.0.0.1
www.sitea.com A 10.0.0.1
www.siteb.com A 10.0.0.1
www.sitec.com A 10.0.0.1

-- 
       Leo Bicknell - bicknell@ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/






--Apple-Mail=_789EF05F-F3DF-49F7-9B4F-0653548C106E
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQIVAwUBUnFDhbN3O8aJIdTMAQJVKA/8CRsQ6DPEIB/CPoQn1pVbHl5Eg9S+5Dtu
/oBsLPWO6iAMFBy2KkYOFLLMTpSHlKXwGmhBR5Rx+fCyFP1WRMmdvLlRtPQN6FkF
g+N3Ieva0GRjhS/kMNcecdEIqwQsW4DGuXpxkkQVcRuJ3GwLv/kToUz9tdtWs2hh
jUxX/rYkY/nhLP9sBBNmQ/qGx66+pa1ywG1uNOO0KjnPCBXTMTGoU1IZFdrbXJ8M
MxRDB/3g9i4WkZIeWxZgUAkjI+k6npOSIlKFjaAByuanIM+7HdrS3v5VF6IY/a1x
9u1bgvY+/V6naba2LvqX3zzL1iQMCzlMV6rQV5tbuOKInuI2uGQqBf+y+mDuRQNQ
4ooieeNOljhiscp0bAU0F8FgXNjcaImltM0DrYzzteWjXWLOtyfsc8V9d0eNv0Dm
LlF1ZvdTAT2DDt/xcPKoecAaXmr5I8bxx3wq4rVbYL+kD+K+NWG+iGxsyrVB+3ZM
Z0H6MgUUL3gd7H+p58XDx7ywJyi/8G4K+swcJXHi1rj3ewMBmMz3LhWIpEvgmlCp
PpNfVhuiGE1cskSgezbf3/Ttjo1ytXJSS49FmFdXqGigjSvx0iHsOHh3qtmW6883
al+cu2thsdQPrbanS0u1JC3riXT+spb8+PueqgluKoGnnb2Lycswz1C+c6Q9d/i0
eDPjSUYmHo4=
=kOwj
-----END PGP SIGNATURE-----

--Apple-Mail=_789EF05F-F3DF-49F7-9B4F-0653548C106E--


home help back first fref pref prev next nref lref last post