[131734] in North American Network Operators' Group

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

Re: IPv6 rDNS

daemon@ATHENA.MIT.EDU (Leo Bicknell)
Tue Nov 2 14:33:53 2010

Date: Tue, 2 Nov 2010 11:33:45 -0700
From: Leo Bicknell <bicknell@ufp.org>
To: nanog@nanog.org
Mail-Followup-To: nanog@nanog.org
In-Reply-To: <Pine.LNX.4.64.1011021808480.26001@a84-22-97-10.cb3rob.net>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org


--KsGdsel6WgEHnImy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

In a message written on Tue, Nov 02, 2010 at 06:21:14PM +0000, Sven Olaf Ka=
mphuis wrote:
> the way bind handles things.. isn't really suitable for bigger ipv4 and i=
t=20
> definately isn't suitable for ANY ipv6 network, and the whole thing with=
=20
> files being transferred.. well.. ahem... "primitive".
>=20
> bind was coded in a time when the internet ran on 64kbit links.. caching=
=20
> downstream back then was desired and things weren't so "large", and it=20
> really didn't matter much if things took hours.
> (why do we STILL have to wait for new domains... just drop the whole=20
> concept of -files- and -zones- domain registrations should work=20
> -instantly-! not after a "reload" of something that should not be used=20
> anymore anyway).

I'll note that most of the behavior you describe here is deeply
rooted in the RFC's.  The concepts of zone transfers for instance
are not unique to BIND, but rather in the definition of how
interoperable DNS is supposed to work.

That said, there is clearly room for improvement, and in fact there
are a lot of folks working on it.  Indeed, some of them have funding
BIND 10, a ground-up rewrite of BIND that I think based on the tone
of your message may please you with the direction that it is going.

For more information...

http://www.isc.org/bind10
http://bind10.isc.org/

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

--KsGdsel6WgEHnImy
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (FreeBSD)

iQIVAwUBTNBZibN3O8aJIdTMAQKzvA/+LF6kb7hSTzDQJhX6Ymdpf/BFnJxSbUcr
gT1AzlWnvwluYfVYLR5GClcJ/mIu0fg86hK0rUYl0sm7N5m+ooi6iguf2CGL16Qp
ze0YwKuR6hy9hobIpNWfrml8Tc9bu2VGLpANRUjeevea69yyd18r2ZMIwKfSpZWr
NRK6TOHQDOVA6FJDivrEy6bCeSKWPF+gufxI+95ikA2JR7zIekW+OWYX4BmWGKrr
jtkvlY/ag/xq8SmgtW3ctXD9B4vC+jnlh5DhK0A9Q3mu1mLMbzqTZY7kj1I1vxA4
HYjjdHR1EAgzsNk9EyAcKY+2Apo8L6YzVanbf8m1B0tC3UsEBbJYq/Wpi1hxUJhN
SVPDpqJkLIL1zkp65AX+IBmch8laH+dC3SpFrX6KY3L+xXi61XM6tWhPbcZaigqg
NmU+kPS243yXhcwVDaG3NCsXnv3qlsQlrU3yJE4y/9Il6PRaw2989yfv8O2fkyjD
Dz9jtPlJO8xtHMxfMjTb0gqT205oWYdMv6KRfe7tI85nSEJ2UMk1DHqz3hMoVQsR
K7cATMKNI5rpLq419MI96tZVrfGwKVenb0SC031WLMXkfIF8cxPFDvgrxteh3c9Z
02qbjo35cFPTQ6JWzojDqEJDbVsdMKN6jtTbE/gFWXoZxtoLfGVk8S/GzEudSzum
1sr065CFR6Y=
=OcA9
-----END PGP SIGNATURE-----

--KsGdsel6WgEHnImy--


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