On 11/09/2014 19:03, dns-operations-requ...@dns-oarc.net wrote:
Thanks for the explanation, that helps! If we step back from the
practise, do we think it's a good thing?
I'm of the opinion that something that can be determined
algorithmically (i.e. when glue should or shouldn't be added),
On 11.09.14 21:51, Colm MacCárthaigh wrote:
For example if a provider booted a box with an empty configuration, it
would be much better to timeout queries than respond with SERVFAIL or
REFUSED.
The protocol expects and response from the server. If no response, the
server is considered down.
On 12.09.14 04:24, Andrew Sullivan wrote:
On Thu, Sep 11, 2014 at 09:35:40PM -0300, Rubens Kuhl wrote:
It was curious to see that a to-be-unnamed TLD registry, a newcomer
to the scene many years after the holy wars that ended up defining
the current RFCs, writing completely new code,
Rubens Kuhl rube...@nic.br wrote:
It was curious to see that a to-be-unnamed TLD registry, a newcomer to
the scene many years after the holy wars that ended up defining the
current RFCs, writing completely new code, mentioned that they found
attributes to be a better option, but decided to go
It was curious to see that a to-be-unnamed TLD registry, a newcomer to
the scene many years after the holy wars that ended up defining the
current RFCs, writing completely new code, mentioned that they found
attributes to be a better option, but decided to go with host objects
due to
On Fri, Sep 12, 2014 at 12:46:29PM +0100,
Tony Finch d...@dotat.at wrote
a message of 27 lines which said:
they have switched to a more standard EPP implementation.
This is absolutely NOT more standard. EPP allows both models (in
other words, you do not have to implement RFC 5732).
[ Note: I haven't had my morning coffee yet, this post likely rambling
/ incoherent... ]
What ever happened to the let's use the glue as a service address
trick? There was some drama about this a number of years ago, but it
died down, possibly as bandwidth and DNS became cheaper...
I cannot
Warren Kumari war...@kumari.net wrote:
I cannot remember all the details, but basically I create a host
object (nameserver) named whatever the service I want to serve is --
so, if I have example.com, I register the nameserver as
'www.example.com', with the IP of my webserver, and now most of
Colm
For gTLDs the nameservers have to be registered via a registrar
Some of the ccTLDs also demand payment and other oddness for adding them
I suspect a lot of this is legacy .. no idea though
Regards
Michele
--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation Domains
On Thu, Sep 11, 2014 at 07:52:31AM -0700,
Colm MacCárthaigh c...@stdlib.net wrote
a message of 26 lines which said:
So why is it that name servers need to be registered? What's the
benefit of doing it?
As an employee of a registry which does not require name server
registration, I wonder,
On Thu, Sep 11, 2014 at 07:52:31AM -0700, Colm MacCárthaigh wrote:
Many registries, if not most, don't let you delegate a zone to
arbitrary name-servers. Instead those nameservers need to be
registered in some way.
I don't know about other kinds of registration systems, but in
EPP-based ones
I'd always thought that this was kinda because of the way EPP is written --
not that it is actually required, but when reading the docs you see the
nameservers object and kinda assume...
I think at this point much of it is hysterical raisons.
W
On Thursday, September 11, 2014, Stephane
Thanks for the explanation, that helps! If we step back from the
practise, do we think it's a good thing?
One the one hand, requiring that nameservers be registered creates
downward pressure on the number of active authoritative name server
names in the world, which has benefits for cache
On Thu, Sep 11, 2014 at 09:34:32AM -0700, Colm MacCárthaigh wrote:
Thanks for the explanation, that helps! If we step back from the
practise, do we think it's a good thing?
From the point of view of data management, I think it is an unalloyed
good. I always thought the nameserver-as-attribute
Vanity nameservers would not be very useful in DDoS mitigation (in terms
of isolating your target) unless you actually create unique IP address
nameserver records for each one.
That's all you'll see in the attack, which IP's the attack is coming
toward, not the hostnames of the vanity nameservers
On Thu, Sep 11, 2014 at 12:46:50PM -0400, Andrew Sullivan wrote:
On Thu, Sep 11, 2014 at 09:34:32AM -0700, Colm MacCárthaigh wrote:
Thanks for the explanation, that helps! If we step back from the
practise, do we think it's a good thing?
From the point of view of data management, I think
In message caaf6gdejb5nw40m4ew58vxwssmlzroeaxvb0vtptf_kfwd+...@mail.gmail.com
, =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= writes:
On Thu, Sep 11, 2014 at 9:46 AM, Andrew Sullivan a...@anvilwalrusden.com wro
te:
Also, it's not like it's terrifically onerous, although I know some
registrars' web
Robert wrote:
Can't you win in either case? If they don't re-resolve you could just
move everyone else off of those IPs by updating the DNS entries for
the unique nameserver labels to those zones. If they do re-resolve you
just move that single unique name to a different IP.
I'm not
On Thu, Sep 11, 2014 at 5:03 PM, Mark Andrews ma...@isc.org wrote:
Which indicates broken recursive servers. Recursive servers should
be expecting misconfigured authoritative servers. You don't stuff
up authoritative behaviour because you have broken recursive servers.
I do whatever is best
From the point of view of data management, I think it is an unalloyed
good. I always thought the nameserver-as-attribute approach was
dramatically worse. Particularly for internal host objects, the
enforced consistency of the glue for every domain that's using it is a
giant help.
It was
On 9/11/2014 5:22 PM, Colm MacCárthaigh wrote:
On Thu, Sep 11, 2014 at 5:03 PM, Mark Andrews ma...@isc.org wrote:
Which indicates broken recursive servers. Recursive servers should
be expecting misconfigured authoritative servers. You don't stuff
up authoritative behaviour because you have
On Thu, Sep 11, 2014 at 09:35:40PM -0300, Rubens Kuhl wrote:
It was curious to see that a to-be-unnamed TLD registry, a newcomer
to the scene many years after the holy wars that ended up defining
the current RFCs, writing completely new code, mentioned that they
found attributes to be a
22 matches
Mail list logo
