At the last IETF, we discussed draft-pauly-ipsecme-split-dns-01.
The authors had one question, related to whether we should use the
DNSKEY or DS record format for the INTERNAL_DNSSEC_TA CP payload.
I talked to the bind, knot and unbound people about this.
Bind cannot perform a runtime trust anchor reconfiguration via its rndc tool.
So you need to create trust anchor files to read in. These files use the
DNS presentation format and currently support only the DNSKEY format,
not the DS format. This makes sense because this is not a runtime
operation where you send the information of ( IP of nameserver, trust
anchor, domain name).
The unbound developers at the last IETF were not sure about the
capabilities of unbound-control. The man page lists that you can configure
trust anchors via DNSKEY or DS record. Running a test command via:
sudo unbound-control set_option trust-anchor: "<DS RECORD>"
with or without an unbound-control forward_add domain 1.2.3.4 (to a real
recursive nameserver) did not seem to properly pickup the trust anchor
and still returned data as insecure.
The knot developers weren't sure what was supported, but said they would
support whichever option we needed.
I did not yet test sysatemd-resolved.
It seems the software still needs work, so probably those vendors can
adapt based on our requirements. So I think we can pick the option we
prefer the most. In my opinion, that would be the DS record, because it
is not as bulkt as DNSKEY records.
A second discusion item that came up was the danger of using strings for
this option, where people could possibly put evil items in the string,
such as "IN DS `cat /etc/passwd`". If the DNS wire format is used,
this attack would be prevented. My issue with that is that I would still
need to convert the wire format to presentation format to present it to
the on-the-fly reconfiguration tools of the DNS server. So I don't see
much value in this additional conversion from a security point of view.
If I missed anything else from discussions at the last IETF, please let
me know. I think the important part was for more people to read the
draft and give us feedback, so we can move on with the draft. As Tommy
said, a standarized option for DNS handling is badly needed for IKEv2.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
