On Wed, Feb 18, 2015 at 3:26 PM, Hosnieh Rafiee <[email protected]> wrote:
> Does it mean that you want to only go with solution to change DNS protocol? > You don't want to put any other solution in agenda which doesn't change > much > the DNS protocol such as cga-tsige. The might be more examples. > > Best, > Hosnieh I am not proposing to change the DNS protocol. What I am proposing is to change the DNS protocol Session layer while keeping the DNS protocol the same. The VeriSign proposal is essentially the same. I know people don't like thinking of things in terms of the ISO stack model (because that particular model is rubbish). But thinking of the problem in terms of a stack is still really useful. A DNS client cannot have an encrypted conversation with a DNS server unless both the client and serve understand the encryption protocol and know the key. So there is going to have to be a code change at both sides. The question is what that change should look like. Despite the name 'TLS', TLS actually works above the TCP layer so it isn't transport. It is something in between. The Internet does not follow the ISO stack model but it does have layers between ISO layers 4 and 7. What changes at each layer is not just the data format, the identifiers change as well. An Application connects to the Internet through a DNS name. The connection to the transport layer is an IP address and port number. Here is the problem: DNS is not just an information service built on top of the Internet stack, it is an information service that is being used in layers 5 and 6. It is certainly being used to map DNS host names to IP addresses and I would like to see it being used to map DNS Service (SRV) names to host names. So the design of any revised DNS client-resolver protocol has to dance round the bootstrap problem.
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
