Re: [dnsext] draft-mohan-dns-query-xml-00.txt

On 2011-09-29, Tony Finch <dot@dotat.at> wrote:
> Ted Hardie <ted.ietf@gmail.com> wrote:
>>
>> Why not re-use the syntax of RFC4501 for the query? [...] It's also not
>> clear why you need an XML-based representation, rather than using a
>> mime-type like that set out in RFC 4027 (which uses detached domain name
>> information as set out in RFC 2540).  Even if those need updating, it's
>> not clear to me what you're gaining with the use of XML here.
>
> I agree with these suggestions and questions.
>
> I don't understand the interoperability argument. The software that will
> be producing and consuming this data is DNS software that already has
> parsers for binary DNS data, and doesn't have serializers or parsers for
> XML. Binary data is also much more friendly for mobile endpoints.
> Interoperability with non-DNS software should be handled by a separate
> gateway that doesn't put a disgustingly wasteful pessimization in the fast
> path.

hi,

i believe this is the first time i've ever posted to an IETF mailing
list, but as someone who writes DNS software and, less frequently, HTTP
software, i'd like to voice support for this point of view.

i don't believe that re-formatting DNS query messages is necessary for
transporting DNS over HTTP(S), and in fact any re-formatting is
effectively a "fork" of the DNS protocol.

i'd much rather see the thinnest possible mapping of DNS onto HTTP.  for
instance, an average DNS query packet length is around 49 octets.
simply hex-encoding the entire query message would not result in an
abnormally long URL, e.g.:

https://server/dns/00000010000100000000000100000200010000291000000080000000

here i've set the ID field to 0.  i suspect that in the majority of uses
the ID field could always be set to a fixed value, and this would aid
HTTP caching.  (speaking of which, you would also want to send a
"Cache-Control: max-age" header in the HTTP response with the max-age
set to the minimum of all RRset TTL values in the DNS response.)

the actual HTTP response payload would simply be a binary wire-format
DNS response message, possibly with a leading two byte length field like
plain TCP DNS.

-- 
Robert Edmonds
edmonds@isc.org

_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext