'Re: DNS based service discovery'

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

List:       kde-devel
Subject:    Re: DNS based service discovery
From:       Jakub Stachowski <stachowski () hypair ! net>
Date:       2004-10-30 20:44:17
Message-ID: 200410302244.18025.stachowski () hypair ! net
[Download RAW message or body]

Dnia sobota, 30 pa¼dziernika 2004 16:32, Thiago Macieira napisa³:
> Jakub Stachowski wrote:
> >> You mean "ability to use UTF-8 instead of ACE for mDNS". IDN means
> >> "International Domain Name". If your UTF-8 domain isn't ASCII, then it's
> >> internationalised and, therefore, IDN.
> >
> >Nope, I meant for both uDNS and mDNS. And for both PTR and SRV (noticed
> > that after reading DNS-SD spec more carefully).
>
> I don't agree, see below. Remember that DNS-SD is still a draft. It can be
> changed and I believe it will before it becomes an RFC.
>

But I have no idea what and how will be changed. So I can only act according 
to its current state.

> >> At least, that's how I read things. Making mDNS not follow the IDN
> >> Nameprep guidelines would wreak havoc and I, quite frankly, refuse to
> >> implement it that way.
> >
> >Implementing it any other way would make it useless - incompatible with
> >specification and every existing implementations.
>
> So we agree that "Fußball Fileserver.local" is the same as "fussball
> fileserver.local"?

Sorry, I'm really not sure at this moment. I have to experiment some more.

>
> >> Also note that PTR queries over normal DNS must be ACE-encoded. I don't
> >> care what DNS-SD says: if you transmit over the normal DNS servers, it
> >> has to be ACE, not UTF-8.
> >
> >From DNS-SD spec: " DNS recommends guidelines for allowable characters for
> >host names [RFC 1033][RFC 1034][RFC 1035], but Service Instance Names are
> > not host names."
> >
> >DNS-SD is _not_ DNS - it only happens to reuse existing infrastructure -
> > DNS servers.
>
> [here is a mental exercise for me]
>
> Imagine the following two uDNS queries (for SRV):
> 	Müller-Website.müller.org
> 	josé.macieira.info
>
> Tell me, just by looking at them: how do we encode each one? If what you're
> asking is to be followed, the "Müller-Website" part would be UTF-8 encoded,
> while "müller.org" is ACE-encoded. And "josé.macieira.info" would be
> encoded with ACE entirely.

Exactly.

>
> I am imagining the following situation:
> 1) user goes to dnssd:/ and selects "Web sites" and it is configured (for
> whatever reason) to list müller.org
> 2) kio_dnssd must send this query:
> 	_http._tcp.xn--mller-kva.org.		IN PTR?
> 3) the answer comes back as:
> 	_http._tcp.xn--mller-kva.org. 		IN PTR
> 		M\195\188ller-Website._http._tcp.xn--mller-kva.org.
> 4) if the user accesses that site, the name-resolver code must run this:
> 	M\195\188ller-Website._http._tcp.xn--mller-kva.org.	IN SRV?
> which could result in:
> 	M\195\188ller-Website._http._tcp.xn--mller-kva.org.	IN SRV
> 		0 0 80 www.xn--mller-kva.org.

Here ends DNS-SD operation and normal DNS starts:

4.5)
> 	www.xn--mller-kva.org.			IN A		192.168.1.2
> 5) I have no idea how Konqueror gets communicated that from kio_dnssd. It
> *cannot* be with a redirection to "http://Müller-Website.müller.org",

kio_dnssd implements DNS-SD so it should perform steps 1-4 and redirect to 
www.xn--mller-kva.org. Konqueror will get http://www.müller.org:80 and use 
normal DNS. 

> because it would result in the behaviour I listed below:
>
> What happens if the user types in Konqueror "Müller-Website.müller.org"?
> 1) Konqueror will try a SRV resolution:
> 	_http._tcp.xn--mller-website-wob.xn--mller-kva.org.	IN SRV?
> with the answer:
> 	_http._tcp.xn--mller-website-wob.xn--mller-kva.org	IN SRV
> 		0 0 80 www.xn--mller.kva.org.
> 	www.xn--mller-kva.org.			IN A		192.168.1.2
> 2) So Konqueror connects to that site.
>
> My conclusions are:
> - KResolver needs more flags:
> => one for name-to-name PTR queries
> => one for generic SRV queries
> => one for SRV queries which prepends the service and protocol

I think that it needs one flag: "DNS mode" or "DNS-SD mode". In first mode 
everything is ACE encoded (for uDNS),  SRV request has <service>.<instance> 
order. In second mode: <instance> is UTF-8 encoded, rest is IDN,  SVR is 
<instance>.<service> order. 
This two modes are never mixed so this flag could be argument for constructor.

>
> - the first two would UTF-8 encode the first part of the nodename, in all
> cases, with care being taken for dots escaped with backslashes. The rest of
> the domain goes ACE if it's uDNS, or UTF-8 if it's mDNS.
>
> - someone who wants to support DNS-SD and normal resolution (SRV- and non
> SRV-based) would be required to write the following records:
> 	<Service>.<Domain>			IN PTR	<Instance>.<Service>.<Domain>
> 	<Instance>.<Service>.<Domain>	IN SRV	...
> 	<Service>.<Instance>.<Domain>	IN SRV	...
> 	<Instance>.<Domain>			IN A		...
>
> example:
> 	; DNS-SD
> 	_http._tcp				IN PTR	Müller-Website._http._tcp
> 	Müller-Website._http._tcp	IN SRV	0 0 80 www
>
> 	; RFC 2782 (SRV):
> 	_http._tcp.Müller-Website	IN SRV	0 0 80 www
>
> 	; old-style:
> 	Müller-Website			IN CNAME www
> 	www					IN A		192.168.1.2
>
> the first two are DNS-SD, the third is SRV-based resolution, the fourth is
> non SRV-based. In the first two, <Instance> is encoded in UTF-8; in the
> latter two, it's encoded in whatever method is used (ACE for uDNS, UTF-8
> for mDNS).
>
> So you see why I say it's stupid to encode in UTF-8 in uDNS?

It is quite messy. I will ask Stuart Cheshire for comment on IDN/UTF-8 
weirdness. 

>
> Also note that DNS-SD inverted the already-established SRV record.Since
> SRV-based resolution is set forth in RFC 2782, whenever DNS-SD conflicts
> with the established RFC, the RFC overrules, until such time as DNS-SD
> becomes an RFC of its own and RFC 2782 is replaced. This is not open for
> negotiation.

We have two clearly separated modes: DNS and DNS-SD. Queries for these two are 
never mixed so there will never be dilemma which syntax should be used.

I understand that you don't want to pollute DNS resolver class with code 
violating DNS standards.  In this case DNS-SD stuff can be in separate class 
(like DNSSD::Resolver for example) reusing private parts of normal resolver 
(for example kresolvermanager.cpp, kresolverstandardworkers.cpp). I have just 
started learning inner working of KResolver so what I said above about 
reusing may be incorrect.

>
> >After reading some more (mDNS spec, Apple's mDNSResponder code, GNOME
> > code, mdnsd code) I think that reimplementing daemon is not best idea:
>
> [snip]
>
> >As you can see, now I am for using libhowl and mDNSResponder as mDNS
> > low-level API for KResolver (exactly as libresolv is used for uDNS).
> > Publishing part should be kept in kdnssd.
> >Single disadvantage is that it adds external dependency (probably optional
> > if someone doesn't care about mDNS) instead of internal.
>
> Agreed.
>
> And if mDNSResponder isn't running, we can still send "legacy DNS" queries
> to the mDNS multicast address and receive answers. We will not cache those.

Kind of fallback? Good idea.

>
> >> However, it has not gone away completely. It's still available as Q3Dns.
> >> The warning on it is "This class is part of the Qt 3 compatibility
> >> library. It is provided to keep old source code working. We strongly
> >> advise against using it in new code.", though.
> >
> >So using it means linking to one more library?
>
> I don't know. It would seem that way.

That is bad, I don't think that linking to one more deprecated library is good 
idea. 

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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