> On Feb 1, 2017, at 4:42 PM, Mark Andrews <ma...@isc.org> wrote: > > > 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 draft restricts use of .alt as follows: This label is intended to be used as the final (rightmost) label to signify that the name is not rooted in the DNS, and that normal registration and lookup rules do not apply. ...which would lead me to believe .alt would not be used for names served using the DNS protocol. However, the phrase "not rooted in the DNS" might need some clarification. In particular, would ".homenet.alt" be OK, as it is a locally-served zone, not a subdomain of the root zone? - Ralph > > 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
