1748089 Members
4979 Online
108758 Solutions
New Discussion юеВ

ipv6 question

 
SOLVED
Go to solution
Mike_Swift
Advisor

Re: ipv6 question

Matti

 

I understand from the RFC perspective, but the DNS team has sadi that the load generated from this particular client is too much to handle for the DNS server (AAAA queries). Is there anything we could do from the Linux side (OS Config) that could stop this load on the DNS Server?? Please advice..

 

Best Regrads

 

Mike

Mike_Swift
Advisor

Re: ipv6 question

Hello Matti

I also noticed on this Linux Server which generates lot of bogus ipv6 AAAA quesries, there are 7 sub-domains listed in the /etc/resolv.conf search string. . Every time the тАЬsshтАЭ command is executed, there are 8 bogus IPv6 тАЬAAAAтАЭ queries issued (which all fail), before finally the valid IPv6 тАЬAтАЭ query is issued (and successfully resolves). When the тАЬsshтАЭ command is being used in monitoring scripts or some other transaction-oriented manner, there will be an exponential number of bogus IPv6 тАЬAAAAтАЭ queries issued before the eventual IPv4 тАЬAтАЭ query is issued. This is a problem with some applications running on the Linux servers. It also generates something of a DoS attack on production DNS servers. Strange it happens only on Linux running Redhat 4 and 5. All other OS seems OK

Best Regards

Mike
Matti_Kurkela
Honored Contributor

Re: ipv6 question

You might want to specify

AddressFamily inet   #IPv4 only

 either in your global /etc/ssh/ssh_config or in user-specific ~/.ssh/config file. That will stop the ssh client from making the AAAA queries.

 

For other applications, you must find other application-specific solutions.

 

And if your resolv.conf search string causes the system to query for so many variations of the name, perhaps you should be using fully-qualified names when setting up your monitoring scripts or other "transaction-oriented" processes. Normally the cost of one DNS query is fairly small, but if you have a long search list and you know you will be making a lot of connections, a simple optimization (i.e. qualifying the names once at configuration time instead of repeatedly at runtime) would be wise.

 

For monitoring systems and other "heavy users" of DNS, you might even consider setting up a local caching-only DNS server on the query-generating host. You would set it to forward all queries (that cannot be answered with the already-cached information) to your regular DNS servers. If the TTL values of your regular DNS servers are sensible, the cache should end up answering most of the recurring DNS queries, minimizing the DNS-related network traffic required.

MK