public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "binki at gentoo dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sources.redhat.com
Subject: [Bug libc/2099] Support for SRV records in getaddrinfo
Date: Tue, 20 Mar 2012 14:26:00 -0000	[thread overview]
Message-ID: <bug-2099-131-HCwPCMgRNi@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-2099-131@http.sourceware.org/bugzilla/>

http://sourceware.org/bugzilla/show_bug.cgi?id=2099

Nathan Phillip Brink (binki) <binki at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |binki at gentoo dot org

--- Comment #7 from Nathan Phillip Brink (binki) <binki at gentoo dot org> 2012-03-20 06:42:41 UTC ---
(In reply to comment #4)
> Actually, it won't work.  RFC 2782 specifies that all SRV records have a host
> name attached.  It's not just information about the port.  Given that, what would
> 
>    getaddrinfo ("host1.domain", "someserv", ....)
> 
> mean if the SRV record for
> 
>   _someserv._tcp.domain

I'm quite sure that when the SRV spec says "domain", it is referring to the
full domain. Not the domain in the sense of domainname(1). I.e., you would
search for _someserv._tcp.host1.domain instead of _someserv._tcp.domain. Am I
misreading the spec here?

> has the host name "host2.domain" associated?  It makes no sense.  There can only
> be a functions which queries the SRV records based on the service name alone. 
> Trying to embed this into getaddrinfo is no good.

If the word "domain" in the SRV spec is interpreted properly, this objection
makes no sense. Sure, it is likely enough that getaddrinfo("domain",
"someserv", ...) will not tell you to go ahead and connect directly to
"domain". But getaddrinfo("host1.domain", "someserv", ...) would likely not hit
any SRV records at all and fall back to the traditional DNS lookups.

The main objection to this change would be that programs would suddenly break
if getaddrinfo(node, serv, ...) would suddenly tried to find the appropriate
host for accessing serv at node. In reality, few domains set SRV records for
services where there is no program support. So, most programs which would be
affected by this change would behave no differently if getaddrinfo() started
actually looking up services instead of just hosts.

It would be really nice to get SRV support in applications with no added
complexity. Maybe the interface provided by ruli
http://nongnu.org/ruli/tutorial/getaddrinfo.html is a way to get these
advantages without departing too far from getaddrinfo()...

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


  parent reply	other threads:[~2012-03-20  6:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-2099-131@http.sourceware.org/bugzilla/>
2011-01-09 11:08 ` quentusrex at gmail dot com
2011-01-09 23:10 ` quentusrex at gmail dot com
2012-03-20 14:26 ` binki at gentoo dot org [this message]
2012-07-29 22:51 ` psimerda at redhat dot com
2012-11-19 14:52 ` psimerda at redhat dot com
2012-12-18 14:29 ` psimerda at redhat dot com
2012-12-19 23:39 ` bugdal at aerifal dot cx
2014-02-07  2:52 ` [Bug network/2099] " jsm28 at gcc dot gnu.org
2020-12-21  2:45 ` jscott at posteo dot net
2005-12-30 23:26 [Bug libc/2099] New: " fredrik at dolda2000 dot com
2006-01-15 16:28 ` [Bug libc/2099] " aj at suse dot de
2006-01-15 17:15 ` fredrik at dolda2000 dot com
2006-05-03  6:46 ` drepper at redhat dot com
2006-05-06  3:28 ` drepper at redhat dot com

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=bug-2099-131-HCwPCMgRNi@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=glibc-bugs@sources.redhat.com \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).