[
https://issues.apache.org/jira/browse/JAMES-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513857
]
Stefano Bagnara commented on JAMES-796:
---------------------------------------
As you can read in the previous dnsjava-users archive link we found a bug in
dnsjava dig and in the mean time Brian answered my questions.
I think what you propose in theory is not wrong. What you propose in practice
is instead at least very dangerous (if not wrong).
Brian Wellington said:
"Continuing the resolution would be the correct thing to do if you were writing
a name server. From the context of a client wishing to lookup MX records, I
believe the right thing to do is simply fail. "
"Pretty much every client application uses a stub resolver. It's possible to
have a full resolver that's not part of a caching name server, but I don't know
of any. "
So, what you are asking in theory is not wrong (and is what name servers do)
even if NO known application using a dns client really handle recursion.
To handle recursion is not a matter of 10 lines of code: the code you wrote is
a security risk as it will be really too easy to break the
server with DNS poisoning. Poisoning is one of the first aspect to take care
when you write a recursive DNS cache / server and the clients are simple stubs
because it doesn't really worth supporting similar complex issues on the client
side.
I compare this to the relay issue: email client could try to deliver email
themselves by locating the MX server and sending it to the
server but this is not done and lately it would be impossible as dialup ip are
blacklisted. So they use a relay-host to send email. Only the
email server of their provider should be opened to relay for them and not every
server around the world.
The same happens with DNS Servers: every dns server that a provider will give
to his customer will handle recursive answers and if you decide to use a
different server then it's up to you to find one that handle recursivity.
It should also be noted that if someone install JAMES in a computer then he
will probably have a recursive dns configured or any other application will
fail because every unix application using the libresolv is a stub resolver and
doesn't handle recursivity.
Currently I don't support inclusion of the current proposed patch because of
the security issues (cache poisoning).
If you're going to write a fully recursive extension to dnsjava then I think
JAMES should evaluate whether this belong to JAMES (maybe by including a
recursive dnsserver service as an option).
IMHO one thing is to make it more clear in the config.xml that the dnsserver
provided must handle recursive queries (even if this IMHO was implicit as
everytime you place a dnsserver in the configuration of a client OS/software
this has to be true).
> Do also query authoritative nameservers to obtain MX record
> -----------------------------------------------------------
>
> Key: JAMES-796
> URL: https://issues.apache.org/jira/browse/JAMES-796
> Project: James
> Issue Type: Improvement
> Reporter: Armin Häberling
>
> for example for zunft-oberstrass.ch
> DNSServer.lockup("zunft-oberstrass.ch", Type.MX, "MX")
> will return null, but
> DNSServer.lockup("zunft-oberstrass.ch", Type.NS, "NS")
> will return two authoritative nameservers, which then can be queried and
> return the MX record for zunft-oberstrass.ch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
