Re: Value of a DNSSEC validating resolver

[Mark Andrews]

-- 
Mark Andrews

> On 10 Feb 2024, at 04:18, Randy Bush  wrote:
> 
> 
>> 
>> I admit here we most often work with internal only forwarders, which
>> are not accessible from outer internet. So those won't be under attack
> 
> i am always impressed by security optiism
> 
> randy

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys?

[Björn Persson]

Jordan Larson via bind-users wrote:
> All the dnssec configuration(s) only need to reside on the master then, 
> correct?

Correct.

Björn Persson


pgpkzz0Ht2jQu.pgp
Description: OpenPGP digital signatur
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Value of a DNSSEC validating resolver

[Randy Bush]

> I admit here we most often work with internal only forwarders, which
> are not accessible from outer internet. So those won't be under attack

i am always impressed by security optiism

randy
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys?

[Jordan Larson via bind-users]

Thank you for the detailed explanation! This is what I was wondering.

All the dnssec configuration(s) only need to reside on the master then, correct?

Looks like it a got a little clean-up to do.

Appreciate everyones insight with this!

~Jordan



On 2/9/24, 8:44 AM, "Björn Persson"  wrote:
Jordan Larson via bind-users wrote:
> Was I wrong to enable “inline-signing yes” for my slave zones? I would assume 
> each slave would need its own DS key? Can I do that?

That sounds very wrong. Your zone shall have one DNSsec key, or set of
keys, that is the same on all slave servers. A client shall see the
same set of DNSKEY records regardless of which DNS server it queries.

If you sign the zone on the master, then you shouldn't sign it again on
the slaves. The slaves shall receive RRSIG records from the master just
like any other records, and serve them to clients. Only the master has
the secret keys.

If the master can't sign for some reason, then you can do "bump in the
wire" signing: A single signing server receives the unsigned zone from
the hidden master over a secure link, signs it, and distributes the
signed zone to multiple slaves. Only the signing server has the secret
keys. That way there's still a single consistent set of DNSKEY records.

If you need to give different answers to different clients, then you
configure separate views, and you must ensure that each client sees the
same view – including the same keys – on all DNS servers it can query.

Björn Persson

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Value of a DNSSEC validating resolver

[Petr Menšík]

On 2/9/24 12:39, Mark Andrews wrote:

Do the analysis where the resolver is under attack or the auth server with the 
best rtt is stale.

I admit here we most often work with internal only forwarders, which are 
not accessible from outer internet. So those won't be under attack, at 
least directed from uncontrolled outside. For internal organization 
resolver it is somehow easier to find source of attack and make them 
stopped. Something not possible on public internet. And of course, if 
auth server becomes unreachable, it is up to resolver to try alternative 
servers known. If they do not respond as well, then yes, stale cache is 
the only thing protecting us from serving SERVFAILs.


But I am not sure how that contradicts what I have written before. Can 
you elaborate a bit more, please?


--
Petr Menšík
Software Engineer, RHEL
Red Hat,https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Value of a DNSSEC validating resolver

[Mark Andrews]

Do the analysis where the resolver is under attack or the auth server with the 
best rtt is stale.

-- 
Mark Andrews

> On 9 Feb 2024, at 21:40, Petr Menšík  wrote:
> 
> Hello Mark,
> 
> allow me here to correct your statement. We spent in Red Hat some time 
> thinking and testing validating clients. Validating resolver is *not* 
> necessary for validating clients to work. They are better and recommended, 
> but not always necessary.
> 
> What is required is dnssec (security) awareness. Meaning that resolver will 
> fetch signatures for all queries with do=1 bit set. For example even dnsmasq 
> in default configuration will forward DNSSEC signatures to all DNSSEC enabled 
> queries. Also in cases dnssec validation is not enabled in it. It is not 
> strictly required fetching them for do=0 queries.
> 
> For example our office resolvers do not have validation enabled. But they 
> allow any clients using dnssec-trigger to validate all queries themselves. 
> And that works for majority of existing DNS caches.
> 
> What is required from bind9 is to have dnssec-enabled yes; That was default 
> even in 9.11 and this is the last version, where it is possible to change it 
> to dnssec-enabled no; Since 9.16 it is not possible to configure it that way. 
> In this case any validating client, be it end station or dns forwarder, will 
> fail all queries sent to it. Clients can validate regardless 
> dnssec-validation value is used, but they need do=1 answers to their do=1 
> queries.
> 
> Following chain of forwarders will still deliver non-bogus answers only. fwd 
> means forwarder only, not using root hints.
> 
> [root-servers]---[non-validating iterative][non-validating 
> fwd]---[validating fwd]--->(secure or unsigned answers only)
> 
> Validating client can refuse answer to dnssec-failed.org, even if the 
> recursive forwarder it is using did not check its validity. If it sends you 
> do=1 enabled answers, that is enough. You have to compute your own SERVFAIL 
> result, which validating upstream forwarder could have sent you straight 
> away. That that is the beauty of DNSSEC. Not everyone in the chain needs to 
> be doing crypto operations. But everyone in the chain can, as long as crypto 
> records are included.
> 
> delv +vtrace or unbound-host -rvD commands work even on non-validating, but 
> security aware resolvers.
> 
> And to answer original question. You store in cache only valuable records, 
> not bogus garbage. Having cache filled also with signatures makes validation 
> of your clients much faster, just RTT between you is used, even when they 
> validate.
> 
> Regards,
> Petr
> 
>> On 12/1/23 22:40, Mark Andrews wrote:
>> A validating resolver is a prerequisite for validating clients to work. 
>> Clients don’t have direct access to the authoritative servers so the can’t 
>> retrieve good answers if the recursive servers don’t filter out the bad 
>> answers.
>> 
>> Think of a recursive server as a town water treatment plant. You could 
>> filter and treat at every house and sometimes you still do like boiling 
>> water for baby formula but on the most part what you get out of it is good 
>> enough for consumption as is.
>> 
>> -- 
>> Mark Andrews
>> 
 On 2 Dec 2023, at 08:14, John Thurston  wrote:
