[192485] in North American Network Operators' Group

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

RE: IPv6 automatic reverse DNS

daemon@ATHENA.MIT.EDU (White, Andrew)
Sat Oct 29 09:43:28 2016

X-Original-To: nanog@nanog.org
From: "White, Andrew" <Andrew.White2@charter.com>
To: Wesley George <wesgeorge@puck.nether.net>
Date: Sat, 29 Oct 2016 13:43:05 +0000
In-Reply-To: <208C7FE5-1D75-46F6-99AD-5CE2921FEEF3@puck.nether.net>
Cc: Steve Atkins <steve@blighty.com>, NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org

Thanks for the clarification, Wes.

Has anyone proposed the method of publishing v6 PTRs on-the-fly as addresse=
s are observed passing through an ISP's router?

Andrew


=1B$B&+&G=1B(Bdr=1B$B'V=1B(Bw Whi=1B$B'd'V=1B(B
Charter Network Operations - DAS DNS
Desk: 314-394-9594 ? Cell: 314-452-4386
andrew.white2@charter.com


-----Original Message-----
From: Wesley George [mailto:wesgeorge@puck.nether.net]=20
Sent: Saturday, October 29, 2016 7:41 AM
To: White, Andrew
Cc: Steve Atkins; NANOG list
Subject: Re: IPv6 automatic reverse DNS


> On Oct 28, 2016, at 11:03 PM, White, Andrew <Andrew.White2@charter.com> w=
rote:
>=20
> There are two competing drafts for synthetic rule-based PTR responses for=
 IPv6 rDNS:
>=20
> Howard Lee, Time Warner Cable (now Charter)
> https://tools.ietf.org/html/draft-howard-isp-ip6rdns-08
>=20
> J. Woodworth, CenturyLink
> https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/
>=20

At the risk of getting into IETF administrivia, a little clarification is i=
mportant here: The first draft you mention above was replaced by the draft =
I referenced in my previous email. It is currently an adopted WG draft in D=
NSOP, moving toward working group last call as a consensus document., thus =
the window for capturing and incorporating feedback is closing soon. The se=
cond document does not appear to be associated with any IETF Working Group =
yet, but it also isn't competing with the first document. The first draft i=
s informational status, discussing the issues and considerations surroundin=
g this problem, of which generating on-the-fly reverse records is one possi=
ble solution. The second draft is a proposed standard defining *how* to gen=
erate those on-the-fly reverse records assuming one decides that is the rig=
ht path to take in one's network, and would dovetail nicely via reference t=
o section 2.5 of isp-ip6-rdns.

Wes George


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