Daniel, Thanks for the review. We will pickup the reported nits and textual clarifications. See comments below on some of your protocol questions.
> I think the motivation should be better exposed. The reason > you need the options are: > - 1) When you have multiple interface to be able to define > for which domain name the DNS query MUST be sent to internal resolver.
I don't think the protocol depends on "interfaces", so I would avoid adding that now. It is all about "views", and changing the view.
> Note, that the architecture implies that my resolution goes through > the internal resolver. In other words, the mobile cannot have a > resolver that directly queries the authoritative servers. Maybe that > would be good the NS are also provided by a INTERNAL_NS_DOMAIN
It can do that if it wants to, by using the supplied resolver. But the way a mobile works is by adding "forwarders" for certain DNS domains. I do not see why it would need to insist on talking to the authoritative internal DNS servers? so unless he can come up with a real use case why that would be needed, I would not want to add INTERNAL_NS_DOMAIN.
3. Protocol Exchange > MGLT: I think the section is missing text that provides an > overview of the protocol. > The purpose of the information exchanged between the VPN > client and the gateway are expected to provide the necessary > information so the VPN client be informed properly of the > domains that resolve differently internally than externally. > In addition, some extra material should be provided so the > resolution can appropriately be performed.
I think that belongs in the introduction, and should not be repeated in Ssection 3 that specifies the protocol.
> MGLT: My understanding is that INTERNAL_IP4_DNS and INTERNAL_IP6_DNS > only concerns the resolution. As resolution could be performed through > the resolvers as well as by the client I would treat this aspect and > the recommendations a separate section. The resolution could be for > example performed by a resolver on the client in which case NS > records may be requested by the client.
See above. The protocol hands over all the information needed to resolve securely. If the client wants to satisfy its curiosity about where the authoritative DNS servers are, it can ask the provided forwarding DNS server.
> MGLT: Maybe that would be good to have a INTERNAL_NS attribute.
Again, I dont see a use case for it.
> Also one domain name may have multiple TA, I think it would be > wiser to be able to have multiple TA payload associated to one > domain.
The TA format includes the domain it applies for already, so there is no reason to complicate things by creating more associations or dependencies between the payload options.
> MGLT: I think that is better to use the wire format than the string format.
As explains in another thread on the list, that just complicates sending this information down to a locally running DNS server. None of the current ones take DNS wireformat for on-the-fly reconfiguration. However, they do take DNS presentation format. Also, for instance if you look at the libreswan implementation, this data is passed into the connection handler via environment variables, so libreswan would have to convert the DNS wire format to DNS presentation format before giving it to the handler for DNS reconfiguration.
> I do not understand why the TTL is ignored. I also think that > would be important in case of KSK roll-over.
The TTL is ignored because this is an administrative reconfiguration. Just like a DNS server loading trust anchors from a file, there is no TTL to that file-based information either. If the zone does a KSK roll without updating the IPsec server, it is an administrative error. Possibly, the IPsec server could have code that reads the KSK's hourly and auto-updates what it gives to its clients, but that would all be implementation specific and I don't think this document needs to specify that.
> Maybe some text could mention that multiple TA can be added > especially during the key roll over.
Sure, if that is not obvious we can do that.
> In addition, I think additional text shoudl be provided to clarify > what ar ethe advanatges of using a DS reccord. In fact providing > the KSK in stead of the DS prevent teh client to request the KSK.... > so it seems the KSK will anyway be transmitted.
Trust anchors for DNS servers tend to be specified using DS records, or "DS or DNSKEY" records. So DS was the common denominator. Additionally, a DS blob is much smaller than a DNSKEY blob. I had asked at the last IETF if DNS vendors prefered one of the other, since getting a DS means they need to fetch the DNSKEY (insecurely) and then confirm it matches the DS record supplied, and they said DS was fine for them. (I talked to unbound, knot and bind people)
For each INTERNAL_DNS_DOMAIN entry in a CFG_REPLY payload, the client SHOULD use the provided INTERNAL_IP4_DNS or INTERNAL_IP6_DNS DNS servers as the only resolvers for the listed domains and its sub- domains and it SHOULD NOT attempt to resolve the provided DNS domains using its external DNS servers. > MGLT: This may come with some privacy issues. So I would rather > let the client chose if the domain is in relation with an internal > resolution.
That can use some rewording. Note there are different use cases. Obviously, we don't want VPN provider FOO to ask for all google.com queries when the VPN client connects to it only for FOO services. But we also want to give university BAR a chance to hand out a list of their own custom domains that the VPN client does not know about beforehand.
If a CFG_REPLY contains one or more INTERNAL_DNS_DOMAIN attributes, the client SHOULD configure its DNS resolver to resolve those domains and all their subdomains using only the DNS resolver(s) listed in that CFG_REPLY message. If those resolvers fail, those names SHOULD NOT be resolved using any other DNS resolvers. All other domain names MUST be resolved using some other external DNS resolver(s), configured independently, and SHOULD NOT be sent to the internal DNS resolver(s) listed in that CFG_REPLY message. For example, if the INTERNAL_DNS_DOMAIN attribute specifies "example.com", then "example.com", "www.example.com" and "mail.eng.example.com" MUST be resolved using the internal DNS resolver(s), but "anotherexample.com" and "ample.com" MUST be resolved using the system's external DNS resolver(s). > MGLT: Unless i am missing some point I would rather mention this as a > SHOULD. This appears to me more a policy.
Well, the idea here is that you will not be able to resolve that resource unless you accept DNS server for it. If you say SHOULD instead of MUST, it means you are going to fail to resolve the internal resource. As for using the internal DNS for more than advertised, if the internal DNS server is okay with resolving everything, it could send the value ".". We could clarify that explicitly. One risk of using an internal DNS for a public DNS name is that the client can be tricked into revealing that it has a VPN connection option to VPN provider FOO by giving it a unique tracking DNS entry to lookup. So unless the VPN provider instructs clients to use it for ALL DNS, I think the advise of MUST is good. Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
