Subject: [DNSOP] draft-bortzmeyer-dname-root-00.txt

From: George Michaelson <[email-masked]>
Date: Wed, 6 Apr 2016 13:41:40 -0300

I'd like to make a brief comment to this document.

I see some utility in having DNSSEC apply over special use names,
because authenticated non-existence is a strong proof of intent, and
would make a 'not in this domainspace' switch have a robust basis.

On that understanding, how would DNAME redirection work for returning
sigs over the NX? Rays sign-on-the-fly model which we know works,
could be used to generate signed denial of almost anything, which I
have felt could be applied under ALT quite nicely to ensure a formally
non-existent state is declared.

Another view, is that having true delegations permits some to be
formally denied to exist while others can be allocated for use if the
special-use delegation actually has to exist eg a mapping into a local
anycast bound on 127/8 is the desired target.

Basically, if we did DNSSEC, could we somehow not only say 'doesn't
exist' but specifically say (somehow) "we've signed that this is an
exit label, and isn't simply a declaration it hasn't yet been
delegated" ? Maybe I'm over-thinking it, but it feels like we could do
something tricky here to make it NX but also make it clear we know it
exists as a label, in denying it.

-G

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 6 Apr 2016 14:22:09 -0300

On Wed, Apr 06, 2016 at 01:41:40PM -0300,
 George Michaelson <[email-masked]> wrote 

> would make a 'not in this domainspace' switch have a robust basis.

Well, the root is signed so, if the draft is implemented, the DNAMEs
will be signed (the target zone, empty.as112.arpa, is not, for good
reasons).

> On that understanding, how would DNAME redirection work for
> returning sigs over the NX?

I'm not sure I understand. A DNAME is like any other record (see
anything.sink.bortzmeyer.fr which is signed and redirects to the new
AS112).

Or do you mean a RFC 7535-bis, with "special" signatures for
empty.as112.arpa?

---

From: George Michaelson <[email-masked]>
Date: Wed, 6 Apr 2016 14:33:28 -0300

I meant a form of signing, which would be a strong signal of
repudiation of the label as well as exclusion of other holders of the
label, so that it could be a first-class signal "not in the DNS" ->
look in another internet-name lookup mechanism.

Delegation via DNAME to the empty serve felt like a weaker form. It
conflates moving traffic off the root, with an authenticated denial
function.

I probably don't understand the protocol implications of things right
so may also be confused myself.

-G

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 6 Apr 2016 14:47:24 -0300

On Wed, Apr 06, 2016 at 02:33:28PM -0300,
 George Michaelson <[email-masked]> wrote 
 a message of 38 lines which said:

> repudiation of the label as well as exclusion of other holders of
> the label, so that it could be a first-class signal "not in the DNS"
> -> look in another internet-name lookup mechanism.

The proposal in my draft is technically trivial and easy to implement
(politically, it is another matter) because it relies only on existing
techniques.

Your proposal is interesting but would require the development of
protocol changes and their implementation.

---

From: George Michaelson <[email-masked]>
Date: Wed, 6 Apr 2016 14:52:19 -0300

Cheap, easy to implement, and tractable in existing systems are very
attractive properties.

-G

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 6 Apr 2016 14:58:24 -0300

> -> look in another internet-name lookup mechanism.

A ND bit (NS = Not in DNS), as a flag in a NXDOMAIN response, would
not be signed with DNSSEC, so it requires a new kind of NSEC...

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Apr 2016 15:27:41 -0300

If the NXDOMAIN response is secure, your "ND" bit would at worst be
harmless if it were faked, unless you're proposing that the ND bit be
retained permanently!

On Wed, Apr 6, 2016 at 2:58 PM, Stephane Bortzmeyer <[email-masked]>
wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>