RE: DNSSEC basic information

[Tony Finch]

John W. Blue  wrote:
>
> Nothing prevents anyone from using DNSSEC internally but, as I
> understand it, that was not the intent.

I'm a relative newcomer having only done DNSSEC for about 10 years (so
I wasn't around until most of the design arguments were settled), but I
don't remember seeing anyone say it wasn't intended for internal zones.

There can be some awkward things that make it much harder than signing a
public zone, though:

  * if your internal DNS squats on a fake TLD

  * if someone says you can't use the same keys to sign internal and
external views

  * RFC 1918 reverse DNS

It would be a lot less awkward if there were a good way to distribute
trust anchors for internal zones, but sadly there isn't.

> Additionally, if there is an obligation to validate zones internal to an
> organization that in of itself should be a really big red flag something
> is wrong with trust relationships.

That depends a lot on how tightly controlled your org is :-) In my fantasy
world the DNS would serve as a convenient PKI for bootstrapping trust; but
in the real world it's probably easier to boostrap off private x.509 trust
anchors or even ssh certificate auth, rather than DNSSEC, sadface.

> So the nuts and bolts of enabling DNSSEC increases zone data by 30 to
> 40%

More like a factor of 3.5x (number of records) or 10x (bytes of
presentation format zone file) based on the cam.ac.uk zone (43k
records before signing).

> not to mention the additional crypto load induced if there are
> frequent changes.

You need to be up in the thousands of updates per second before this is a
problem - see
https://lists.dns-oarc.net/pipermail/dns-operations/2019-September/019205.html

> If a split horizon is in use then internal zones typically have more
> records than external.

Yeah, private.cam.ac.uk has 350k records unsigned, but we're possibly
being silly about DHCP placeholder records :-)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Dover, Wight, Portland, Plymouth, Biscay: West or southwest 5 to 7,
occasionally gale 8 except in Biscay. Moderate or rough in Dover and east
Wight, but elsewhere rough or very rough. Showers. Moderate or good.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: DNSSEC basic information

[John W. Blue]

Anne,

Nothing prevents anyone from using DNSSEC internally but, as I understand it, 
that was not the intent.  Additionally, if there is an obligation to validate 
zones internal to an organization that in of itself should be a really big red 
flag something is wrong with trust relationships.

So the nuts and bolts of enabling DNSSEC increases zone data by 30 to 40% not 
to mention the additional crypto load induced if there are frequent changes.  
If a split horizon is in use then internal zones typically have more records 
than external.  On a zone that has a handful of records and very low QPS then a 
signed internal zone a non-issue.

As with everything, when you scale up unintended consequences of choices made 
tend to kick in.

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Anne 
Bennett
Sent: Tuesday, September 24, 2019 12:46 PM
To: bind-us...@isc.org
Subject: Re: DNSSEC basic information


Evan Hunt answers Jukka Pakkanen:

> In newer releases there's also a configuration option, 
> "validate-except", which permanently disables validation below 
> specified domains. This can be used, for example, if you have an 
> internal network using a fake TLD and you want to prevent it from showing up 
> as bogus.

... and in a separate message, John W. Blue wrote:

> 1. DNSSEC was designed for external zones


I have a case where I recently had to use "validate-except" because of a domain 
(not mine) whose external view is signed but not the internal view; my resolver 
gets the internal view for that zone.

Can someone enlighten me as to why "DNSSEC was designed for external zones", 
and under what circumstances it makes sense to *not* sign an internal view?  It 
seems to me that it would be most consistent to sign both external and internal 
views.



Anne.
--
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
a...@encs.concordia.ca+1 514 848-2424 x2285
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC basic information

[Anne Bennett]

Evan Hunt answers Jukka Pakkanen:

> In newer releases there's also a configuration option, "validate-except",
> which permanently disables validation below specified domains. This can
> be used, for example, if you have an internal network using a fake TLD
> and you want to prevent it from showing up as bogus.

... and in a separate message, John W. Blue wrote:

> 1. DNSSEC was designed for external zones


I have a case where I recently had to use "validate-except" because of
a domain (not mine) whose external view is signed but not the internal
view; my resolver gets the internal view for that zone.

Can someone enlighten me as to why "DNSSEC was designed for external
zones", and under what circumstances it makes sense to *not* sign an
internal view?  It seems to me that it would be most consistent to
sign both external and internal views.



Anne.
-- 
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
a...@encs.concordia.ca+1 514 848-2424 x2285
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC basic information

[Tony Finch]

Evan Hunt  wrote:
>
> There's a way now for a signed domain to send an in-band signal to its
> parent that the DS RRset needs updating. A new tool "dnssec-cds" is
> available to help with this. AFAIK this mechanism hasn't been adopted by
> any TLDs yet, but may be of interest anyway.

