Re: signing for a hidden primary

2023-01-22 Thread Eric K Germann via bind-users



I use an unsigned hidden master I maintain from inside my local network. 
 This feeds a secondary server where the signing is done and it acts as 
a master to other secondaries.  Works well.  Started as an experiment 
and works well enough I've left it alone.


  Hidden master >> DNSSEC signing server (slave to hidden, master to 
secondariers) >> secondaries


Here's a config block

zone example.com {
type slave;
masters { a.b.c.d key master-dns01; };
file "slave/example.com.db";
key-directory   "keys/example.com";
dnssec-policy   domain-policy;
inline-signing  yes;
zone-statistics yes;
};

If you're interested in  more specifics, I'm happy to share.  Ping me 
off-list


Eric

On 2023-01-21 19:56, Randy Bush wrote:


hi mark

hidden primary can not sign.  can the public primary which fetches
from it, and happens to be primary for the parent zone, do bitw
signing?
In-line signing is the concept you are looking for and yes named
supports it.


i know bind9 does bitw.  happy to learn it is called inline-signing.

sorry not to have been clear.  i want to sign a zone where the server is
secondary.  i.e. may i use

  zone "foo.bar" {
type slave;
file "secondary/bar.foo";  // yes, i like dir list to alpha sort
...
auto-dnssec maintain;
inline-signing yes;
}

looking at example 2 in https://kb.isc.org/docs/aa-00626, i think that
this will work, i.e. there will be a `secondary/bar.foo.signed` from
which i can extract the DS needed by the parent zone, the server will
send notifies etc.

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: "not exact" error message

2023-01-22 Thread Mark Andrews


> On 22 Jan 2023, at 09:54, Havard Eidnes  wrote:
> 
>> The consistency checks are not new. The message indicates that
>> the IXFR contained a delete request for a record that doesn't
>> exist or an add for a record that exists. Named recovers be
>> performing an AXFR of the zone.
> 
> Interesting.
> 
> BIND 9.16.36 does not produce this log message, so it was easy to
> be misled to conclude that this was a new consistency check.
> Does 9.16.36 and 9.18.10 behave differently in terms of their
> usage of IXFR?
> 
> The log message BIND 9.18.10 produces does not mention IXFR or
> that it's going to fallback to AXFR.  I mis-interpreted it as a
> fatal error message, and downgraded to BIND 9.16.36 without
> verifying whether 9.18.10 actually worked as intended anyway (it
> does, I just re-instaled 9.18.10 and re-signed a zone and
> verified that it makes it through).

The log message can only be produced when an IXFR stream is being
processed.  The consistency checks have been there as long as IXFR
has existed.  There are too many ways that zone content can be
changed by administrators incorrectly.  Then there are other behaviours
that lead to inconsistencies.  Transferring from multiple Microsoft
Windows Active Directory servers can produce this, the LDAP synchronisation
doesn’t ensure that a given serial number matches the same content on each
server.  Transferring from multiple servers each doing their own
inline-signing can produce this (RRSIGs will differ between servers
as the RRsets are changed at different times and zone serial numbers
may also differ).

There are a whole heap of reasons for IXFR to fail, this being one
of them, and named will fall back to AXFR on any of them.

> Regards,
> 
> - Håvard

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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