Re: [dns-operations] solutions for DDoS mitigation of DNS

On Friday, 3 April 2020 02:55:21 UTC Tessa Plum wrote: > Where is "dnsdbq" coming from? I didn't see my ubuntu system has that a > command. it's an example of passive dns lookups. the source code is here: https://github.com/dnsdb/dnsdbq there are dozens of passive dns database systems; only two

Re: [dns-operations] solutions for DDoS mitigation of DNS

Where is "dnsdbq" coming from? I didn't see my ubuntu system has that a command. Thank you. Paul Vixie wrote: $ dnsdbq -r '\*.berkeley.edu/ns' -A 2020-01-01 -j | jq .rrname | uniq ___ dns-operations mailing list dns-operations@lists.dns-oarc.net

Re: [dns-operations] solutions for DDoS mitigation of DNS

In article <26a9dd93-91a3-dbc4-c34b-145f33e74...@plum.ovh> you write: >Hi Stephane, > >I saw you were from FRNIC. May I ask a question that, since I got a >domain from .ovh, It seems anyone can have a domain extension? So how >can I have my own extension, such as .plum? Shall I contact the root

Re: [dns-operations] solutions for DDoS mitigation of DNS

On Friday, 3 April 2020 01:18:46 UTC Tessa Plum wrote: > ... > > Not only for those private domain names, but zone data also includes the > administrative structure of corp/group. nothing in the dns is private. if you don't want something viewed, cataloged, indexed, searched, and used, then do

Re: [dns-operations] Any DNAME usage experience?

Hi Meir, The issues are mainly historical at this point. - Limited some of our options when looking at global zone distribution partners. - Very old resolver code that just did not handle it well, this has faded with time. - Some issues with CA's and certificates, this also not so

Re: [dns-operations] Cloudflare considered harmful?

On Thursday, 2 April 2020 23:59:30 UTC Mark Andrews wrote: > ... > > This means there is no push back on operators doing the wrong thing with > those servers. BIND has refused to load zones with CNAME and other data > for the last 20+ years so, yes, it can be done. It just requires DNS >

Re: [dns-operations] solutions for DDoS mitigation of DNS

Hi Stephane, I saw you were from FRNIC. May I ask a question that, since I got a domain from .ovh, It seems anyone can have a domain extension? So how can I have my own extension, such as .plum? Shall I contact the root server operators to put .plum glues there? Thank you. Tessa Stephane

Re: [dns-operations] solutions for DDoS mitigation of DNS

Fred Morris wrote: There is this thing called a "search list". Love 'em or hate 'em (kind of like DNAMEs!). Suppose your (ab)user is in a coffee shop (wearing appropriate hazmat gear of course). They load their web browser. It's visited secret-project.university-example.edu previously.

Re: [dns-operations] solutions for DDoS mitigation of DNS

Yes, although if you don't believe us maybe you're looking in the wrong place On Thu, 3 Apr 2020, John Levine wrote: In article , Tessa Plum wrote: University has generally some private research projects who have their domain names, but university won't let others see these domain names

Re: [dns-operations] solutions for DDoS mitigation of DNS

John Levine wrote: If those names are ever retrieved by users on networks outside your university, it's very likely that they're in public passive DNS databases that are widely visible. It is not realistic to believe that you can put names in your public DNS and not have the world know about

Re: [dns-operations] Cloudflare considered harmful?

Edit: Thanks for reporting this. We are looking into it and will update once we know why its happening. looking at this briefly shows multiple level of CNAMEs across different zones. On Thu, Apr 2, 2020 at 17:35 Vicky Shrestha wrote: > Hi Brian, > > On Thu, Apr 2, 2020 at 12:46 Brian Somers

Re: [dns-operations] Cloudflare considered harmful?

Hi Brian, On Thu, Apr 2, 2020 at 12:46 Brian Somers wrote: > Hi, > > I saw an example of some pretty poor nameserver behaviour recently and it > has now turned up again for a different domain, both hosted by cloudflare. > It seems to be related to >

Re: [dns-operations] omnibus reply (Re: solutions for DDoS mitigation of DNS)