.ch https://www.nic.ch/de/faqs/dnssec/cds/
.cz https://ripe75.ripe.net/presentations/123-CDNSKEY-FRED-KNOT-RIPE75.pdf
RIPE reverse DNS 
https://ripe78.ripe.net/presentations/138-138-RIPE78_DNS_Update.pdf

Maybe others?

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Portland, Plymouth, Biscay: West or southwest 5 to 7, occasionally gale 8
later except in Biscay. Moderate or rough, becoming rough or very rough,
occasionally high later in northwest Plymouth. Rain or thundery showers. Good,
occasionally poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC basic information

[Tony Finch]

Mark Elkins  wrote:
>
> 2) When a Zone is signed, you will be given some DS Records - which need to be
> passed on for inclusion into the Parent Zone. Currently, BIND creates two DS
> keys.
> You'll find them inside "dsset-Zone.being.signed".

... if you are using dnssec-signzone, but I would not recommend that
because it is a lot more error-prone. Use `auto-dnssec maintain` in
`named` instead. If you like to edit zone files, also use `inline-signing`
(you don't need that if you just use dynamic updates).

Get the DS records for a zone using `dnssec-dsfromkey -2 -f 
[zonename]`.

> 3) Adding "CDS" (Child versions of the DS record) into your zone is also a
> useful thing to do (I *think* BIND may do this automagically?)

You need to set the right timing parameters in the key files using
`dnssec-settime` so that CDS records are generated to match your rollover
timing. CDS records say what the DS records should be, so their timing
will generally not match the timing of KSK records.

The rollover bible is https://tools.ietf.org/html/rfc7583

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Portland, Plymouth, Biscay: West or southwest 5 to 7, occasionally gale 8
later except in Biscay. Moderate or rough, becoming rough or very rough,
occasionally high later in northwest Plymouth. Rain or thundery showers. Good,
occasionally poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC basic information

[Mark Elkins]

On 2019/09/23 23:00, John W. Blue wrote:


Jukka,

Some odds n ends in no particular order:

1. DNSSEC was designed for external zones


1) I'd also suggest using Algorithm 13 - Elliptical Curve - for any new 
key creations


dnssec-keygen -a ECDSAP256SHA256 ( -f KSK) Zone.being.signed

This way - DNSKEY's are shorter (query responses are shorter, save data) 
so in a DNS Amplification attack - you are less lightly to be the source 
of the amplification.


In your DNSSEC Authoritative Nameserver, add into your BIND config 
(named.conf) :-


|options { directory "/var/named"; ... rate-limit { responses-per-second 
10; }; }; |


The "rate-limit" should also help dissuade people from using you as a 
source of amplification.
(@BIND) This perhaps should be the default behaviour for an 
authoritative only config.


2) When a Zone is signed, you will be given some DS Records - which need 
to be passed on for inclusion into the Parent Zone. Currently, BIND 
creates two DS keys.
You'll find them inside "dsset-Zone.being.signed". Use just the "13 2" 
version - SHA256  (this needs to become the minimum default 
behaviour by DNSSEC operators)
SHA384 Digests may break DNSSEC in some resolvers (unbound) - so perhaps 
avoid for now. Not everyone has upgraded.


3) Adding "CDS" (Child versions of the DS record) into your zone is also 
a useful thing to do (I *think* BIND may do this automagically?)


4) Keeping DNSSEC aware resolvers and DNSSEC authoritative Nameservers 
separate is best practise - follow that. Configs will then be more simple.


--
Mark James ELKINS  -  Posix Systems - (South) Africa
m...@posix.co.za   Tel: +27.128070590  Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC basic information

[Evan Hunt]

On Tue, Sep 24, 2019 at 03:15:42AM +, Evan Hunt wrote:
> Six years is a long time, I've probably forgotten a few.

Oh here's one: "dig +sigchase" is dead now, use "delv" to check DNSSEC
validation chains.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC basic information

[Evan Hunt]

On Mon, Sep 23, 2019 at 08:16:43PM +, Jukka Pakkanen wrote:
> I am finally diging in to DNSSEC, updating out BIND 9.14.5 servers to
> support it, both resolving & signing, secure zone transfers etc.
> 
> I just have read the DNSSEC Mastery by Michael W. Lucas from year 2013,
> and my question basically is, is this information from 6 years back still
> valid, or hopelessly outdated?  I do suppose in six years things have
> already changed a lot.  And while started testing some things, noticed
> they are not working as expected, as presented in the book.  Like when
> upgraded our servers to DNSSEC resolving, the only zone I can find the ad
> flag set is paypal.com, example isc.org does not show it.

