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
Server disposition
A fred-db server, a fred-admin server, a genzone+signer server and a whois/LDAP server.
The last one is fully public.
Situation
In a test environment using this server architecture all the services work perfectly. Also, I tested the last version of the test installation and all services work in one test server.
What we want
* Installing FERDA in the fred-admin sever
* Installing the web whois service and the RDAP service on the whois server.
This means that a Docker server would be installed in both fred-admin and fred-whois. One alternative if possible is using a preexisting Docker server (we have one).
Also, apparently both three Docker servers need the messenger and secretary services. But there is something I'm omitting.
A tutorial for installing these three services in an environment similar to the described one.
Best regards
Mario Guerra - NIC-CR
Hey there, suddenly today, zone files are not getting updated with the new
names in it for example zone db.ind.mom is not getting updated with the new
names in it, even after booking a successful domain. I am able to see the
domain from admin panel that it is booked, but cant see via db zone file.
Please help
I have done this, according to http://www.tc.umn.edu/~brams006/selfsign.html, part 1B (generating your own CA):
a) create a CA authority (ca.key and ca.crt)
b) make a certificate request (server.csr)
c) sign the certificate request (server.crt and server.key) with the new CA authority
d) change the server key so it does not ask for a passphrase.
Afterwards, the server.crt and server.key files are included in /usr/share/fred-client/ssl directory, and the fred-client configuration file is modified like this:
ssl_cert = %(dir)s/server.crt
ssl_key = %(dir)s/server.key
Now, if I try to run fred-client this is the result:
ERROR: socket.sslerror: [Errno 1] _ssl.c:480: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca (200.107.82.18:700)
Certificate not signed by verified certificate authority
What should I do for fred-client to identify these certificates as valid?.
Thanks in advance.
Note: the new fred-client is perfectly compatible with FRED 2.2.
--
Mario Guerra <mguerra(a)nic.cr>
Hey there i needed help for setting up whois server
I have successfully installed fred, and created zones for .techy.pw domain
Now i want a whois url for this tld, and a socket url i guess for other
scripts to check availability of the 3rd level domains, kindly help with
this
Hey there, all of a sudden i am getting this issue on Fred, as its not
getting up , i am not aware of the error, anyone up for help? Will pay for
your time.
Hey there, i am trying to connect Fred with an epp client of metaregistrar,
Getting error of Peer certificate CN= ‘localhost’ did not match expected
CN=‘registry.sparrowhost.in’
I had changed my server hostname, is that error related to this??
Kindly help me out
Hey there i wanted to know if anyway to integrate FRED with whmcs to show
domain availability on search results? I have installed fred and able to do
epp commands via terminal.
Hey there i tried adding a zone techy.pw
For selling its 3rd level domains
I have updated the nameservers of this domain to our server ip,
root1.sparrowhost.netroot2.sparrowhost.net
I have added a test registrar via 1.7.3 of installation part, after then i
created a domain web.techy.pw
But its not resolving to the nameservers i updated on it.
