Private corporate batches, live online cohorts and 1-on-1 mentoring in plugin-chained DNS for Kubernetes and beyond — the Corefile, zones, forwarding, caching and resolution failure — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches CoreDNS as a chain rather than as a configuration file: what each plugin in a Corefile block does, the order in which they execute, and precisely which one answered a given query. Sessions cover the kubernetes plugin against a live cluster — the DNS specification for headless, named-port and ExternalName services, and the resolv.conf, ndots and search-path behaviour that produces most cluster DNS complaints — then forwarding policy and upstream health, cache and serve-stale, rewrite and template, and loop and loadbalance. The troubleshooting half is worked live with dig, tcpdump, the log and errors plugins and Prometheus metrics, through to NodeLocal DNSCache, conntrack-related UDP timeouts and scaling the deployment.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For CoreDNS that means a trainer who has run it in production — plugin-chained DNS for Kubernetes and beyond — the Corefile, zones, forwarding, caching and resolution failure — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private CoreDNS batchCoreDNS is a DNS server written in Go whose entire behaviour is an ordered chain of plugins. Its configuration file, the Corefile, declares server blocks — a zone and a port — and inside each block a list of plugins in a fixed execution order. A query enters at the top of that chain and each plugin may answer it, rewrite it, record something about it, or pass it further down. There is no monolithic configuration language and no feature set to enable: adding a capability means adding a plugin line, and building a CoreDNS that does something the standard build cannot means compiling a plugin in.
That design is why CoreDNS replaced kube-dns as the cluster DNS in Kubernetes. The kubernetes plugin watches the API server for Services, Endpoints and EndpointSlices and answers according to the Kubernetes DNS specification: A and AAAA records at service.namespace.svc.cluster.local, SRV records for named ports, PTR records for reverse lookups, headless services resolving to the individual pod addresses, and ExternalName services returning a CNAME. What a pod then experiences is shaped as much by its own /etc/resolv.conf — the nameserver, the search list and ndots:5 — as by the server, which is why the single most common cluster DNS complaint is not a CoreDNS fault at all but the four extra queries that ndots produces before an external name resolves.
Outside Kubernetes the same binary is a competent general-purpose server. The file and auto plugins serve authoritative zones from standard zone files, hosts serves entries from a hosts-file format, forward proxies to upstream resolvers with health checking and policy, cache implements TTL-aware caching with serve-stale and prefetch, and rewrite and template manipulate queries and synthesise answers. errors, log, health, ready, prometheus and trace provide the operational surface, and loop, loadbalance, autopath, bufsize and acl handle the awkward realities of production resolution.
Every Kubernetes cluster in existence runs CoreDNS, and DNS resolution sits underneath every request any workload makes. That combination makes it the highest-leverage component almost nobody on the platform team can read. When a service intermittently fails to reach another service, when latency has an unexplained five-second mode, when an external API resolves from one namespace and not another — the answer is in the Corefile, in resolv.conf, or in conntrack, and teams routinely burn days on it because nobody owns that knowledge.
The operational stakes rise as clusters grow. CoreDNS replica count, cache configuration, the forward plugin's upstream policy, NodeLocal DNSCache and the UDP behaviours of the underlying network all become capacity questions rather than defaults. Meanwhile the security surface has expanded: DNS over TLS and DNS over HTTPS to upstreams, split-horizon resolution between internal and external views, and query-level access control are now normal requirements rather than exotic ones.
And CoreDNS is not only cluster DNS. It is a genuinely capable authoritative and recursive server that teams increasingly use for internal zones, service discovery over etcd or Consul, and dynamic record generation from the platform's own state. Learning it once covers both jobs.
A deliberate refresher, because most CoreDNS problems are DNS problems. Record types and what each is actually for, the resolution path from stub resolver to authoritative server, delegation and glue, TTL and negative caching, and the transport realities — 512-byte UDP, EDNS0, truncation and TCP fallback — that explain a surprising number of intermittent failures.
Topics: Record types: A, AAAA, CNAME, SRV, PTR, TXT, NS, SOA, MX · Recursive, iterative and stub resolution · Delegation, glue records and zone cuts · TTL, negative caching and the SOA minimum · UDP 512 bytes, EDNS0, truncation and TCP fallback · Authoritative versus recursive versus forwarding servers · Reading dig output properly: flags, sections and timing · Common DNS failure signatures and what they look like on the wire
How CoreDNS is built and configured. The plugin chain model and its fixed execution order, server blocks keyed by zone and port, the difference between plugins that answer and plugins that observe, and the operational plugins that make a server diagnosable before anything goes wrong.
Topics: The plugin chain and plugin.cfg execution order · Corefile syntax: server blocks, zones, ports and stanzas · Snippets, import and reusable configuration · Which plugins answer, which modify, and which only observe · errors, log and the query logging format · health, ready and readiness in an orchestrator · prometheus metrics and what to alert on · bind, reload and configuration reload behaviour · Running CoreDNS: binary, container and systemd unit · Comparing CoreDNS with BIND, dnsmasq and Unbound
The plugins that do the work outside Kubernetes. Authoritative zones from files and from directories with automatic reload; forwarding to upstreams with policy and health checking; caching with all its subtleties; and the query manipulation plugins that solve problems no zone file can express.
Topics: file and auto: authoritative zones and dynamic zone loading · hosts: hosts-file entries with fallthrough · secondary and zone transfer with transfer · forward: upstreams, policy, health checks, max_fails and expire · DNS over TLS and DNS over HTTPS to upstreams · cache: TTL bounds, negative caching, serve_stale and prefetch · rewrite: name, type, class and answer rewriting · template: synthesising answers from a query pattern · loadbalance, loop detection and why loops happen · acl, bufsize and dnssec plugins · etcd and other service-discovery back ends
The deployment almost every attendee already runs. The kubernetes plugin and how it watches the API, the Kubernetes DNS specification in full, the default cluster Corefile line by line, and then the client half — resolv.conf, ndots, search paths, dnsPolicy and dnsConfig — which is where the behaviour people complain about actually originates.
Topics: The kubernetes plugin: API watch, Services, Endpoints and EndpointSlices · The Kubernetes DNS specification: A, AAAA, SRV and PTR records · Headless services and pod-address resolution · ExternalName services and CNAME chains · The default cluster Corefile explained stanza by stanza · Pod resolv.conf, the search path and ndots:5 · dnsPolicy: ClusterFirst, Default, None and ClusterFirstWithHostNet · dnsConfig for per-pod overrides · Stub domains and custom upstreams for internal zones · Extending the cluster Corefile safely through the ConfigMap · external-dns and publishing cluster services to real DNS
The module teams book this course for. A structured method for cluster DNS incidents, then the specific failure classes worked end to end: intermittent five-second timeouts, resolution that works from one namespace and not another, NXDOMAIN storms, loops, upstream failures and the conntrack race that produces dropped UDP responses.
Topics: A repeatable diagnostic order: pod, resolv.conf, service, CoreDNS, upstream · Reading CoreDNS logs and enabling per-query logging safely · Prometheus metrics: request duration, response codes and cache hit rate · The five-second timeout and conntrack UDP races · ndots latency and search-path expansion costs · Resolution loops and the loop plugin's refusal to start · NXDOMAIN storms and negative-cache tuning · Upstream resolver failure and forward policy behaviour · NetworkPolicy blocking DNS traffic · Capturing DNS on the wire with tcpdump inside a cluster · Node-level resolution problems that masquerade as CoreDNS faults
Running cluster DNS as capacity rather than as a default. Sizing replicas and cache, NodeLocal DNSCache and what it changes, autoscaling approaches, then transport security and access control — and finally writing and compiling a plugin when the answer genuinely does not exist yet.
Topics: Sizing CoreDNS: replicas, CPU, cache size and query rate · NodeLocal DNSCache: architecture, benefits and operational cost · Autoscaling cluster DNS and the proportional autoscaler · Topology-aware and per-node resolution strategies · DNS over TLS and over HTTPS for upstream privacy · DNSSEC validation and signing considerations · acl and rate limiting abusive clients · Multi-cluster and split-horizon resolution designs · External plugins and building a custom CoreDNS image · Writing a plugin: the ServeDNS interface and plugin ordering · Upgrading CoreDNS and testing a Corefile before rollout
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild a Corefile serving an authoritative internal zone and forwarding everything else, then prove from logs and metrics which plugin answered each query.
From inside a pod, resolve normal services, headless services, named ports via SRV, ExternalName CNAMEs and reverse PTR records, and explain each answer.
Measure external name resolution from a pod, count the search-path expansions on the wire, then cut them with dnsConfig and quantify the improvement.
Diagnose four injected DNS failures — a loop, a NetworkPolicy block, a dead upstream and a conntrack timeout — using only dig, logs, metrics and tcpdump.
Deploy NodeLocal DNSCache into a running cluster and produce before-and-after numbers for query latency, cache hit rate and CoreDNS CPU.
Deliver a tuned, monitored, documented cluster DNS layer with stub domains, secured upstreams, capacity numbers, an incident runbook and a tested rollback.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.