On Mon, 20 Mar 2017, Steve Crocker wrote:
If you assume the local environment is going to get complicated and that signing of the local domain will become important in order to guard against hijacking by errant devices inside the perimeter, it looks to me there will have to be a local trust anchor. For devices brought into the environment, DHCP already assigns the IP address and the DNS servers. It can “easily” be augmented to hand out the public key of the local hierarchy. Or, I suppose, since I’ve just posited that the DHCP server will tell the new device which DNS server to use, the device could then query the DNS server to find out if it has a signed .homenet domain and what its public key is.
I am assuming that if stubs are validating, then they must also support excluding special queries from validation, such as mDNS, .onion and .homenet. The .homenet queries should never reach real DNS servers, so I would not think an insecure delegation in the root is required. If the DNS resolver doesn't know how to handle .homenet, it is already as wrong as it can be, regardless of the type of answer. I thought the reason to ask for a Special Names domain was to ensure no one else can register and launch .homenet in the future. Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
