Stephane Bortzmeyer bortzme...@nic.fr wrote:
But having host objects is not mandatory and some registries (like
.FR) do not use them at all, even when they use EPP.
Very sensible :-)
Tony.
--
f.anthony.n.finch d...@dotat.at http://dotat.at/
Trafalgar: In southeast, northerly 4 or 5,
Hi Stéphane,
On 25 Jun 2015, at 7:26, Stephane Bortzmeyer wrote:
On Tue, Jun 23, 2015 at 02:18:59PM -0300,
Joe Abley jab...@hopcount.ca wrote
a message of 119 lines which said:
The EPP data model includes host objects and domain objects. Every
domain is linked to one or more host objects
On Tue, Jun 23, 2015 at 02:18:59PM -0300,
Joe Abley jab...@hopcount.ca wrote
a message of 119 lines which said:
The EPP data model includes host objects and domain objects. Every
domain is linked to one or more host objects (two or more in
practice, for policy reasons orthogonal to the data
Joe Abley jab...@hopcount.ca wrote:
Thanks for your very helpful reply...
The requirements I am stating below are from the DNS point of view rather
than from the registry point of view.
I think that's not going to help you get a clear answer, but let's give it a
try. People who actually
Stephane Bortzmeyer (bortzmeyer) writes:
It has always been our policy (and, I believe, the one of the majority
of DNS operators), that responsability and monitoring belongs to the
_master_. If a secondary of .fr lags behind, it is _our_ role and
responsability to detect it and to solve it
all true. but mw is a tough case, hard circumstances. and a sat link
does not help. so frank from tz helps watch and debug. warren also
watches, but he is up at layers nine and ten this week. life goes on.
randy
___
dns-operations mailing list
On Thu, Jun 25, 2015 at 11:12:40AM +0200,
Gunter Grodotzki gun...@grodotzki.co.za wrote
a message of 78 lines which said:
But shouldn't that raise a big red flag - even if it is not your
fault?
DNS operator hat _on_. At $DAYJOB, we both have secondaries for other
domains, and domains for
Hello,
I did a domain update last week on cheki.mw, but it seems like some OPs
are either sleeping or their syncing is not really working ;)
The following auth-ns is still delivering a old record:
mw.21599INNSrip.psg.com.
$ dig +nocomments ns cheki.mw @rip.psg.com
;
On 25/06/15 10:30, Randy Bush wrote:
rip.psg.com:/root# dig +short @196.45.188.5 mw. soa
;; connection timed out; no servers could be reached
rip.psg.com:/root# dig +short @41.221.99.135 mw. soa
;; connection timed out; no servers could be reached
having fun over there?
We also operate
Hi Randy,
Thank you for your quick response!
So in other words master is blocking you from fetching updates? But
shouldn't that raise a big red flag - even if it is not your fault?
Currently your slave is the only one not receiving any updates thus
poisoning dns-caches with wrong/outdated
On Thu, Jun 25, 2015 at 10:23:46AM +0200,
Gunter Grodotzki gun...@grodotzki.co.za wrote
a message of 47 lines which said:
I did a domain update last week on cheki.mw, but it seems like some
OPs are either sleeping or their syncing is not really working ;)
Inconsistencies are always fun to
Ah ok my mistake, sorry for that! I made the wrong assumption, did not
know it was a overall problem with the masters.
The Zone-OPS according to iana.org are in cc'ed and should hopefully
have enough debug data to see the problem and solve it?
Thanks again Randy for your feedback, I'm glad
The Zone-OPS according to iana.org are in cc'ed and should hopefully
have enough debug data to see the problem and solve it?
frank has been working with them for a while and debugging. just did
not see the need to start screaming fire in a crowded theater.
randy
I did a domain update last week on cheki.mw, but it seems like some OPs
are either sleeping or their syncing is not really working ;)
The following auth-ns is still delivering a old record:
mw.21599INNSrip.psg.com.
$ dig +nocomments ns cheki.mw @rip.psg.com
;
14 matches
Mail list logo
