Date: Tue, 25 Feb 2014 00:52:39 -0800 From: Peter Wemm <peter@wemm.org> To: hubs@freebsd.org Subject: Future of DNS, DNSSEC, country code delegations, etc. Message-ID: <530C59D7.30204@wemm.org>
next in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3HE5dgHTfNKl1nkhGUci5nipd9qdCufUQ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We (with clusteradm@ hat on) have been looking at another round of broken= mirrors, delegated DNS servers that have gone lame/missing, subzones that= have gone missing. wwwN.freebsd.org / wwwN.cc.freebsd.org that now point = to Ubuntu or Microsoft IIS pages, stale/missing ftp mirrors etc. (by "cc" I mean country codes - "us", "eu", "au", "ru", etc.. I am not picking on anyone in particular) One of the problems we've been hitting is that *.cc.freebsd.org was originally set outside of the core project infrastructure. When they go stale and the volunteers who originally set it up go missing, the data simply disappears and is lost. In retrospect, this was a mistake. As things stand today, more than half of the original *.cc.freebsd.org subzones have been lost. An uncomfortable number of the remaining record= s are tragically stale. There's also the DNSSEC and ipv6 reachability question. Many of our cc.freebsd.org zones are ipv4-only and only one has DNSSEC signatures. The question of what to do about it have come up many times inside clusteradm@/dnsadm@ and ideas have bounced around ranging from extremes l= ike simply abandoning the whole *.cc.freebsd.org idea, through just taking th= em back, or simply letting them die and quietly deleting them when they go = stale. I'm leaning towards a middle ground. My preferred option at this point i= s to take the zones back so that we have a copy of the data within the core= infrastructure, and switch to a regional coordinator model. We kind of already have this, except when current regional coordinators move on, we tend to lose the data. What I'm talking about is something like this.. As they stand now, in the parent dns zone: ; zone cc email for <person@univerity.edu.cc> MIA april 2008, data lost ; zone cc email for <person@somecompany.cc> email bouncing may 2012 ; zone cc current contact is <somebody@somedomain.cc> cc.freebsd.org. IN NS someserver1.cc. cc.freebsd.org. IN NS someserver2.cc. And after such a change, it'd be email alias: coordinator-cc@freebsd.org: somebody@somedomain.cc =2E. and we host the records inside the freebsd.org zone. This coordinat= or will directly arrange with dnsadm@ to update the records in their area. They would receive commit messages when records in their area were update= d, and be reachable via coordinator-cc@freebsd.org. We (freebsd.org) use ISC's global anycasted ISC-SNS dns servers. In our experience they have excellent coverage around the world so we'd prefer t= o fold the *.cc.freebsd.org zone into the main freebsd.org zone (like wwwN.us.freebsd.org and ftpN.us.freebsd.org are right now). Actual sub-zones could be done if there's a regional reachability problem but I would rather not unless we absolutely had to. Advantages: * We get better continuity and handovers if/when people want to move on.= * In theory, we should never lose zone data, contact addresses again. * We still get local regional knowledge and coordination. * 100% DNSSEC coverage and IPV6 connectivity. Disadvantages: * There has been resistance and hurt feelings when ideas like this have come up in the past. * Loss of independence. * There are residual bad memories from when working with dnsadm@ was rea= lly painful and slow. (I assure you, this is no longer a problem!) Ideally this would be done zone by zone, by contacting the current coordinator for obtaining the current zone source, setting up email alias= es, and adopting it into ns0.freebsd.org/ISC-SNS. If we can do it this way then we get to preserve notes, comments, history= etc. On the other hand, doing a blind zone transfer or scraping/iteratin= g through likely records and documented mirrors is far less satisfactory an= d practically begging for hurt feelings. We even have a number of zones where we have *no working contact address*= for the current operator. I'm sure we can track them down eventually but= it doesn't look good if we have to resort to asking on public mailing lists questions like "Does anyone know who runs yy.freebsd.org?" Thoughts? How can we make this work without provoking (too many) ruffled= feathers? --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6F= JV UTF-8: for when a ' just won\342\200\231t do. --3HE5dgHTfNKl1nkhGUci5nipd9qdCufUQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMMWdwACgkQFRKuUnJ3cX+ZegCeNWPIQAXjxW0lGFX01nWPLN2f CCwAnRegXhjoaswlqIO+LWQVTKl7Wz0K =KBJF -----END PGP SIGNATURE----- --3HE5dgHTfNKl1nkhGUci5nipd9qdCufUQ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?530C59D7.30204>