Tech Talk Augusta — August Meetup Recap

Tech Talk Augusta — August Meetup Recap: DNS, AI, and Solving the Right Problem

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.

Jason: Troubleshooting DNS

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.

Is it actually DNS?

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.”

Learning to read 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 validated

We 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.

DNS has a lot of caches

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.

Real-world troubleshooting

The talk became especially useful when Jason walked through realistic failure scenarios.

For example:

“The internet is down for me.”

• Ping works.
• dig times out.
• The configured resolver points at the router.
• A direct query to another resolver works immediately.

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.

The organizational side of DNS

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:

1. Your registrar
2. Your DNS host
3. Your web or mail host

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:

• Lower TTLs before the migration.
• Recreate every record at the new provider.
• Be careful with CNAMEs at the domain apex.
• Verify delegation.
• Don't assume that querying the new DNS server directly proves that the migration is working.

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: Apoointly — Applying AI to Healthcare

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:

• Missed calls
• Long response times
• No-shows
• Language barriers
• Difficult scheduling processes
• Overwhelmed staff
• Increasing staffing costs

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.

An AI receptionist

Apoointly is positioned as a HIPAA-aligned AI receptionist designed to operate around the clock.

The system focuses on four major areas:

• Call management
• Scheduling and intake
• Follow-up
• Insights

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: Not Every Problem Needs Code

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.

Start with the business case

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.

What do you need from me?

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.

When speed works against clarity

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:

• Risks
• Assumptions
• Issues
• Dependencies
• Resources
• Stakeholders
• Quality control

We also touched on tools and techniques such as RAID logs and Ishikawa diagrams for understanding the causes and dependencies behind problems.

Three Talks, One Theme

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.