Hey guys,

Actually when you get an NXDOMAIN reply you can just stop resolving that domain. Basically there are 2 types of "negative" replies in DNS:

NODATA: basically this is when you don't get an error (NOERROR in dig), but not the actual data you are looking for. You might have gotten some CNAME data but no A or AAAA record (depending on what you wanted obviously). This means that the actual domain name does exist, but doesn't have data of the type you requested. The term NODATA is used in DNS RFC's but it doesn't actually have its own error code.

NXDOMAIN: This is denoted by the NXDOMAIN error code. It means that either the domain you requested itself or the last target domain from a CNAME does not exist at all (IE no data whatsoever) and there also isn't a wildcard available that matches it. So if you asked for an A record, getting an NXDOMAIN means there also won't be an AAAA record.

The above explanation is a bit of an over simplification cause there are also things like empty non-terminals which also don't have any data, but instead of an NXDOMAIN actually return a NODATA (in most cases, there are some authoritative servers that don't do it properly). But the end result is that you can pretty much say that when you get NXDOMAIN, there really is nothing there for you so you can just stop looking (at least at that the current server).

-Robin-

On 10/20/2015 10:25 PM, Willy Tarreau wrote:
On Tue, Oct 20, 2015 at 10:20:50PM +0200, Baptiste wrote:
On Tue, Oct 20, 2015 at 9:09 PM, Lukas Tribus <luky...@hotmail.com> wrote:
I don't know. I'm always only focused on the combination of user-visible
changes and risks of bugs (which are user-visible changes btw). So if we
can do it without breaking too much code, then it can be backported. What
we have now is something which is apparently insufficient to some users
so we can improve the situation. I wouldn't want to remove prefer-* or
change the options behavior or whatever for example.
Ok, if we don't remove existing prefer-* keywords a 1.6 backport sounds
possible without user visible breakage, great.

lukas
Ok, just to make it clear, let me write a few conf examples:
- server home-v4 home-v4.mydomain check resolve-prefer ipv4
  => A then AAAA (failover on NX)
- server home-v4 home-v4.mydomain check v4only
  => A only (stop on NX)

If both 'resolve-prefer ipv[46]' and 'v[46]only' are set, whatever
combination, then, v[46]only applies, but configuration parsing may
return a warning.
Yes, but please avoid the warning, it makes it unconvenient to edit
configs. You may for example have "resolve-prefer ipv4" in the
default-server directive, and having it warn because one of your
servers has v4only is annoying. BTW, the v4only and resolve-prefer
should also be used during the initial resolving phase performed
by getaddrinfo() but that's for a future patch :-)

Willy




Reply via email to