'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:       Thiago Macieira <thiago.macieira () kdemail ! net>
Date:       2004-10-30 14:32:54
Message-ID: 200410301133.03245.thiago.macieira () kdemail ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]

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.

>> 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"?

>> 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.

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.
	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", 
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

- 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? 

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.

>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.

>> 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.

-- 
  Thiago Macieira  -  Registered Linux user #65028
   thiago (AT) macieira (DOT) info
    ICQ UIN: 1967141   PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

[Attachment #5 (application/pgp-signature)]

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

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