From kde-devel Sat Oct 30 14:32:54 2004 From: Thiago Macieira Date: Sat, 30 Oct 2004 14:32:54 +0000 To: kde-devel Subject: Re: DNS based service discovery Message-Id: <200410301133.03245.thiago.macieira () kdemail ! net> X-MARC-Message: https://marc.info/?l=kde-devel&m=109914683423829 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0090511289==" --===============0090511289== Content-Type: multipart/signed; boundary="nextPart1453287.bYz0hOTu0f"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart1453287.bYz0hOTu0f Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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= =20 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=DFball Fileserver.local" is the same as "fussball=20 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=FCller-Website.m=FCller.org jos=E9.macieira.info Tell me, just by looking at them: how do we encode each one? If what you're= =20 asking is to be followed, the "M=FCller-Website" part would be UTF-8 encode= d,=20 while "m=FCller.org" is ACE-encoded. And "jos=E9.macieira.info" would be=20 encoded with ACE entirely. I am imagining the following situation: 1) user goes to dnssd:/ and selects "Web sites" and it is configured (for=20 whatever reason) to list m=FCller.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=20 *cannot* be with a redirection to "http://M=FCller-Website.m=FCller.org",=20 because it would result in the behaviour I listed below: What happens if the user types in Konqueror "M=FCller-Website.m=FCller.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: =2D KResolver needs more flags: =3D> one for name-to-name PTR queries =3D> one for generic SRV queries =3D> one for SRV queries which prepends the service and protocol =2D the first two would UTF-8 encode the first part of the nodename, in all= =20 cases, with care being taken for dots escaped with backslashes. The rest of= =20 the domain goes ACE if it's uDNS, or UTF-8 if it's mDNS. =2D someone who wants to support DNS-SD and normal resolution (SRV- and non= =20 SRV-based) would be required to write the following records: . IN PTR .. .. IN SRV ... .. IN SRV ... . IN A ... example: ; DNS-SD _http._tcp IN PTR M=FCller-Website._http._tcp M=FCller-Website._http._tcp IN SRV 0 0 80 www ; RFC 2782 (SRV): _http._tcp.M=FCller-Website IN SRV 0 0 80 www ; old-style: M=FCller-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= =20 non SRV-based. In the first two, is encoded in UTF-8; in the=20 latter two, it's encoded in whatever method is used (ACE for uDNS, UTF-8=20 for mDNS). So you see why I say it's stupid to encode in UTF-8 in uDNS?=20 Also note that DNS-SD inverted the already-established SRV record.Since=20 SRV-based resolution is set forth in RFC 2782, whenever DNS-SD conflicts=20 with the established RFC, the RFC overrules, until such time as DNS-SD=20 becomes an RFC of its own and RFC 2782 is replaced. This is not open for=20 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= =20 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. =2D-=20 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 --nextPart1453287.bYz0hOTu0f Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBg6YfM/XwBW70U1gRAt6OAJwOqreKndGpya2097FFbyRBwjq6TQCgoghr 0OIsuWsR6jhL5DCqHUAAzac= =khoz -----END PGP SIGNATURE----- --nextPart1453287.bYz0hOTu0f-- --===============0090511289== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << --===============0090511289==--