>>> 
>>> 
>>> 
>>> At first glance, the concept of a validating resolver seemed like a good 
>>> idea. But in practice, it is turning out to be a hassle.
>>> 
>>> I'm starting to think, "If my clients want their answers validated, they 
>>> should do it." If they *really* care about the quality of the answers they 
>>> get, why should my clients be trusting *me* to validate them?
>>> 
>>> Can someone make a good case to me for continuing to perform DNSSEC 
>>> validation on my central resolvers?
>>> 
>>> -- 
>>> --
>>> Do things because you should, not just because you can.
>>> 
>>> John Thurston907-465-8591
>>> john.thurs...@alaska.gov
>>> Department of Administration
>>> State of Alaska
> 
> -- 
> Petr Menšík
> Software Engineer, RHEL
> Red Hat, https://www.redhat.com/
> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
> 


OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: Binary data
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
> this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users


OpenPGP_signature.asc
Description: Binary data
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Value of a DNSSEC validating resolver

[Petr Menšík]

Hello Mark,

allow me here to correct your statement. We spent in Red Hat some time 
thinking and testing validating clients. Validating resolver is *not* 
necessary for validating clients to work. They are better and 
recommended, but not always necessary.


What is required is dnssec (security) awareness. Meaning that resolver 
will fetch signatures for all queries with do=1 bit set. For example 
even dnsmasq in default configuration will forward DNSSEC signatures to 
all DNSSEC enabled queries. Also in cases dnssec validation is not 
enabled in it. It is not strictly required fetching them for do=0 queries.


For example our office resolvers do not have validation enabled. But 
they allow any clients using dnssec-trigger to validate all queries 
themselves. And that works for majority of existing DNS caches.


What is required from bind9 is to have dnssec-enabled yes; That was 
default even in 9.11 and this is the last version, where it is possible 
to change it to dnssec-enabled no; Since 9.16 it is not possible to 
configure it that way. In this case any validating client, be it end 
station or dns forwarder, will fail all queries sent to it. Clients can 
validate regardless dnssec-validation value is used, but they need do=1 
answers to their do=1 queries.


Following chain of forwarders will still deliver non-bogus answers only. 
fwd means forwarder only, not using root hints.


[root-servers]---[non-validating iterative][non-validating 
fwd]---[validating fwd]--->(secure or unsigned answers only)


Validating client can refuse answer to dnssec-failed.org, even if the 
recursive forwarder it is using did not check its validity. If it sends 
you do=1 enabled answers, that is enough. You have to compute your own 
SERVFAIL result, which validating upstream forwarder could have sent you 
straight away. That that is the beauty of DNSSEC. Not everyone in the 
chain needs to be doing crypto operations. But everyone in the chain 
can, as long as crypto records are included.


delv +vtrace or unbound-host -rvD commands work even on non-validating, 
but security aware resolvers.


And to answer original question. You store in cache only valuable 
records, not bogus garbage. Having cache filled also with signatures 
makes validation of your clients much faster, just RTT between you is 
used, even when they validate.


Regards,
Petr

On 12/1/23 22:40, Mark Andrews wrote:
A validating resolver is a prerequisite for validating clients to 
work. Clients don’t have direct access to the authoritative servers so 
the can’t retrieve good answers if the recursive servers don’t filter 
out the bad answers.


Think of a recursive server as a town water treatment plant. You could 
filter and treat at every house and sometimes you still do like 
boiling water for baby formula but on the most part what you get out 
of it is good enough for consumption as is.


--
Mark Andrews


On 2 Dec 2023, at 08:14, John Thurston  wrote:



At first glance, the concept of a validating resolver seemed like a 
good idea. But in practice, it is turning out to be a hassle.


I'm starting to think, "If my clients want their answers validated, 
they should do it." If they *really* care about the quality of the 
answers they get, why should my clients be trusting *me* to validate 
them?


