Fwd: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete
Apologies for cross-posting, but I believe this relevant to the NANOG operator community. FYI, /John Begin forwarded message: From: ARIN <info@arin.net<mailto:info@arin.net>> Date: February 16, 2011 3:53:38 PM EST To: <arin-announce@arin.net<mailto:arin-announce@arin.net>> Subject: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete Today ARIN and ICANN are jointly working on the transition of the technical management function for the IN-ADDR.ARPA zone from ARIN to ICANN. ARIN carried out the DNS zone maintenance function for IN-ADDR.ARPA since 1997 and worked closed with ICANN throughout the transition period. Immediately upon transfer to ICANN, the IN-ADDR.ARPA zone will also be signed using DNS Security Extensions (DNSSEC), providing end-users with the ability to validate answers to reverse DNS queries. The IN-ADDR.ARPA zone is also in the process of being moved from twelve root servers to dedicated nameservers operated by the five Regional Internet Registries (RIRs) and one operated by ICANN. For more details on the history of this transition please see <http://in-addr-transition.icann.org/>. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN)
John, Congratulations to you and ICANN for this significant step, at all the various layers and meanings of significant. :) Relevant to another post today, I've noticed that neither the *.ip6-servers.arpa nor the *.in-addr-servers.arpa allow axfr. Which leads to the following questions: 1. Was that a conscious decision, and if so why? 2. Is there any hope that axfr could be permitted in the future? Of course, if you're not the right person to ask feel free to redirect me. Best regards, Doug On 02/16/2011 13:00, John Curran wrote:
Apologies for cross-posting, but I believe this relevant to the NANOG operator community. FYI, /John
Begin forwarded message:
From: ARIN<info@arin.net<mailto:info@arin.net>> Date: February 16, 2011 3:53:38 PM EST To:<arin-announce@arin.net<mailto:arin-announce@arin.net>> Subject: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete
Today ARIN and ICANN are jointly working on the transition of the technical management function for the IN-ADDR.ARPA zone from ARIN to ICANN. ARIN carried out the DNS zone maintenance function for IN-ADDR.ARPA since 1997 and worked closed with ICANN throughout the transition period.
Immediately upon transfer to ICANN, the IN-ADDR.ARPA zone will also be signed using DNS Security Extensions (DNSSEC), providing end-users with the ability to validate answers to reverse DNS queries. The IN-ADDR.ARPA zone is also in the process of being moved from twelve root servers to dedicated nameservers operated by the five Regional Internet Registries (RIRs) and one operated by ICANN.
For more details on the history of this transition please see<http://in-addr-transition.icann.org/>.
Regards,
Communications and Member Services American Registry for Internet Numbers (ARIN)
-- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
On Feb 16, 2011, at 4:30 PM, Doug Barton wrote:
John,
Congratulations to you and ICANN for this significant step, at all the various layers and meanings of significant. :)
Relevant to another post today, I've noticed that neither the *.ip6-servers.arpa nor the *.in-addr-servers.arpa allow axfr. Which leads to the following questions:
1. Was that a conscious decision, and if so why? 2. Is there any hope that axfr could be permitted in the future?
Of course, if you're not the right person to ask feel free to redirect me.
Doug - Excellent questions (of which I do not know the answer) Allow me some time for research. Thanks! /John John Curran President and CEO ARIN
On 02/16/2011 13:44, John Curran wrote:
On Feb 16, 2011, at 4:30 PM, Doug Barton wrote:
John,
Congratulations to you and ICANN for this significant step, at all the various layers and meanings of significant. :)
Relevant to another post today, I've noticed that neither the *.ip6-servers.arpa nor the *.in-addr-servers.arpa allow axfr. Which leads to the following questions:
1. Was that a conscious decision, and if so why? 2. Is there any hope that axfr could be permitted in the future?
Of course, if you're not the right person to ask feel free to redirect me.
Doug -
Excellent questions (of which I do not know the answer)
Allow me some time for research.
Thanks!
No no, thank YOU. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
Hi Doug, On 2011-02-16, at 16:30, Doug Barton wrote:
Relevant to another post today, I've noticed that neither the *.ip6-servers.arpa nor the *.in-addr-servers.arpa allow axfr. Which leads to the following questions:
1. Was that a conscious decision, and if so why?
It's a question for the individual operators of the servers. I can only speak for the particular servers that ICANN operates. ICANN operates B.IN-ADDR-SERVERS.ARPA and B.IP6-SERVERS.ARPA. As with L-Root, we don't permit zone transfers from the servers themselves; our goal with the nameservers themselves is to provide them with as much headroom as possible for answering DNS queries, and it has never seemed to us that also responding to AXFR is going to help with that. We do however support open zone transfers for the root zone, ARPA, IN-ADDR.ARPA and IP6.ARPA from two locations for anybody who cares to use them: xfr.lax.dns.icann.org xfr.cjr.dns.icann.org The availability of these servers for AXFR is documented at <http://dns.icann.org/services/axfr/>. Joe
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/16/2011 14:23, Joe Abley wrote: | Hi Doug, | | On 2011-02-16, at 16:30, Doug Barton wrote: | |> Relevant to another post today, I've noticed that neither the *.ip6-servers.arpa nor the *.in-addr-servers.arpa allow axfr. Which leads to the following questions: |> |> 1. Was that a conscious decision, and if so why? | | It's a question for the individual operators of the servers. I can only speak for the particular servers that ICANN operates. | | ICANN operates B.IN-ADDR-SERVERS.ARPA and B.IP6-SERVERS.ARPA. As with L-Root, we don't permit zone transfers from the servers themselves; our goal with the nameservers themselves is to provide them with as much headroom as possible for answering DNS queries, and it has never seemed to us that also responding to AXFR is going to help with that. | | We do however support open zone transfers for the root zone, ARPA, IN-ADDR.ARPA and IP6.ARPA from two locations for anybody who cares to use them: | | xfr.lax.dns.icann.org | xfr.cjr.dns.icann.org | | The availability of these servers for AXFR is documented at<http://dns.icann.org/services/axfr/>. Joe, Thanks for clarifying. I almost included "is axfr available from any other source?" as a 3rd question, but figured that would come out in the wash. :) This leads to 2 additional questions: 1. Is the zone available from those 2 locations "the same" as what's available on the authoritative servers, or is there a lag time between updates on the auth and the xfr servers? 2. Is there any objection to having those servers listed in publicly available documentation on how to configure resolvers to slave the root and related zones? Thanks again, Doug - -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBCAAGBQJNXFC4AAoJEFzGhvEaGryEDJsIAMPnaAEjXUJHJieA5YlsLL7U iHaCdNAW4q9pBRao8syG9c6l1ZNTG/qZu2CfJ5sBfXfLuimiCvJ4qsfqBX3koc+/ n8EC7f9tEFYQuTQJOZQs3xoT8dYfFxBRn9OFYLRVnEzWXfNB0LpY1a+Q+wEjwU/M U5/1k2ejDyhSSZGpc3VqrSpnQNu8/KAcJM3Ybt0eZE9oZoS7qE5oKmbJ7KuVPHug mH/4PeNoLTtfL1kg+k663SafGbERtfCarZvSOIWbDKPl2YjJcXT9mhpCuPHV/Tkf SHyvB9vcvhZS2PPvVOd/WpZxowG3PxLQJPdv2j/rB1HHu8/QT8KLxm60AivxYh8= =go0l -----END PGP SIGNATURE-----
On 2011-02-16, at 17:33, Doug Barton wrote:
This leads to 2 additional questions:
1. Is the zone available from those 2 locations "the same" as what's available on the authoritative servers, or is there a lag time between updates on the auth and the xfr servers?
The two servers mentioned transfer the zone from the same place as the *.in-addr-servers.arpa servers. They're a little closer than some of the other servers. I imagine some propagation lag between them would be visible with the right instrumentation. The speed of light is the speed of light.
2. Is there any objection to having those servers listed in publicly available documentation on how to configure resolvers to slave the root and related zones?
My personal opinion is that such advice is misguided, but we place no restrictions on the soundness of the reasons for transferring zones from those places :-) Joe
----- Original Message -----
From: "Joe Abley" <jabley@hopcount.ca> To: "Doug Barton" <dougb@dougbarton.us> Cc: "John Curran" <jcurran@arin.net>, "NANOG" <nanog@merit.edu> Sent: Thursday, 17 February, 2011 12:05:16 PM Subject: Re: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete On 2011-02-16, at 17:33, Doug Barton wrote:
2. Is there any objection to having those servers listed in publicly available documentation on how to configure resolvers to slave the root and related zones?
My personal opinion is that such advice is misguided, but we place no restrictions on the soundness of the reasons for transferring zones from those places :-)
Would it break DNSSEC ?
On 02/16/2011 15:13, Franck Martin wrote:
----- Original Message -----
From: "Joe Abley"<jabley@hopcount.ca> To: "Doug Barton"<dougb@dougbarton.us> Cc: "John Curran"<jcurran@arin.net>, "NANOG"<nanog@merit.edu> Sent: Thursday, 17 February, 2011 12:05:16 PM Subject: Re: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete On 2011-02-16, at 17:33, Doug Barton wrote:
2. Is there any objection to having those servers listed in publicly available documentation on how to configure resolvers to slave the root and related zones?
My personal opinion is that such advice is misguided,
Yes, I know. :) I obviously believe that reasonable minds can differ on this topic, but as we've gone round about this before and I don't want to get too deep in the DNS weeds I'll just say that I respect your perspective on this topic, even though I disagree with it. I should also add that the fact that this configuration can get out of sync and cause problems is not to be taken lightly. When I first started using and recommending this configuration 10 years ago my feeling was that the days of "set it and forget it" DNS were coming to an end since DNSSEC was "just around the corner." I was wrong about that on both counts, but I still believe that for those that are willing and able to take appropriate care with their DNS infrastructure that this configuration is a win.
but we place no restrictions on the soundness of the reasons for transferring zones from those places :-)
Would it break DNSSEC ?
No. In my current configuration I have the root zone trust anchor configured and I just re-configured it to download ip6.arpa and in-addr.arpa from the ICANN servers Joe mentioned. Note the "ad" bit: dig @127.0.0.1 6.0.1.0.0.2.ip6.arpa. ns +dnssec ; <<>> DiG 9.8.0rc1 <<>> @127.0.0.1 6.0.1.0.0.2.ip6.arpa. ns +dnssec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39677 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;6.0.1.0.0.2.ip6.arpa. IN NS ;; ANSWER SECTION: 6.0.1.0.0.2.ip6.arpa. 172800 IN NS sns-pb.isc.org. 6.0.1.0.0.2.ip6.arpa. 172800 IN NS sec3.apnic.net. 6.0.1.0.0.2.ip6.arpa. 172800 IN NS sunic.sunet.se. 6.0.1.0.0.2.ip6.arpa. 172800 IN NS tinnie.arin.net. 6.0.1.0.0.2.ip6.arpa. 172800 IN NS ns3.nic.fr. 6.0.1.0.0.2.ip6.arpa. 172800 IN NS sec1.apnic.net. 6.0.1.0.0.2.ip6.arpa. 172800 IN NS ns-pri.ripe.net. 6.0.1.0.0.2.ip6.arpa. 172800 IN NS munnari.oz.au. 6.0.1.0.0.2.ip6.arpa. 172800 IN RRSIG NS 5 8 172800 20110318135006 20110216125006 63865 6.0.1.0.0.2.ip6.arpa. fe3wJGI5KHjrR2HasKojm8gpJxpQXcPY5Piy7c58XmSyzKlONxOTwvdC +Cjlw/XCfWCSc6IjNlmJm7kACRtQrOrv2PnvYan+1yslAJyguoTvl56j N+nOTD0VDlNeInKkonn/attHWvV+c05gxdXLEkW11PSdF1xtkDKgPkwV n54= ;; Query time: 376 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Feb 16 16:07:34 2011 ;; MSG SIZE rcvd: 435 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
Sorry, this probably should be moved to dns-ops, but this may interest some of the network operators here. Doug Barton (dougb) writes:
I should also add that the fact that this configuration can get out of sync and cause problems is not to be taken lightly. When I first started using and recommending this configuration 10 years ago my feeling was that the days of "set it and forget it" DNS were coming to an end since DNSSEC was "just around the corner." I was wrong about that on both counts, but I still believe that for those that are willing and able to take appropriate care with their DNS infrastructure that this configuration is a win.
Not to tread on a landmine, but reading /etc/namedb/named.conf on a (recent) FreeBSD, it states: [...] Slaving the following zones from the root name servers has some significant advantages: 1. Faster local resolution for your users 2. No spurious traffic will be sent from your network to the roots 3. Greater resilience to any potential root server failure/DDoS On the other hand, this method requires more monitoring than the hints file to be sure that an unexpected failure mode has not incapacitated your server. Name servers that are serving a lot of clients will benefit more from this approach than individual hosts. Use with caution. [...] (note that other zones can be configured to be slaved per the above setup, but I'm only mentioning root for the sake of the discussion) In order: Point 1: After the NS has primed itself, and has been running for a few minutes, how much faster are we talking about ? Is this something you have some numbers on ? Is it measurable from a user experience point of view ? Is there a sweet spot/ROI of sorts on scale ranging from "small network" to "large corporation" ? With ~300 TLDs in the forward space (don't know how many subdelegations in-addr.arpa has off the top of my head), is this a real, noticeable win ? Imagining that the new vTLDs are a success, and this grows to potentially thousands of new TLDs, what's the projected improvement value from this setup ? Does it become a handicap ? Point 2: I've heard that 98% of traffic to the root is junk, but since NXDOMAINs get quickly neg cached, how much bandwidth conservation and resource preservation are we talking about ? If one takes AS112 into account, how much improvement is this ? Point 3: Do we have a historical scenario where DDoS has effectively hindered DNS resolution for caching nameservers to the extent that they couldn't look up non-cached TLD records/prime themselves at startup ? Analysis of a big DoS attack in 2006, IIRC, did nothing more that slow down somewhat some of the affected anycast instances. Now, I'm not being skeptical here, but you put the arguments for slaving the top level zones as a win-only situation. So I feel compelled to ask you to back those claims, especially considering the tradeoff in complexity and stability it entails with regards to monitoring requirements. The days of "set if and forget it" for DNS may be gone, but it's no reason to make life unnecessarily complex for system administrators, and while it's a personal choice to enable slaving, your recommending it should be thoroughly justified :) Cheers, Phil
On Thu, 17 Feb 2011 10:14:48 +0800, Phil Regnauld said:
Point 2:
I've heard that 98% of traffic to the root is junk, but since NXDOMAINs get quickly neg cached, how much bandwidth conservation and resource preservation are we talking about ? If one takes AS112 into account, how much improvement is this ?
If that's the CAIDA paper I'm thinking of, a lot of the 98% junk was the sort of stuff you'd expect from broken sites who probably won't do neg caching right - and in fact, a significant portion (30%?) was *specifically* sources that failed to negative cache a reply and asking over and over again, often multiple times a second. Of course, those sort of broken sites probably will manage to screw up deploying a local hints file, resulting in *more* traffic at the roots :)
On 02/16/2011 18:14, Phil Regnauld wrote:
Not to tread on a landmine,
Actually it seems like you want to jump up and down on it. Given that both the benefits and the potential problems have been extensively debated elsewhere, I'll simply say that you raise interesting questions that I think people interested in this method should answer for themselves.
Now, I'm not being skeptical here, but you put the arguments for slaving the top level zones as a win-only situation.
And for me, and a lot of others it has been. If you have something new to contribute in regards to the negatives I'm happy to listen, although this might not be the best forum. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
Doug Barton (dougb) writes:
Actually it seems like you want to jump up and down on it. Given that both the benefits and the potential problems have been extensively debated elsewhere, I'll simply say that you raise interesting questions that I think people interested in this method should answer for themselves.
So, you're advocating a method that potentially fragilizes one's DNS infrastructure, but you're not providing factual data backing up the purported advantages, and actually leave it up to the users to find out for themselves ? Gee, that's a seller :)
Now, I'm not being skeptical here, but you put the arguments for slaving the top level zones as a win-only situation.
And for me, and a lot of others it has been. If you have something new to contribute in regards to the negatives I'm happy to listen, although this might not be the best forum.
Well, I was trying to raise constructive criticism - and hoped you would reply by providing links to resources/references summarizing the advantages, with more than empirical claims. But agreed, this is best discussed elsewhere :) Cheers, Phil
On 02/16/2011 22:16, Phil Regnauld wrote:
Doug Barton (dougb) writes:
Actually it seems like you want to jump up and down on it. Given that both the benefits and the potential problems have been extensively debated elsewhere, I'll simply say that you raise interesting questions that I think people interested in this method should answer for themselves.
So, you're advocating
This is the second time you've made this claim, I ignored it the first time, but let me be clear. I'm not advocating anything. Someone else asked if it made sense to do so, and I responded. Yes, the FreeBSD named.conf states that there are advantages to this method, it also states that there are things to be careful about.
a method that potentially fragilizes one's DNS infrastructure, but you're not providing factual data backing up the purported advantages,
Nope, I'm saying that it's all been discussed before, and this isn't the forum to discuss it in more detail.
and actually leave it up to the users to find out for themselves ? Gee, that's a seller :)
I think you'd be pretty foolish to not carefully weigh the pros and cons for yourself before making any change of this nature to something as critical as DNS, and I include things that I _do_ advocate in that category like DNSSEC and IPv6.
Now, I'm not being skeptical here, but you put the arguments for slaving the top level zones as a win-only situation.
And for me, and a lot of others it has been. If you have something new to contribute in regards to the negatives I'm happy to listen, although this might not be the best forum.
Well, I was trying to raise constructive criticism - and hoped you would reply by providing links to resources/references summarizing the advantages, with more than empirical claims.
But agreed, this is best discussed elsewhere :)
Funny how you keep saying that .... Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
Relevant to another post today, I've noticed that neither the *.ip6-servers.arpa nor the *.in-addr-servers.arpa allow axfr. Which leads to the following questions:
1. Was that a conscious decision, and if so why? Speaking for the operator of f.in-addr-servers.arpa and f.ip6-servers.arpa this was simply not on our radar.
2. Is there any hope that axfr could be permitted in the future? Since we are also operating k.root-servers.net and have provided XFR from it for all this time we will do so for these servers as well. This has now been enabled on our systems.
Regards, Wolfgang Nagele RIPE NCC DNS Group Manager -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1dOrcACgkQjO7G63Byy8f5hACgmRBBPCYlPI4vVumvAwyWZAgJ t8MAoJs4BOwzKiKYwNjYY9oOIADlhTzs =aFMj -----END PGP SIGNATURE-----
On 02/17/2011 07:11, Wolfgang Nagele wrote:
Hi,
Relevant to another post today, I've noticed that neither the *.ip6-servers.arpa nor the *.in-addr-servers.arpa allow axfr. Which leads to the following questions:
1. Was that a conscious decision, and if so why? Speaking for the operator of f.in-addr-servers.arpa and f.ip6-servers.arpa this was simply not on our radar.
2. Is there any hope that axfr could be permitted in the future? Since we are also operating k.root-servers.net and have provided XFR from it for all this time we will do so for these servers as well. This has now been enabled on our systems.
Thanks! I sort of suspected that this was the case at least for the servers operated by RIPE NCC because of the history with K as you pointed out above. I appreciate your quick attention to this issue, and my (admittedly non-comprehensive) tests indicate that f.ip6-servers.arpa and f.in-addr-servers.arpa are indeed now allowing transfers. Best Regards, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
Congrats to all on getting this done! It's been a long time in coming. Good to see it finally finished. Regards, -drc On Feb 16, 2011, at 1:00 PM, John Curran wrote:
Apologies for cross-posting, but I believe this relevant to the NANOG operator community. FYI, /John
Begin forwarded message:
From: ARIN <info@arin.net<mailto:info@arin.net>> Date: February 16, 2011 3:53:38 PM EST To: <arin-announce@arin.net<mailto:arin-announce@arin.net>> Subject: [arin-announce] IN-ADDR.ARPA Zone Transfer Complete
Today ARIN and ICANN are jointly working on the transition of the technical management function for the IN-ADDR.ARPA zone from ARIN to ICANN. ARIN carried out the DNS zone maintenance function for IN-ADDR.ARPA since 1997 and worked closed with ICANN throughout the transition period.
Immediately upon transfer to ICANN, the IN-ADDR.ARPA zone will also be signed using DNS Security Extensions (DNSSEC), providing end-users with the ability to validate answers to reverse DNS queries. The IN-ADDR.ARPA zone is also in the process of being moved from twelve root servers to dedicated nameservers operated by the five Regional Internet Registries (RIRs) and one operated by ICANN.
For more details on the history of this transition please see <http://in-addr-transition.icann.org/>.
Regards,
Communications and Member Services American Registry for Internet Numbers (ARIN)
On 2011-02-16, at 21:15, David Conrad wrote:
Congrats to all on getting this done! It's been a long time in coming. Good to see it finally finished.
You're very welcome :-) however, the work is not quiet yet done. Next steps are: week of 2011-02-21: IN-ADDR.ARPA zone dropped from B, C, E, G, I, M root servers week of 2011-02-28: IN-ADDR.ARPA zone dropped from A, D, F, H, K, L root servers week of 2011-03-06: DS record for IN-ADDR.ARPA inserted into ARPA zone At the end of this process every subdomain of ARPA will be fully DNSSEC-signed. Query rates on the new servers (those operated by the RIRs and ICANN) are currently low, but are expected to increase as the IN-ADDR.ARPA zone is dropped from root servers. Some stats on the ICANN-operated servers can be found here: http://dns.icann.org/services/inaddr-arpa/ http://dns.icann.org/services/ip6-arpa/ (click through on the graphs for more detail) Joe
On Feb 17, 2011, at 8:03 AM, Joe Abley wrote:
At the end of this process every subdomain of ARPA will be fully DNSSEC-signed.
Cool.
Query rates on the new servers (those operated by the RIRs and ICANN) are currently low, but are expected to increase as the IN-ADDR.ARPA zone is dropped from root servers.
It'll be interesting to see what the corresponding drop in traffic in the root servers will be... Regards, -drc
Hi,
It'll be interesting to see what the corresponding drop in traffic in the root servers will be... We expect it to be around 2000qps (or ~8% of the total traffic) for k.root-servers.net. PTR query rates are very steady and do not follow the general diurnal cycle.
Regards, Wolfgang
participants (8)
-
David Conrad -
Doug Barton -
Franck Martin -
Joe Abley -
John Curran -
Phil Regnauld -
Valdis.Kletnieks＠vt.edu -
Wolfgang Nagele