This is advance notice that there is a scheduled change to the IP addresses
for one of the authorities listed for the DNS root zone and the .ARPA TLD.
The change is to H.ROOT-SERVERS.NET, which is administered by the U.S. Army
Research Laboratory.
The new IPv4 address for this authority is 198.97.190.53.
The new IPv6 address for the authority is 2001:500:1::53.
This change is anticipated to be implemented in the root zone on 1 December
2015, however the new addresses are operational now. They will replace the
previous IP addresses of 128.63.2.53 and 2001:500:1::803f:235 (also
previously known as AOS.BRL.MIL and AOS.ARL.ARMY.MIL).
We encourage operators of DNS infrastructure to update any references to the
old IP addresses and replace them with the new addresses. In particular,
many DNS resolvers have a DNS root "hints" file. This should be updated with
the new IP addresses.
New hints files will be available at the following URLs once the change has
been formally executed on December 1:
The old IPv4 address will continue to work for six months after the
transition (until 1 June 2016), at which point it will be retired from
service. The address will remain under the control of the Army Research
Laboratory, never to be used again for DNS service. The old IPv6 address
will continue to work indefinitely, but may ultimately be retired from
service.
Simultaneous to the retirement of the old address on June 1, 2016, the
ASN for H-root will change from 13 to 1508.
You can monitor the transition of queries to the new addresses at the
following URL:
From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Kash, Howard M
CIV USARMY RDECOM
ARL (US)
Sent: Monday, August 31, 2015 12:39 PM
To: nanog@nanog.org
Subject: Advance notice - H-root address change on December 1, 2015
This is advance notice that there is a scheduled change to the IP
addresses
for one of the authorities listed for the DNS root zone and the .ARPA TLD.
The change is to H.ROOT-SERVERS.NET, which is administered by the U.S.
Army
Research Laboratory.
The new IPv4 address for this authority is 198.97.190.53.
The new IPv6 address for the authority is 2001:500:1::53.
This change is anticipated to be implemented in the root zone on 1
December
2015, however the new addresses are operational now. They will replace the
previous IP addresses of 128.63.2.53 and 2001:500:1::803f:235 (also
previously known as AOS.BRL.MIL and AOS.ARL.ARMY.MIL).
We encourage operators of DNS infrastructure to update any references to
the
old IP addresses and replace them with the new addresses. In particular,
many DNS resolvers have a DNS root "hints" file. This should be updated
with
the new IP addresses.
New hints files will be available at the following URLs once the change
Just a heads up, even the latest CentOS 7 package has the wrong IPv4 and v6
address.
whilst the new H-ROOT is alive now, the official switch-over date is 1st December 2015
and the old address will be available for 6 months after that....so if any BIND package
comes out AFTER 1st December with old addresses in it, THEN complain/warn
And given that built in values can be overridden there isn't even
a need to do that.
Josh,
If you want to complain about something useful. Complain
that CentOS is still at BIND 9.9.4 rather than BIND 9.9.8. You are
missing bug fixes. We ship maintainence releases for a reason.
This is like saying. We know there are 360 fixes between 9.9.4 and
9.9.8 and we don't think you are going to need any of them despite
other people discovering these bugs.
No. CentOS follows RedHat. They backport fixes to older versions rather than put the new version out. It appears that have aversion to new feature and just want to put the fixes onto the older versions. So that 9.9.4 probably has 60% of the changes that the diff of 9.9.4 has to 9.9.8 . This action confuses most.
The point of putting out maintainence releases is to fix bugs in
the existing code not to introduce features. We leave features to
the .0 releases. The [func] below are bug fixes / security fixes.
Even with 60% of the changes one is missing a huge number of bug
fixes.
Mark
diff --git a/CHANGES b/CHANGES
index e3c5595..5929d64 100644
--- a/CHANGES
+++ b/CHANGES
@@ -1,8 +1,1220 @@
+ --- 9.9.8 released ---
This action by red hat is nice from a stability perspective but infuriates many standards derived folks like ISC/BIND and NTP amongst others as a version number means something to them.
This dialogue is typically broken from both sides as expectations are different and bug reports get lost between the OS packaging and the supplier packaging. Sometimes this is good other times it can be quite bad.
I would prefer to see fewer variants and better bug fixes across the board but the enterprise side often want a specific version number and expect fixes that the upstream maintainers don't want to keep the same version numbering for "that fix" or add a stealth feature and red hat may not want to pick it up...
Not saying who is right or wrong but these views sometimes drive the intractable situation where 4.2.6 is shipped for NTP from red hat (as example) but it is EOL from the NTP.org folks.
The good news is most people don't need all 13 hints, or more when you consider them dual stacked like all new DNS servers are
Either way it's confusing to everyone involved and why I generally track fedora myself.
This action by red hat is nice from a stability perspective but
infuriates many standards derived folks like ISC/BIND and NTP amongst
others as a version number means something to them.
This dialogue is typically broken from both sides as expectations are
different and bug reports get lost between the OS packaging and the
supplier packaging. Sometimes this is good other times it can be
quite bad.
I would prefer to see fewer variants and better bug fixes across the
board but the enterprise side often want a specific version number
and expect fixes that the upstream maintainers don't want to keep the
same version numbering for "that fix" or add a stealth feature and
red hat may not want to pick it up...
Not saying who is right or wrong but these views sometimes drive the
intractable situation where 4.2.6 is shipped for NTP from red hat (as
example) but it is EOL from the NTP.org folks.
Red Hat has known for YEARS that we only have the resources to support
one stable code branch, and that if they want support for older versions
we can offer that at cost.
Nobody has ever approached us about support for older releases of NTP.
The folks who scream the loudest about our not supporting older releases
are the folks who charge their customers money for support. These same
companies do nothing to support us.
Anybody can see the list of companies that support NTP at:
I was very happy to see this feature added in 9.9.8, and I can certainly
agree that it is security related. But I hardly think it is suitable
for the strict "no new features" policy that many stable distros
enforce:
+3938. [func] Added quotas to be used in recursive resolvers
+ that are under high query load for names in zones
+ whose authoritative servers are nonresponsive or
+ are experiencing a denial of service attack.
+
+ - "fetches-per-server" limits the number of
+ simultaneous queries that can be sent to any
+ single authoritative server. The configured
+ value is a starting point; it is automatically
+ adjusted downward if the server is partially or
+ completely non-responsive. The algorithm used to
+ adjust the quota can be configured via the
+ "fetch-quota-params" option.
+ - "fetches-per-zone" limits the number of
+ simultaneous queries that can be sent for names
+ within a single domain. (Note: Unlike
+ "fetches-per-server", this value is not
+ self-tuning.)
+ - New stats counters have been added to count
+ queries spilled due to these quotas.
+
+ These options are not available by default;
+ use "configure --enable-fetchlimit" (or
+ --enable-developer) to include them in the build.
+
+ See the ARM for details of these options. [RT #37125]
Yes, I know they could still upgrade to 9.9.8 without this particular
feature, by simply not enabling it in the build. But the restricted
feature set policy tends to be applied on a source level.
Playing the devil's advocate here... As I said, I was really happy to see
this feature in 9.9.8 myself.
