On Mar 5, 2009, at 10:40 AM, Andrew Sullivan wrote:
On Thu, Mar 05, 2009 at 10:32:28AM -0800, Doug Otis wrote:
Note that there has been work in DNSOP suggesting that rejecting
on the failure of reverse DNS lookup is not always a good idea.
Agreed.
Just to be clear: I am not sure I agree with those who think reverse
DNS should not be maintained, but there were strong currents in the
WG that led to the text of that I-D as it stands. It isn't clear to
me where the I-D stands in its progression (if there is to be any)
from the WG, so I have no idea what the Chairs will say was
consensus. But there was a WGLC in which at least some people
suggested the text of draft-ietf-dnsop-reverse-mapping-
considerations-06.txt still contained too much endorsement of the
reverse tree. My personal interpretation of those remarks is that
there will always be a hard core of operators who regard the reverse
tree as an insupportable burden (without consideration for the v4/v6
differences).
When there is to be reverse namespace, it should be ensured to work.
In reality, this is not always the case.
Whether the reverse namespace becomes an expensive luxury for
countries adopting IPv6 seems to be an open question. This namespace
can be frail, and often is not properly configured which reduces
reliability. To sustain the delays reverse transactions create,
additional servers might be required to handle the same amount of
traffic possible when reverse namespace is ignored.
Reverse namespace is often used to determine, by the nature of the PTR
labels, whether an IP address might be dynamically assigned before
deciding to accept email from a specific IP address. Will resolving
labels for specific IP addresses make sense for IPv6?
Could network policy be listed using HTTPS instead? Say for example:
A DNS query of b.a.
9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.ARPA.
becomes:
https://2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.DOA.IP6.ARPA.
that redirects to the registered network owner's https servers. The
page returned would contain CIDR lists and policy assertions within an
encapsulation, such as XHTML.
Finer grain resolutions could be obtained from a network domain of
authority or NDOA.<referenced-domain> contained within the CIDR lists
and policy page, CLAPP. :^)
-Doug
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf