[Development] QTBUG-10481: Adding support for DNS SRV lookups

[Jeremy Lainé]

Hi Peter,

On 11/01/2011 11:27 AM, Peter Hartmann wrote:
> While I like the API and the naming proposed by Shane, I wonder if we need some more 
> general API for doing other DNS lookups, like e.g. TXT records or the new record types 
> needed for DNSSEC?
> Could we maybe have an overload for QHostInfo::lookupHost() instead of a new class, or 
> would that be to generic when it comes to parsing the response?

I am convinced the results of the different DNS lookup types need to be stored in 
different classes (QDnsServiceInfo, QDnsTextInfo..), as the resulting records have very 
different fields (take at look at RFC1035 vs RFC2782). I don't have a strong opinion 
regarding where the static methods used for lookup (Qxxx::lookupXXX) live, but 
"lookupHost" would be inacurate for service records.

While we are on the topic of the API, one thing which needs to be adressed is the kind of 
"handle" (if any) we return for asynchronous lookups:

- QHostInfo::lookupHost() returns an integer
- QDnsServiceInfo::lookupService() currently doesn't return anything

If I recall correctly, Thiago was not happy with returning an integer, stating a "more 
modern API" should be used. Are we talking about replacing QDnsServiceInfo with a 
QDnsServiceReply* ? Pro: it's consistent with QNAM. Con: we place the burden of freeing 
memory on the user.

> Regarding Olivier's comment: I'd rather prefer the low-level API. I understand the point 
> of convenience when having that logic in a connect() call, however I am not convinced it 
> covers all the use cases:
>
> * Maybe at some point you might want to parse DNS responses "by hand" (e.g. for DNSSEC?)
> * Some anti-virus software apparently stores versioning information directly in DNS 
> responses so the client does not need to contact the server all the time
> * another (admittedly creative) example of using DNS TXT records is the Google 
> certificate checker at ->
> http://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate-security.html
>

Same here, I think the low-level API needs to exist, but I am not opposed to building some 
convenience logic on top of it.

Jeremy