isc.org and all of its subdomains *except* for "www" should have the AD
flag set.  We switched recently to having our website hosted at a cloud
provider, which is why the "www" domain doesn't have it.

Some other domains that I use when I want to check quickly whether my
local resolver is validating are nasa.gov (really anything at all .gov),
ietf.org, icann.net.

> Also, with current status of DNSSEC, is it still recommend/required to
> have separate authoritative & recursive servers, DNSSEC-wise?

Technically it was never required. It's still widely considered to be a
best practice, though.  But that's not really because of DNSSEC.

> DLV functionality seems to be dropped from the current BIND too?

Yes. The ISC DLV service was shut down a few years ago. The DLV key and the
"dnssec-lookaside auto" feature were removed from BIND 9.14, but it could
still be switched on manually if you wanted to use some other DLV zone that
you set up yourself.  Lookaside validation has been fully removed from the
current development branch, which will become 9.16.

> And so on... would like to know how outdated this book is, what has
> changed since 2013, and also, any hints for a good DNSSEC tutorials with
> todays BIND versions.

Well, the big environmental change is that root key has been rolled.

You longer need to specify "dnssec-validation auto" to activate the root
key; it's on by default in BIND now.

There's a new tool for generating DNSSEC keys, "dnssec-keymgr". It will
create all the keys for your zone according to policy that can be set up
in a "policy.conf" file, and maintains them for you if you run it in
a cron job. (Something similar is likely to become an internal feature
of named in a future release.)

There's a way now for a signed domain to send an in-band signal to its
parent that the DS RRset needs updating. A new tool "dnssec-cds" is
available to help with this. AFAIK this mechanism hasn't been adopted by
any TLDs yet, but may be of interest anyway.

There's an rndc command "nta" to temporarily disable DNSSEC below a
specified domain, to allow a domain to be resolved insecurely when it's
been misconfigured.

In newer releases there's also a configuration option, "validate-except",
which permanently disables validation below specified domains. This can
be used, for example, if you have an internal network using a fake TLD
and you want to prevent it from showing up as bogus.

Six years is a long time, I've probably forgotten a few.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: DNSSEC basic information

[John W. Blue]

Jukka,

Some odds n ends in no particular order:

1. DNSSEC was designed for external zones

2. Use delv instead of dig when troubleshooting DNSSEC and play around with 
these options:

+rtrace (resolver)
+vtrace (validation)

You want to see “fully validated”.

3. Commit these values to memory so that when using delve you will know what is 
being returned:

256 = ZSK
257 = KSK

4. Always remember that the way that records are signed is linear and it will 
help with situational awareness:

A DNS record is signed by the ZSK and the ZSK is signed by KSK.  And a DSKEY is 
created by the KSK.

5. DNSSEC takes a small amount of maintenance and housekeeping to manage key 
rollovers.

Rolling a ZSK is purely an internal operation and requires no interaction with 
the outside world.  Roll monthly.
Rolling a KSK requires a new DS record to be published to the parent.  Roll 
yearly.

6. Use NSEC3.

Hope that helps!

John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Jukka 
Pakkanen
Sent: Monday, September 23, 2019 3:32 PM
To: Jukka Pakkanen; bind-us...@isc.org
Subject: VS: DNSSEC basic information

Already found out about 
https://ftp.isc.org/isc/dnssec-guide/html/dnssec-guide.html, and that example 
the dnssec-enable option is now on by default…   but any usefull hints still 
gladly received 

Jukka

Lähettäjä: bind-users 
mailto:bind-users-boun...@lists.isc.org>> 
Puolesta Jukka Pakkanen
Lähetetty: 23. syyskuuta 2019 22:17
Vastaanottaja: bind-us...@isc.org
Aihe: DNSSEC basic information

I am finally diging in to DNSSEC, updating out BIND 9.14.5 servers to support 
it, both resolving & signing, secure zone transfers etc.

I just have read the DNSSEC Mastery by Michael W. Lucas from year 2013, and my 
question basically is, is this information from 6 years back still valid, or 
hopelessly outdated?  I do suppose in six years things have already changed a 
lot.  And while started testing some things, noticed they are not working as 
expected, as presented in the book.  Like when upgraded our servers to DNSSEC 
resolving, the only zone I can find the ad flag set is paypal.com, example 
isc.org does not show it.

Also, with current status of DNSSEC, is it still recommend/required to have 
separate authoritative & recursive servers, DNSSEC-wise?

DLV functionality seems to be dropped from the current BIND too?

And so on... would like to know how outdated this book is, what has changed 
since 2013, and also, any hints for a good DNSSEC tutorials with todays BIND 
versions.

Jukka
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users