Am Freitag, 12. Juni 2020, 20:52:41 schrieben Sie:
Show quoted text> <URL:
https://rt.cpan.org/Ticket/Display.html?id=132772 >
>
> On Fri Jun 12 13:21:11 2020, wolfgang.walter@stwm.de wrote:
> > My problem is that this is a regression, that is: 1.23 and earlier
> > behaved differently and wie rely on it.
>
> No! You chose to exploit a laxity in the code when the documentation
> explicitly tells you the expected filename conventions.
> > In 1.23 and earlier a .key file could have an arbitrary name but was
> > always parsed as as dnssec-keyfile. So there was no need to preserve
> > these names. Actually there is no way for me to simple rename this
> > files because our software which uses Net::DNS relies that it can
> > choose the name of the file. I could easily use another ending instead
> > of .key, but I can't go to the K....key scheme.
>
> Filename of a BIND public key is and never was a free choice.
>
dnssec-keygen does give you a certain name, thats true. But actually we do not
use dnssec-keygen.
Show quoted text> An obvious solution is to generate your keys using tsig-keygen which allows
> a free choice of filename and can be read unchanged into your BIND config
> using $INCLUDE.
This could be done but will not work with 1.23 an earlier, or I'm missing
something?.
What wie really do is indeed use tsig-keygen, parse it and then create a .key
file because earlier versions of Net::DNS did not parse tsig-keygen generated
files.
String these keys as a key file (and not as a config-snippet for bind) has
other advantaged, too. You can use Net::DNS::ZoneFile to parse them, use
database storage schemes for RRs etc.
A KEY RR is well defined and can basically be parsed by most DNS libs, whereas
a bind conf snippet usually is
Show quoted text>
> The alternative is to use a symbolic link:
> ln -s /path/to/secret/keys/Khmac-sha1.example.+161+39562.key alias.key
>
This would not solve our problem. See below.
Show quoted text> > Another solution to keep compabiltiy coudl be to check if $secret is
> > undef and then try to parse as dnssec-keyfile:
> >
> > require File::Spec; # ( keyfile, options )
> > require Net::DNS::ZoneFile;
> > my $keyfile = new Net::DNS::ZoneFile($karg);
> > ...
> >
> >8
>
> my ( $algorithm, $secret, $junk );
> while ( $keyfile->_getline ) { ### reads entire file
> ### $key = $1 if /^key "([^"]+)"/; # BIND tsig key $secret = $1
> if /secret "([^"]+)";/;
> $algorithm = $1 if /algorithm ([^;]+);/;
>
> ( $junk, $secret ) = split if /^Key:/; #
> BIND dnssec private key ( $junk, $algorithm ) = split if /^Algorithm:/; }
>
> if ( !defined($secret) || !defined($algorithm) ) {
> my $keyrr = $keyfile->read; ### fails here ###
>
>
> This code does not work because the while loop has already exhausted the
> file before attempting to read the KEY RR.
ok, did not test it. If it is certain to be a file one could use seek().
Show quoted text> > this would probably allow upgrading from 1.23 and earlier to 1.24 and
> > later without breaking code.
>
> Upgrade from 1.23 to 1.24 already breaks code and no amount of rewriting can
> change that retrospectively.
>
> However, this code does need to be made more robust.
>
> Another useful improvement might be to follow symbolic links:
>
> ln -s /path/to/secret/keys/Khmac-sha1.example.+161+39562.private
> private.key ln -s /path/to/secret/keys/Khmac-sha1.example.+161+39562.key
> public.key
We have a lot of key files in one directory. Our names consists only of the
name of the zone this key should be used for updating that zone (and not the
name of the key itself which also contains the nameserver or algo or anything
else), so that we can deduct the name of the file directly from the domain we
want do update.
I probably just change our code to not call sign_tsig() with a filename but
with
Net::DNS::ZoneFile->new()->read()
instead.
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
