Can you give the content of zone table i.e select * from zone mguerra wrote: > When trying to implement FRED for production we got these strange cases. > > We are dividing our zones in a first-level one, .cr, and seven > second-level > ones, co.cr, ac.cr, fi.cr,, go.cr, ed.cr, or.cr, go.cr. > > For them, we generated a zone file, in total eight. But the cases below > behave prettry strangely. Our zone file for .cr is db.cr, for co.cr, > db.co.cr, and so on. BUT aasa.cr is NOT generated under db.cr but under > db.sa.cr!. bcrsafi.cr, the same, under db.fi.cr. > > This is strange. Perhaaps we misconfigured something?. > > > > -------- Original Message -------- > Subject: caso > Date: Sun, 5 Sep 2010 19:30:21 -0600 > From: Carlos watson &lt;cwatson(a)nic.cr&gt; > To: Mario Guerra &lt;guerramarioalberto(a)gmail.com&gt;om>, Mario Guerra > &lt;mguerra(a)nic.cr&gt;cr>, Jessica Calvo &lt;jcalvo(a)nic.cr&gt; > > tenemos las siguientes categorías > > sa.cr > fi.cr > co.cr > sa.cr > go.cr > ed.cr > > > casos > aasa.cr > bcrsafi.cr > faco.cr > biomasa.cr > mercadopago.cr > compeed.cr > > ------------------------------------------------------------------------ > > tenemos las siguientes categorías > > sa.cr > fi.cr > co.cr > sa.cr > go.cr > ed.cr > > > casos > aasa.cr > <https://www.nic.cr/niccr_privado/#> > bcrsafi.cr <https://www.nic.cr/niccr_privado/#> > faco.cr <https://www.nic.cr/niccr_privado/#> > biomasa.cr <https://www.nic.cr/niccr_privado/#> > mercadopago.cr <https://www.nic.cr/niccr_privado/#> > compeed.cr <https://www.nic.cr/niccr_privado/#> > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > fred-users mailing list > fred-users(a)lists.nic.cz > https://lists.nic.cz/mailman/listinfo/fred-users >

I'm adding some more information so it can be useful for solving this curious case. Here is a fragment of the co.cr zone file> isiva.co.cr. IN NS xxxxxxxxx isladelcoco.cr. IN NS xxxxxxxxx isladelcoco.cr. IN NS xxxxxxxxx ism.co.cr. IN NS xxxxxxxxx Notice the "isladelcoco.cr" lines. These were supposed to be in the "cr" zone file, but it resides in the "co.cr" file. As a result, these particular domains wouldn't be resolved adequately. This happens with all our second-level zones, for examples "somethingsa.cr" would reside in the "sa.cr" file, which is incorrect. And so on. I did more tests yesterday. With an initial state database I used fred-admin in the way I describe below: fred-admin --registrar_add --handle=NIC-REG1 --country=CR --no_vat fred-admin --zone_add --zone_fqdn=co.cr --ex_period_min=1\ --ex_period_max=241 --hostmaster=domreg(a)nic.cr --ns_fqdn=ns.cr\ --refresh=1800 fred-admin --zone_add --zone_fqdn=cr --ex_period_min=1 --ex_period_max=241\ --hostmaster=domreg(a)nic.cr --ns_fqdn=ns.cr --refresh=1800 fred-admin --zone_ns_add --zone_fqdn=cr --ns_fqdn=ns.cr --addr=163.178.8.2 (several other fred-admin lines for assigning the domains to the registrar) Then these fred-client instructions were typed for creating some test domains: NIC-REG1(a)127.0.0.1&gt; create_contact MGUERRA_AT_NIC.CR 'Mario Guerra' mguerra(a)nic.cr 'ANC' 'San Jose' 2060 CR NIC-REG1(a)127.0.0.1&gt; create_nsset POCO_CR ((ns1.poco.cr (201.198.6.186)),(secundario.nic.cr ())) MGUERRA_AT_NIC.CR NIC-REG1(a)127.0.0.1&gt; create_domain poco.co.cr MGUERRA_AT_NIC.CR NULL POCO_CR NULL (1 y) NIC-REG1(a)127.0.0.1&gt; create_domain poco.cr MGUERRA_AT_NIC.CR NULL POCO_CR NULL (1 y) The contents for the co.cr zone: TTL 18000 ;default TTL for all records in zone co.cr. IN SOA ns.cr. domreg.nic.cr. (1283811305 1800 3600 1209600 7200) IN NS ns.cr. ; ;--- domain records --- ; poco.cr. IN NS ns1.poco.cr. ns1.poco.cr. IN A 201.198.6.186 poco.cr. IN NS secundario.nic.cr. poco.co.cr. IN NS ns1.poco.cr. poco.co.cr. IN NS secundario.nic.cr. The contents for the testbed cr zone: $TTL 18000 ;default TTL for all records in zone cr. IN SOA ns.cr. domreg.nic.cr. (1283811305 1800 3600 1209600 7200) IN NS ns.cr. ns.cr. IN A 163.178.8.2 ; ;--- domain records --- ; I also reversed the way how I insert the co.cr and cr zones (firstly the cr, then the co.cr zone). Same results. Best regards. _______________________________________________ fred-users mailing list fred-users(a)lists.nic.cz https://lists.nic.cz/mailman/listinfo/fred-users

It works!. Two details, though: 1. The name of subzone files would be now db..co.cr.

2. Because of the way FRED works (it associates a domain with a zone when you register the domain), you can't simply change the "fqdn" filed in the "zone" table for domains already inserted. You have to delete and create again the domain. Any further comments?. Thanks and best regards. _______________________________________________ fred-users mailing list fred-users(a)lists.nic.cz https://lists.nic.cz/mailman/listinfo/fred-users

mguerra wrote: > > It works!. Two details, though: > > 1. The name of subzone files would be now db..co.cr. > 2. Because of the way FRED works (it associates a domain with a zone

> you register the domain), you can't simply change the "fqdn" filed in

Hello, 2. If you are fond of db hacking, every domain has zone field what suggests in what zone it is, you can mess around with it by hand aswell, so in theory you can get away without recreating the domain and just changing the zone fqdns to correct ones and modify the zone fields of domains, depending on your domain count and import method, just recreating them can be much easier and cleaner solution. _______________________________________________

In postgres table enum_parameters there are 2 parameters to be set: - expiration_registration_protection_period - expiration_dns_protection_period My question is: When a domainname has expired and the limits above are reached, does fred automatically delete the domainname ? or do i have to put some fred script in cron to do this ? regards Peter .fo _______________________________________________ fred-users mailing list fred-users(a)lists.nic.cz https://lists.nic.cz/mailman/listinfo/fred-users