Hello everyone,
The FRED team is proud to announce new public release 2026.1. New
version contains two major changes - migration to Debian 12 and database
upgrade to PostgreSQL 17. We've also completed the dockerization of the
Messenger, Secretary, and Fileman and plan on adding other services.
Visit the Get FRED page <https://fred.nic.cz/en/get-fred/>, with the
latest versions of packages in the Install binaries section.
In addition to the public release, a new version of FRED Demo image is
available, which has pre-installed newest version of the registry and,
in addition, the previously introduced new version of the DNSSEC
automation tool AKM
<https://fred.nic.cz/documentation/html/Concepts/AKM.html>.
The demo image is available to download here
<https://fred.nic.cz/documentation/html/AdminManual/Installation/FredDemo.ht…>
------------------------------------------------------------------------
Development highlights
*Messenger, secretary and fileman dockerization*
We are continuing with our strategy of migrating everything to Docker.
As part of this effort we recently successfully dockerized secretary,
messenger and fileman marking a key milestone toward more consistent and
maintainable deployments.
Building on this progress, the plan is to continue dockerizing
additional packages to improve portability, scalability, and operational
efficiency across environments.
*Migration to Debian 12*
Debian’s more conservative release cycle and focus on stability make it
better suited for server deployments. Technically, this is a
straightforward transition with minimal changes to configurations or
service management, as the core components remain largely the same and
it will result in the unification of the operational environment across
infrastructure.
Future public releases will be based on Debian as well, so registries
operating FRED are advised to start preparing migration plan as well in
order to adapt these changes efficiently.
*Upgrade to PostgreSQL17*
The latest FRED release now requires PostgreSQL 17, which offers
improved performance, better query handling, and more robust database
management.
*EPPIC 3.1.0*
The CZ.NIC Association released a new version of EPPIC on July 2, 2025.
Compared to the previous version, new commands have been added, the
behavior of existing commands has been improved (in a
backward-compatible way), and text errors have been fixed.
Session management in EPPIC 3.1.0 has been significantly improved to
better align with the EPP protocol. A new epp-login command now allows
users to specify full login parameters (like newPW, lang, extURI, and
clTRID), offering more control than the previous simplified login
approach. Support for the fred-client tool officially ended in April
last year. It had served as the standard interface for communicating
with the Czech domain registry FRED. A new client |eppic| is built on
the modern Python library |fred-epplib|, which is significantly easier
to integrate into existing systems and workflows compared to its
predecessor.
More in our blog post
<https://en.blog.nic.cz/2025/07/17/eppic-3-1-0-is-released/>
------------------------------------------------------------------------
Future plans
*GlobalBlock integration*
Along with version 2.49.0, FRED added support for the GlobalBlock, a
service from Brand Safety Alliance, allowing domain name registration
blocking across multiple TLDs. Registries using FRED can now automate
these blocks using this BSAPP extension. The extension is currently
fully functional and available to members with paid support, and we plan
to add it into the future public release.
In case of any questions, or inputs, please let us know!
Kind regards
--
------------------------------
Jitka Sochurkova
technicky koordinator / technical coordinator
CZ.NIC, z. s. p. o.
Milesovska 5, 130 00 Praha 3
------------------------------
Tel.: +420 222 745 111
E-mail:jitka.sochurkova@nic.cz
www.nic.czwww.mojeID.cz
Hello everyone,
a new version of a Java EPP client for FRED has been released.
You can find more details here:
- Source codes: https://github.com/novotnyradek/fred-client
- Release notes:
https://github.com/novotnyradek/fred-client/releases/tag/fred-client-2.51
Thanks to Mr. Radek Novotny for contribution!
Best regards
--
------------------------------
Jitka Sochurkova
technicky koordinator / technical coordinator
CZ.NIC, z. s. p. o.
Milesovska 5, 130 00 Praha 3
------------------------------
Tel.: +420 222 745 111
E-mail: jitka.sochurkova(a)nic.cz
www.nic.czwww.mojeID.cz
I’m discovering *FRED*, and I’d like to deploy it with *Let’s Encrypt*.
I found a demo installation project here:
https://gitlab.nic.cz/fred/demo-install.git, but it’s not working properly.
Hello,
after i run this command ( apt --assume-yes install fred) i have stack in this point any suggestion.
==========
The following packages have unmet dependencies:
fred : Depends: fred-rdap but it is not going to be installed or
fred-rdap-py3
Depends: fred-rdap-apache but it is not going to be installed
Depends: fred-webwhois but it is not going to be installed or
fred-webwhois-py3 but it is not going to be installed
Depends: fred-webwhois-apache but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
=============
Hello, I am trying to execute the fred-client command, and it gives me this error on the fred master server
CORBA exception: IDL:omg.org/CORBA/COMM_FAILURE:1.0
Could not get greeting data from fred_rifd
Hello
UltraDNS is working on implementations of the multi-signer DNSSEC (RFC 8901) specification.
It has been our desire to be able to use CDNSKEY records as an indicator to other signers that a ZSK roll is in process and the other signer should adjust their DNSKEY rrSet to reflect the new ZSK created by the UltraDNS signing processes.
Our interpretations of RFCs 7344 and 8078 do not prohibit the use of CDNSKEY for this purpose and we had developed the service to publish CDNSKEY records with a DNSKEY flags value of 256 to indicate a change in the ZSK for the zone.
Unfortunately, this approach appears to be causing issues for TLDs using FRED as the cdnskey scanner process does not consider the flags attribute of the rdata and treats every CDNSKEY record as a KSK key event.
We would like know if FRED could be updated to consider the flags of CDNSKEY records and only act on those records where the SEP indicator is set - i.e. flags = 257?
Acknowledging that the RFCs are silent on the use of flags=256 in a CDNSKEY record, it seems to us to be a reasonable use of the CDNSKEY record for signaling and informing other signers implementing RFC 8901.
Thoughts?
Steve deJong
UltraDNS
Hello,
I want to test fred, so I ran the install script. It fails
because omniorb and apache2 are not installed.
Then in the a2ensite commands, I'm not sure where these sites are coming
from.
Can I please get an account in gitlab.nic.cz? I can report the issues
there and fix the things that are clearly missing.
Hello.
One of our clients, who wish to connect to our FRED server is having problems for managing his connection. Also, I can reproduce their situation.
Most of our registrars use either the fred-client Python-based script, or the Python API. And they can manage all their operations without problems.
In their case, they connect in a completely different way. They use a Java-based client, and also they generated THEIR csr file. It was sent to us, along their key, in a zip file). The csr file was appopiately signed, put in the proper place at /usr/share/fred-client/ssl, so the certificate and key are present.
And here is what is odd. They can properly login (and us too using fred-client testing that). But if you try to manage any objects at the creation, a Command failed is issued. This happens with their Java-based client and also with fred-client, testing their configuration, certificate and all.
And the odd thing is that any other client manages every thing appropiately.
Here is the fred-client.conf relevant part:
### Connection settings
[connect]
# Path to the directory with certificates
dir = /usr/share/fred-client/ssl
# Server name
host = 127.0.0.1
# Server port (default: 700)
port = 700
# File path of the certificate
ssl_cert = %(dir)s/<our client>.crt
# File path of the private key
ssl_key = %(dir)s/<their key>.pem
# Login username and password
username = <their username>
password = <their password>
As I said the login is perfect but not the object management
Any hints?
The certificate was signed using their key, but our CA.
Best regards
Mario Guerra - NIC-CR
Happy new year, hope you are well.
Due to the current and developing tough economic situation in Malawi,
we at .mw ccTLD are considering ways to provide better conditions for
registrars that operate or are based in Malawi.
One possible way to do this is to charge them for EPP operations at a different
rate as they provide and manage domains locally to those in Malawi.
We are aware that FRED does not provide a differential pricing scheme,
however, FRED does provide VAT charges that can be different from one
registrar to another, some registrars can be configured to be charged
VAT but others can be on no-vat.
When we looked at this we also noticed that there is a parameter call
"koef" in the database. This seems to affect how credit is allocated
to a registrar but it does not appear to be linear.
So, we would like to find out the following:
1. If we wanted a group of registrars to be charged say 10% less for an EPP transaction, how
can we use the VAT setting in FRED to achieve that ?
2. How is koef used in the FRED system - is there a formula ?
3. Can we use koef in a positive way to benefit some registrar only ?
4. What happens if we set a negative value for koef ?
5. Can we set a negative value for VAT ?
Please provide any additional details as we are also exploring SQL
ways to achieve differential pricing or crediting of groups of
registrars.
Regards,
Paulos
=====================================
Dr Paulos B Nyirenda
NIC.MW & .mw ccTLD: http://www.nic.mw
SDNP: http://www.sdnp.org.mw
Tel: +265-(0)-882 089 166
Cell: +265-(0)-888-824787
WhatsApp: +265-(0)-887386433
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
------- End of forwarded message -------
Folks:
I want to know who gets commands like sendauthinfo_domain and the rest of those commands.
And also, what is needed for those commands to work appropiately (the messenger configuration, for example?).
Mario Guerra - NIC-CR
