Re: Advance notice - H-root address change on December 1, 2015
On 11/16/15 4:55 PM, Jared Mauch wrote: > 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: http://nwtime.org/current-members-donors/ The free software companies listed there do not give us any money. >> On Nov 16, 2015, at 7:16 PM, Mark Andrews wrote: >> >> 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. In NTP's case, we fixed over 1100 things between 4.2.6 and 4.2.8. Skippy (Harlan'e evil twin brother)
Re: Advance notice - H-root address change on December 1, 2015
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. Jared Mauch > On Nov 16, 2015, at 7:16 PM, Mark Andrews wrote: > > > In message , Alan Buxey > writes: >> 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. >> >> alan > > 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.
Re: Advance notice - H-root address change on December 1, 2015
In message , Alan Buxey writes: > > > 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. > > alan 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 --- + + --- 9.9.8rc1 released --- + +4193. [bug] Handle broken servers that return BADVERS incorrectly. + [RT #40427] + +4192. [bug] The default rrset-order of random was not always being + applied. [RT #40456] + +4191. [protocol] Accept DNS-SD non LDH PTR records in reverse zones + as per RFC 6763. [RT #37889] + +4190. [protocol] Accept Active Diretory gc._msdcs. name as + valid with check-names. still needs to be + LDH. [RT #40399] + +4189. [cleanup] Don't exit on overly long tokens in named.conf. + [RT #40418] + +4188. [bug] Support HTTP/1.0 client properly on the statistics + channel. [RT #40261] + +4187. [func] When any RR type implementation doesn't + implement totext() for the RDATA's wire + representation and returns ISC_R_NOTIMPLEMENTED, + such RDATA is now printed in unknown + presentation format (RFC 3597). RR types affected + include LOC(29) and APL(42). [RT #40317]. + +4183. [cleanup] Use timing-safe memory comparisons in cryptographic + code. Also, the timing-safe comparison functions have + been renamed to avoid possible confusion with + memcmp(). Thanks to Loganaden Velvindron of + AFRINIC. [RT #40148] + +4182. [cleanup] Use mnemonics for RR class and type comparisons. + [RT #40297] + +4181. [bug] Queued notify messages could be dequeued from the + wrong rate limiter queue. [RT #40350] + +4179. [bug] Fix double frees in getaddrinfo() in libirs. + [RT #40209] + +4178. [bug] Fix assertion failure in parsing UNSPEC(103) RR from + text. [RT #40274] + +4177. [bug] Fix assertion failure in parsing NSAP records from + text. [RT #40285] + +4176. [bug] Address race issues with lwresd. [RT #40284] + +4175. [bug] TKEY with GSS-API keys needed bigger buffers. + [RT #40333] + +4174. [bug] "dnssec-coverage -r" didn't handle time unit + suffixes correctly. [RT #38444] + +4173. [bug] dig +sigchase was not properly matching the trusted + key. [RT #40188] + +4172. [bug] Named / named-checkconf didn't handle a view of CLASS0. + [RT #40265] + +4171. [bug] Fixed incorrect class checks in TSIG RR + implementation. [RT #40287] + +4170. [security] An incorrect boundary check in the OPENPGPKEY + rdatatype could trigger an assertion failure. + (CVE-2015-5986) [RT #40286] + +4169. [test] Added a 'wire_test -d' option to read input as + raw binary data, for use as a fuzzing harness. + [RT #40312] + +4168. [security] A buffer accounting error could trigger an + assertion failure when parsing certain malformed + DNSSEC keys. (CVE-2015-5722) [RT #40212] + + --- 9.9.8b1 released --- + +4165. [security] A failure to reset a value to NULL in tkey.c could + result in an assertion failure. (CVE-2015-5477) + [RT #40046] + +4164. [bug] Don't rename slave files and journals on out of memory. + [RT #40033] + +4163. [bug] Address compiler warnings. [RT #40024] + +4162. [bug] httpdmgr->flags was not being initialized. [RT #40017] + +4159. [cleanup] Alphabetize dig's help output. [RT #39966] + +4158. [protocol] Support the printing of EDNS COOKIE and EXPIRE options. + [RT #39928] + +4154. [bug] A OPT record should be included with the FORMERR + response when there is a malformed E
Re: Advance notice - H-root address change on December 1, 2015
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. alan
Re: Advance notice - H-root address change on December 1, 2015
In message <20151116161939.ga3...@lboro.ac.uk>, a.l.m.bu...@lboro.ac.uk writes: > Hi, > > > 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 thatso if any > BIND package > comes out AFTER 1st December with old addresses in it, THEN complain/warn ;-) > > alan 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. [rock:~/git/bind9] marka% git diff v9_9_4 v9_9_8 CHANGES | grep '^+[34]' | wc 3603385 22807 [rock:~/git/bind9] marka% Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Project Fi and the Great Firewall
With Wi-Fi calling it gets a bit more simplified (no "transit" operators in user plane) and may provide better privacy (only your home country will monitor your calls, lol). The UE establishes IPsec tunnel over the Internet to the home operator and uses it for native VoIP/messaging applications. On Sun, Nov 15, 2015 at 9:33 PM, Carlos Alcantar wrote: > > Similar to the SS7 phone network where call signaling data is done on a > totally different path then the actual rtp path. > > > Carlos Alcantar > Race Communications / Race Team Member > 1325 Howard Ave. #604, Burlingame, CA. 94010 > Phone: +1 415 376 3314 / car...@race.com / http://www.race.com > > > > From: NANOG on behalf of Jared Geiger < > ja...@compuwizz.net> > Sent: Saturday, November 14, 2015 7:08 PM > To: NANOG > Subject: Re: Project Fi and the Great Firewall > > When you roam onto another cellular network other than your home network, > your data is encapsulated and sent back to your home network before going > out to the internet. This is to provide a seamless experience for the > customer. > > The network it rides on is the GRX/IPX which is a a worldwide MPLS network > that the GSMA specified to make the data roaming experience work. The > GRX/IPX also can carry voice and text back to the home network. Since it is > a separate network from the Internet, the Great Firewall was bypassed. > > There are several GRX/IPX providers and they all peer with each other in > key locations which usually end up being in the same major Internet peering > locations. TATA, Syniverse, SAP, Telia, and many others run an IPX/GRX > network and Equinix has IPX/GRX peering exchanges. > > The wikipedia articles will start you in the right direction for more > information: > https://en.wikipedia.org/wiki/GPRS_roaming_exchange > https://en.wikipedia.org/wiki/IP_exchange > > ~Jared > > On Sat, Nov 14, 2015 at 6:27 PM, Jake Mertel < > jake.mer...@ubiquityhosting.com> wrote: > > > I know the service/device uses VPN if you are using "wifi assist" to > > connect to an open WAP -- it automatically tunnels the traffic so it > can't > > be read by nearby snoopers. Perhaps they employ a similar technology or > are > > using something like PPP to take all of the traffic back to one (or many) > > "access servers" before sending it off to the Internet. I have no > > experience whatsoever in cellular network operations, but I know many > > providers employ similar methodologies to assist in meeting their CALEA > > requirements. > > > > On Saturday, November 14, 2015, Roland Dobbins > wrote: > > > > > On 15 Nov 2015, at 9:00, Sean Hunter wrote: > > > > > > While in China recently, I noticed that my Project Fi phone was > accessing > > >> Google. > > >> > > > > > > Accessing, or attempting to access? > > > > > > Were you using a local SIM card, or roaming w/data? What about WiFi? > > > > -- Best regards, Yury.
Re: Advance notice - H-root address change on December 1, 2015
Hi, > 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 thatso if any BIND package comes out AFTER 1st December with old addresses in it, THEN complain/warn ;-) alan
Re: Advance notice - H-root address change on December 1, 2015
Just a heads up, even the latest CentOS 7 package has the wrong IPv4 and v6 address. Version : 9.9.4 Release : 18.el7_1.1 Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Mon, Nov 16, 2015 at 7:30 AM, Kash, Howard M CIV USARMY RDECOM ARL (US) < howard.m.kash@mail.mil> wrote: > > Friendly reminder... > > > > -Original Message- > > From: NANOG [mailto:nanog-boun...@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 > has > > been formally executed on December 1: > > > > http://www.internic.net/domain/named.root > > http://www.internic.net/domain/named.cache > > > > 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: > > > > http://h.root-servers.org/old_vs_new.html > > > > > > -- > > Howard Kash > > U.S. Army Research Laboratory >
RE: Advance notice - H-root address change on December 1, 2015
Friendly reminder... > -Original Message- > From: NANOG [mailto:nanog-boun...@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 has > been formally executed on December 1: > > http://www.internic.net/domain/named.root > http://www.internic.net/domain/named.cache > > 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: > > http://h.root-servers.org/old_vs_new.html > > > -- > Howard Kash > U.S. Army Research Laboratory smime.p7s Description: S/MIME cryptographic signature
RE: DNSSEC and ISPs faking DNS responses
eric-l...@truenet.com wrote: > Actually, how are other places implementing these lists? I would have > thought to use RPZ, but as far as I know if the blocked DNS domain is > using DNSSEC it wouldn't work. You can configure RPZ with the "break-dnssec" option which means validating clients will fail to resolve the blocked domains. DNSSEC only protects you from getting bad answers. If someone wants you to get no answers at all then DNSSEC cannot help. Tony. -- f.anthony.n.finchhttp://dotat.at/ Tyne, Dogger, Fisher: Southwest 6 to gale 8, occasionally severe gale 9 at first. Rough or very rough, becoming mainly moderate in Tyne. Rain or showers. Good, occasionally poor.
Re: DNSSEC and ISPs faking DNS responses
Owen DeLong wrote: > Again, if you’re the only resolver the clients are using, you can claim that > nothing from the root down is signed without ever providing any cryptographic > anything. If the client is validating it will know the root is signed and the ISP resolver will not be able to strip signature without breaking validation. Tony. -- f.anthony.n.finchhttp://dotat.at/ Thames, Dover, Wight, Portland: Southwest 6 to gale 8, decreasing 5 for a time, perhaps severe gale 9 later. Moderate or rough, occasionally very rough later. Rain at times. Moderate or good, occasionally poor.
Time Waner Cable IPv6 help needed
Last month after a service upgrade/reprovisioning I am no longer getting an IPv6 prefix. Now all I see are RAs and never a response to DHCPv6 solicit. I have tried different support channels but no luck getting an answer. >From what I gathered IPv6 is available in my market and no known outages. Can someone please ping me offline? Very much appreciated Yang
Re: EoMPLS vlan rewrite between brands; possibly new bug in Cisco IOS 15
On 15 November 2015 at 01:31, Jonas Bjork wrote:
> Dear Mr. Jeff,
>
> Thank you for your reply. Below is the complete output in question (l2 is
> short for l2transport).
> You are mentioning platform capabilities and that the default might have
> changed. How do I alter this?
>
> pe#sh mpls l2 vc 42 d
> Local interface: Po190.42 up, line protocol up, Eth VLAN 42 up
> Destination address: X.X.1.89, VC ID: 42, VC status: down
> Last error: Imposition VLAN rewrite capability mismatch with peer
> Output interface: none, imposed label stack {}
> Preferred path: not configured
> Default path: no route
> No adjacency
> Create time: 00:00:59, last status change time: 00:31:40
> Last label FSM state change time: 00:00:18
> Last peer autosense occurred at: 00:00:18
> Signaling protocol: LDP, peer X.X.1.89:0 up
> Targeted Hello: X.X.0.2(LDP Id) -> X.X.1.89, LDP is UP
> Graceful restart: not configured and not enabled
> Non stop routing: not configured and not enabled
> Status TLV support (local/remote) : enabled/not supported
> LDP route watch : enabled
> Label/status state machine: remote invalid, LruRnd
> Last local dataplane status rcvd: No fault
> Last BFD dataplane status rcvd: Not sent
> Last BFD peer monitor status rcvd: No fault
> Last local AC circuit status rcvd: No fault
> Last local AC circuit status sent: DOWN PW(rx/tx faults)
> Last local PW i/f circ status rcvd: No fault
> Last local LDP TLV status sent: No fault
> Last remote LDP TLVstatus rcvd: Not sent
> Last remote LDP ADJstatus rcvd: No fault
> MPLS VC labels: local 242, remote 1199
> Group ID: local 0, remote 0
> MTU: local 9216, remote 9216
> Remote interface description:
> Remote VLAN id: 42
> Sequencing: receive disabled, send disabled
> Control Word: Off (configured: autosense)
> SSO Descriptor: X.X.1.89/42, local label: 242
> Dataplane:
> SSM segment/switch IDs: 0/0 (used), PWID: 142
> VC statistics:
> transit packet totals: receive 0, send 0
> transit byte totals: receive 0, send 0
> transit packet drops: receive 0, seq error 0, send 0
> pe#
>
> Anyone else: feel free to join in. Maybe we have any L2VC/PW ninjas watching.
>
> Best regards,
> Jonas Bjork
Hi Jonas,
In that output you have "Remote VLAN id: 42" -What is the local VLAN
ID on your Cisco PE? Do you need to VLAN rewrite here?
Since you using different VLANs at each end, can you build the
pseudowire at a point in the network stack where the VLAN tag has been
popped off already and transport the frames untagged, so they will be
pushed on again at the other end? (Is this is a VC type 4 pseudowire,
check with "show mpls l2transport binding 42", if so, a dummy VLAN
should be pushed on and popped off transparently if all hardware in
use supports it).
I don't know HP but with the Cisco 7600 for example, if it's VLAN 50
then you could add "interface vlan 50; xconnecy X.X.1.89 42 encaps
mpls", if your hardware supports that. Or use mux-uni; "int gix/x.y;
encaps dot1q y; xconnecy X.X.1.89 42 encaps mpls". Then add vice versa
on the HP kit.
What IOS have you tried to upgrade to, 15.2(4)S4a? If this is a VC
type 4 pseudowire and either the HP or Cisco isn't supporting
inserting a dummy VLAN tag, why is this a VC type 4 pseudowire? The
VLAN re-write I guess. Certainly in IOS 15.3 (so probably also in 15.2
but I'm not 100% certain of that) Cisco IOS should be defaulting to VC
type 5 unless the other end negotiates down to VC type 4. VC type 5 in
IOS supports transporting of untagged, tagged and double tagged
frames, I don't think there is any functionality in VC type 5 that
wasn't in older type 4's so I'd try and work out why your devices are
negotiating type 4 and maybe try to fix that, or as above, transport
untagged.
Cheers,
James.
