[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: Fwd: SRV support in konqueror ?
From:       Peter_Håkanson <peter () ipsec ! nu>
Date:       2001-07-26 22:10:17
[Download RAW message or body]

Thiago,

a few comments,

I've studied bsd/KAME getaddrinfo() and yes, srv processing _could_ be
introduced. It will however vastly complicate the code. 

I do however have a feeling that it could break existing implementations.
I don't see any signs of the kame folks even thinking about srv.

One way forward could be to implement gethostbysrv() , a not previously 
used verb. This function could be called instead of getaddrinfo
 (the socket is opened by trying the list of fqdn+port+(struct sockaddr) that is
returned by gethostbysrv() )

If, in a distant future getaddrinfo() does deal with srv, it's a matter
of a simple change to use that. But we don't have to wait for it.

Some results returned from searching with srv should stop the
process, sa a "." returned as url, thats an indication that the
service do not exist.

So theoretical, an url that is processed for url might be "unreachable"
while the same url used "without srv" could be ok. This is a
result of the rfc2782 p4, "Target" section.


There is a slight complication, the user types an url, this url 
is used to get srv record(s), which might return a fqdn+port that is
quite different from what the user typed. It's however what 
should be opened and shown.
At that moment a browser should display the original url, and any 
operations ( saving as bookmark etc) should be the original url.
( maybe not a problem with konqueror, maybe no problem at all)

Another thing that should be considered is that srv processing should be
configurable, a user that is delay-sensitive might not want the extra
lookups needed for every open ( and initially will srv be exotic ).

Now, 

how can i contribute to this ?


Regards
Peter h

On 26 Jul 2001, Thiago Macieira wrote:

> 
> 
> On Wed, 25 Jul 2001 14:48:02 +0200 (CEST), Peter Håkanson <peter@ipsec.nu> 
> wrote :
> 
> > Doing it yourself , right before the getaadrinfo() ( yes, it's
> > here it should be done, since the SRV gives back a FQDN that should be 
> used)
> > See it as a filter that is given an fqdn and returns a struct
> > containing an array of fqdn+port numbers.
> 
> getaddrinfo returns a list of full socket addresses. That is, you give it a 
> hostname and service name, or port number, and it returns to you a list 
> where that is true. Currently, it does a name resolution on the hostname 
> and searches the service name in /etc/services.
> 
> If SRV is supported, then it will do the SRV lookup. In most cases, I think 
> the DNS server will voluntarily send the additional information requested 
> along with the SRV record; that is, the A and A6 records to the related 
> hostnames, that will make a second lookup unnecessary. With that 
> information, getaddrinfo(3) can already set up the necessary socket 
> addresses. It doesn't matter that they belong to different servers.
> 
> > > However, there are two better ways:
> > > 1) wait for getresrrset function or something like that, that is to be 
> > > included in the BIND 9 API and would allow us to ask for a resolution 
> of a 
> > > certain RR kind, not necessarily A, AAAA, A6 or PTR
> > you still need to do a second lookup, since the data returned in
> > the SRV record is a port and a fqdn. So a second question is needed.
> 
> Indeed. If we send the packet ourselves, as I stated earlier, we might get 
> lucky and have the information be sent along. If else, we have to hope the 
> user has a caching nameserver close to him, because we will be doing a 
> second lookup. Actually, three more lookups, since we need A6, AAAA and A 
> records for each hostname.
> 
> > > 2) wait for the SRV API to be standardised and be supported by the 
> > > underlying resolving layer. When that is so, I trust getaddrinfo will 
> do 
> > > that for us, without the need to rewrite anything else in the code, 
> except 
> > > to have the service port ("http", for instance) be passed on to the 
> > > resolution, instead of doing getservbyname(3).
> > I don't thing getaddrinfo() will ever do this since that would
> > break existing code. And, in addition, teh resolver api _does_
> > support srv ( has done for a long time). It's only the
> > "convenience routines" ( getnnnbyzzz() that does not ( and will
> > break if adjusted)
> 
> The convenience routines are exactly what I meant when I said "underlying 
> resolving layer". I don't see how getaddrinfo(3) could be broken by that 
> change of behaviour. The code using getaddrinfo(3) should be clever enough 
> to expect that kind of thing, as well as new other protocols that we don't 
> know nothing about. Imagine when SCTP/IPv6 replaces completely TCP/IPv4. Or 
> when IPv8 is unleashed.
> 
> > Additionally, doing the resolver calls yourself will liberate
> > from different platforms peculiar ways of dealing with dns.
> 
> Indeed. In that, I couldn't agree with you more. But I think the cost of 
> that would be too high. We need a daemon to do that. Maybe a separate 
> project could be started, including a daemon with a library, with new 
> functions to replace the old convenience routines. The KDE resolver code 
> would then be adapted to use that library when available.
> 
> But, please, take into account that, after the SRV packet be sent -- and we 
> have to wait for it to return -- we have to send three queries for each 
> hostname returned (A6, AAAA and A) and wait for them before returning to 
> the caller. I already don't like the fact that we have to wait for two 
> packets to return (AAAA and A, since A6 isn't operational yet), imagine 
> what would be the cost for four packets.
> 
> Anyways, despite my pessimism, I really like the idea. It's something new 
> KDE will support and we'd be in the lead.
> --
>   Thiago Macieira - UFOT Registry number: 1001
>  thiagom@mail.com
>    ICQ UIN: 1967141  PGP: 0x8F2978D5 and 0xEA9037A5 (PGP 2.x)
>      Registered Linux user #65028
> 
> 
> 

--  
-- quote of the week 
        There's never money to do it right, but always money to do it
	again ... and again ... and again ... and again.

=========================================================================
Peter Håkanson            Phone     +46707328101       Fax +4631223190
IPSec sverige                Email      peter@ipsec.nu  
"Safe by design"             Address    Bror Nilssons gata 16  Lundbystrand
                                        S-417 55  Gothenburg   Sweden         

[prev in list] [next in list] [prev in thread] [next in thread]