In our everlasting quest to strengthen security around the Kentik Platform, we're happy to introduce WebAuthN today – a growing web browser native Web Authentication standard with many benefits over prior ones.
Until today, we offered Multi-Factor Authentication (MFA) to our users via these 2-Factor (2FA) methods: Time-based One-Time Password (TOTP, also known as Authenticator App-based Tokens) and hardware keys such as YubiKeys from the FIDO Alliance.
While these methods offer a better security level than plain user/password authentication and we strongly encourage our users to adopt 2FA, the standards have evolved to new, more secure methods that we are now proud to offer to our user base.

Let's see what this is all about!

Authentication security concepts

Let’s take a look at modern improvements recently achieved in the domain of Web Authentication.

"Something you are"

In authentication, there are three categories of credentials (or factors) used to verify a user's identity. They are: something you know (like a password), something you have (such as a security token), and something you are (like a fingerprint). Using a combination of two or more of these factors is known as multi-factor authentication (MFA). 

Modern Authentication favors something you are with the use of Biometric Methods: Fingerprint Recognition (known as Touch ID for Apple users, or Hello for Microsoft users), or camera-based Face Recognition (known as Face ID for Apple users, Face Unlock for Android users). While a malevolent actor can phish something you know, steal something you own, it is much harder to spoof something you are when it is based on your unique biometric markers.

Public/Private keys

Another recent security improvement on the web is the adoption of browser-based Public-key credentials extensions (WebAuthN, which we’ll talk about in a minute, uses this scheme).

In a public-key based Authentication model, a pair of keys (public key and private key) are used in authentication. The remote authenticating system stores a user's public key (visible to anyone) and a credential ID, not a password. The private key, which is the secret half of the key pair, is stored securely on the user's device, not on the server. 

This design offers significant security benefits compared to traditional passwords: 

• Security by design: The server has no shared secret with the user that could be compromised. The public key is useless to an attacker on its own.
• Phishing resistance: The private key is cryptographically bound to a specific website domain, so it cannot be used on a fake phishing site to trick the user.
• Data breach protection: If a server's database is breached, the attacker can only steal public keys and credential IDs, which cannot be used to impersonate a user.

What is WebAuthN ?

WebAuthN is the latest version of the FIDO Alliance’s open authentication standard (FIDO2). It is an effort to bring strong 2FA to the web and is based on the W3C’s Web Authentication API, which is supported by many, if not most, common web browsers.
In a nutshell, WebAuthN brings these attractive improvements to prior 2FA technologies:

• it is the leading open authentication standard on the web: it is widely adopted, can be audited, and comes natively in most recent browsers
• it adds public-key cryptography to most existing 2FA methods, securing them further (with the exception of TOTP, which becomes the least secure 2FA method)
• because most recent browsers are tightly integrated with the hardware and OS they run on, it brings Biometrics (aka "something you are") to web authentication, alleviating the need to procure physical keys

What does it look like in Kentik Portal ? 

To enable WebAuthN we've made changes to the User Profile section's Authentication tab, surfacing these new 2-Factor capabilities now offered to users - 

but before we dive into these changes, let's summarize the levels of security now offered by Kentik Portal per Authentication method and outline their respective security levels:

Multiple 2-Factor Methods per user

Kentik still offers each user to configure multiple 2-Factor Authentication methods in their User Profile – this allows users to configure backups or configure alternatives between when they're at home and on the go. A user can configure and name as many of these as they desire.

These Authentication methods are now split in 3 separate tables (click the button on the top right of each table to add one):

• (1) Legacy Methods: 
  Least secure 2-Factor - will include your Legacy Hardware Keys such as YubiKeys, and your TOTP.
  You can re-create a new entry for your YubiKey in the Security Keys table, which will make them WebAuthN compliant (more secure): we strongly encourage you to do so !
  Because Time-Based One-Time Passwords aren't compatible with the WebAuthN standard, they will stay in this "Legacy Methods" section, we advise to move away from them.
  That being said, they're still a better alternative than no 2-Factor.
  
  
