Hey Amir, The DNSSEC setup is not delivery service specific, but CDN specific. Once enabled, it will generate signatures for *all* DNS records for which the Traffic Routers are authoritative. There are no delivery service specific settings.
The big thing to understand is the relationship between the CDN and the DNS delegation point, as it relates to DNSSEC. You can generate keys for the CDN under Tools -> Manage DNSSEC Keys; once generated, you should see data, and more specifically, the data around "DS Record Information" is what's important. This represents the DS RR type and a DS record with the data shown on this screen goes into the parent domain's zone, at the delegation point for your CDN. For example, if you delegate cdn.example.com to a Traffic Control system, Traffic Router is authoritative for that entire domain. You would need to work with the owners of example.com to insert a DS record with this information. The record itself would exist in example.com, and would look something like: cdn.example.com IN DS XXXX Y Z DIGEST ..where XXXX is the key ID (auto generated), Y is the algorithm, Z is the digest type, and DIGEST is the digest in hex. If you want to enable DNSSEC familiarize yourself with the operational best practices, documented in RFC 6781 and the key rollover timing considerations documented in RFC 7583. You will need to know what a KSK and ZSK are, how they relate to DNSKEY and DS RR types, and understand how you "roll" the KSK at the delegation point. KSKs that Traffic Control generates are generally good for one year, so that means you should roll the CDN's KSK annually. We used the pre-publish strategy for our 2016 key roll and will be doing the same this year when the time comes. This means creating a KSK that's effective in the future, which is published but not used to sign records. You can do this by using the "Regenerate KSK" button on the management screen and setting the effective date to one in the future to allow resolvers to get a new copy of DNSKEYs and DS records prior to the actual effective date. Traffic Router uses the effective date to know which key to sign RR sets with, so it won't actually use the new key until the effective date. When testing a DNSSEC implementation, it's important to test and understand the relationship between each zone and RR type. There are two sites I use for this: http://dnsviz.net/ http://dnssec-debugger.verisignlabs.com/ ..these sites will help you identify why DNSSEC validation might be failing, which manifests only as a SERVFAIL at the client side, which isn't very helpful. -- Thanks, Jeff On Wed, Sep 27, 2017 at 10:40 AM, Amir Yeshurun <[email protected]> wrote: > Hello dev list. > > To avoid DNS cache pollusion, I would like to use DNSSEC, so that TR sign > cdn- domain A records. > > The docs say that this feafure is only available for DNS based delivery > services. > > My delivery services are HTTP. > > I would like to understand what are the gaps to fill in order to have > DNSSEC support in HTTP delivery services. > > Thanks > /amiry
