In message <1b8e640b-c38e-4b76-a73d-7178491a9...@fugue.com>, Ted Lemon writes: > > On Feb 1, 2017, at 3:50 PM, Ralph Droms <rdroms.i...@gmail.com> wrote: > >> It appears to me that requesting an insecure delegation is the right > >> thing to do, as a "technical use". We have, so far, been very careful in > >> what we ask for. If ICANN does not agree, then we can discuss other > >> options. > > > > I agree. > > I'm confused. The .ALT TLD is expected to be used for non-DNS name > lookups. So isn't a secure denial of existence exactly what we want for > .ALT?
No. > What is the utility in having an un-signed delegation? Alt can be used for whatever purpose that the user wants to use it for including names served using the DNS protocol. The only requirement is that leaked queries for "<name>.alt" get NXDOMAIN and that queries for 'alt.' get a NODATA response other than for SOA and NS. Signing those answers would further constrain how the namespace is used. Additionally such leaked queries should be answered as early as possible in the resolution processes to reduce the privacy exposure. The simple way to achieve that is to recursive server serve a "empty" 'alt.' zone. If there is a secure delegation then every recursive server would need to continually transfer a copy of that zone from some designated servers as the contents would need to be re-signed periodically. If there is a insecure delegation then no transfer of zone contents is needed as the entire contents can be hard coded into the server with only the decision about whether to serve the zone or not being needed to be made. We do this for 10.IN-ADDR.ARPA today. The rest of the configuration of the server decides if 10.IN-ADDR.ARPA is automatially served with a way to explictly disable the serving. For 10.IN-ADDR.ARPA we actually constuct a entire zone automatically as people configure zones like 0.0.10.IN-ADDR.ARPA and the intermediate names need to get a NODATA response. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
