Thanks Jeff, This is very clear and informative On Wed, Sep 27, 2017 at 10:36 PM Jeff Elsloo <els...@apache.org> wrote:
> 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 <am...@qwilt.com> 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 >
