From owner-freebsd-hubs@FreeBSD.ORG Tue Feb 25 08:52:50 2014 Return-Path: Delivered-To: hubs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08FBB8D9 for ; Tue, 25 Feb 2014 08:52:50 +0000 (UTC) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C60DD1D7E for ; Tue, 25 Feb 2014 08:52:49 +0000 (UTC) Received: by mail-pb0-f50.google.com with SMTP id rq2so7782501pbb.23 for ; Tue, 25 Feb 2014 00:52:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type; bh=9SFFJqDlmthfdCoCWjEteC3bo/yFCOh39ZVa/3pEVfU=; b=NkApFhl2QxKrsAIzpG4po6g6dwI8Bqc5Mt/lUoxSmf/796vZlt2nFM6remAqsV4pEG xmZlDtyrBnMBTRLkhkh5NWGNYx/raOXAywHHffxvmW+ZnIr00sNcwGoIup7xBVEJg6rW Ep/uvKEdmM+EJxHM2sq2KYHyBXCxiwAvEEx1I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:subject:content-type; bh=9SFFJqDlmthfdCoCWjEteC3bo/yFCOh39ZVa/3pEVfU=; b=l3d3VQGBCmZXaVic9FuXYahiMjzpynuy9JVKiAAxNAcg5IcMFVo14BshLnkcOcWS5e pmrEudESJgMQYhfBTjx9QbOqH7djpzRcwg1NYz8ZwVmP8wAsjCOpmb6wNEp44V0LBflg 4dwAWILyTdJSfDno8ghYduZBarjlIVfePhzB5lhnLQu1/HBexTtOHIlzb1T83YysWLIy 8xAfrSCiivOE6cKGgCBaV9UGK6ZWDcYzckaZ3L+NUrn6Re9tiL4jRP2gl12ztbaDt978 /C3XzvrjJDt98KOZzYICsR9IV1JwbNU38GH98UoZnc0niDGI3AvFGUGcnzGXYpXH6cm1 WmPg== X-Gm-Message-State: ALoCoQnDVvZFhluJZolV4+QNukLWNAsWmtQh6KBS4i2ewXMb2+nTusRfXxhcDIVtLBKOmlyUNO7y X-Received: by 10.67.14.231 with SMTP id fj7mr244085pad.115.1393318368057; Tue, 25 Feb 2014 00:52:48 -0800 (PST) Received: from hackintosh.wemm.org ([2601:9:e80:770:fc67:2b3f:6356:f0d8]) by mx.google.com with ESMTPSA id ou9sm8091830pbc.30.2014.02.25.00.52.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Feb 2014 00:52:46 -0800 (PST) Message-ID: <530C59D7.30204@wemm.org> Date: Tue, 25 Feb 2014 00:52:39 -0800 From: Peter Wemm Organization: World Domination in progress. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: hubs@freebsd.org Subject: Future of DNS, DNSSEC, country code delegations, etc. X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3HE5dgHTfNKl1nkhGUci5nipd9qdCufUQ" X-BeenThere: freebsd-hubs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "FreeBSD Distributions Hubs: mail sup ftp" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 08:52:50 -0000 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 MIA april 2008, data lost ; zone cc email for email bouncing may 2012 ; zone cc current contact is 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--