Subject: Re: [DNSOP] on draft-wkumari-dnsop-alt-tld-01

From: Warren Kumari <[email-masked]>
Date: Thu, 3 Jul 2014 18:28:53 -0400

On Sat, Jun 21, 2014 at 8:21 PM, John Levine <[email-masked]> wrote:
>>So, I have 2 drafts that I'd really appreciate feedback on - one of
>>the is the .alt TLD document (which many of y'all have already read):
>>http://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-01
>
> This brings the delightful semi-anarchy of Usenet to the DNS, which is
> not necessarily a bad thing.  (Usenet still works pretty well if you
> ignore the alt.* groups.)
>
> I get the impression that the plan is that .alt is for things like
> .onion that are implemented completely outside the DNS in application
> specific ways, and would have to be intercepted at a layer no lower
> than a stub resolver and probably higher.

Yup. This is primarily for those sorts of things that use a browser
plugin / DNS shim / custom stub.

> Would it also be
> appropriate for the sort of link-local names people typically do with
> .home that often resolve A or AAAA records with addresses only locally
> visible?

Personally I don't really think so -- I think that the
draft-chapin-additional-reserved-tlds-01 solution (which reserves
"domain", "lan", "home", "corp", "localdomain" and "mail") is a better
alternative. This, combined with some guidance ("You should consider
using a subdomain of a domain under your control (e.g
home.example.com). If you are building a disconnected network, you can
use .localdomain (or .home or something). Chances are, someday this
will be connected to the Internets, and you'll wish you'd used a
subdomain. Don't say we didn't warn you." :-)) seems cleaner.
Actually, I think that we should have a separate draft saying basically this.

W

> R's,
> John

---

From: Warren Kumari <[email-masked]>
Date: Thu, 3 Jul 2014 18:56:56 -0400

On Mon, Jun 23, 2014 at 1:07 PM, Tony Finch <[email-masked]> wrote:
> Warren Kumari <[email-masked]> wrote:
>>
>> Draft: http://tools.ietf.org/html/draft-wkumari-dnsop-dist-root-00
>
> What I do on my toy server at the moment is similar but different, based
> on a suggestion from Mark Andrews:
> https://lists.dns-oarc.net/pipermail/dns-operations/2013-November/011158.html
>
> The idea is to have an authoritative view with a local copy of the root
> zone, and a recursive view which validates as normal but queries the auth
> view instead of the usual servers.
>
> The downside compared to your proposal is the lack of any way (other than
> operator intervention) to recover from a bogus zone transfer.
>
> view rec {
>         match-recursive-only yes;
>         zone "." {
>                 type static-stub;
>                 server-addresses { ::1; };
>         };
> };
>
> view auth {
>         recursion no;
>         allow-recursion { none; };
>         zone "." {
>                 type slave;
>                 masters { 2001:500:2f::f; 192.5.5.241; };
>         };
> };
>

Yup, this accomplishes a very similar thing - and a number of folk are
doing exactly this (or even "while true; do dig AXFR .
@f.root-servers.net > root.db; rndc reload root.db; sleep 1800; done"
or, less scarily, cron).

As you say, it doesn't deal well with bogus zone transfers, but also,
depending on just how you implement it, doesn't necessarily do
validation (for example, the dig -> file), but, it *is* very similar.
A fair bit of this document is simply codifying this existing
behavior.

W

> Tony.
> --
> f.anthony.n.finch  <[email-masked]>  http://dotat.at/
> Plymouth, Northwest Biscay: Northeasterly 4 or 5. Slight or moderate. Fair.
> Good.