Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Warren Kumari <[e-mail]>]

I'm sorry, I apparently did some overly aggressive editing of my mail
before sending it (or I'm completely confused, which is ALWAYS a
possibility).

In order to try and stop leaks, the draft requests that the domain be
added to the "Locally Served Zones" registry. This means that, when a
validating stub A goes off and queries it's recursive server B for
'foo.alt', it will get back an (authoritative) answer from B, saying
that there is nothing under .alt -- e.g:
# dig foo.alt @204.194.23.4

; <<>> DiG 9.11.0-P2 <<>> foo.alt @204.194.23.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36039
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 0797210975d60eb10da3940d58926228926455130e02e825 (good)
;; QUESTION SECTION:
;foo.alt.                       IN      A

;; AUTHORITY SECTION:
alt.                    604800  IN      SOA     alt. alt. 1 604800
86400 2419200 604800

;; Query time: 0 msec
;; SERVER: 204.194.23.4#53(204.194.23.4)
;; WHEN: Wed Feb 01 17:33:12 EST 2017
;; MSG SIZE  rcvd: 100


I **think** (perhaps incorrectly!), that when the validating stub (A)
tries to validate this, it will see that there is an NSEC at the root
which says that there is nothing between 'alstom' and 'am'.
This makes it look like someone has tried to make .alt sprint into
existence -- I had thought that the correct error for that is
SERVFAIL, not NXD, but it is entirely possible that I'm wrong....

W

On Wed, Feb 1, 2017 at 3:44 PM, Robert Edmonds <[e-mail]> wrote:
> Warren Kumari wrote:
>> The largest outstanding issue is what to do about DNSSEC -- this is
>> (potentially) a problem for any / all 6761 type names.
>> The root is signed, so if a query leaks into the DNS (as they will),
>> an (unaware) validating resolver will try resolve it, and will expect
>> either a signed answer, or proof of an insecure delegation; without
>> this things will look bogus, and so resolvers will SERVFAIL.
>>
>> Clearly, a signed answer isn't feasible, so that leaves 2 options - 1:
>> simply note that validation will fail, and that SERVFAIL will be
>> returned in many case (to me this seems "correct"), or 2: request that
>> the IANA insert an insecure delegation in the root, pointing to a:
>> AS112 or b: an empty zone on the root or c" something similar.
>
> Hi, Warren:
>
> I'm kind of confused. If a .ALT query leaks into the DNS, and there's
> neither a secure or insecure delegation in the root, isn't the result a
> signed NXDOMAIN, not a SERVFAIL?
>
>     ; <<>> DiG 9.11.0-P1 <<>> +dnssec foo.alt
>     ;; global options: +cmd
>     ;; Got answer:
>     ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36917
>     ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
>
> --
> Robert Edmonds



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf