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 

Re: Facing issues while resolving only one record

[Mark Elkins via bind-users]

To disable DNSSEC validation for a domain from the command line - I 
use:   dig +cd eportal.incometax.gov.in 


Works as expected.

Better answer is to get them to fix the problem.

On 2023/08/30 17:08, Bob McDonald wrote:

Turning off validation for that domain fixes the issue.

When using dig to diagnose this issue, one might be tempted to use the 
DNSSEC switch. However, the following command:


dig eportal.incometax.gov.in . +NODNSSEC

will NOT turn off DNSSEC validation.

The DNSSEC switch in dig is used to display the associated DNSSEC 
records (if they exist). It doesn't affect validation. You must make 
the options change indicated by Greg Choules in his previous post to 
disable DNSSEC validation for a specific domain.


Sorry if this is redundant or very rudimentary.

Bob

--

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




-- 
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: Zone stats

[Mark Elkins via bind-users]

Thank you Timothe for this. I tested this on some of my domains and 
found AXFR worked the best


dig @::1 $zone axfr | grep -v '^;' | grep -v '^$zone' | grep 'NS    
' | cut -f1 | cut -f1 -d' ' | sed 's/\.$//' |sort -u > axfr.$zone


... does the trick. $zone is the Zone in question. There is a  
after "NS".


Take a Zone, Strip comments, Strip lines beginning with the Zone, Look 
for NS records (exclude NSEC records), take the first argument (strip 
trailing dot) and make the output sorted and unique...


I'll be writing in PHP and already use a similar PHP "NET::DNS" type 
library so shouldn't be difficult.


Yes - this will go into a Database - etc..

On 2023/08/22 02:10, Timothe Litt wrote:


(Sorry for the duplicate/reply without context).  See below.

On 21-Aug-23 11:11, Mark Elkins wrote:


Hi,

I'm writing some software to be able to read information from a Zone 
file. I am a legally authorised Secondary Authoritative Nameserver 
for a number of domains or rather zone files, eg. EDU.ZA (and 
others). Is there an easy way to:-


1) Count how many delegated domains there are (Names with NS records)

2) Extract the above Names - so I can look for changes (Added/Deleted 
names)


3) find out how many unique names have DS records (I can DIG I suppose)

I'd also like to spot broken stuff (named-checkzone ?)

So the zones (such as EDU.ZA) contain the domain name of the entity 
(whois.edu.za) along with the Nameserver records and in this case, a 
DS record. e.g... "whois.edu.za" looks like


whois  NS control.vweb.co.za.
   NS secdns1.posix.co.za.
   NS secdns2.posix.co.za.
   NS secdns3.posix.co.za.
   DS    27300 13 2 
8ED21DB407F6AC3E6EA757AE566953C1BBADD8B652BE4C7C0744B1D7 9DF42894
   DS    17837 13 2 
36FD5B19450B672988AE507FB7D2F948ED1E889546C6E16554C7EAF9 CE9C3FEA


One hindrance is that journal files are present - so it is not just 
the zone file but the zone.jnl file as well.


Some African ccTLDs have everything in one zone e.g. their COM, EDU, 
GOV - etc. In South Africa, these are all separate zones, making life 
somewhat easier.


I'd hate to re-invent software that already exists.

The primary purpose is to pull in data into an (ICANN requested) 
African DNS Observatory.



--

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


Mark,

a) Use named-compilezone to extract the zone with journals applied.

b) my favorite: do an axfr of the zone, which gives the correct data 
with all the pseudo-ops expanded


c) Use a library - I use Perl's Net::DNS - and write code to do the 
axfr & walk the zone - it allows you to access fields in the records.


https://github.com/tlhackque/certtools has a simple utility called 
acme_token_check  that does (c) to remove stray ACME records - it 
shows how to do the transfer and walk the zone.   (And also how to use 
DNS UPDATE to maintain it.)


Enjoy.


Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.

--

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




-- 
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

Zone stats

[Mark Elkins via bind-users]

Hi,

I'm writing some software to be able to read information from a Zone 
file. I am a legally authorised Secondary Authoritative Nameserver for a 
number of domains or rather zone files, eg. EDU.ZA (and others). Is 
there an easy way to:-


1) Count how many delegated domains there are (Names with NS records)

2) Extract the above Names - so I can look for changes (Added/Deleted names)

3) find out how many unique names have DS records (I can DIG I suppose)

I'd also like to spot broken stuff (named-checkzone ?)

So the zones (such as EDU.ZA) contain the domain name of the entity 
(whois.edu.za) along with the Nameserver records and in this case, a DS 
record. e.g... "whois.edu.za" looks like


whois  NS    control.vweb.co.za.
   NS    secdns1.posix.co.za.
   NS    secdns2.posix.co.za.
   NS    secdns3.posix.co.za.
   DS    27300 13 2 
8ED21DB407F6AC3E6EA757AE566953C1BBADD8B652BE4C7C0744B1D7 9DF42894
   DS    17837 13 2 
36FD5B19450B672988AE507FB7D2F948ED1E889546C6E16554C7EAF9 CE9C3FEA


One hindrance is that journal files are present - so it is not just the 
zone file but the zone.jnl file as well.


Some African ccTLDs have everything in one zone e.g. their COM, EDU, GOV 
- etc. In South Africa, these are all separate zones, making life 
somewhat easier.


I'd hate to re-invent software that already exists.

The primary purpose is to pull in data into an (ICANN requested) African 
DNS Observatory.



--

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



Posix SystemsVCARD for MJ Elkins

-- 
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: TLS Statistics

[Mark Elkins via bind-users]

Seems like an excellent idea.
I've added  an additional "Thumbs Up" to the ISC web page linked below. 
Perhaps others might do the same so this already two year old idea can 
be implemented a bit sooner?


On 2023/08/02 10:00, Richard T.A. Neal wrote:


Hi Florian,

This feature doesn’t yet exist but is tentatively planned for the 
9.19.x timeframe. You can see more about it here:


https://gitlab.isc.org/isc-projects/bind9/-/issues/2748 



Best,

Richard.

*From:*bind-users  *On Behalf Of 
*Ritterhoff, Florian

*Sent:* Wednesday, August 2, 2023 7:43 AM
*To:* bind-users@lists.isc.org
*Subject:* TLS Statistics

Hello everyone,



we have activated DoT and DoH for a few days.We would like to make a 
statement regarding the use.




Unfortunately, we are currently unable to find any explicit statistics 
or explicit log attribute or similar that would allow conclusions 
about the use of TLS.


Can someone possibly help here?



Best regards

Florian Ritteroff

--
Florian Ritterhoff - Zentrale IT
Hochschule München University of Applied Sciences
Lothstraße 34, 80335 München, G2.21a
T +49 89 1265-1745



--

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




-- 
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: Changing DNS servers (name only) for a DNSSEC enabled domain

[Mark Elkins via bind-users]

If the IP addresses of the DNS servers (dns[123].olddomain and 
dns[123].newdomain) are staying the same - then you only need to send an 
update to change your domain from being hosted at olddomain to 
newdomain. Ideally, the newdomain would be created first (pointing to 
the same IP addresses as in olddomain) in the Registry, then after a day 
or two, have the olddomain in the Registry deleted - but it shouldn't 
really matter.


People who are looking for DNSSEC records will still go to the correct 
places - because the IP addresses at those places are not changing.


On 2023/02/13 17:58, Danilo Godec via bind-users wrote:

Hello,


in the near future I will have to change NS records for one of my 
domains, as DNS servers currently use an old domain (not mine), that 
will be phased out. DNS servers will actually remain the same, only 
the domain name will change.


So, basically:

  * mydomain currently uses dns1.olddomain, dns2.olddomain,
dns3.olddomain, ...
  * dns*.olddomain are the same servers as dns*.newdomain
  * mydomain has to change DNS server to dns1.newdomain,
dns2.newdomain, dns3.newdomain, ...



Since DNSSEC is enabled on mydomain, I've been reading some 
instructions about doing this with DNSSEC and they say:


1. Disable DNSSEC at Registrar
2. Wait 24 hours
3. Disable DNSSEC at Name Server (remove DS-records)
4. Switch name servers
5. Wait 24 hours
6. Re-enable DNSSEC


I personally prefer,

Create the Domain on the new nameservers, sign it, send the new DS 
record to the Registry. This probably means loading the DS record via 
the old (existing) Registrar. Wait 24 hours (propagation time) then 
update (swap) the Nameservers at the Registry to the new Nameservers.

Wait a day or two then remove the domain from the old servers.
As long as one of the DS records matches the DNSKEY on either the old or 
new Nameservers - DNSSEC should validate.


The problem is - not many Registrars allow a foreign DS record to be 
loaded in their system for uploading to the Registry. I do allow the 
client to do this. Don't think it has ever happened though.






Is this really necessary in this case, changing only DNS server names? 
I would like to avoid changing DS records at the registrar level as 
they don't provide a 'self-service' interface for managing them, so I 
have to go though their support and that's usually tedious.


