This document was marked as "waiting for more reviews before taking as
WG draft", so I did my review now. Here are my comments:
----------------------------------------------------------------------
In the section 1 there is text:
The client device
can use the internal DNS server(s) for any DNS queries within the
assigned domains, while routing other DNS queries to its regular
external DNS server.
which would indicate that we can also use internal dns servers for
other DNS queries too.
Then on section 5 there is text saying:
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.
This is bit confusing. First of all all other domain names MUST use
external DNS servers, but then the requirement for ont using internal
DNS is only SHOULD NOT.
What is what we want there. Do we want to have clear splitting of the
DNS servers, i.e. all request for internal names go to the internal
servers, and never external ones, and do we want all request to
external names go to the external servers, and never internal ones.
I think the 1st point (I.e. all requests about internal names go to
the internal servers) is something that is important for security, so
it should perhaps be MUST.
On the other hand the 2nd point is not about security. Quite often
people can and want to use internal DNS server even for external DNS
requests. So I think that should be allowed in both ways, i.e.,
external DNS names can be asked from either internal or external name
servers, or even both.
--
>From section 3.2
If the CFG_REQUEST included INTERNAL_DNS_DOMAIN attributes with non-
zero lengths, the CFG_REPLY MUST NOT assign any domains in its
INTERNAL_DNS_DOMAIN attributes that are not contained within the
requested domains. The initiator SHOULD ignore any domains beyond
its requested list.
This whole thing about restricting the subdomains server can send by
sending the list from client is different than what we normally do. In
normal case the client sends list of suggestions for the configuration
values to the server. Here the client forces server to do something.
I think it would be better to say that client can send list of dns
names it would like to be included, and server can then reply whatever
list it has in its configuration, and client is free to ignore as many
of the items from the list it likes.
This way if you have originally configured company1.com to the
internal dns names, and then company decides to buy another company
called company2.com, teh client can still request company1.com and
server can return both company1.com and company2.com in its reply.
Then it is up to the client whether it will belive the list or not.
--
In section 4.2 it would be useful to repeat the fact that the bytes
after the Length match the DNS wire format of a DS record as specified
in [RFC4034]. The bytes match, but we repeat the definition from the
RFC4034, so it would be good idea to also explictly say it here, and
not only in section 3.2.
--
In section 5 the text:
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.
Why is that only SHOULD. I mean if there is INTERNAL_DNS_DOMAIN
specified, shouldn't the client be following it? So why it is not
MUST? And in which cases the SHOULD can be broken? What are the
exceptions where internal domains can be resolved from the outside dns
servers (or actually failed to be resolved).
--
If the initiator host is configured to block DNS answers containing
IP addresses from special IP address ranges such as those of
[RFC1918], the initiator SHOULD allow the DNS domains listed in the
INTERNAL_DNS_DOMAIN attributes to contain these IP addresses.
I think this is wrong. I think we should say that it should not block
any addresses which are part of the configured INTERNAL_IP*_SUBNETS.
I.e., if the vpn is not configured to pass packets to 10.0.0.0/8
network, then blocking those DNS answers is still fine.
--
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.
Again why only SHOULD? When should it ignore the instructions from the
server?
--
If those resolvers fail, those names SHOULD
NOT be resolved using any other DNS resolvers.
Should this also be MUST NOT?
--
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.
This was already in my previous comment.
--
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).
But then in the example there is only MUSTs....
--
When an IPsec connection is terminated, the DNS forwarding must be
unconfigured. The DNS forwarding itself MUST be be deleted. All
cached data of the INTERNAL_DNS_DOMAIN provided DNS domainis MUST be
flushed. This includes negative cache entries. Obtained DNSSEC
trust anchors MUST be removed from the list of trust anchors. The
This might cause security issues. I.e., if you have mail.example.com
resolved using internal dns server to have IP-address of 10.0.0.1, and
then someone manages to tear down the VPN connection, and suddenly all
these mappings go away, the next time your mail client tries to fetch
email, it does mail.example.com lookup using external DNS servers, and
will get IP-address of 1.1.1.1 from ns.evil.org, then then it will
connect to wrong mail server...
Perhaps we should keep the mappings for some time, just in case the
connection comes back few seconds later when the vpn reconnects...
--
A domain that is served via INTERNAL_DNS_DOMAIN MUST NOT have
indirect references to DNS records that point to other Split DNS
domains that are not served via INTERNAL_DNS_DOMAIN attributes.
Indirect reference RRtypes include CNAME, DNAME, MX and SRV RR's.
How this going to be done?
I.e., how do you convince the system adminstrator of the company1.com
that adding mail.company2.com CNAME mail.company1.com is against RFC,
and must not be done until all clients are configured to ask
company1.com and company2.com internal dns domains?
I think we can put that text in the security consideration section and
say that adminstrators should take care that the CNAMES etc used in
the internal domains, do not leak out to wrong domain names or
something.
--
In section 6:
If a host connected to an authenticated IKE peer is connecting to
another IKE peer that attempts to claim the same domain via the
INTERNAL_DNS_DOMAIN attribute, the IKE connection should be
terminated.
Which of the IKE connection should be terminated? Perhaps the first
connection has died and user tried to reconnect to the same server,
which will of course give the same INTERNAL_DNS_DOMAIN. Tearing down
that new connection and not allowing it to be formed until the first
one is timed out is bit annoying.
--
If the IP address value of the received INTERNAL_IP4_DNS or
INTERNAL_IP6_DNS attribute is not covered by the proposed IPsec
connection, then the local DNS should not be reconfigured until a
CREATE_CHILD Exchange is received that covers these IP addresses.
I think this is dangerous. I.e. if the server returns INTERNAL_IP4_DNS
of 10.0.0.1 and INTERNAL_DNS_DOMAIN of example.com, but initial Child
sa connection fails for some reason (out of resources). Next the email
client trying to resolve the mail.example.com goes out to the external
dns servers to find the name, instead of trying to use 10.0.0.1 dns
server. Note, that when it tries to send packet to 10.0.0.1, then the
IPsec will simply trigger for that packet, and will create the Child
SA needed...
So I think the DNS configuration should be done immediately,
regardless whether the Child SA to cover those IP address is there.
In properly configured system the IP-address will then trigger the SA
to be created when they are first time used.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
