(Slightly OT) No authorative server available - what response?

[Kevin Darcy]

The only legitimate choices here are: a) keep retrying in hopes of
getting an answer, or b) return SERVFAIL to the client. RFC 1034's
"recommended priorities for resolver design" (see section 5.3.3) are, in
order:

1. Bound the amount of work.

2. Get back an answer if at all possible

3. Avoid unnecessary transmissions

4. Get the answer as quickly as possible.

(Note that a recursive nameserver is functioning as a "resolver" here,
albeit not a *stub* resolver). It's up to the implementation how many
retries to make, and the timeouts associated with each retry, before
giving up and returning SERVFAIL to the client. Note that the client may
time out before it even gets the SERVFAIL, so the values here are driven
largely by the prevailing timeout/retry parameters that client/stub
resolvers use.

Under no circumstances should a resolver return NXDOMAIN or
NODATA (NOERROR with 0 answers) just because it can't reach the
nameservers for the zone. That's an outright *lie* and the lie could end
up getting cached by other resolvers and cause all sorts of problems.

In the case of a "complex" query, like an MX record query or when a CNAME
is encountered, it is acceptable to return "partial" results if the full
answer is not obtainable, e.g. an MX answer without the corresponding
A records in the Additional Section, or a CNAME or CNAME chain in the
Answer Section without the corresponding canonical name. The client
resolver is then free to try to complete the query. (Unfortunately,
I think most stub resolver implementations are incapable of completing a
CNAME chain and most apps using them would probably interpret such a
response as "no such name").


- Kevin

Michael Kjorling wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I was thinking - what would happen in this worst possible scenario (at
> least with regards to DNS)?
>
> 1. Client sends a query to a root server for foo.com
> 2. Root server responds with ns1.foo.com and ns2.foo.com, and their IP
> addresses
> 3. ns1.foo.com is unreachable
> 4. ns2.foo.com is unreachable
>
> Since the resolver got a bunch of NS records, the domain technically
> is there (otherwise there would be no records, right?), but it cannot
> use this information to figure out the IP address of foo.com (which is
> what the user asked for). It gets even worse if you aren't asking for
> an A record, but rather e.g. a MX record, which may very well require
> further lookup to be usable.
>
> What will be reported by the resolver? Host not found? Server failure?
> Simply a timeout? Or what?
>
> If this is in the manual, please excuse my ignorance and feel free to
> point me in the right direction.
>
> Michael Kjörling
>
> - --
> Michael Kjörling - michael at kjorling.com - PGP: 8A70E33E
> "We must be the change we wish to see" (Mahatma Gandhi)
>
> ^..^     Support the wolves in Norway -- go to     ^..^
>  \/   http://home.no.net/ulvelist/protest_int.htm   \/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE7H5x1KqN7/Ypw4z4RAu99AJ9l+L5lyQPgrN2Kw1PDCzncs7TZ0gCgswsW
> CylaCgn6C4ulI8Z9n2xX+ms=
> =WK7U
> -----END PGP SIGNATURE-----