On 07/11/2021 09:28, Ray Bellis wrote:
There most certainly were - a similar leak/poison pattern was
detected from an I root node hosted in China in March 2010.
and checking our own records, we've had F root servers in China since at
least 2006.
However we announce our Anycast prefixes
On 06/11/2021 20:20, Manu Bretelle wrote:
I believe back in 2013 there were no root servers in China
There most certainly were - a similar leak/poison pattern was
detected from an I root node hosted in China in March 2010.
I recall the date because Roy Arends and I had previously been
On 28/05/2020 22:56, Viktor Dukhovni wrote:
> Indeed this looks rather precarious, and the SOA serial number is not
> any higher on the other remaining server, the expiration time is 7 days,
> so not much time left if the primary went down in the 21st.
>
> The MX record for cmc.iq is: cmc.iq.
that happens there'll only be one functioning NS for the ccTLD, and
for all I know that one might be about to expire the zone too.
thanks,
Ray Bellis
Director of DNS Operations, ISC.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https
On 02/04/2020 11:10, Davey Song wrote:
> I'm very confused that why people on the list are suggesting RRL (even
> BCP38) to the victim of DoS attack? If I remember correctly, the goal of
> both RRL and BCP38 is to reduce the chance of participating the attack
> as a innocent helper.
>
> In the
On 02/04/2020 10:12, Tessa Plum wrote:
> All the packages were DNS requests, some queries like 'dig domain.com any'.
> but their IP address seems spoofed.
> A request from the fake address to our nameserver, but nameserver try
> its best to reply to this unreal address.
If it's a recursive
On 25/02/2020 18:45, Paul Wouters wrote:
> I understand mistakes happen, and we can look forward at improved
> monitoring of the root zone and its anycast clouds. But this statement
> in the report seems a weak excuse for lowering the bar of expectations
> we have from root zone operators.
That
On 30/01/2020 13:30, Ray Bellis wrote:
> We won't be publishing anything before then, but in practise any public
> report is unlikely to say much that wasn't already disclosed on the day
> (see my email of 21:44 UTC on 2020/01/23).
Our incident report is now online at:
<https:/
On 30/01/2020 11:19, Bill Woodcock wrote:
> So it’s been a week… Cloudflare folks, have you published a post-incident
> analysis yet?
ISC has scheduled a post-mortem meeting with Cloudflare during NANOG.
We won't be publishing anything before then, but in practise any public
report is
which was
causing some resolvers to have issues.
The cause was identified, and so far as possible routes to those nodes
were withdrawn while a fix was being rolled out.
The fix is now in place and the prefixes are being re-advertised.
Ray Bellis
Director of DNS Operation
8.046 ms
4 100ge10-2.core1.lax1.he.net 65.768 ms 63.279 ms 62.687 ms
5 * * *
6 * * *
7 * * *
8 * * *
9 * *^C
Thanks for the report - we'll look into this.
Ray Bellis
Director of DNS Operations, ISC.
___
dns
On 23 Oct 2014, at 16:11, David Conrad
d...@virtualized.orgmailto:d...@virtualized.org wrote:
On Oct 23, 2014, at 6:29 AM, Jelte Jansen
jelte.jan...@sidn.nlmailto:jelte.jan...@sidn.nl wrote:
I do not think putting multiple questions in one request isn't reliably
possible without heavy protocol
On 10 Jan 2014, at 11:28, Stephane Bortzmeyer bortzme...@nic.fr wrote:
I suspect that, in many cases, the leak comes from systems which are
not under the direct control of the system administrator.
1) Jane Sysadmin, who works for Acme Corp, decides (wrongly) to use
.HOME for the local
On 21 Aug 2013, at 11:00, Geoff Huston g...@apnic.net wrote:
Yes, our goal was to test out the asserting in RFC5966 that: The majority of
DNS server operators already support TCP and we wanted to see if we could
quantify what that majority actually was.
[I've been on holiday, so apologies
On 20 Mar 2013, at 13:35, Jaap Akkerhuis j...@nlnetlabs.nl wrote:
Whatalways cracks me up on this page is that all IDNs are sorted under the
X (because of XNN- I assume).
Does a sensible sorting order for characters from different character sets even
exist?
The only one I can think of is by
On 20 Mar 2013, at 14:19, Ray Bellis ray.bel...@nominet.org.uk wrote:
Does a sensible sorting order for characters from different character sets
even exist?
The only one I can think of is by strict code point value, but then that
would produce incorrect results for those languages whose
On 8 Mar 2013, at 11:21, Wolfgang Nagele wolfgang.nag...@ausregistry.com.au
wrote:
Hi,
Any tool recommendations for DNS performance testing when using TCP as a
transport? dnsperf and all others I know only do UDP.
I've previously used tcpreplay with the --pps option to replay a real
On 25 Feb 2013, at 20:11, wbr...@e1b.orgmailto:wbr...@e1b.org wrote:
I'm not a guru on much of the consumer equipment, but what I have seen
allows you to use whatever DNS settings are pushed out by the ISP as part
of DHCP. Just leave that box ticked and you get the ISP's idea of the
proper DNS
On 7 Oct 2012, at 18:09, Matthew Ghali mgh...@snark.net wrote:
To unbias the recommendation a bit more, I agree with Bert. I've used nearly
all the servers you mentioned, and built a largish DNS service product around
PowerDNS, after looking at my options as well. The one you don't mention
On 13 Jun 2012, at 00:56, Mark Andrews wrote:
Both firewall configuration are broken. You don't look at source
ports if you are offering a service.
Although BIND does drop queries from source port 7 and a couple others... ;-)
Ray
___
20 matches
Mail list logo
