[Development] API review for a new QDnsResolver class
thiago.macieira at intel.com
Thu Nov 3 16:12:13 CET 2011
On Thursday, 3 de November de 2011 15:45:31 Peter Hartmann wrote:
> > An open question: should we have multiple lookupXXX() methods, or a single
> > lookup() which takes a QDnsRequest?
> It might make sense to have a generic method for querying any type of
> DNS; but then would we need a QDnsRequest class which might be overkill
> if we only support SRV and maybe TXT records short term? How complex can
> a DNS query possibly get so it would justify creating an own class? I am
> not sure about (one generic method plus request class) vs. (several
> specific methods) yet...
The DNS query is not the problem. A query is always composed of a domain name
being queried, along with the DNS class (Internet, no one uses anything else
for real purposes) and the record type. For the record type, it's very easy to
just list all types and also say that the user can use other types from the
DNS documentation. See the ns_type enum in /usr/include/arpa/nameser.h .
The problem is the DNS reply. Each query type contains a different kind of data
structure that would need to be parsed. It gets very complex very quickly if
we want to present the data in a nice, C++ class.
A 4 bytes containing an IPv4 address (QHostAddress)
NS a domain name (QString)
CNAME a domain name (QString)
SOA two domain names and five integers
PTR a domain name (QString)
MX an integer and a domain name
TXT text (QString)
AAAA 16 bytes containing an IPv6 address (QHostAddress)
SRV two integers and a domain name
A6 an integer, an IPv6 address and a domain name
DNAME a domain name (QString)
TKEY, TSIG ?
And that's just listing the ones that I thought we'd like to support. CNAME
and DNAME are likely not to be the query, but they might appear as part of the
 a that suffers from the "creat" syndrome.
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/development/attachments/20111103/19fb5d4f/attachment-0001.bin
More information about the Development