Resolver: MAXNS should be increased

Bug #118930 reported by Martin Emrich
28
This bug affects 5 people
Affects Status Importance Assigned to Milestone
glibc (Ubuntu)
Confirmed
Wishlist
Unassigned
Nominated for Karmic by Mattias Wadenstein

Bug Description

Currently, MAXNS (the maximum number of nameservers in /etc/resolv.conf) is set to 3. In todays times, where many people (including me) use VPN clients and such, I think this is not enough. I sometimes use two VPN clients at the same time (one to home network, one to my company, admittedly not really a common scenario), this is not enough.

So I propose to increase the value e.g. to 6, allowing three DNS servers for different connection and three backup servers.

Regards,

Martin

Revision history for this message
Martin Emrich (emme) wrote :

I just bumped into this again today (VPN server at work pushed 3 DNS servers, and my local server was then set as the unlucky fourth by network-manager). I wonder if there would be any disadvantages by increasing MAXNS?

Revision history for this message
Mattias Wadenstein (maswan) wrote :

Also, this affects ipv6 deployment. For a dual-stacked network, you would like to list both the v4 and v6 IP so that you can resolve in case either of the network stacks/routings/etc get messed up. But then you are down to 1.5 nameservers.

A larger number would make sense to me, we currently see a need of 6-8 nameserver directives in our networks..

Revision history for this message
xteejx (xteejx) wrote :

Has this been implemented yet? Does this work in Jaunty? Thank you.

Changed in glibc (Ubuntu):
importance: Undecided → Wishlist
status: New → Incomplete
Revision history for this message
Martin Emrich (emme) wrote :

No, not yet. If I further think about it, just increasing MAXNS does not entirely solve the underlying problem, as glibc seems to return "hostname not found" if the first reachable DNS server does not know it. One example:

I connect to my employer's LAN via VPN. I am assigned a second set of DNS servers, and usually an additional domain search suffix, e.g. "myoffice.company.zz". So if I e.g. try to SSH into my workstation at at work, I would need to resolve "mybox.myoffice.company.zz".

If my company's DNS server is the first in the list, it will work. But all other resolutions will go there as well (e.h. google.com or launchpad.net), which might adversely affect DNS performance. Also, my company's DNS server will certainly not know "mymediaserver.athome.zz", so I cannot reach my box at home.

If the local DNS server is first in the list (my DSL router, or my ISP's DNS server), I won't be able to resolve any box at work.

An easy fix would be to use a local DNS server that relay requests to the "right" DNS server based on domain suffix, but this would either break the entire NetworkManager thing, or would need to be integrated into it.

But as the basic problem remains, I would recommend to keep this bug on "New".

Ciao

Martin

Changed in glibc (Ubuntu):
status: Incomplete → New
Revision history for this message
xteejx (xteejx) wrote :

I shall mark this as Confirmed, and leave it as Wishlist. You can nominate to have this implemented into Karmic, or future versions by selecting "Nominate for Release" at the top of the page. Thank you.

xteejx (xteejx)
Changed in glibc (Ubuntu):
status: New → Confirmed
Revision history for this message
Mattias Wadenstein (maswan) wrote :

Martin: the domain suffix ends up in "search" field in resolv.conf or equivalent, and that's a purely client-side expansion. All that does is to append the domain or search suffix to all queries and try those first, before trying to resolve the query as given. It doesn't matter which resolver is contacted, the resolvers should all have the same domain tree starting with the root record.

Teej: The more I've thought about this, the more I end up wanting to run my own caching recursor locally. That might need some NetworkManager integration to always stick 127.0.0.1 first if there is a locally cahcing bind installed. I'm not sure this is a good default behaviour though, since it loads the common infrastructure on the internet more than using your providers caching servers...

Just increasing MAXNS won't actually hurt anything (I think), unless you locally configure in more nameserver entries. I have a couple of server networks with a few hundred servers where this would really help reliability though. Especially those where I want to have both v4 and v6 nameservers listed.

Revision history for this message
Martin Emrich (emme) wrote :

The available DNS servers do not always have the same domain tree. In my scenario above, both the company network and my home network have private DNS entries (hence the .zz domain), which only the respective DNS server(s) know about.

Let's say I am at work, and connected to my home network via VPN. The work DNS server comes first. If I ping "mymediaserver", the resolver will try all the domain suffixes, including ".athome.zz". Each expansion will be sent to the work DNS server, which won't be able to resolve any of the expansions.

My wish would be (in addition to the increased MAXNS), that glibc's resolver (or an intermediate daemon working together with NetworkManager) will move on to the next DNS servers until one can resolve the query, instead of returning right away if the first DNS server is available but cannot resolve the request.

Revision history for this message
Haven Hash (havenster) wrote :

Re: Comment #7

That would probably be better served by an intermediate daemon that you could locally install as it's probably not standard behavior that people want, but I could see use cases for it.

Having multiple IPv4 servers in addition to multiple IPv6 servers is a pretty valid use case IMO for at least increasing the MAXNS.

Revision history for this message
Leith Bade (ljbade) wrote :

This should be increased for dual-stack at least.

What happens if IPv6 get configured first? Only leaves for one IPv4 address later.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.