For the most part, our tests with FRED 2026.1 has been successful as follows:
*
We use a copy of a development DB and modify it so the log tables in the DB FRED are eliminated
*
We configured the fred-app services properly
*
We have successfuly generated DNS tables (and signed them, BTW)
*
FERDA, whois, web whois and RDAP work as expected
*
Messenger, secretary and fileman are properly configured.
There is one curious problem with eppic (and it happens with our homemade EPP client, too).
eppic works mostly well, but there is one command that does not:
root@fred26-app:~# eppic
2026-09-03 09:59:15,956 WARNING transport:connect:105 Verification of the peer certificate is disabled.
NIC-REG1(a)192.168.81.203 > info-contact --id=CN_1
2026-09-03 09:59:18,244 WARNING epp:send_request:163 Communication with the server failed. Retrying...
2026-09-03 09:59:18,245 WARNING epp:logout:71 Logout failed.
2026-09-03 09:59:18,287 WARNING transport:connect:105 Verification of the peer certificate is disabled.
2026-09-03 09:59:18,530 ERROR epp:send_request:166 Communication with the server failed. Logging out and closing connection...
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/eppic/epp.py", line 159, in send_request
return self._send_request(request, cltrid)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/eppic/epp.py", line 175, in _send_request
response = self._client.send(request, tr_id=cltrid)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/epplib/client.py", line 109, in send
response = cast(ResponseT, self._receive(request.response_class))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/epplib/client.py", line 121, in _receive
response_raw = self.transport.receive()
^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/epplib/transport.py", line 158, in receive
raise TransportError('Empty response recieved.')
epplib.exceptions.TransportError: Empty response recieved.
2026-09-03 09:59:18,531 WARNING epp:logout:71 Logout failed.
2026-09-03 09:59:18,531 ERROR app:run:184 Communication with the server failed.
If only happens with this particular operation. The other info operations and the rest of commands, including creation of a contact, work perfect.
And it seems that it happens on the backend, because the corresponding XML generated from our page, which is a homemade XML, equivalent to info-contact, fails too.
As I said, info-nsset, etc. work well, too.
What do you think?
BTW, we have copied our dev DB and modified it (exporting or eliminating the log tables, now in the fredlog DB). And that's it.
Best regards.
Mario Guerra - NIC-CR
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.52
Many 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
Greetings everyone,
we've spent some time trying to improve the docs for people just getting
to know the software. I'm sending a pre-release build of the
documentation with added overview and quickstart guide sections. The
admin guide also has added troubleshooting section with some commonly
encountered errors and fixes.
Before we move on to language review etc, any feedback and comments
regarding the contents would be much appreciated.
Local version can be built using sphinx and viewed in your browser.
|sphinx-build -b html . build/html/ ; firefox build/html/index.html|
Thank you and kind regards,
--
Jan Dobiášovský
SQA
CZ.NIC, z.s.p.o.
Milešovská 1136/5
130 00 Praha 3
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.
