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