If that is necessary, why?


   Thanks, Danilo

PS: If it matters, this is (still) a manually DNSSEC'd domain.


--

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



Posix SystemsVCARD for MJ Elkins

-- 
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-policy - KSK rollover

[Mark Elkins via bind-users]

OK - so I read RFC7344... Automating DNSSEC Delegation Trust Maintenance

There are two interesting paragraphs.

_/5.  CDS/CDNSKEY Publication/_/
//
//   The Child DNS Operator publishes CDS/CDNSKEY RRset(s).  In order to//
//   be valid, the CDS/CDNSKEY RRset(s) MUST be compliant with the rules//
//   in Section 4.1. *When the Parent DS is in sync with the CDS/CDNSKEY*/*/
/**/   RRset(s), the Child DNS Operator MAY delete the CDS/CDNSKEY 
RRset(s);/*/

//   the Child can determine if this is the case by querying for DS//
//   records in the Parent./



_/6.1.1.  CDS/CDNSKEY Polling/_/
//
//   This is the only defined use of CDS/CDNSKEY resource records in this//
//   document.  There are limits to the scalability of polling techniques;//
//   thus, some other mechanism is likely to be specified later that//
//   addresses CDS/CDNSKEY resource record usage in the situation where//
//   polling runs into scaling issues.  Having said that, polling will//
//   work in many important cases such as enterprises, universities, and//
//   smaller TLDs.  In many regulatory environments, the Registry is//
//   prohibited from talking to the Registrant.  In most of these cases,//
//   the Registrant has a business relationship with the Registrar, so the//
//   Registrar can offer this as a service.//
//
//*If the CDS/CDNSKEY RRset(s) do not exist, the Parental Agent MUST*/*/
/**/   take no action.  Specifically, it MUST NOT delete or alter the/**/
/**/   existing DS RRset./*

I'm confused. There is no text describing how a Key Rollover might work. 
The Child can delete the CDS once it believed the Parent has activated 
the appropriate DS. There is no discussion on how a Parent will know to 
remove that DS record... unless it is via asking the Child for all 
existing DNSKEY records of type 257 and then recalculating the DS 
records and working out what is missing. Then we don't need CDS records 
at all - just Poll for DNSKEY records?


I think I really prefer the simplicity of mirroring the CDS's of a Child 
into the DS's on the Parent. Makes handling of Null CDS records easier.


On 2022/11/24 09:50, Matthijs Mekking wrote:

Hi,

I think this should work with some caveats.


This is true for BIND 9, as it will publish the CDS for as long as the 
DS should be in the parent. But it doesn't have to be the case. The 
RFC (7344) says:


   When the Parent DS is in sync with the CDS/CDNSKEY
   RRset(s), the Child DNS Operator MAY delete the CDS/CDNSKEY RRset(s);
   the Child can determine if this is the case by querying for DS
   records in the Parent.
--


Mark James ELKINS  -  Posix Systems - (South) Africa
m...@posix.co.za   Tel: +27.826010496 



-- 
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-policy - KSK rollover

[Mark Elkins via bind-users]

:-) Will let you know in a year!


ps - please, please keep the CDS's in the child zone - reflecting the 
current KSK's!  (etc)


On 2022/11/24 09:50, Matthijs Mekking wrote:

Hi,

I think this should work with some caveats.

First, If you migrate to dnssec-policy (that is the zone is already 
signed), make sure that the key properties match the current DNSKEYs.


Second is about your script:

> If the child looses a CDS record - my external script will remove the
> corresponding DS record from the parent.

This is true for BIND 9, as it will publish the CDS for as long as the 
DS should be in the parent. But it doesn't have to be the case. The 
RFC (7344) says:


   When the Parent DS is in sync with the CDS/CDNSKEY
   RRset(s), the Child DNS Operator MAY delete the CDS/CDNSKEY RRset(s);
   the Child can determine if this is the case by querying for DS
   records in the Parent.

Personally I like to keep the CDS in the child zone, so you can see if 
the parent is in sync, that is why I implemented it in BIND 9 to keep 
the CDS.


Best regards,

Matthijs


On 23-11-2022 18:24, Mark Elkins via bind-users wrote:

Hi people,

I have read https://kb.isc.org/docs/dnssec-key-and-signing-policy

I have put the following policy in my named.conf file:-

dnssec-policy "ecdsa256-policy" {
 signatures-refresh 5d;
 signatures-validity 14d;
 signatures-validity-dnskey 14d;
 dnskey-ttl 3600;
 publish-safety 1h;
 retire-safety 1h;
 purge-keys 10d;

 keys {
 ksk lifetime 370d algorithm ecdsa256;   // < this part 
in particular!

 zsk lifetime 34d algorithm ecdsa256;
 };

 zone-propagation-delay 300s;
 max-zone-ttl 86400s;
 parent-propagation-delay 1h;
 parent-ds-ttl 3600;
};

I also have some external code that goes trawling for CDS records and 
puts into a parent whatever it finds in the child - that in this case 
is signed with the above policy stanza.


If the child creates a new CDS - my external scripts will find it and 
pop it into the parent as a DS record.
If the child looses a CDS record - my external script will remove the 
corresponding DS record from the parent.
Basically - whatever is in the child as a CDS will be in the parent 
as a DS.

A null CDS removes all DS records - but that's not my question.

Is there anything else I need to do? Any additional rndc's ??

--

Mark James ELKINS  -  Posix Systems - (South) Africa
m...@posix.co.za   Tel: +27.826010496 



--

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


Posix SystemsVCARD for MJ Elkins

-- 
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

dnssec-policy - KSK rollover

[Mark Elkins via bind-users]

Hi people,

I have read https://kb.isc.org/docs/dnssec-key-and-signing-policy

I have put the following policy in my named.conf file:-

dnssec-policy "ecdsa256-policy" {
    signatures-refresh 5d;
    signatures-validity 14d;
    signatures-validity-dnskey 14d;
    dnskey-ttl 3600;
    publish-safety 1h;
    retire-safety 1h;
    purge-keys 10d;

    keys {
    ksk lifetime 370d algorithm ecdsa256;   // < this part in 
particular!

    zsk lifetime 34d algorithm ecdsa256;
    };

    zone-propagation-delay 300s;
    max-zone-ttl 86400s;
    parent-propagation-delay 1h;
    parent-ds-ttl 3600;
};

I also have some external code that goes trawling for CDS records and 
puts into a parent whatever it finds in the child - that in this case is 
signed with the above policy stanza.


If the child creates a new CDS - my external scripts will find it and 
pop it into the parent as a DS record.
If the child looses a CDS record - my external script will remove the 
corresponding DS record from the parent.

Basically - whatever is in the child as a CDS will be in the parent as a DS.
A null CDS removes all DS records - but that's not my question.

Is there anything else I need to do? Any additional rndc's ??

--

Mark James ELKINS  -  Posix Systems - (South) Africa
m...@posix.co.za   Tel: +27.826010496 

-- 
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: 'inline-signing' might go away and be replaced by dnssec-policy ?

[Mark Elkins via bind-users]

Yes - I think "automated" in-line signing would be useful in 
"dnssec-policy" run zones.


We didn't need this some versions of BIND ago ( I had to add it recently 
on a zone that I've been testing with - untouched from a year or so ago)


We don't generally edit the signed zone - just the unsigned zone (at 
least that is how this zone is modified!)


On 2022/10/26 10:19, Matthijs Mekking wrote:
Thanks for this. It probably should be removed from the docs at this 
point.


When introducing dnssec-policy, my goal was to reduce the dozens of 
DNSSEC related configuration options that are scattered throughout 
named.conf and contain them in one stanza. But some options are more 
difficult to be replaced than others.


On 24-10-2022 18:16, PGNet Dev wrote:

i've read this comment


'inline-signing' might go away and be replaced by dnssec-policy


now a few times, in posts and in docs

currently, WITH 'dnssec-policy' signing enabled & in-use, i've

 zone "example.com" IN {
 type master; file "namedb/primary/example.com.zone";
 dnssec-policy "test";
 inline-signing yes;
 ...

the 'inline-signing yes;' is needed IN ADDITION to 'dnssec-policy' in 
order to _not_ overwrite original zone files/data on signing.  e.g., 
with the config above


 cd namedb/primary/
 ls -1 *example*
 example.com.zone  < THIS is the original, 
unsigned zone data

 example.com.zone.jbk
 example.com.zone.jnl
 example.com.zone.signed   < THIS is the 
signing-generated zone data, which gets propagated

 example.com.zone.signed.jnl

without it, the original "example.com.zone" is overwritten with 
signed data.


is there already config in, or planned for, 'dnssec-policy' that 
preserves that separate-file functionality, preserving the original?


There are two ways of DNSSEC maintenance in BIND. One is the 
inline-signing approach, that preserves the original zone file. The 
other is to apply the changes directly to the zone (and zone file) and 
requires the zone to allow dynamic updates.


Since the latest release dnssec-policy requires either inline-signing 
to be set to yes, or allow dynamic updates.


I am thinking of adding inline-signing to dnssec-policy, do you think 
that would that be useful?


Best regards,

Matthijs

--

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



Posix SystemsVCARD for MJ Elkins



OpenPGP_0xB6FA15470B82C101.asc
Description: application/pgp-keys


OpenPGP_signature
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 adoption

[Mark Elkins via bind-users]

I generally agree with you - comments in line

On 8/3/22 5:56 PM, Peter wrote:

I see a two-fold issue with DNSSEC:

1. The wide-spread tutorials seem to explain a key rollover as an
exceptional activity, a *change* that is infrequently done. And
changes, specifically the infrequent ones, bring along the
possibility of failure, mostly due to human error.


Domains with Cloudflare seem to get Signed once -(KSK/DS - etc) and 
that's it!




I don't see reason why this is so. DNSSEC can be fully
automated (mine is), and then it can be done frequently, and the
human factor is out of the loop. It is then no longer a change,
but a regular operation that happens every 
without anybody even need noticing it.
(Let'sEncrypt did the same for certificates, and that also works
well.)


Both my DNSSEC and Let's Encrypt are totally automated as well. I 
usually run two KSK's overlapping by 6 months - so plenty of "rollover" 
time. Other domains, there is only a second KSK for a week or so.




2. TCP seems still to be considered a second-class-citizen in the
DNS world. (If I got the details right, TCP is only "optional",


Agh! No. NOT OPTIONAL. One might see it as a fall-back for when UDP 
fails (Truncated) but it is completely necessary!




and must only be tried as a second choice after receiving TC.)
So people may be induced to try and squeeze replies into whatever
512 or 1280 or 1500 bytes. Which means, they probably cannot use
more than one key, and so take possible redundancy out of the game.

I do not currently know about how or where this issue could be
tackled appropriately; I for my part have decided to happily ignore
it, and am using *four* KSK, thereby supporting RFC 5011 and RFC
7344, all with one simple script - and anyway now I have the longest;
here you can see it in action: https://dnsviz.net/d/daemon.contact/dnssec/
Let's see where this leads into problems; for now it appears not to.

-- PMc



Fair enough. And Elliptical Curve (Algo 13 ???) - so much shorter.

ps - Algorithm rollovers can be fun!!!

--

Mark James ELKINS  -  Posix Systems - (South) Africa
m...@posix.co.za   Tel: +27.826010496 





OpenPGP_0xB6FA15470B82C101.asc
Description: application/pgp-keys


OpenPGP_signature
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 signing of an internal zone gains nothing (unless??)

[Mark Elkins via bind-users]

Hmmm - might be saying the wrong thing but...

.SE was DNSSEC Signed waaay before the root, so if living in Sweden, one 
would prep your DNSSEC aware resolver with the DS Key of the .SE Zone. 
DNSSEC then worked for .SE domains. Perhaps do the same?


I do get confused further down in this email when one says you'll get 
back an "AA" flag in the answer. That will only happen if you ask the 
Authoritative Server for the domain you are looking in. That shouldn't 
be a Recursive server. It is terribly bad practice to have a BIND server 
running in both Authoritative and Recursive mode at the same time - 
should be two separate instances of BIND.


On 8/1/22 7:51 PM, John W. Blue via bind-users wrote:

Also do not disagree.

However, the intent of the thread is to talk about the lack of an AD flag from 
a non-public internal authoritative server.  Based upon what I am seeing only 
the AA flag is set.

John

-Original Message-
From: John Franklin [mailto:frank...@sentaidigital.com]
Sent: Monday, August 1, 2022 12:45 PM
To: John W. Blue
Cc: bind-users@lists.isc.org
Subject: Re: DNSSEC signing of an internal zone gains nothing (unless??)

On Aug 1, 2022, at 12:15, John W. Blue via bind-users 
 wrote:

As some enterprise networks begin to engineer towards the concepts of 
ZeroTrust, one item caught me unaware:  PM’s asking for the DNSSEC signing of 
an internal zone.
  
Granted, it has long been considered unwise by DNS pro’s with a commonly stated reason that it increasing the size of the zone yadda, yadda, yadda.

  [snip]
Thoughts?

DNSSEC enables use of certain security RRs, such as SSHA and TLSA, which can be 
used as part of a zero trust solution in DevOps pipelines.  It’s also good 
practice managing DNSSEC before deploying it in public production sites.

jf

--

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






OpenPGP_0xB6FA15470B82C101.asc
Description: application/pgp-keys


OpenPGP_signature
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