• (2) Device Authenticators:
  These are Hardware/OS level biometrics such as Apple's Touch ID and Microsoft Hello - they are considered to currently be the most secure methods, because they correspond to the "Something you are" principle.
  Registration of these via the Enroll Device button is natively supported by most recent browsers using a common UI.
  
  
• (3) Security Keys:
  These authentication factors include both Hardware USB Security Keys (such as Yubikey, or Google's Titan- both FIDO and FIDO2), both natively WebAuthN compliant -with FIDO2, they come with a PIN code.
  In addition to these keys, you can also configure a mobile based (both iPhone or Android) WebAuthN compliant methods in this section. In this clever method, a QR code is presented to the user at login time, triggering the device's biometric native UI to proceed with a Face ID / Face Unlock verification.

When multiple methods are available, authentication will always prioritize the Device Authenticators first, via a native browser prompt. If other WebAuthN methods have been configured by the user such as a YubiKey or an iPhone/Android Mobile Authentication - these will be available as part of the same prompt by choosing Other Methods. (see screengrab below)

As a user, what should I do ?

This choice depends a lot on the Security policy dictated by your company, which you should always conform to.
With that said, as outlined by the previous diagram in this article comparing the security level of the various available methods, Kentik highly suggests that you always opt for the most secure one possible, which is encompassed in the following recommendations:

• Always use 2-Factor – plain password authentication is unsafe.
• If your current 2-Factor is TOTP, you should consider adding a WebAuthN compatible one now – in this case HW based biometrics are your best choice since they’re available on any recent laptop or mobile device.

• If your current 2-Factor is a YubiKey, you should consider

  • re-registering it in the Security Keys section to add WebAuthN to it
  • adding a biometrics-based Device Authenticator if your computer allows it, it will be prioritized over the YubiKey
• Try to have at least two methods configured, in case you lose one of them or if it happens to get compromised – so that you won't lose access to Kentik portal.

As someone who is responsible for Kentik App Security, what should I do ?

As a security focused Kentik Administrator,  you want to increase Authentication Security for all your SaaS Applications, Kentik being no exception. To make your job easier of migrating users from a weaker 2FA to a stronger, WebAuthN 2FA, we added a filter in the Company Settings > Users screen to identify users based on their 2FA settings:

Additionally, a new Custom button appeared at the top right of the Users table, which will let you add two new columns in - to help Kentik admins track 2 Factor adoption within their company:

• Strong Authenticators: number of WebAuthN 2Factor Authenticators configured
• Weak Authenticators: number of non-WebAuthN 2Factor Authenticators configured

What's next for Kentik Portal Authentication ?

Making 2-Factor authentication mandatory

At this juncture, we're seriously considering this further step as the next one. There are a couple ways we could go about doing so: 

• In a first step, we could expose a company-wide setting where your security staff could set it as mandatory for your tenant to respect your company's security stance, with a disabled default to make for a smooth and easy transition.
• In a second step, we could make it mandatory by default and bake it in the user registration/onboarding process.

One of the reasons we haven't made a call about it yet is that a lot of customers have a centralized AAA strategy to access their SaaS apps that goes through centrally managing it via SSO, with the implication that the underlying SSO should take care of the multi-factor strategy.

Do let us know what your preference would be on the matter!

Do let us know what your preference would be on the matter !

A note on Password-less authentication

One of the eventual benefits of WebAuthN is password-less authentication such as PassKeys: this standard converges towards allowing users to register to a web application without providing the proverbial insecure password and exclusively replace it in our user profiles data store with the generated Public Key from the initial WebAuthN challenge.
While this is one of our long term goals, password-less is not part of this release, as it requires us to completely overhaul the user registration process.

Still, do let us know if password-less authentication is something you'd like to see in the product in the future.

One of Kentik's core missions has always been to help our users make sense of their infrastructure, taking the front seat in the Network Intelligence space by constantly enriching the Telemetry our users send us to ingest.
This release adds new BGP dimensions and filters for you and the AI Advisor to leverage as you are trying to make sense of the Infrastructure at the edge of your network.

Let's dive into it!

How do BGP enrichments work ?

When registering devices in Kentik, you have the option of establishing a BGP session with our SaaS or OnPrem cluster. These sessions, v4 and v6 are configured as iBGP Route Reflector Clients.
As we ingest your Netflow/Sflow/IPFIX telemetry, we map the SRC_IP and DST_IP from the flow fields with the Routing Data gathered from these iBGP sessions and enrich flows with such useful dimensions as

• Source or Destination ASN (Autonomous System)
• AS Path for the outgoing traffic
• Next-Hop, 2nd Hop, 3rd Hop ASN from the AS Path
• BGP Communities
• A variety of VRF related dimensions
• ...

If you don't peer directly with our clusters for a Kentik-registered device, you can choose to adopt the routing table of another device, or use a Generic Routing Table to access part of that information.

Alternate enrichment of Source or Destination ASN with a Generic Table

If your device is iBGP-peered with Kentik's SaaS cluster, the Source and Destination ASN enriched in your Netflow/Sflow/IPFIX records will be in priority based off your own routing data, but will fall back to a Generic Routing table if your own routing information has no entry for a given Source or Destination IP. This Generic Routing table is built on MTR Route Dumps from the RouteViews Project (courtesy of University of Oregon).

Two things are worth noting

• you should never send default routes (0.0.0.0/0) in your iBGP Route Reflector Client sessions to Kentik, as it will attract all source or destinations that you do not have a route for
• if your device does not have an iBGP session established with Kentik, we'll use this Generic Routing table for your entire traffic

In some cases, using your BGP tables to enrich your traffic may hide an issue: if these are intermittent, you may see Source or Destination ASN flapping around for the same prefix, which can result in a long and often sterile investigation.

We are now solving that problem by adding two Source ASN (Generic Table) and Destination (Generic Table) to the default BGP available dimensions. These are additions and do not replace the original Source ASN and Destination ASN dimensions: they can be used together within the same Data Explorer query to more rapidly track down such situations. You'll find them in the Dimensions selector as depicted in the screenshot below:

Collapsed AS Path

Every prefix learned by a BGP peer contains an AS Path, which indicates the series of Networks (identified by their Autonomous System Number, aka ASN) - this path is used heavily in the BGP decision mechanism to determine which route is best when multiple are received, and the length of the AS Path is a key decision factor: the BGP route election process will select the one with the fewer hops (ASN Hops) in the AS Path attribute of the prefix received.

Most BGP-speaking Networks are homed Multi-Homed: this means they have at least two upstream providers to receive the Full Internet Routing table from. While it is trivial BGP-wise to influence which of the two upstream providers you want to select for any destination prefix, it is much more complicated (if not impossible) to influence which one of the two upstreams you want to receive traffic from in priority.
To achieve that, BGP offers a mechanism named AS Path Prepending which basically allows any ASN along the path to insert their ASN in the AS Path attribute of the prefix as a last-ditch effort have their upstreams prefer another route for this prefix (Last ditch because this is far from being an efficient method).

In the following example, AS62775 which originates two /48 IPv6 prefixes and announces them to AS396955 who in turns announces them to AS1299. AS396955 prepends their ASN one more time when announcing to AS1299, signaling that they want to prevent AS1299 to use them to reach these AS62775 prefixes.

As a way to de-noise the above picture, we've come up with a bunch of additional of AS Path related dimensions that contract the AS Path when it sees duplicate hops in it - these dimensions come in addition to the existing AS Path related ones, as can be seen on the screenshot below

Using AS Path (Collapsed) instead of AS Path as a Group By dimension will yield the following sankey for the same prefixes

IPv6 Flow Labels

IPv6 flow labels are a 20-bit field in the IPv6 header used to identify packets belonging to the same traffic flow, allowing routers to provide special handling for them. A flow is a sequence of packets from a specific source to a destination. The label is used to efficiently handle and prioritize these flows, such as for real-time voice or video, without inspecting the entire packet payload.

As this relatively new standard gets adopted more broadly (it allows routers along the path to perform special handling of a Flow between a Source and a Destination marked with these labels), a number of our customers have asked us to include this additional dimension to our flow enrichment process. This has now been done as part of the below highlighted dimension.

Unfortunately, as any new networking standard tends to be vendor specific, our initial support for IPv6 Flow Labels is currently limited to Juniper Networks devices.
Please do let us know if your current use warrants to extend this support to other vendors by raising a feature request with your Customer Success specialist and we'll add it to our list of future work to consider for future roadmaps.

Interface Classification is one of the key components of Kentik Portal. It makes interface-based enrichments possible. 

• Network Boundary gives users an easy way to limit queries to traffic entering or exiting the network without the risk of double-counting.
• Connectivity Type adds both technical and business context to traffic moving into or out of these interfaces, making it easier to identify, for example, which interfaces are used for peering or transit at the network's edge.
• Provider (or Customer) automatically enriches any traffic on these interfaces with the name of the connected customer.

As Interface Classification is a load-bearing feature used throughout many of the portal workflows, including our AI Advisor (which relies on it to understand the tasks an interface performs), we have always kept the list of available values for Connectivity Types locked in.

Today we're adding three more values to Connectivity Types that our users have requested over the past years.

Management

Management Interfaces are quite self-explanatory. This Connectivity Type describes the port on a device that is connected to the Management network, which is the common network used to administer devices. It comes with the default Connectivity Type of “Internal” but can be set to “External” in the case of externally based OOB monitoring.

DDoS Mitigation: Cloud or Appliance

DDoS Mitigation Cloud or Appliance Connectivity Types are intended to classify interfaces that sit in front of a DDoS mitigation platform, whether it is an appliance-based internal solution (A10, Radware, Corero, etc.) or an external scrubbing DDoS Mitigation Cloud provider.

In one case, the default Network Boundary will be “Internal,” and in the latter, it will be “External.” The DDoS Mitigation: Cloud Connectivity Type pairs well with the Provider/Customer Interface Classification attribute, and users can programmatically set it using capture groups if a consistent Interface Description policy permits them to do so.

What's next ?

As we mentioned earlier, Interface Classification is tightly controlled, as it needs to provide consistent behavior across all areas of the Kentik Portal where it is utilized. This doesn't mean we are not open to suggestions from you regarding any additional required values, especially for Connectivity Types, that help better describe the taxonomy of your network.

Do let us know if you would like us to add more of these in the future.

In May 2025, we introduced a major update to Kentik Portal's search capabilities. Since it was well received by our users, we queued an iteration to make it even more useful to you. Back then, we had added: Favorites, Most Recent Dashboards and Saved Views, and categorized lists of result matching common Portal objects such as ASNs, Devices, Interfaces....

With the recent launch of Kentik AI Advisor, we’ve started weaving AI more deeply into the Kentik experience. This new release continues that journey—this time by bringing AI into how you move around Kentik.

We're excited to introduce Navigation to Search, infused with awesome Kentik AI Superpowers!

What is Navigation Search ?

Kentik Portal delivers broad set of screens and functionalities, more than the average Kentik user can memorize - while our Navigation menu has served us well all these years to present these in an orderly fashion to our users, a few elements have come into play:

• Users have gotten accustomed to functionalities provided by the Apps they use every day: amongst others, apps like "Spotlight" on MacOS, but also a large amount of SaaS apps have made it easier for users to navigate to functionalities or applications using a central search component
  
• AI has become the new popular kid in town, and users are now expecting to be able to prompt their way into navigating towards functionalities
• Portal functionalities have moved from one section of the portal to another section, with our users sometimes struggling to follow recent changes
• A lot of new customers have joined Kentik that aren't yet fully familiar with its broad array of screens and functionalities

This is where Search comes to the rescue: starting today, you can now leverage our newly updated Search feature to navigate to portal screens: whether this makes navigation faster for the Keyboard, or helps you orient yourself towards a screen/feature which name you don't fully remember, just enter what you are looking for and Search will fetch it for you and report it in the new Navigation section of the results, as shown below.

Additional cheat-code: this whole operation can be entirely piloted via keyboard shortcuts

1. CMD + / (MacOS) or CTRL + / (Windows or Linux) will spawn the search box
2. ↑ and ↓ keys will allow you to navigate the search results - while ← and → will let you switch between Favorites, Recents and Search Results tabs.
3. Enter will navigate to the selected result
4. Esc once will clear the search field, while Esc twice, will both clear the search field and leave the Search context

Great, but where's the AI in there?

Having heard this from more than one prospect or customer in the past, we have become increasingly aware that Kentik Portal packs more features than we're able to teach you in the course of a trial period. It's therefore not uncommon that our customers have a feature they've been toured that they want to use and simply can't find it anymore past the trial period in our dense feature set. 

Here's an example:

Your Kentik Solutions Engineer toured you around the "Connectivity Costs" feature, which allows you to enter your IP Transit Contracts and track your Transit costs in Kentik Portal.
Only you can't remember what the name of the workflow, you just remember that there was a very neat feature demo'd to you that allowed you to track these.

AI-Powered Navigation search to the rescue!

Another example: 

You remember being told that you needed to further classify your Interfaces in Kentik in order to get more accurate Data Explorer query results, but you just can't remember how the function is called and where to access it

Again, AI-Powered Navigation Search to the rescue!
Even better, we are showing the main Knowledge Base article for this feature as part of the Search Result displayed !

What about the Security aspects?

• Search will not return results that a user does not have access to (based on RBAC and UserLevel configuration)
• Each search action kicks multiple search jobs in parallel and appends results as they come back to the browser:
  • new: A basic search process against a dictionary of all Screens and their Title and Descriptions.
    👍 This process does not leverage AI and doesn't go through Prompting, it will yield results regardless to your company's enablement settings for AI
  • new: An AI search based on the same Site Map. For this process our Site Map contains a sample description paragraph for all the screens in Kentik Portal provided as additional context to the prompt
    🧠 This process is AI-powered, it is only enabled if your AI is enabled with your company.
  • the legacy database search against Object Instances such as Dashboards, Saved Views, ASNs, IPs, Sites, Devices ...
    👍 This process doesn't leverage AI and doesn't go through Prompting, it will yield results regardless to your company's enablement settings for AI

Hey Kentik Users!

We've heard you, and we're excited to announce a small-but-mighty quality-of-life update for your Alerting page! Say goodbye to manual refreshes and hello to the latest alerts, delivered automatically!

What's New?

You can now select a refresh frequency directly on the Alerting page! We've added new refresh rate options—1, 2, or 5 minutes—that will cause the page to periodically reload and pull in the most recent alerts automatically. 

Why This Matters for You

This feature is a game-changer for anyone who needs eyes on the latest network health status, especially your NOC and SOC teams! 

• Real-time Visibility: Automatic reloading means you're always looking at the freshest data without lifting a finger, ensuring you catch critical events as soon as they happen. 
• Operational Efficiency: Free up your operators' attention from hitting the refresh button so they can focus on what matters: analyzing and responding to the alerts! 

This update is all about making your workflow smoother and ensuring your teams can receive the most recent alerts automatically. 

Head over to the Alerting page today and set your preferred refresh rate! Let us know what you think—we're always working to make your Kentik experience better! 

Since launching Kentik Market Intelligence (KMI) in 2022, it's grown to become one of our service provider customers' all time favorites (press release linked here). 

In a nutshell, KMI uses the global routing table to classify the peering and transit relationships between ASes, and to identify the providers, peers, and customers for any AS in any geography.

Today, we're extending KMI's reporting functionalities to include Report Subscriptions – a feature already available in multiple workflows in Kentik Portal. 

A few words on Kentik Market Intelligence (KMI)

KMI is a dynamic database that leverages public BGP routing data (amongst others from the RouteViews project) to determine, rank, and classify relations between all networks that make up the Internet. It's essentially a living database of the ever-changing relations between networks. 

Kentik's service provider customers, notably IP Transit providers and customers, rely on KMI for a couple of key use cases: 

• Competitive Rankings: Leverage KMI's benchmarking and rankings to evaluate how well connected your ASN/network is to other networks in any geographic region. Use these insights to compare your network’s connectivity against competitors, and highlight strong rankings to promote your network’s performance and market position with objective, third-party data.
• Sales Prospecting: Uncover all upstream transit providers for any prospect network and understand each provider’s share of the network’s advertised IP space. Identify the downstream customers of those transit providers — including which are single-homed (critically dependent on a single upstream) — to build targeted sales prospecting lists.
• Competitive Intelligence: Receive daily insights on shifting interconnection relationships across the global internet. Track how competitor rankings evolve, monitor customer gains and losses, and stay ahead of changes that may signal new business opportunities or threats.

As our service provider customers have grown to rely on this intelligence to prospect, highlight their competitive advantages, and monitor competitors, a common request has been the ability to generate recurring weekly or monthly reports for their internal teams on specific networks or regions of interest. That’s exactly what today’s new feature delivers.

Pulling Report Subscriptions into KMI

The Share button in the top-right corner of the KMI interface just got more powerful. It now offers a set of report subscriptions designed to help service providers stay ahead of the connectivity competition and keep track of the latest changes in the marketplace. To access these new subscriptions, head to the Subscriptions tab in the updated Share modal window.

For now, all of these reports will generate spreadsheet compatible reports in the form of .csv files, and are currently capped to the 100 Top Entries. All reports leverage the current/freshest KMI data at the exact time they are being generated.

Convenience Features for Report Subscriptions

In addition to the report-specific configuration options, Report Subscriptions let users fine-tune how their reports are delivered:

• File naming: Choose how the attached CSV file should be named, with suggestions on how to include the date in the filename.
• Recipients: Specify who should receive the report by adding To, Cc, and Bcc recipients for each scheduled delivery.
• Scheduling: Define when and how often the report should be generated and sent — daily, weekly, monthly, or on the last day of the month — including the exact time of delivery.

All the Report Subscriptions configured in Kentik Portal across the available workflows can be displayed in the Company Settings > Report Subscriptions section of Kentik Portal, where they can be edited once they've been created.

We're thrilled to announce a major granularity enhancement to Role-Based Access Control (RBAC) in Kentik. Gone are the days of broad, level-based access for Kentik Alerting and Protect. Build custom roles to define exactly who can create, view, update, or delete your critical alert policies, notification channels, and DDoS mitigations.

What's New?

We've rolled out a comprehensive set of permissions and custom roles specifically for Alerting and Protect. This update moves these modules into our modern RBAC framework, replacing the legacy user-level system for these features. 

You can now create custom roles with specific permissions for:

• Alerts: Control who can read, acknowledge, or clear alerts. 
• Alerting Policies: Manage permissions for creating, reading, updating, and deleting policies. 
• Notification Channels: Define who can create, read, and update notification channels. 
• DDoS Mitigation: Assign precise control over who can create, view, start, stop, and delete mitigations. 
• BGP Announcements: Manage who has the ability to view or withdraw BGP announcements. 

Why It Matters

This is a huge step forward for security and operational efficiency. By creating custom roles, you can ensure your team members have exactly the access they need to do their jobs.

• Enforce Least Privilege: Grant NOC operators the ability to acknowledge alerts without letting them change policies.
• Delegate with Confidence: Allow your network security team to manage mitigations without giving them full administrator access to your entire Kentik account.
• Streamline Workflows: Create roles like "Mitigation Authors" or "Alerting Policy Viewers" to match your team's specific responsibilities. 

Take control of your user permissions today!

Ready to fine-tune your team's access? Administrators can head over to the Manage RBAC Roles page in your Organization Settings. From there, you can click "+ Create a Role" to start building your own custom roles with these powerful new permissions! 

Your existing permissions within Alerting and Protect were all migrated to this new RBAC schema and existing role access will be unaffected by this update.

We're excited to see how you use these new controls to secure and streamline your network operations. As always, let us know if you have any feedback!

Hello Kentik Users

Ever felt like you were searching for a needle in a haystack of alerts? We get it. When you need to find a specific alert, you need to find it now. That's why we're thrilled to announce a massive power-up to the search bar on the Alerting page!

What's New?

Previously, your search was limited to the Alert Policy name and its dimensions. While useful, we knew it could be better. You can now use the search bar to find alerts based on any information contained within the alert details.

Just type what you're looking for, and we'll scan everything. This includes, but is not limited to:

• Site names or geographic locations
• NMS device details like manufacturer or model
• Alert Policy labels
• Specific IP addresses, ASNs, or tenants
• Mitigation IDs or Alert IDs

Why You'll Love It 

This enhancement is all about speed and precision, helping you slash the time you spend managing alerts.

• Find What You Need, Faster: No more clicking through complex filter combinations. Instantly pinpoint the exact alerts you're looking for with a simple text search.
• Deeper, Quicker Investigations: Need to find all "Critical" alerts from your "Cisco" routers in the "Ashburn" site? Just type it in. Troubleshooting has never been this easy.
• Improved Workflow: Spend less time hunting and more time resolving. This intuitive search experience streamlines your entire incident response process.

Jump into the Alerting page today and take the new, supercharged search for a spin.

Happy searching!

🔓 Unlocked: More Power and Flexibility for Custom Webhook Headers!

Get ready to level up your integrations! We've heard your feedback and have supercharged our Custom Webhook notification channels. Gone are the days of being restricted in how you format your headers.

Previously, Custom Headers were limited to 

Authorization and headers prefixed with x-. We're excited to announce that we've removed this limitation, giving you far more freedom and flexibility!

What's New?

We've enhanced our Custom Webhook notifications to support a much broader range of HTTP headers. You can now send notifications with virtually any custom header required by your third-party systems, internal tools, and automation scripts. The only headers we restrict are standard ones that could conflict with the HTTP connection itself.

This means you can now seamlessly integrate with services that require specific header formats for authentication, routing, or metadata without needing complex workarounds.

Why It Matters

This update is all about making your life easier and your integrations more powerful.

• Ultimate Flexibility: Integrate Kentik alerts with an even wider universe of applications and services. If your endpoint needs a X-Custom-Auth-Token, My-App-Identifier, or any other unique header, you can now add it directly.
• Streamlined Automation: Simplify your incident response playbooks. Send alerts with the exact headers your systems expect, making your custom scripts and downstream tools more robust and easier to maintain.
• Enhanced Security: Securely pass custom API keys, tokens, or other authentication data in the precise header format required by your infrastructure.

Get Started!

Putting this new flexibility to work is easy:

1. Navigate to 
   Settings > Notification Channels in the Kentik portal. 
2. Click 
   Add Notification Channel and select 
   Custom Webhook, or edit an existing webhook channel by clicking the pencil icon.
3. In the 
   Custom Headers section, click the + Add button and input any key-value pair you need for your custom headers. 

That's it! We can't wait to see the powerful and creative integrations you build with this new capability. Happy automating!

In a previous announcement, we introduced Universal Agent as a foundational piece of software to further operationalize and unify our collection of telemetry agents under a single umbrella. With the benefits of this approach, we are hard at work porting all of our existing collection agents towards this new paradigm as Universal Agent Capabilities. 

Today, we will be talking about our OTT Service Tracking DNS tapping agent, and how as an existing OTT Service Tracking user you can migrate these DNS taps at no operational cost and start benefiting as early as today from their highly improved operability. Read on!

OTT Enrichments, how do they work?

Firstly, let's review how Kentik's OTT Service Tracking functionality works. Contrary to DPI (Deep Packet Inspection) which requires you to deploy DPI hardware at your network edge to map your subscribers' consumed applications, Kentik offers a creative, lightweight, and operationally and financially efficient method to perform the same task: users deploy a DNS Tapping Agent, in addition to exporting network flow telemetry from their devices, and our True Origin engine maps DNS query responses to traffic based on an ever-growing library of domain name patterns to directly color this flow telemetry with OTT describing attributes – OTT Service, OTT Category, OTT Provider.

Until today, the DNS tap collection was instrumented via our former host monitoring agent kprobe in a specific mode that did not export host telemetry, but only DNS query/responses. The drawbacks of this legacy approach are:

• kprobe is not observable in Kentik Portal, both from a DNS tapping activity metrics standpoint and an out-of-the box alerting standpoint
• kprobe upgrades are manual, requiring deployment for each new version
• combining host monitoring and DNS tapping in the same telemetry agent introduces a shared bug surface between two very different functions
• in cases where kprobe couldn't be installed on a DNS resolver, deploying it as a DNS tap required a complicated launch command

Taking a hard look at these constraints, we are now happy to offer a much more operable and easy-to-deploy solution via a new Universal Agent capability, so let's look at the benefits now!

So what's new ?

Trivial deployment of DNS taps, under the hood upgrades

As of today, all Universal Agents deployed offer a new capability aptly named DNS OTT Tap which replaces kprobe's legacy role of conveying DNS query/responses to our flow ingest clusters for OTT-related flow enrichments. Installing it will download the capability's core binary and enable it.

Once the capability is enabled, users will be able to configure the few parameters, and the Universal Agent host will keep the OTT DNS Tap capability in its latest version without any further operational attendance needed.

Easy promiscuous mode

You can now select a specific host interface to capture DNS queries and responses. In addition, if you’re using port mirroring, port spanning, or tunneling to send this traffic from the server-facing port to another host, you can enable Promiscuous Mode on that interface to capture it, as shown in the diagram below.

OTT DNS Tap metrics

Every Universal Agent capability comes with its own set of metrics. The OTT DNS Tap is no exception to this principle: clicking on the capability [Details] button will show two charts – one for the amount of DNS query/response funneled by the capability to Kentik's ingest clusters, and a second on the number of query/responses discarded, to monitor for any issue related to the capability's specific job.

As can be seen on both screenshots, both metrics are instantly available in Metrics Explorer for further reporting, so that administrators of the DNS Tap fleet can quickly troubleshoot. Here's an example of a single Metrics Explorer query showing the number of query/responses per seconds that an entire fleet of DNS Taps is performing:

At last, we've improved the [Configuration] screen of our Service Provider > OTT Service Tracking workflow to now include all deployed OTT DNS Taps with their agent status health. 

What does the migration path to the OTT DNS Tap Universal Agent Capability look like?

The process to switch from a standalone kprobe setup to Universal Agent's OTT DNS Tap capability couldn't be safer and simpler. It consists of the below steps:

1. On each DNS server where kprobe is currently running on, deploy Universal Agent. (Knowledge Base Article)
   The process is trivial: enter the command line on the server's shell and follow the instructions until Kentik Portal offers you to register the newly detected agent.
2. Once Universal Agent is installed successfully on the DNS server, install the OTT DNS Tap capability. (see Knowledge Base entry here)
3. Configure the OTT DNS Tap capability to your liking – default settings should cover most of the installs.
4. At this point both kprobe and the OTT DNS Tap will be sending the same data to Kentik's DNS ingest cluster, and it does not affect the OTT enrichment data at all.
5. Verify that the OTT DNS Tap capability is receiving DNS Query/Responses from the capability's drawer in the Universal Agent UI. (see screenshot in the OTT DNS Tap metrics paragraph in this post)
6. 🎓 Congratulations, you are done: you can now safely uninstall kprobe and proceed to the next DNS server.

The simplicity of the migration path relies in the fact that both kprobe and the new Universal Agent capability can coexist without causing any OTT Flow enrichment issues.
👌 So, go ahead and migrate your kprobe instances right away and benefit from the improved observability of our Universal Agent as soon as today!

Note: if any doubt whether the kprobe instance running on a DNS server is used as a Legacy DNS Tap or to generate host flow telemetry, the following command on the host will help disambiguate - if it yields any result, then there's a kprobe running on this instance needing to be replaced with a Universal Agent OTT DNS Tap capability:  ps auxw | grep kprobe | grep dns

What comes next ?

In one of our next releases, we'll be adding out-of-the-box alerting for both Universal Agents and capabilities, sending you notifications whenever your fleet of telemetry agents is encountering issues.

In addition, we have a really neat slate of improvements that we are also going to bring to life in the near future, amongst others: new agents such as Flow Proxy (fka kproxy) will be ported over under Universal Agents, as well as some large scale deployment options, and also an initial set of HA (High Availability) options – so watch this space!