cancel
Showing results for 
Search instead for 
Did you mean: 
JonQ
Cadet
Cadet
  • 761 Views

Client-side DNS

Hi everyone,

I'm currently exploring how client-side DNS works in Red Hat environments and wanted to open up a discussion around it. I understand that when a user initiates a DNS query, the client resolver either checks the local cache or forwards the request to a DNS server (often assigned via DHCP). This is a fundamental part of how systems resolve hostnames to IPs.

That said, I'm interested in the security side of things. Client-side DNS seems like a potential vulnerability point — especially when it comes to threats like DNS spoofing or cache poisoning. I’m wondering what best practices others here follow to harden client-side DNS configurations in Red Hat systems.

Question:
What are the most effective ways to secure client-side DNS and reduce the risk of spoofing or cache poisoning in a RHEL environment?

Appreciate any insights or tips from your experience.

Thanks!

Labels (1)
5 Replies
Trevor
Starfighter Starfighter
Starfighter
  • 744 Views

Hello JonQ,

One thing that I would do is to ensure that the systemd-resolved.service unit is enabled to start at bootup.  That should be the case in a RHEL 9.X environment.

I'm promoting this service because it uses DNSSEC - DNS with a security component.  That provides an extra level of confidence that the integrity of DNS queries are being compromised.  If you're not already familiar with DNSSEC, do yourself a favor, and do a little reading about it.  You'll see rather quickly, it's not just a lightweight extension of DNS.  You won't have to look far to find something to read - info about DNSSEC is all over the web, like a rash

Since the cache that DNS queries can be vulnerable, it's nice to that DNSEC offers some protection for the data that sits in that cache!  I love it that DNSSEC expands DNS with public-key cryptopgraphy!  But again, the real biggee for me is the protection DNSSEC offers against cache poisoning.

Anyway, that's my pennies worth.  There will be others following me, that will offer much more elevated suggestions!!!

 

Trevor "Red Hat Evangelist" Chandler
JonQ
Cadet
Cadet
  • 641 Views

Hey Trevor,

I appreciate the reply and definitely agree with you about the value of DNSSEC. I’ve started looking more into how system resolution works in RHEL 9.x, especially its handling of DNS over TLS and DNSSEC validation. It’s definitely a big step forward from traditional resolver setups.

The point about cache poisoning is exactly why I brought this up; even with local caching improving performance, it opens the door for bad actors if left unsecured. 

Thanks again for your input.

– JonQ

Trevor
Starfighter Starfighter
Starfighter
  • 634 Views

Thanks JohQ for your comments, and thanks again for your initial query!!!!

Trevor "Red Hat Evangelist" Chandler
Chetan_Tiwary_
Community Manager
Community Manager
  • 593 Views

@JonQ DNSSEC was introduced to combat DNS spoofing. One should definitely use end to end encryption, DNS firewalls, randomized port numbers , disable DNS recursion or use only protected corporate netwrks, DoT ( DNS over TLS ) or DoH ( DNS over HTTPS ) , monitoring , use VPN , flushing your DNS caches regularly , shorter TTLs force more frequent authoritative lookups, minimizing the attack surface by limiting how long bad data persists.

Trevor
Starfighter Starfighter
Starfighter
  • 583 Views

Just to add a little to Chetan's explanation, I want to make sure that everyone understands the TTL that he's referring to is the TTL that determines how long a DNS record can/will be cached by a DNS resolver before the resolver must make another query to the authoritative server. 

TTL also refers to a value in a field of an IP packet header.  This TTL value determines how many hops a packet can make before being discarded by a router - essentially preventing packets from looping indefinitely in the network.

The values used for DNS records are in the range from 300 to 86400, and these values refer to seconds (i.e. 300 seconds   86400 seconds).  The values used for the number of hops that a packet can traverse, range from 0 to 255.   

Note:  You don't even have the ability to mistakenly configure a TTL value larger than 255 for the number of hops!!!  Don't take my word - try it!!!   The command used to set the TTL value for the number of hops is:
sudo  sysctl -w net.ipv4.ip_default_ttl=<NEW_TTL_VALUE>

 

The file used to permanently set the TTL value for DNS records is /etc/named.conf !!!!!

 

Trevor "Red Hat Evangelist" Chandler
Join the discussion
You must log in to join this conversation.