Re: DNSSEC basic information
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
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
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
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
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
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
Tony, Thanks for the observations! My comments about intent and zone data size is based upon information that was presented at Infoblox training classes I have attended. I would assume that Infoblox being Infoblox would be (mostly) accurate when it comes to developing a slide deck. However, context is everything. .local et al TLD's have forever been a burr under my saddle and I know that many on this list will see no objection to the use of them. But I kill em off every chance I get. John -Original Message- From: Tony Finch [mailto:d...@dotat.at] Sent: Tuesday, September 24, 2019 2:01 PM To: John W. Blue Cc: bind-us...@isc.org Subject: RE: DNSSEC basic information 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