Paul Vixie wrote: there is never a time when DNS RRL won't help, but it may not be_enough_. DNS RRL should be the default for all authority servers, subject to tuning, but never requiring knowledge or action by operators. if you turn on DNS RRL on an authority server that you didn't think

Re: [dns-operations] solutions for DDoS mitigation of DNS

In article , Tessa Plum wrote: >University has generally some private research projects who have their >domain names, but university won't let others see these domain names >unless the projects have got public. If those names are ever retrieved by users on networks outside your university,

Re: [dns-operations] Cloudflare considered harmful?

> On 3 Apr 2020, at 06:30, Brian Somers wrote: > > Hi, > > I saw an example of some pretty poor nameserver behaviour recently and it has > now turned up again for a different domain, both hosted by cloudflare. It > seems to be related to >

Re: [dns-operations] solutions for DDoS mitigation of DNS

> On 3 Apr 2020, at 00:09, Tessa Plum wrote: > > On 2020/4/2 7:28 下午, Stephane Bortzmeyer wrote: >> BCP38 is Good,*but* it protects others against you. So, to be >> protected, you need the*others* to implement it. > > Ah OK. > So BCP38 is useless for my case. Others don't care if I am

Re: [dns-operations] [meta] some emails on this list being sent out as EML attachments

On Thu, 2 Apr 2020, at 18:40, Grant Taylor via dns-operations wrote: > It's how the dns-operations mailing list is configured to deal with >DMARC protected domains. > >Rather than alter the message as it passes through the mailing list, the >dns-operations list operators have chosen to have

Re: [dns-operations] [meta] some emails on this list being sent out as EML attachments

--- Begin Message --- On 4/2/20 3:02 PM, Sadiq Saif wrote: Hi all, Hi, Can someone tell me what causes this? Yep. I've been on Mailman based mailing lists for a while and I've not seen this particular behaviour in so far as I can recall. It's how the dns-operations mailing list is

[dns-operations] [meta] some emails on this list being sent out as EML attachments

Hi all, Some messages to this list are sent out as EML attachments instead of the text being in the body of the email. It appears to be messages that have the sender name with "via dns-operations" suffixed. Can someone tell me what causes this? I've been on Mailman based mailing lists for a

Re: [dns-operations] looking for suggestion: ML for DNS anti-dos

--- Begin Message --- On 4/2/20 1:01 PM, John R Levine wrote: I would triply emphasize that. Data from the root servers show that the vast majority of queries they get are garbage: technically ill-formed or for names that have never existed and likely never will. This is another reason that

