Aks Deployment Skill
timothywarner/chatgptclass
Deploy and operate workloads on Azure Kubernetes Service (AKS) the safe way.
Manage DNS records, TTL strategies, and DNS-as-code automation for infrastructure.
$ npx skills add ancoleman/ai-design-components --skill managing-dns -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install ancoleman/ai-design-components managing-dns --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/ancoleman/ai-design-components.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/managing-dns .claude/skills/managing-dns && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "managing-dns" agent skill from https://github.com/ancoleman/ai-design-components/tree/main/skills/managing-dns into .claude/skills/managing-dns/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "managing-dns", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/ancoleman/ai-design-components/tree/main/skills/managing-dnsType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add ancoleman/ai-design-components --skill managing-dns -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install ancoleman/ai-design-components managing-dns --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/ancoleman/ai-design-components.git skills-src && mkdir -p .agents/skills && cp -r skills-src/skills/managing-dns .agents/skills/managing-dns && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "managing-dns" agent skill from https://github.com/ancoleman/ai-design-components/tree/main/skills/managing-dns into .agents/skills/managing-dns/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "managing-dns", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add ancoleman/ai-design-components --skill managing-dns -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install ancoleman/ai-design-components managing-dns --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/ancoleman/ai-design-components.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/skills/managing-dns .cursor/skills/managing-dns && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "managing-dns" agent skill from https://github.com/ancoleman/ai-design-components/tree/main/skills/managing-dns into .cursor/skills/managing-dns/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "managing-dns", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/ancoleman/ai-design-components.git --path skills/managing-dns--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add ancoleman/ai-design-components --skill managing-dns -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install ancoleman/ai-design-components managing-dns --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/ancoleman/ai-design-components.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/skills/managing-dns .gemini/skills/managing-dns && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "managing-dns" agent skill from https://github.com/ancoleman/ai-design-components/tree/main/skills/managing-dns into .gemini/skills/managing-dns/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "managing-dns", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install ancoleman/ai-design-components managing-dnsInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add ancoleman/ai-design-components --skill managing-dns -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/ancoleman/ai-design-components.git skills-src && mkdir -p .github/skills && cp -r skills-src/skills/managing-dns .github/skills/managing-dns && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "managing-dns" agent skill from https://github.com/ancoleman/ai-design-components/tree/main/skills/managing-dns into .github/skills/managing-dns/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "managing-dns", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add ancoleman/ai-design-components --skill managing-dns -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install ancoleman/ai-design-components managing-dns --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/ancoleman/ai-design-components.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/skills/managing-dns .opencode/skills/managing-dns && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "managing-dns" agent skill from https://github.com/ancoleman/ai-design-components/tree/main/skills/managing-dns into .opencode/skills/managing-dns/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "managing-dns", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
managing-dnsManage DNS records, TTL strategies, and DNS-as-code automation for infrastructure.
Managing DNS is an agent skill from ancoleman/ai-design-components. Manage DNS records, TTL strategies, and DNS-as-code automation for infrastructure. Use when configuring domain resolution, automating DNS from Kubernetes with external-dns, setting up DNS-based load balancing, or troubleshooting propagation issues across cloud providers (Route53, Cloud DNS, Azure DNS, Cloudflare).
Its SKILL.md is about 3.6k tokens, which your agent loads only when the skill is triggered. The skill folder holds 20 other files, including scripts and reference files (for example `examples/external-dns/helm-values.yaml`, `examples/external-dns/ingress-example.yaml` and `examples/external-dns/service-example.yaml`).
It sits in DevOps & Cloud, covering Cloud networking and Container orchestration. It works with Cloudflare, Kubernetes and Microsoft Azure. The repository describes itself as: Comprehensive UI/UX and Backend component design skills for AI-assisted development with Claude. The licence is MIT.
Read from SKILL.md and the folder at commit 76551b7. It shows what the files ask for, not the result of running them.
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Ships 2 files in scripts/ (Python and Shell), which the agent can run.
From the folder's file list and the shell code blocks in SKILL.md.
No URLs in SKILL.md.
From URLs in SKILL.md, links to its own repository left out.
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Managing DNS loads about 3.6k tokens when it runs, and up to ~28k if it reads all its reference files. Until then it costs about 82 tokens; SKILL.md has 1,070 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
The automated check noted patterns worth knowing about, such as sudo or a known installer.
sudo dscacheutil -flushcache; sudo killall -HUP mDNSRespondersudo systemd-resolve --flush-cachesAutomated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.
The full file from ancoleman/ai-design-components at commit 76551b7, republished under its MIT licence (© ancoleman). 1,070 words, ~3,603 tokens.
.claude/skills/managing-dns/SKILL.md (or your agent's skills folder). This skill also uses 14 other files; get the full folder from GitHub.Configure and automate DNS records with proper TTL strategies, DNS-as-code patterns, and troubleshooting techniques.
Guide DNS configuration for applications, infrastructure, and services with focus on:
Apply DNS management patterns when:
Address Resolution:
Email Configuration:
Service Discovery:
Delegation and Security:
Cloud-Specific:
Need to point domain to:
├─ IPv4 Address? → A record
├─ IPv6 Address? → AAAA record
├─ Another Domain?
│ ├─ Zone apex (@) → ALIAS/ANAME or A record
│ └─ Subdomain → CNAME
├─ Mail Server? → MX record (with priority)
├─ Email Authentication? → TXT record (SPF/DKIM/DMARC)
├─ Service Discovery? → SRV record
├─ Domain Verification? → TXT record
├─ Certificate Control? → CAA record
└─ Subdomain Delegation? → NS recordFor detailed record type examples and patterns, see references/record-types.md.
By Change Frequency:
Key Principle: Lower TTL = faster propagation but higher DNS query load
When planning DNS changes:
T-48h: Lower TTL to 300s
T-24h: Verify TTL propagated globally
T-0h: Make DNS change
T+1h: Verify new records propagating
T+6h: Confirm global propagation
T+24h: Raise TTL back to normal (3600s)Propagation Formula: Max Time = Old TTL + New TTL + Query Time
Example: Changing a record with 3600s TTL takes up to 2 hours to fully propagate.
| Use Case | TTL | Rationale |
|---|---|---|
| Production (stable) | 3600s | Balance speed and load |
| Before planned change | 300s | Fast propagation |
| Development/staging | 300-600s | Frequent changes |
| DNS-based failover | 60-300s | Fast recovery |
| Mail servers | 3600s | Rarely change |
| NS records | 86400s | Very stable |
For detailed TTL scenarios and calculations, see references/ttl-strategies.md.
Kubernetes DNS Automation → external-dns
examples/external-dns/Multi-Provider DNS Management → OctoDNS or DNSControl
examples/octodns/examples/dnscontrol/Infrastructure-as-Code → Terraform
examples/terraform/| Tool | Language | Best For | Kubernetes | Multi-Provider |
|---|---|---|---|---|
| external-dns | Go | K8s automation | ★★★★★ | ★★★★ |
| OctoDNS | Python/YAML | Version control | ★★★ | ★★★★★ |
| DNSControl | JavaScript | Complex logic | ★★ | ★★★★★ |
| Terraform | HCL | IaC integration | ★★★ | ★★★★ |
# Kubernetes Service with DNS annotation
apiVersion: v1
kind: Service
metadata:
name: app
annotations:
external-dns.alpha.kubernetes.io/hostname: app.example.com
external-dns.alpha.kubernetes.io/ttl: "300"
spec:
type: LoadBalancer
ports:
- port: 80Deploy external-dns controller once, then all annotated Services/Ingresses automatically create DNS records.
For complete examples, see examples/external-dns/ and references/dns-as-code-comparison.md.
AWS Route53
Google Cloud DNS
Azure DNS
Cloudflare
Choose based on:
├─ AWS-heavy? → Route53
├─ GCP-native? → Cloud DNS
├─ Azure-native? → Azure DNS
├─ Multi-cloud? → Cloudflare or OctoDNS/DNSControl
├─ Need fastest global DNS? → Cloudflare
├─ Need DDoS protection? → Cloudflare
└─ Budget-conscious? → Cloudflare (free tier) or Cloud DNS (lowest zone cost)For detailed provider comparisons and examples, see references/cloud-providers.md.
Return different IP addresses based on client location to:
Example Pattern:
Client Location → DNS Response
├─ North America → 192.0.2.1 (US data center)
├─ Europe → 192.0.2.10 (EU data center)
└─ Default → CloudFront edge (global CDN)Distribute traffic by percentage for:
Example Pattern:
DNS Responses:
├─ 90% → 192.0.2.1 (stable version)
└─ 10% → 192.0.2.2 (canary version)Automatically route traffic away from unhealthy endpoints.
Pattern:
Primary: 192.0.2.1 (health checked every 30s)
├─ Healthy → Return primary IP
└─ Unhealthy → Return secondary IP (192.0.2.2)
Failover time: ~2-3 minutes
= Health check failures (90s) + TTL expiration (60s)For complete load balancing examples, see examples/load-balancing/.
Check DNS Resolution:
# Basic query
dig example.com
# Clean output (just IP)
dig example.com +short
# Query specific DNS server
dig @8.8.8.8 example.com
dig @1.1.1.1 example.com
# Trace resolution path
dig +trace example.comCheck TTL:
dig example.com | grep -A1 "ANSWER SECTION"
# Look for TTL value (number before IN A)Check Propagation:
# Multiple resolvers
dig @8.8.8.8 example.com +short # Google
dig @1.1.1.1 example.com +short # Cloudflare
dig @208.67.222.222 example.com +short # OpenDNSFlush Local DNS Cache:
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Windows
ipconfig /flushdns
# Linux
sudo systemd-resolve --flush-cachesSlow Propagation:
CNAME at Zone Apex:
external-dns Not Creating Records:
external-dns.alpha.kubernetes.io/hostname--domain-filter=example.comFor detailed troubleshooting, see references/troubleshooting.md.
# Deploy external-dns (once per cluster)
helm install external-dns external-dns/external-dns \
--set provider=aws \
--set domainFilters[0]=example.com \
--set policy=sync
# Then annotate Services
apiVersion: v1
kind: Service
metadata:
annotations:
external-dns.alpha.kubernetes.io/hostname: api.example.com
external-dns.alpha.kubernetes.io/ttl: "300"
spec:
type: LoadBalancer# octodns-config.yaml
providers:
config:
class: octodns.provider.yaml.YamlProvider
directory: ./config
route53:
class: octodns_route53.Route53Provider
cloudflare:
class: octodns_cloudflare.CloudflareProvider
zones:
example.com.:
sources: [config]
targets: [route53, cloudflare]# Route53 with health checks
resource "aws_route53_health_check" "primary" {
fqdn = "primary.example.com"
port = 443
type = "HTTPS"
resource_path = "/health"
failure_threshold = 3
request_interval = 30
}
resource "aws_route53_record" "primary" {
zone_id = aws_route53_zone.main.zone_id
name = "api.example.com"
type = "A"
ttl = 60
set_identifier = "primary"
failover_routing_policy {
type = "PRIMARY"
}
health_check_id = aws_route53_health_check.primary.id
records = ["192.0.2.1"]
}
resource "aws_route53_record" "secondary" {
zone_id = aws_route53_zone.main.zone_id
name = "api.example.com"
type = "A"
ttl = 60
set_identifier = "secondary"
failover_routing_policy {
type = "SECONDARY"
}
records = ["192.0.2.2"]
}infrastructure-as-code:
kubernetes-operations:
load-balancing-patterns:
security-hardening:
secret-management:
Reference Documentation:
references/record-types.md - Detailed record type guide with examplesreferences/ttl-strategies.md - TTL scenarios and propagation calculationsreferences/cloud-providers.md - Provider comparison and detailed featuresreferences/troubleshooting.md - Common problems and solutionsreferences/dns-as-code-comparison.md - Tool comparison matrixExamples:
examples/external-dns/ - Kubernetes DNS automationexamples/octodns/ - Multi-provider sync with YAMLexamples/dnscontrol/ - Multi-provider with JavaScript DSLexamples/terraform/ - Cloud provider configurationsexamples/load-balancing/ - GeoDNS and failover patternsScripts:
scripts/check-dns-propagation.sh - Verify propagation across resolversscripts/validate-dns-config.py - Validate DNS configurationscripts/export-dns-records.sh - Export existing DNS recordsscripts/calculate-ttl-propagation.py - Calculate propagation time| Record | Purpose | Example |
|---|---|---|
| A | IPv4 address | example.com → 192.0.2.1 |
| AAAA | IPv6 address | example.com → 2001:db8::1 |
| CNAME | Alias to domain | www → example.com |
| MX | Mail server | 10 mail.example.com |
| TXT | Text/verification | "v=spf1 include:_spf.google.com ~all" |
| SRV | Service location | 10 60 5060 sip.example.com |
| NS | Nameserver delegation | ns1.provider.com |
| CAA | CA authorization | 0 issue "letsencrypt.org" |
| Scenario | TTL | Why |
|---|---|---|
| Stable production | 3600s | Balance speed/load |
| Before change | 300s | Fast propagation |
| Failover | 60-300s | Fast recovery |
| NS records | 86400s | Very stable |
| Provider | Best For | Key Feature |
|---|---|---|
| Route53 | AWS | Advanced routing, health checks |
| Cloud DNS | GCP | DNSSEC, private zones |
| Azure DNS | Azure | Traffic Manager integration |
| Cloudflare | Multi-cloud | Fastest, DDoS protection, free tier |
| Tool | Use When |
|---|---|
| external-dns | Kubernetes DNS automation |
| OctoDNS | Multi-provider, Python shop |
| DNSControl | Multi-provider, JavaScript preference |
| Terraform | Managing DNS with other infrastructure |
© ancoleman, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
SKILL.md and 14 other files (scripts, references) in skills/managing-dns of ancoleman/ai-design-components.
Open the folder on GitHubat commit 76551b7
Managing DNS next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Managing DNS this skillancoleman/ai-design-components | 526 | — | ~3.6k | Automated safety check: Notes | MIT | |
| Aks Deployment Skilltimothywarner/chatgptclass | 143 | — | ~916 | Automated safety check: Pass | Custom licence | |
| Aks Troubleshootingmicrosoft/GitHub-Copilot-for-Azure | 255 | — | ~3.2k | Automated safety check: Pass | MIT | |
| Kubeshark KFL2 Filter Referencekubeshark/kubeshark | 12k | — | ~3.6k | Automated safety check: Pass | Apache-2.0 | |
| Nginx To Higress Migrationhigress-group/higress | 9.5k | — | ~3.9k | Automated safety check: Pass | Apache-2.0 | |
| NGINX Ingress Controller Feature Checklistsnginx/kubernetes-ingress | 5.1k | — | ~1.4k | Automated safety check: Pass | Apache-2.0 |
timothywarner/chatgptclass
Deploy and operate workloads on Azure Kubernetes Service (AKS) the safe way.
microsoft/GitHub-Copilot-for-Azure
Debug live Azure Kubernetes Service (AKS) incidents with a read-only, evidence-first investigation.
kubeshark/kubeshark
Syntax reference for KFL2, the CEL-based display filter language used to search Kubernetes network traffic captured by Kubeshark, loaded before any filter is written.
higress-group/higress
Migrate from ingress-nginx to Higress in Kubernetes environments.
nginx/kubernetes-ingress
Gives step-by-step checklists for adding Ingress annotations, VirtualServer fields and Helm values to the NGINX Kubernetes Ingress Controller, with common gotchas.
nginx/kubernetes-ingress
Step-by-step checklist for adding a new Policy CRD type to the NGINX Ingress Controller, from the Go types and validation to config generation and templates.
ancoleman/ai-design-components
Builds AI chat interfaces and conversational UI with streaming responses, context management, and multi-modal support.
ancoleman/ai-design-components
Builds form components and data collection interfaces including contact forms, registration flows, checkout processes, surveys, and settings pages.
ancoleman/ai-design-components
Builds tables and data grids for displaying tabular information, from simple HTML tables to complex enterprise data grids.
ancoleman/ai-design-components
Creates comprehensive dashboard and analytics interfaces that combine data visualization, KPI cards, real-time updates, and interactive layouts.
ancoleman/ai-design-components
Designs layout systems and responsive interfaces including grid systems, flexbox patterns, sidebar layouts, and responsive breakpoints.
ancoleman/ai-design-components
Displays chronological events and activity through timelines, activity feeds, Gantt charts, and calendar interfaces.
Works with
Categories
Manage DNS records, TTL strategies, and DNS-as-code automation for infrastructure. Managing DNS is an agent skill from ancoleman/ai-design-components. Manage DNS records, TTL strategies, and DNS-as-code automation for infrastructure.
Managing DNS fits situations like: configuring domain resolution; automating DNS from Kubernetes with external-dns; setting up DNS-based load balancing; troubleshooting propagation issues across cloud providers (Route53.
Run `npx skills add ancoleman/ai-design-components --skill managing-dns -a claude-code`. Or copy the skill folder (skills/managing-dns in ancoleman/ai-design-components) into .claude/skills/managing-dns in your project. Claude Code loads it when a task matches its description.
Run `npx skills add ancoleman/ai-design-components --skill managing-dns -a codex`. Or copy the skill folder (skills/managing-dns in ancoleman/ai-design-components) into .agents/skills/managing-dns in your project. Codex loads it when a task matches its description.
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add ancoleman/ai-design-components --skill managing-dns -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/managing-dns, .gemini/skills/managing-dns, .github/skills/managing-dns and .opencode/skills/managing-dns in your project.
Going by SKILL.md and its folder, Managing DNS needs Python and a shell for the scripts in its folder. Our summary lists: Python 3; A Bash shell.
SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.
Our automated static check of SKILL.md found notes only (runs commands with sudo), nothing it rates as a warning. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.
Managing DNS is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
About 3.6k tokens (SKILL.md is roughly 14k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 24k tokens, read only when the agent opens those files.
Skills that share tags, products or a category with Managing DNS: Aks Deployment Skill (timothywarner/chatgptclass, 143 stars), Aks Troubleshooting (microsoft/GitHub-Copilot-for-Azure, 255 stars), Kubeshark KFL2 Filter Reference (kubeshark/kubeshark, 12k stars) and Nginx To Higress Migration (higress-group/higress, 9.5k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
ancoleman (a GitHub user) maintains it in ancoleman/ai-design-components, which has 526 GitHub stars. The repository holds 75 skills in this directory. The repository was last updated on December 11, 2025.
Source: ancoleman/ai-design-components on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.