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

[Ted Hardie <[e-mail]>]

On Wed, Sep 28, 2011 at 2:49 PM, Mohan Parthasarathy <[e-mail]>wrote;wrote:

> On Wed, Sep 28, 2011 at 2:06 PM, Ted Hardie <[e-mail]> wrote:
> > Howdy,
> >
> > I have a few questions on this proposal.
> >
> > Why not re-use the syntax of RFC4501 for the query?  That is:
> >
> https://relayingwebserver.example.com/query.cgi?dns:[//authority/]domain[?CLASS=class;TYPE=type]
> > ?
> >
> We should definitely study that for the next revision. We need to be
> able to specify more than what is given in RFC 4501. Is that
> extensible ?
>
>
What kind of extension do you need, the validation bit?

It likely is extensible if there is need, provided the existing strings
remain valid.  At worst, you'd need to mint a new URI.  If you go down that
road, though, I would suggest simply minting a URI for dns.https, where the
authority is the webserver you are querying and the path is the
domain[?CLASS=class;Type=Type;CD=1].  That makes https a "transport" for
DNS, rather than seeing this as a relayed service.  To me, it also suggests
you continue to use the DNS binary representations, since the results will
get fed to a local DNS subsystem.  With either XML or JSON, you're going
through a double translation (once on the relaying server and once in the
local subsystem pushing it to the DNS), and that seems more likely to
introduce error than to get you much benefit.




> > Declaring a namespace for the xml is generally good practice.  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.
> >
>
> We chose XML because it is readily available and also better
> inter-operability.
>
>
As others have noted, XML parsers are common--but the interpretation of the
XML in any particular namespace has to develop interoperability on its own.


> > It seems like you're wanting this to be used when CD bit is set to 1; any
> > reason why you'd want to support this for CD bit set to 0?
> > In general, I think a little bit more wording on when this tunneling
> would
> > be used would be really useful to flesh out when this is needed.
> >
> Yes, the main use case is DNSSEC. Does it make sense to restrict to just
> that ?
>
>
The advantage is really that you can tailor the return data parsers to throw
out anything that doesn't include the required DNSSEC bits.  As it is,
you're going to move from one set of issues (poor caching resolvers) to
another:  HTTP interception proxies.  Those are often not known to the end
host and their behavior is, at best, "interesting".  Mandating the use of
HTTPS will help some, but there is going to be an increased risk of HTTP
cache poisoning having an impact on the DNS if you use this--without DNSSEC,
that attack vector seems to me personally pretty bad.

regards,

Ted


> > NIT: You cite RFC 2396, but the current reference is RFC 3986
> >
> Will fix that.
>
> thanks
> mohan
>
> > regards,
> >
> > Ted Hardie
> >
> >
> > On Wed, Sep 28, 2011 at 11:24 AM, Mohan Parthasarathy <
> [e-mail]>
> > wrote:
> >>
> >> Hi,
> >>
> >> DNSSEC validation is stub resolver is dependent on DNSSEC-aware CPEs,
> >> recursive servers etc. Here is a draft that we submitted yesterday to
> >> address this problem.
> >>
> >> http://www.ietf.org/id/draft-mohan-dns-query-xml-00.txt
> >>
> >> Please send your comments/feedback to the list.
> >>
> >> thanks
> >> -mohan
> >> _______________________________________________
> >> dnsext mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dnsext
> >
> >
>

_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext