DNSSEC in Traffic Router

[Amir Yeshurun <am...@qwilt.com>]

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

Re: DNSSEC in Traffic Router

[Amir Yeshurun <am...@qwilt.com>]

Thanks Jeff,
This is very clear and informative

On Wed, Sep 27, 2017 at 10:36 PM Jeff Elsloo <el...@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
>

Re: DNSSEC in Traffic Router

[Jeff Elsloo <el...@apache.org>]

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