Re: [dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode

On Thursday, 2 April 2020 21:06:26 UTC Brian Somers wrote: > FWIW, OpenDNS/Umbrella/Cisco will use the glue to look things > up and won’t explicitly ask the authority for its own NS record. > > However, if we’re asked for an NS record by a client, we’ll lookup > & return the authoritative answer

Re: [dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode

Thank you for flushing it, I can see that the nodes which were previously failing are now working. I also appreciate the logs, which confirms my fear that the old NS set was stuck in the cache with what's left of the parent's TTL. That's sort of good news in the short term since at least we

Re: [dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode

FWIW, OpenDNS/Umbrella/Cisco will use the glue to look things up and won’t explicitly ask the authority for its own NS record. However, if we’re asked for an NS record by a client, we’ll lookup & return the authoritative answer and that answer will trump the glue. We’ll never serve glue to a

Re: [dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode

I’ve flushed shopdisney.co.uk/NS globally. Should work now for Umbrella/OpenDNS/Cisco > On Apr 2, 2020, at 1:36 PM, Brian Somers wrote: > > This is what I see with diagnostics turned up: > > $ dig +bufsize=16384 +cd +dnssec shopdisney.co.uk @test-resolver > > shopdisney.co.uk. 0

Re: [dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode

On Thursday, 2 April 2020 20:12:50 UTC Puneet Sood via dns-operations wrote: > ,,, > > Google Public DNS is “parent-centric”—meaning that it only uses the > name servers that are returned in the referral responses from the > parent zone name servers, and does not make NS queries to this child >

Re: [dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode

This is what I see with diagnostics turned up: $ dig +bufsize=16384 +cd +dnssec shopdisney.co.uk @test-resolver shopdisney.co.uk. 0 IN TXT "shopdisney.co.uk categorization: None" shopdisney.co.uk. 0 IN TXT "cache_get shopdisney.co.uk/A: ttl=0

Re: [dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode

Thank you for the response. I think it is dependent on the node, since I still see it failing sometimes: dig @8.8.4.4 shopdisney.co.uk ns ; <<>> DiG 9.10.6 <<>> @8.8.4.4 shopdisney.co.uk ns ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status:

Re: [dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode

--- Begin Message --- Pasted wrong output above. dig @8.8.4.4 shopdisney.co.uk ; <<>> DiG 9.11.5-P4-5.1+build2-Debian <<>> @8.8.4.4 shopdisney.co.uk ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15107 ;; flags: qr rd ra; QUERY: 1,

Re: [dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode

--- Begin Message --- Hi Doug, Google Public DNS resolution is working now. Google Public DNS is “parent-centric”—meaning that it only uses the name servers that are returned in the referral responses from the parent zone name servers, and does not make NS queries to this child zone. So updating

[dns-operations] omnibus reply (Re: solutions for DDoS mitigation of DNS)

there has been quite a bit of factual confusion on this thread while i slept; so much so that i can't really figure out where to chime in most usefully. so i'll answer three questions which seem most pertinent, choosing the best example of each question from the thread before me. --- first:

[dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode

Howdy, I redelegated shopdisney.co.uk this morning. I can see that all of the Nominet authorities are returning the correct new NS set, however I have a number of reports of resolution failures. There are resolvers from OpenDNS, Google, Virgin, O2, and others that are not finding any name

Re: [dns-operations] solutions for DDoS mitigation of DNS

strong +1 here. recommended reading or re-reading. On Thursday, 2 April 2020 17:23:22 UTC Fred Morris wrote: > On Thu, 2 Apr 2020, Davey Song wrote: > > I'm very confused that why people on the list are suggesting RRL (even > > BCP38) to the victim of DoS attack? > > The reason rate limiting, of

[dns-operations] Cloudflare considered harmful?

Hi, I saw an example of some pretty poor nameserver behaviour recently and it has now turned up again for a different domain, both hosted by cloudflare. It seems to be related to https://blog.cloudflare.com/zone-apex-naked-domain-root-domain-cname-supp/. I thought I’d bring it up here to

Re: [dns-operations] solutions for DDoS mitigation of DNS

On Thursday, 2 April 2020 11:28:51 UTC Stephane Bortzmeyer wrote: > On Thu, Apr 02, 2020 at 03:06:17PM +0800, > Tessa Plum wrote > > a message of 18 lines which said: > > I never knew BCP38 before. I will try to study it. > > BCP38 is Good, *but* it protects others against you. So, to be >

Re: [dns-operations] looking for suggestion: ML for DNS anti-dos

In article , Warren Kumari wrote: One thing to keep in mind is that DNS traffic is a VERY noisy data source, and corrupt / pathologic queries are incredibly common.. I would triply emphasize that. Data from the root servers show that the vast majority of queries they get are garbage:

Re: [dns-operations] solutions for DDoS mitigation of DNS

On Thu, 2 Apr 2020, Davey Song wrote: I'm very confused that why people on the list are suggesting RRL (even BCP38) to the victim of DoS attack? The reason rate limiting, of any kind (not just DNS, not just UDP; TCP SYN for example), helps in a spoofed source attack is because it makes you a

Re: [dns-operations] solutions for DDoS mitigation of DNS

On Thu, Apr 02, 2020 at 09:31:18PM +0800, Tessa Plum wrote a message of 7 lines which said: > I think we can put the devices in our own network to protect such attacks. Commercial boxes are typically optimised for HTTP, DNS is very different. I remember a box which was creating an entry in

Re: [dns-operations] looking for suggestion: ML for DNS anti-dos

On Thu, Apr 2, 2020 at 9:38 AM Tessa Plum wrote: > > Hello > > I am not familiar with DNS servers, trying my hard to learn it. > I am a researcher on ML/DL field. > Just got a thought, do you think if it's possible to improve DNS > anti-dos capability by deep learning? > As we know, ML/DL is just

Re: [dns-operations] solutions for DDoS mitigation of DNS

Tessa Plum wrote: > > Does RRL work based on IP addr? but the requesting IP seems spoofed. RRL is based on the contents of the DNS response as well as the IP address. Usually for a DDoS attack the IP address is spoofed as the address of the victim, so rate limiting reduces the amount of response

Re: [dns-operations] solutions for DDoS mitigation of DNS

> I think we can put the devices in our own network to protect such attacks. > Sorry. I think no such kind of devices effective for your university, IMHO. Usually anti-DoS solution providers are able to undertake huge amont traffic and clean them bacause they can utilize huge amout of network

Re: [dns-operations] solutions for DDoS mitigation of DNS

On 2020/4/2 9:29 下午, Davey Song wrote: Usually the commercial DoS mitigation solution require you to put your service in their network I think we can put the devices in our own network to protect such attacks. regards. ___ dns-operations mailing

Re: [dns-operations] solutions for DDoS mitigation of DNS

Usually the commercial DoS mitigation solution require you to put your service in their network, like the secondary DNS in which you have privacy concern. Davey On Thu, 2 Apr 2020 at 21:15, Tessa Plum wrote: > On 2020/4/2 7:09 下午, Klaus Darilion wrote: > > > > So my advice: use a name server

[dns-operations] looking for suggestion: ML for DNS anti-dos

Hello I am not familiar with DNS servers, trying my hard to learn it. I am a researcher on ML/DL field. Just got a thought, do you think if it's possible to improve DNS anti-dos capability by deep learning? As we know, ML/DL is just statistics science based on big data. If we have got huge

Re: [dns-operations] solutions for DDoS mitigation of DNS

On 2020/4/2 7:35 下午, Stephane Bortzmeyer wrote: You said you are managing DNS for your university and your concern for secondary DNS is privacy. I'm not sure what exactly the privacy concerns are. RFC 7626. Also, it may raise issues about integrity/trust/etc. In that case, DNSSEC certainly

Re: [dns-operations] solutions for DDoS mitigation of DNS

On Thu, 2 Apr 2020 at 20:58, Tessa Plum wrote: > On 2020/4/2 5:39 下午, Ray Bellis wrote: > > If it's an authoritative server, turn on Response Rate Limiting (RRL) if > > it's BIND, or the equivalent feature if is isn't. > > Yes they are authoritative servers. > Does RRL work based on IP addr? but

Re: [dns-operations] solutions for DDoS mitigation of DNS

On 2020/4/2 7:28 下午, Stephane Bortzmeyer wrote: BCP38 is Good,*but* it protects others against you. So, to be protected, you need the*others* to implement it. Ah OK. So BCP38 is useless for my case. Others don't care if I am meeting the attack or not. regards.

Re: [dns-operations] solutions for DDoS mitigation of DNS

On 2020/4/2 7:09 下午, Klaus Darilion wrote: So my advice: use a name server which can fill your upstream bandwith (NSD, Knot ...). And for volumetric attacks use a commercial DDoS mitigation provider which filters your traffic (ie. buy the service from your ISP or from a remote DDoS

Re: [dns-operations] solutions for DDoS mitigation of DNS

On 2020/4/2 6:43 下午, Klaus Darilion wrote: So what was the bottleneck? I.e. if you use PowerDNS with DB backend you quite early hit the limit with random subdomains, which are not a problem if you use NSD for example. To mitigation such traffic patterns for example we use dnsdist with 2

Re: [dns-operations] solutions for DDoS mitigation of DNS

On Thu, 2 Apr 2020 at 19:38, Stephane Bortzmeyer wrote: > > RFC 7626. > > Also, it may raise issues about integrity/trust/etc. In that case, > DNSSEC certainly helps a lot. > OK. I need more sense of privacy :) Davey ___ dns-operations mailing list

Re: [dns-operations] [Ext] Re: Contingency plans for the next Root KSK Ceremony

Denesh wrote: >> Interestingly enough, the Super 7 - part of the IAO - who ensured >> web addresses were real... were the main topic in the episode Ill >> Tidings of Sherlock inspired US TV show Elementary .. I think it was >> around 4 years ago. I'm surprised I never heard of it at the time.

Re: [dns-operations] solutions for DDoS mitigation of DNS

On 2020/4/2 5:39 下午, Ray Bellis wrote: If it's an authoritative server, turn on Response Rate Limiting (RRL) if it's BIND, or the equivalent feature if is isn't. Yes they are authoritative servers. Does RRL work based on IP addr? but the requesting IP seems spoofed. Thanks Tessa

Re: [dns-operations] solutions for DDoS mitigation of DNS

On Thu, Apr 02, 2020 at 05:39:48PM +0800, Davey Song wrote a message of 111 lines which said: > You said you are managing DNS for your university and your concern > for secondary DNS is privacy. I'm not sure what exactly the privacy > concerns are. RFC 7626. Also, it may raise issues about

Re: [dns-operations] solutions for DDoS mitigation of DNS

On Thu, Apr 02, 2020 at 11:05:48AM +0100, Tony Finch wrote a message of 30 lines which said: > > ACLs in the server are not enough, you also need ingress filtering > > on the borders of your network, to prevent packets claiming to be > > from your network to get inside. > > That kind of

Re: [dns-operations] solutions for DDoS mitigation of DNS

Indeed - I only wanted to comment on the rate limiting. It is not that I argue against rate limiting, but that admins should be aware when it actually helps, and when not. Sorry, when my email seemed a bit harshly. We also used rate limiting with dnsdist, but due to the mentioned problems we

Re: [dns-operations] solutions for DDoS mitigation of DNS

On Thu, Apr 02, 2020 at 03:06:17PM +0800, Tessa Plum wrote a message of 18 lines which said: > I never knew BCP38 before. I will try to study it. BCP38 is Good, *but* it protects others against you. So, to be protected, you need the *others* to implement it.

Re: [dns-operations] solutions for DDoS mitigation of DNS

On Thu, 2 Apr 2020 at 18:22, Jim Reid wrote: > > RRL won’t help with the volume of incoming queries. Exactly! > It will however reduce the volume of outgoing responses which may well be > DoS’ing another innocent victim. > Agree Davey ___

Re: [dns-operations] solutions for DDoS mitigation of DNS

That's very selective cutting of my sentence Klaus > On 2 Apr 2020, at 13:09, Klaus Darilion > wrote: > > Am 02.04.2020 um 09:15 schrieb Frank Louwers: >> dnsdist allows you to do general ratelimiting/blocking > > Ratelimiting is often not the correct

Re: [dns-operations] solutions for DDoS mitigation of DNS

But Tessa Plum are asking for help when they were under attack with a lot of UDP requests flooding to the servers. When a patient with flu asking for help, but his doctor only suggest him to mask himself avoid he inffectiing others. Wearing masks is generally good for public but not a cure for

Re: [dns-operations] solutions for DDoS mitigation of DNS

Am 02.04.2020 um 09:15 schrieb Frank Louwers: dnsdist allows you to do general ratelimiting/blocking Ratelimiting is often not the correct choice. If the source IP is random (which is usually the case with spoofed source IP addresses), a rate limiting based on source IP is not useful. If

Re: [dns-operations] solutions for DDoS mitigation of DNS

Am 02.04.2020 um 05:51 schrieb Tessa Plum: Hello Paul We were under some attack like UDP flood to the authority servers, there were a lot of UDP requests flooding to the servers. The traffic size was about 20Gbps last time as I have said in last message. The clients seem using spoofed IP

Re: [dns-operations] solutions for DDoS mitigation of DNS

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

Re: [dns-operations] solutions for DDoS mitigation of DNS

Stephane Bortzmeyer wrote: > On Thu, Apr 02, 2020 at 03:06:49AM +, > Paul Vixie wrote > a message of 29 lines which said: > > > to keep your own recursive servers from amplifying spoofed-source > > attacks, you need ACL's that make it unreachable outside your > > specific client base. > >

Re: [dns-operations] [Ext] Re: Contingency plans for the next Root KSK Ceremony

> On 1 Apr 2020, at 00:24, Denesh Bhabuta via dns-operations > wrote: > > > Interestingly enough, the Super 7 - part of the IAO - who ensured web > addresses were real... were the main topic in the episode Ill Tidings of > Sherlock inspired US TV show Elementary .. I think it was around 4

Re: [dns-operations] solutions for DDoS mitigation of DNS

<> The intuitive solution against the DoS attack is to scale your system wiith mulitple servers in the globe. You can either develop global anycast instance as Paul suggested or select and operate secondary DNS servers documented in RFC2182/BCP16. There are many secondary DNS providers

Re: [dns-operations] solutions for DDoS mitigation of DNS

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

Re: [dns-operations] solutions for DDoS mitigation of DNS

On Thu, Apr 02, 2020 at 05:12:29PM +0800, Tessa Plum wrote a message of 11 lines which said: > All the packages were DNS requests, some queries like 'dig domain.com any'. > but their IP address seems spoofed. In that case, yes, RRL would help. ___

Re: [dns-operations] solutions for DDoS mitigation of DNS

On 2020/4/2 3:19 下午, Stephane Bortzmeyer wrote: DNS or another type? Stephane, 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

Re: [dns-operations] solutions for DDoS mitigation of DNS

On Thu, Apr 02, 2020 at 11:51:05AM +0800, Tessa Plum wrote a message of 37 lines which said: > We were under some attack like UDP flood to the authority servers, DNS or another type? > The traffic size was about 20Gbps Note that for DNS traffic, the useful metric is often

Re: [dns-operations] solutions for DDoS mitigation of DNS

> >> May I ask if there are any solutions for DDoS mitigation of DNS? > > All solutions that were mentioned here are correct but incomplete: > there is no general solution against dDoS, because "it depends". There > are many types of dDoS. You will need several tools in your toolbox, > and

Re: [dns-operations] solutions for DDoS mitigation of DNS

On Thu, Apr 02, 2020 at 03:06:49AM +, Paul Vixie wrote a message of 29 lines which said: > to keep your own recursive servers from amplifying spoofed-source > attacks, you need ACL's that make it unreachable outside your > specific client base. ACLs in the server are not enough, you also

Re: [dns-operations] solutions for DDoS mitigation of DNS

On 2020/4/2 12:25 下午, Mark Andrews wrote: You use all the mechanisms available to you. Traceback. Getting BCP38 installed at the sites emitting spoofed traffic help yourself and everyone else. In many cases this is coming from compromised machines. You enable/tune response rate filtering.

Re: [dns-operations] solutions for DDoS mitigation of DNS

On Wed, Apr 01, 2020 at 07:35:35PM -0700, Fred Morris wrote a message of 10 lines which said: > Depends on what you mean. You might look at "response rate limiting" in for > instance BIND. -- FWM RRL protects people against you (when your name server is used as a reflector) but not really

Re: [dns-operations] solutions for DDoS mitigation of DNS

On Thu, Apr 02, 2020 at 10:14:14AM +0800, Tessa Plum wrote a message of 14 lines which said: > May I ask if there are any solutions for DDoS mitigation of DNS? All solutions that were mentioned here are correct but incomplete: there is no general solution against dDoS, because "it depends".

Re: [dns-operations] [Ext] Re: Contingency plans for the next Root KSK Ceremony

LOL. Where do I sign?! /Anne-Marie > -Ursprungligt meddelande- > Från: dns-operations För Jacques > Latour > Skickat: den 1 april 2020 22:57 > Till: Warren Kumari ; Dave Lawrence > Kopia: dns-operations@lists.dns-oarc.net Operations operati...@lists.dns-oarc.net>; Grant Taylor >