Can someone make a good case to me for continuing to perform DNSSEC 
validation on my central resolvers?


--
--
Do things because you should, not just because you can.

John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska


--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys?

[Mark Elkins via bind-users]

Couple of things...

Use the words Primary and Secondary... don't use Master and Slave - as 
it upsets many people.
(I teach DNS/DNSSEC and still say dumb things at times, and I live in 
South Africa)


The Secondary Nameservers should not have any additional DNSSEC 
configurations if the Primary is doing all the DNSSEC signing, and it 
sounds like the Primary is working fine from a DNSSEC point of view. You 
want the Secondaries to simply give the same responses (e.g. the same 
DNSKEY records) when queried - not a bunch of variations depending on 
who is asked.


On the Primary Nameserver - there should now be some CDS records, or at 
least one. This should become the DS record in the Parent zone.


Try and update the BIND software on all your servers to something that 
is supported by the community. There is no time delay required for this, 
just do it. (I've read the other comments regarding this and agree with 
them).


Using Algorithm 13 is a good choice - well done.
You only need to provide the (C)DS SHA-256 version (digest type 2) to 
the parent


After providing the parent zone with the correct DS record, you then may 
need to tell the Primary nameserver that you have done this.


On 2024/02/08 21:56, Jordan Larson via bind-users wrote:


Greetings!

I have what is hopefully a simple question regarding proper setup 
around DNS. I feel somewhat comfortable navigating around BIND but 
possibly am getting confused around the DNSSEC portion.


This is for an internally facing DNS, not exposed to the internet.

High level setup is as follows:

We have 1 master/primary and 4 slaves/secondaries. These are running 
Ubuntu 20.04 with OS installed BIND (9.16.1).


Any DNS updates/changes are made on the stealth master and the zones 
are propagated to the slaves and entries are added and removed. Slaves 
handle all DNS requests and forward out to google for any externally 
facing DNS requests.


I have the dnssec-policy set to default on the master AND slaves at 
the global level via the named.conf.options.


While reviewing the following doc 
https://kb.isc.org/v1/docs/dnssec-key-and-signing-policy#ksk-rollover 
 
it appeared that perhaps I was missing a critical settings for 
inline-signing set to yes for all of the zones on the 
slaves/secondaries. This is a recent addition as of a few days ago. I 
now have that set.


While watching the key state and waiting for all them to go to 
omnipresent I noticed that DSState has been sitting at rumored for 
over 48+ hours.


I saw this very helpful mailing list thread: 
https://lists.isc.org/pipermail/bind-users/2022-May/106182.html 



I was hopeful that after 26 hours (default settings) that this would 
eventually roll over to omnipresent. However upon reading further down 
in the first link it makes mention of the following:


“DSState stuck in rumoured?

If you see the DSState stuck in rumoured after the migration, you need 
to run rndc dnssec -checkds published example.com to tell BIND that 
the DS is already published in the parent zone. Be sure and confirm 
that the DS has actually been published before performing the command 
(see KSK rollover for details about checking the DS state).”


On my hidden master:
root@master:~# cat /var/cache/bind/Kexample.com.+013+64370.state

; This is the state of key 64370, for example.com.

Algorithm: 13

Length: 256

Lifetime: 0

KSK: yes

ZSK: yes

Generated: 20231117041456 (Fri Nov 17 04:14:56 2023)

Published: 20231117041456 (Fri Nov 17 04:14:56 2023)

Active: 20231117041456 (Fri Nov 17 04:14:56 2023)

DNSKEYChange: 20231117061956 (Fri Nov 17 06:19:56 2023)

ZRRSIGChange: 20231118051956 (Sat Nov 18 05:19:56 2023)

KRRSIGChange: 20231117061956 (Fri Nov 17 06:19:56 2023)

DSChange: 20231120071956 (Mon Nov 20 07:19:56 2023)

DNSKEYState: omnipresent

ZRRSIGState: omnipresent

KRRSIGState: omnipresent

DSState: omnipresent

GoalState: omnipresent

Slaves can query the master (nothing else can and recursion is also 
off). If I do a check for the key, I can see it here:


root@slave1:~# dig @10.0.0.20 example.com DNSKEY +multiline

; <<>> DiG 9.16.1-Ubuntu <<>> @10.0.0.20 example.com DNSKEY +multiline

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48018

;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

; COOKIE: 766c81fa38f5d458010065c52a97cbca37018dd97375 (good)

;; QUESTION SECTION:

;example.com.   IN DNSKEY

;; ANSWER SECTION:

example.com.    3600 IN DNSKEY 257 3 13 (

rvOPupnLJkkYyrVI9dr7EygIBF3yLLnjR1UIpIj7+Wcy

MeoUVuCY0lAEkOlseCm5d0RGlBtOXC6gpV6SZuFwRg==

) ; KSK; alg = ECDSAP256SHA256 ; key id = 64370

;; Query time: 0 msec

;; SERVER: 10.0.0.20#53(10.4.2.36)

;; WHEN: Thu