# Tech Talk Augusta — August Meetup Recap > Source: > Published: 2026-08-14 16:06:21+00:00 Our August Tech Talk brought together three very different talks, but they shared a surprisingly common thread: **understanding the problem before jumping to the solution**. Jason took us deep into DNS troubleshooting, Anish introduced Apoointly, an AI receptionist designed for healthcare practices, and Chris challenged us to reconsider one of our favorite instincts as technologists: writing code. DNS is one of those technologies that most developers interact with constantly without necessarily thinking much about how it works—until something breaks. Jason's talk was a practical tour through diagnosing DNS problems and, more importantly, figuring out whether a problem is actually DNS in the first place. He started with the fundamentals: recursive resolvers, authoritative servers, TTLs, and common record types. We also covered some of the less obvious roles of DNS records. For example, TXT records are heavily used for security, authentication, and proving ownership, while SOA records describe important information about a DNS zone. One of the most useful troubleshooting principles was deceptively simple: **Before troubleshooting DNS, make sure the problem is actually DNS.** If a domain resolves correctly but the server isn't responding, the problem may be the IP address, networking, or the service itself. Jason walked through a number of tools that can help answer that question: `dig` — the detailed, powerful option for understanding exactly what DNS is doing.`host` — a great quick one-liner.`nslookup` — widely available and useful when you need something that's everywhere.`resolvectl` — particularly useful for understanding the resolver configuration on Linux systems using systemd.`Resolve-DnsName` — the PowerShell equivalent on Windows.And then there was one of the more memorable quotes of the night: “dig uses a plus sign for arguments. Don't ask me why I didn't write it.” `dig` A `dig` response can look intimidating, but Jason broke down the pieces that actually matter. The **status** tells you whether the query succeeded. The **flags** tell you what happened along the way: `aa` — authoritative answer`rd` — recursion desired`ra` — recursion available`ad` — DNSSEC validatedWe also covered several important response codes: `NXDOMAIN` — the domain does not exist.`SERVFAIL` — the server couldn't successfully answer the query.`REFUSED` — the server deliberately refused to answer.Options such as `+short` , `+trace` , and `+norecurse` can turn `dig` into a much more targeted troubleshooting tool. `dig -x` is useful for reverse lookups. Another important lesson was that DNS propagation is complicated because **there isn't necessarily one cache**. Depending on the environment, caching can occur in the browser, operating system, local resolver, and upstream recursive resolver. Not every machine has every layer, either. And there's an important limitation: **You can only clear caches that you control.** That is one reason DNS migrations can be frustrating. You can change the authoritative record immediately, but somebody else's resolver may still have the old answer cached. Which leads to an excellent operational rule: **Don't shut down the old website until the DNS team has confirmed that the record has changed.** Jason also covered search domains, trailing dots, hosts files, split-horizon DNS, DNS-over-HTTPS, captive portals, and the difference between UDP/53 and TCP/53. The talk became especially useful when Jason walked through realistic failure scenarios. For example: **“The internet is down for me.”** `dig` times out.That points toward a local resolver problem rather than an internet outage. Or consider an email bounce where the website still works. The bounce might specifically identify an MX record problem. From there, you can use `dig` to determine whether an MX record exists and whether its target resolves. We also got a reminder of an important DNS rule: **An MX record must point to a hostname—not an IP address and not a CNAME.** Perhaps the biggest source of DNS confusion isn't technical at all. When you own a domain, there may be three completely different companies involved: Understanding who controls what means following the delegation rather than assuming that the company you bought the domain from controls everything. This becomes particularly important during migrations. Jason's migration advice included: If the new server gives the correct answer but customers don't see it, the problem may be delegation rather than the zone itself. And, appropriately, Jason ended with a haiku. We unfortunately weren't fast enough to capture it. Anish shifted the conversation from infrastructure to an emerging application of AI: **the AI receptionist**. The problem Apoointly is targeting is straightforward. Healthcare practices are struggling with an increasingly demanding communication and scheduling workload. Patients may encounter: The result is a frustrating experience for both patients and healthcare providers. Anish described a survey suggesting that scheduling can consume a significant portion of staff time—leaving people spending much of their day on the phone rather than on other valuable work. Apoointly is positioned as a HIPAA-aligned AI receptionist designed to operate around the clock. The system focuses on four major areas: The goal isn't simply to have an AI answer the phone. It's to have the system actually complete useful work. A typical flow looks something like: **Patient call → AI understands request → Action completed → EMR updated** That could include answering questions with appropriate clinical information, handling prescription refill requests, collecting intake information, verifying patient identity, and scheduling appointments. The key piece is integration with the practice's existing EMR rather than creating another disconnected system for staff to manage. It was a good example of an AI application where the value isn't necessarily the model itself. The value comes from **connecting the model to an existing workflow and allowing it to take meaningful action.** Chris brought us back to a lesson that is easy for technologists to forget: **Sometimes the best technical solution is not to build anything.** With a background spanning product management and engineering, Chris talked about the difficulty of solving problems when the initial request is ambiguous. One of the biggest challenges is context. When someone brings you a problem, it's tempting to immediately jump into solution mode. But doing that can mean solving the wrong problem extremely efficiently. Chris described his role somewhat like “urgent care for manufacturing”—coming into situations where something isn't working and figuring out what actually needs to happen. One of the strongest themes was repeatedly asking: **What's the business case?** Before building something, understand why it matters, who needs to be involved, what needs to happen, and when it actually matters. Chris emphasized mapping the process and making sure you're touching the relevant value streams. Then start with the simplest possible solution and iterate. His decision hierarchy was particularly memorable: **Rule → Process → Low-code → Custom code** In other words, don't reach for custom software until you've established that a rule, process change, or low-code solution won't solve the problem. Another useful communication technique was simply asking: **“What do you need from me?”** That question can turn an ambiguous conversation into an actionable one. Instead of assuming what the other person wants, identify the actual decision, resource, information, or action needed. Chris also discussed triage: choosing the most effective solution rather than automatically choosing the most sophisticated one. Agile environments create another challenge. Sometimes stakeholders want something immediately, while the people doing the work don't yet have enough clarity to know exactly what should be built. Chris suggested that when we choose speed over clarity, we should at least make the assumptions explicit. That means paying attention to: We also touched on tools and techniques such as RAID logs and Ishikawa diagrams for understanding the causes and dependencies behind problems. At first glance, DNS troubleshooting, an AI medical receptionist, and project management don't have much in common. But they all pointed toward the same engineering lesson: **Don't jump to the implementation before understanding the system.** Jason showed this through DNS troubleshooting. Before changing records, determine what is actually failing and understand which layer is responsible. Anish showed it through AI. The interesting part isn't simply putting an LLM on the phone; it's integrating AI into an existing workflow so that a patient's request can actually result in a completed action. Chris made the principle explicit: before writing code, understand the business case, map the process, and choose the simplest solution that creates value. Whether you're debugging a domain, building an AI product, or responding to a request from a stakeholder, the same question keeps coming back: **What problem are we actually trying to solve?** That's a pretty good lesson to take away from this month's Tech Talk.