linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jim Rees <rees@umich.edu>
To: David Howells <dhowells@redhat.com>
Cc: jmorris@namei.org, keyrings@linux-nfs.org,
	linux-nfs@vger.kernel.org, linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-cifs@vger.kernel.org,
	linux-api@vger.kernel.org, libc-alpha@sourceware.org
Subject: Re: [PATCH 2/2] Define ENONAMESERVICE and ENAMEUNKNOWN to indicate name service errors
Date: Thu, 9 Feb 2012 08:44:29 -0500	[thread overview]
Message-ID: <20120209134429.GC6663@umich.edu> (raw)
In-Reply-To: <17614.1328781889@redhat.com>

David Howells wrote:

  Jim Rees <rees@umich.edu> wrote:
  
  >   Define ENAMEUNKNOWN to indicate "Network name unknown".  This can be used to
  >   indicate, for example, that an attempt was made by dns_query() to make a query,
  >   but the name server (e.g. a DNS server) replied indicating that it had no
  >   matching records.
  > 
  > Would this be the same as NXDOMAIN?  That is, does it mean the name server
  > couldn't find a record, or does it mean that the record doesn't exist?
  
  Is there a way to tell the difference?  Can you store a negative record in the
  DNS?  Or is it that the DNS has records for the name, just not records of the
  type you're looking for (eg. NO_ADDRESS/NO_DATA from gethostbyname())?

It's an important distinction to the resolver if you want to avoid dns
hijacking.  See rfc2308.  There doesn't seem to be a way to tell the
difference from the gethostbyname call, which was designed before this was a
problem.  The on-the-wire dns query protocol does make the distinction.

I suspect kernel dns clients won't need to know the difference, but I think
it's useful if we decide on and document the meaning of the error codes.
Maybe the answer is that ENAMEUNKNOWN means the same as a HOST_NOT_FOUND
from gethostbyname().

  reply	other threads:[~2012-02-09 13:44 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-08 12:29 [PATCH 1/2] Define ENOAUTHSERVICE to indicate "Authentication service unavailable" David Howells
2012-02-08 12:29 ` [PATCH 2/2] Define ENONAMESERVICE and ENAMEUNKNOWN to indicate name service errors David Howells
2012-02-08 14:15   ` Jim Rees
2012-02-09 10:04   ` David Howells
2012-02-09 13:44     ` Jim Rees [this message]
2012-02-10 20:02     ` David Howells
2012-02-08 15:48 ` [PATCH 1/2] Define ENOAUTHSERVICE to indicate "Authentication service unavailable" Joseph S. Myers
2012-02-08 23:53 ` Valdis.Kletnieks
2012-02-09 10:01 ` David Howells
  -- strict thread matches above, loose matches on Subject: below --
2012-06-01  3:32 Trond Myklebust
2012-06-01  3:32 ` [PATCH 2/2] Define ENONAMESERVICE and ENAMEUNKNOWN to indicate name service errors Trond Myklebust
2012-03-22 13:35 [PATCH 1/2] Define ENOAUTHSERVICE to indicate "Authentication service unavailable" David Howells
2012-03-22 13:35 ` [PATCH 2/2] Define ENONAMESERVICE and ENAMEUNKNOWN to indicate name service errors David Howells
2011-03-07 15:02 [PATCH 1/2] Define ENOAUTHSERVICE to indicate "Authentication service unavailable" David Howells
2011-03-07 15:02 ` [PATCH 2/2] Define ENONAMESERVICE and ENAMEUNKNOWN to indicate name service errors David Howells
2011-03-07 16:00   ` Alan Cox
2011-03-08 15:09   ` David Howells
2011-03-08 15:25     ` Alan Cox
2011-03-08 16:37     ` David Howells

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120209134429.GC6663@umich.edu \
    --to=rees@umich.edu \
    --cc=dhowells@redhat.com \
    --cc=jmorris@namei.org \
    --cc=keyrings@linux-nfs.org \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).