The Domain Name System (DNS) is a naming system for computers, services, or other resources connected to the Internet or a private network. DNS translates domain names to the numerical IP addresses needed for locating and identifying computer services and devices. For decades It’s been an essential component of the Internet. It’s an essential part of Kubernetes as well, and is used to determine how workloads connect to Kubernetes services as well as resources outside the cluster.
DNS also happens to be a common source of outages and issues in Kubernetes clusters. When applications are not working as expected, the root cause is often DNS-related. However, debugging and troubleshooting DNS issues in Kubernetes environments is not a trivial task given the limited amount of information Kubernetes provides for DNS queries.
Lacking the necessary visibility into the cluster to correlate a DNS query or reply with a specific workload, for example, you are left in the dark. Without Kubernetes context, you are unable to capture even the most fundamental information needed for troubleshooting, such as the type of DNS query (or reply) or the source of the query.

Figure: The DNS Dashboard from Tigera helps Kubernetes teams more quickly confirm or Continue reading
Today's Tech Bytes is a customer story with sponsor Riverbed. It’s a tale of latency and its impact on network performance when moving applications to cloud. Our guests from Riverbed are Aly Walowski, whose title is roughly “Cloud Goddess” at Riverbed; and Jack Sweeney, Major Account Manager.
The post Tech Bytes: Accelerating Cloud Applications With Riverbed’s Cloud SteelHead (Sponsored) appeared first on Packet Pushers.
Burnout stalks most network engineers—and most people in the world of information technology—striking at least once in every career, it seems, and often more than once. In this episode, Brian Keys joins Eyvonne Sharp, Tom Ammon, and Russ White to discuss his personal experience with burnout. The discussion then turns to general strategies and ideas for avoiding burnout on a day-to-day basis.


On Sunday, December 13, FireEye released a report on a sophisticated supply chain attack leveraging SolarWinds' Orion IT monitoring software. The malware was distributed as part of regular updates to Orion and had a valid digital signature.
One of the notable features of the malware is the way it hides its network traffic using a multi-staged approach. First, the malware determines its command and control (C2) server using a domain generation algorithm (DGA) to construct and resolve a subdomain of avsvmcloud[.]com.
These algorithmically generated strings are added as a subdomain of one of the following domain names to create a new fully-qualified domain name to resolve:
.appsync-api[.]eu-west-1[.]avsvmcloud[.]com
.appsync-api[.]us-west-2[.]avsvmcloud[.]com
.appsync-api[.]us-east-1[.]avsvmcloud[.]com
.appsync-api[.]us-east-2[.]avsvmcloud[.]com
An example of such a domain name might look like: hig4gcdkgjkrt24v6isue7ax09nksd[.]appsync-api[.]eu-west-1[.]avsvmcloud[.]com
The DNS query response to a subdomain of one of the above will return a CNAME record that points to another C2 domain, which is used for data exfiltration. The following subdomains were identified as the C2 domains used for data exfiltration:
freescanonline[.]com
deftsecurity[.]com
thedoccloud[.]com
websitetheme[.]com
highdatabase[.]com
incomeupdate[.]com
databasegalore[.]com
panhardware[.]com
zupertech[.]com
virtualdataserver[.]com
Continue reading
There's a lot of hype and fanfare around Kubernetes, but on today's Day Two Cloud episode we'll cut through the hype with a guest who has enterprise experience with Kubernetes and containers--including the pain and problems. Those pains revolve around complexity, the ignorance of the Kubernetes platform, and the disconnect between the designers of Kubernetes and the people trying to use it now. Our guest is Eric Wright, Technology Evangelist at Turbonomic and host of the DiscoPosse podcast.
The post Day Two Cloud 079: Kubernetes Is Inevitable But Not Always Necessary appeared first on Packet Pushers.
We’ve all done it once The old buggers say Powered down the data centre by accident one day Today its a lot harder to do because people like me have all done it once Now no one does it just once And no one remembers Why the power system Is done that way
Internet Society Chapters in Europe are warning the European Commission that its recent plea for Member States to help find ways to access encrypted communications could make millions of citizens and countries more vulnerable to harm and terrorism online.
Representing digital security experts who share the Internet Society’s mission for a bigger and stronger Internet, several EU chapters issued statements expressing concern about the danger of the Commission’s request for backdoor access to encrypted communications in its Counter Terrorism Agenda. It was announced the same week the European Medicines Agency was victim to a major data breach when cyber attackers unlawfully accessed sensitive documents about COVID-19 vaccines.
End-to-end encryption is crucial to the security of European citizens, its economy, and the national security of its Member States. It is our strongest digital security tool online because it keeps data and communications private between the sender and receiver. Even the European Commission relies on Signal, an end-to-end encrypted messaging app, to secure its communications.
A recent report signed by over 50 leading cybersecurity experts shows how there is no way to give law enforcement access to end-to-end encrypted communications without putting all users at risk.
Encryption backdoors are dangerous because Continue reading
Last week I described how I configured PVLAN on a Linux bridge. After checking the desired partial connectivity with ios_ping I wanted to verify it with LLDP neighbors. Ansible ios_facts module collects LLDP neighbor information, and it should be really easy using those facts to check whether port isolation works as expected.
---
- name: Display LLDP neighbors on selected interface
hosts: all
gather_facts: true
vars:
target_interface: GigabitEthernet0/1
tasks:
- name: Display neighbors gathered with ios_facts
debug:
var: ansible_net_neighbors[target_interface]
Alas, none of the routers saw any neighbors on the target interface.
Last week I described how I configured PVLAN on a Linux bridge. After checking the desired partial connectivity with ios_ping I wanted to verify it with LLDP neighbors. Ansible ios_facts module collects LLDP neighbor information, and it should be really easy using those facts to check whether port isolation works as expected.
---
- name: Display LLDP neighbors on selected interface
hosts: all
gather_facts: true
vars:
target_interface: GigabitEthernet0/1
tasks:
- name: Display neighbors gathered with ios_facts
debug:
var: ansible_net_neighbors[target_interface]
Alas, none of the routers saw any neighbors on the target interface.
This book will be soon available
Click "read more >>" to open the Table of Contents and see the About the Book section
Continue reading