On Mon, Feb 6, 2017 at 11:27 PM, Mark Andrews <ma...@isc.org> wrote: > > In message <99431a77-7b62-4655-89ef-faa32f2a8...@gmail.com>, Brian > Dickson writes: > > The suggestion of DNAME to empty.as112.arpa involves some subtle details, > > which IMHO may in combination be the right mix here. > > > > The DNAME target is an insecure empty zone. > > > > This avoids the validation issue, and facilitates use of local "alt" > > namespaces. > > No it doesn't. > > > The default response to queries under alt would be unsigned NXDOMAINs. > > No, it would be a secure response saying that foo.alt is covered > by a DNAME. The names under empty.as112.arpa are unsigned NXDOMAINs. > > The difference between the two descriptions is critical to why a > DNAME in the root zone will not work. You *have* to leak names to > the root to get a DNAME returned by ordinary processing because the > DNAME is signed. > > > I am not seeing a problem with this. > > > > Am I missing anything? > > Yes. A solution that *works*. > > What are the specific requirements for the solution?
I am inferring that the following are needed: The ability to have a local authority server for *.alt, where responses to queries with DO=1 do not include any DNSSEC RRs, i.e. unsigned responses. The ability to have validating forwarders configured to point to one or more resolvers, where the resolvers are configured to use these alt server(s) (directly or indirectly) The ability of validating stub resolvers to accept the answers received (not BOGUS). Does the existence of query rewriting matter, as long as the end result RDATA is the expected value? I.e. If the query is "my-thing.foo.alt", returns a combo of "alt DNAME empty.as112.arpa" plus "my-thing.foo.empty.as112.arpa <RRTYPE> <RRDATA>", is that acceptable, as long as there is no validation failure? Whatever initiated the DNS call, via the stub, would get back <RRDATA>, and presumably be unaware of the presence of the DNAME. I just want to be sure what is or is not acceptable, and what is explicitly within the requirements for a working solution. Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
