--- Begin Message ---
A distinct possibility is that it will happen in Santa Marta, Colombia, and
will be colocated with LAC DNS Week and ICANN DNS Symposium.
Previous editions websites:
https://dnsweek.lat/en
https://www.icann.org/ids
Rubens
> Em 17 de abr. de 2024, à(s) 12:00, Petr
--- Begin Message ---
> Em 22 de fev. de 2024, à(s) 14:25, Gaurav Kansal
> escreveu:
>
> Hi Rubens,
>
> Is it mandatory for the ccTLD to get its RSP evaluated ? Or they have the
> freedom to choose the RSP without evacuation purpose.
>
> Please ignore my lack of knowledge here.
ccTLDs can
--- Begin Message ---
>
> I did some of the technical evaluations in the previous round, and we
> saw that the vast majority of applications used about five back end
> providers. Prequalifying those providers would have made the whole
> process much faster.
>
> R's,
> John
--- Begin Message ---
>
> I did some of the technical evaluations in the previous round, and we
> saw that the vast majority of applications used about five back end
> providers. Prequalifying those providers would have made the whole
> process much faster.
>
> R's,
> John
--- Begin Message ---
Gaurav,
If an applicant so prefers it can have its own RSP evaluated at the same time
its application is evaluated, so it’s not restricted to the list of
pre-approved RSPs.
Rubens
> Em 22 de fev. de 2024, à(s) 00:57, Gaurav Kansal via dns-operations
> escreveu:
--- Begin Message ---
What’s your popularity metric ?
Installations ?
Number of queries served ?
Number of zones served ?
Number of OS distributions that include it in the base system ?
Rubens
> Em 15 de fev. de 2024, à(s) 12:33, Turritopsis Dohrnii Teo En Ming via
> dns-operations
--- Begin Message ---
Wireshark is a good DNS teacher unless DoT/DoH is in play.
Resillience of the DNS system is why most people know little about it. People
just take it for granted.
Rubens
Em 29 de jul. de 2023 09:20, em 09:20, Stephane Bortzmeyer
escreveu:
>As usual, a good practical
--- Begin Message ---
HI there.
I am considering a DNSSEC transition in the following scenario:
- Org 1 operates both the parent domain, with a delegation-only server, and the
child domain, with a set of authoritative servers. A zone cut is present.
- Org 2 operates only authoritative
--- Begin Message ---
Is anyone seeing issues resolving .mx domains ? Not working from here and
DNSViz seems to have issues with some of the authoritatives but not all of them:
https://dnsviz.net/d/citas.sre.gob.mx/dnssec/
• mx zone: The server(s) were not responsive to queries over TCP.
--- Begin Message ---
The list of malicious websites in browsers is constantly updated without having
to follow the release cycle... where there's a will, there's a way.
Rubens
> On 27 Aug 2022, at 22:43, Jothan Frakes wrote:
>
> I am really frustrated that the materials developed for IANA
--- Begin Message ---
>
> So bottom line, browser behavior is not based on DNS resolving, nor by any
> IANA list, but rather on the PSL.
> As I wrote earlier we have already merged the diff into the list.
> The next update of firefox and hopefully chromium based browsers (sept 26),
> should
At Vivo in Brazil, AS 27699 for the broadband service using AS 10429 resolvers,
recursive DNS (powered by Akamai / Nominum) can't resolve some Google services:
$ dig +noall +question +answer lh3.googleusercontent.com @200.204.0.10 #
Vivo recursive DNS
;lh3.googleusercontent.com. IN A
$ dig
Not exactly what you asked, but a registrar example: Openprovider requires
registrant to provide the DNSKEY, not DS, to activate and manage DNSSEC.
Rubens
> On 22 Jan 2020, at 19:13, Tony Finch wrote:
>
> Are there any registries that configure secure delegations from DNSKEY
> records (and
> Em 11 de dez de 2019, à(s) 10:20:000, Jim Reid escreveu:
>
>
>
>> On 11 Dec 2019, at 12:51, Stephane Bortzmeyer wrote:
>>
>> IMHO, this is by far the biggest issue with your proposal: TLDs change
>> from one technical operator to another and, when it happens, all name
>> servers change
> On 30 Nov 2019, at 14:31, Keith Mitchell wrote:
>
> On 11/29/19 8:32 PM, Rubens Kuhl wrote:
>
>> including making studies that other parties can't reproduce due to
>> being limited to DITL data.
>
> DITL data is available to any party who signs an OARC Dat
>>
>> The data could have monetary value. Passwords that are otherwise
>> difficult to come by might be leaking.
>
> Hi Florian,
>
> I can assure you that Verisign does not monetize the root server data. If
> any other operators do, I'm not aware of it.
>
> We do utilize root server data
> On 9 Nov 2019, at 03:00, Mehmet Akcin wrote:
>
> Hey there
>
> I am trying to improve the performance of tlds in various parts of the world
> as part of a project.
>
> Besides PCH, who else I can get a hold of these days to have local caches of
> DNS? I am focusing on Brazil, Argentina,
> On 12 Oct 2019, at 10:03, Keith Mitchell wrote:
>
> On 10/11/19 6:30 PM, Shumon Huque wrote:
>
>> It might be much more important for diagnostic and measurement services
>> like DNSviz though. At the moment, if you run IPv6 DNS servers on
>> networks that are singly connected to Cogent, it
% dig @a.in-addr-servers.arpa. 12.in-addr.arpa. ns
...
12.in-addr.arpa.5INNScmtu.mt.ns.els-gms.att.net.
12.in-addr.arpa.5INNSdbru.br.ns.els-gms.att.net.
12.in-addr.arpa.5INNScbru.br.ns.els-gms.att.net.
12.in-addr.arpa.5INNS
Em 11/06/2015, à(s) 10:45:000, Kumar Ashutosh kumar.ashut...@microsoft.com
escreveu:
@Kevin
See if this interests you
http://azure.microsoft.com/en-us/services/dns/
Services with per-query charges are not what the original poster is looking
for. Azure, AWS and similar offerings can
Firefox (Linux, Mac) are broken. Safari is broken. Some versions of curl
work,
some don't.
Same behaviour in Chrome for Mac OS X. With the added bonus of HSTS moving
access to HTTPS for a good number of domains.
Rubens
___
dns-operations
On Dec 31, 2014, at 11:05 AM, Alexander Neilson alexan...@neilson.net.nz
mailto:alexan...@neilson.net.nz wrote:
I am a relatively new operator of DNS servers and have inherited a rather
messy existing system.
In the past year I have been learning more about the operations of DNS
Paul,
Complementing what Edmon Chung mentioned that root-servers was already reserved
in the last new gTLD round, here follows the complete list of reserved names:
AFRINIC
IANA-SERVERS
NRO
ALAC
ICANN
RFC-EDITOR
APNIC
IESG
RIPE
ARIN
IETF
ROOT-SERVERS
ASO
INTERNIC
RSSAC
CCNSO
INVALID
SSAC
Registrars making it difficult to add addresses. Inertia.
CDN's not supporting IPv6 nameservers.
Yes. they need more incentive to update their system.
Actually, I firstly pay attention to the dual-stack in DNS is the setting to
keep the independence of DNS transport and DNS
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
Em 11/09/2014, à(s) 22:58:000, Joshua Smith juice...@gmail.com escreveu:
Probably something I should know. But what's the best way to get notified of
new TLDs coming online to help arm the NOC?
Two ways: signing up to https://mm.icann.org/mailman/listinfo/gtldnotification
where you know a
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
What I can tell you is that registries and applicants suggested ICANN to not
require DNSSEC-signign of wildcard controlled interruption due to likely
differences in resolver behaviour, including some known bugs.
Rubens
On Sep 3, 2014, at 4:00 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote:
Em 29/08/2014, à(s) 12:40:000, David Conrad d...@virtualized.org escreveu:
Hi,
On Aug 28, 2014, at 11:59 PM, Patrik Fältström p...@frobbit.se wrote:
On 29 aug 2014, at 07:04, SM s...@resistor.net wrote:
At 14:13 28-08-2014, Rod Rasmussen wrote:
I note that these documents speak to many of
On Aug 16, 2014, at 11:32 PM, Ken Peng o...@dnsbed.com wrote:
Thanks for the info.
I have two another questions,
1st, does the .watch tld owned by your company fully?
Nope, .watch TLD registry operator is Donuts, Inc:
http://donuts.co
Rubens
On Jul 20, 2014, at 6:00 PM, Sebastian Castro sebast...@nzrs.net.nz wrote:
Call for Presentations - DNS-OARC Fall Workshop, October 2014
Next OARC Fall Workshop will take place in Los Angeles, California, USA
on October 11th to the 13th, the weekend before ICANN51. On Monday
October 13th
RFC 2606 seems to suggest using a registered domain. That¹s great except
that split-brain inevitably creeps into the equation. Is this a case of
choosing the ³least worst² option?
Register a domain, but delegate it to DNS servers that are not in your network
and always contains a
Em 19/03/2014, à(s) 14:30:000, Florian Weimer f...@deneb.enyo.de escreveu:
Is there are offical, documented WHOIS redirector for TLDs with some
long-term interface stability. WHOIS.IANA.ORG might do the job, but I
couldn't find official documentation pointing to it.
Do you mean WebWHOIS
Em 19/03/2014, à(s) 14:52:000, Florian Weimer f...@deneb.enyo.de escreveu:
* Rubens Kuhl:
Em 19/03/2014, à(s) 14:30:000, Florian Weimer f...@deneb.enyo.de escreveu:
Is there are offical, documented WHOIS redirector for TLDs with some
long-term interface stability. WHOIS.IANA.ORG might
Em 13/01/2014, à(s) 12:52:000, Alexander Mayrhofer alexander.mayrho...@nic.at
escreveu:
Florian Streibelt wrote:
# dig +short txt berlin
;; Truncated, retrying in TCP mode.
The .berlin-zone is protected through the German Copyright-Law. Beyond it
is protected by criminal law and data
Em 10/01/2014, à(s) 19:05:000, Miek Gieben m...@miek.nl escreveu:
[ Quoting rube...@nic.br in Re: [dns-operations] Is it illegal ... ]
the zone is prohibited. All rights, in particular the right of
duplication,
circulation or usage, belong exclusively to nic.berlin, unless you have an
Em 26/11/2013, à(s) 00:22, Mark Andrews ma...@isc.org escreveu:
In message 5293fa31.9030...@dnsbed.com, Dnsbed Ops writes:
Hello,
My nameservers currently have been meeting the attacks.
All these queries are against one special domain, from the seemed fake IPs.
And those eat up the
Is whatever Google doing documented somewhere? I didn't see anything
with https://www.google.com/search?q=chromium+nxdomain+detection+dns
and one or two similar searches.
Yeap, in the source code. Some discussions on those:
http://productforums.google.com/forum/#!topic/chrome/dQ92XhrDjfk
Which brings me to the topic of resolver-behind-upstream attacks which were
not commented upon.
As you know, one of the recommendations of experts and Internet operators,
following Kaminsky attack, was `either deploy patches or configure your
resolver to use a secure upstream forwarder`,
Em 22/10/2013, às 18:06:000, Michele Neylon - Blacknight escreveu:
On 22 Oct 2013, at 20:28, Jared Mauch ja...@puck.nether.net
wrote:
It's difficult because there is not universal support amongst registrars.
Once again the wheel gets stuck when the technical side meets the business
Em 22/10/2013, às 20:40, Jim Reid escreveu:
On 22 Oct 2013, at 22:53, Rubens Kuhl rube...@nic.br wrote:
.nl and .cz got massive registrar adoption to DNSSEC offering business
incentives, so it seems business side accounts for most of it.
So where are the incentives for resolver
Em 14/10/2013, às 13:08:000, Paul Hoffman escreveu:
A fictitious 100-person company has an IT staff of 2 who have average IT
talents. They run some local servers, and they have adequate connectivity for
the company's offices through an average large ISP.
Should that company run its own
If you get a Google cluster to be installed in your network, 8.8.8.8 could
become local without the need for hijacking... but civilized way to deal with
this is talk to customer about the issues that using a far-away DNS server will
have.
Rubens
Em 25/02/2013, às 14:26:000, Graham Beneke
Em 04/01/2013, às 14:05:000, Matthew Pounsett escreveu:
A friend of mine at an ISP asked me recently whether I had any suggestions
for fingerprinting stub resolvers. They've got pcaps from the downstream
side of their caching servers and are looking at trying to pull more
interesting
On Oct 17, 2012, at 2:14 PM, Tony Finch d...@dotat.at wrote:
On 15/10/2012, at 3:10 AM, Ondřej Surý ondrej.s...@nic.cz wrote:
Just a question - would anyone would be interested in joining a
project to build an OpenHardware FPGA-based HSM with focus on DNSSEC?
One interesting possibility
Much better and very detailed analysis (by the same author!) So, it
was not DNS poisoning at all but a change in the DNS settings of the
router, after the box was cracked. (DNSchanger-style)
http://www.securelist.com/en/blog/208193852/The_tale_of_one_thousand_and_one_DSL_modems
I'm not sure if I phrased my question correctly. It's not about
redundancy, but about keeping the queries to root/g(TLD) name servers
to a minimum.
In your example, if 127.0.0.1 was the resolver that just came up again
after a restart, it wouldn't return a failure for a query that it has
Em 13/07/2012, às 18:19:000, Jason Gurtz escreveu:
My parent is .com and in searching around I found a whole lot about what a
DS record is, but nil on the operational aspects of it.
May a zone administrator transfer their DS record to the parent zone to
establish the chain of trust, or is
48 matches
Mail list logo
