Florian,
--On 20 October 2009 06:52:22 +0000 Florian Weimer <fwei...@bfk.de> wrote:
I've just submitted the following draft.
This will work for a short time only because those proxies will likely
be changed to return their own address for DOMAIN.LOCAL.ARPA.
I think you are presuming that such a proxy vendor is deliberately
setting out to break things. I don't think that's the case. Ignorance
is the main cause.
As per the draft, a proxy which implements a full recursive server
that correctly passes DNSSEC packets is permitted to return its own
address from DOMAIN.LOCAL.ARPA; the sort of proxies we see today
may not. Ray in his response to you correctly points out that companies
may choose to violate the draft (perhaps it could be more explicit
about the consequences of doing so); we have no IETF police force
and people can always violate drafts.
You cannot rely on a NXDOMAIN response for DOMAIN.LOCAL.ARPA when the
resolver does not support this protocol due to widespread DNS
poisoning.
Could you amplify a bit on this one? I think what you are saying is
that recursive servers which do not support DOMAIN.LOCAL.ARPA
(and hence don't strip it out of any response to a recursive
query) can be subject to poisoning attacks which will result in
duff nameserver records being sent to clients that are aware
of the protocol.
I think that is indeed a security concern, and perhaps not
one that can be brushed aside with the response "but such
servers can have any DNS query made to them poisoned anyway".
May be we need to come up with a way for a server
to signal that it does indeed support DOMAIN.LOCAL.ARPA
(or perhaps LOCAL.ARPA) in a manner not reliant upon
poisonable records. For instance, the client could always
query with a given EDNS0 option set, which would be returned
to the client by the server; any response without this set
would indicate lack of support for {DOMAIN.,}LOCAL.APRA
and cause the response to be treated like NXDOMAIN. The
disadvantage here is that this would require a server s/w
change and a larger protocol change, whereas the current
protocol only requires a configuration change. I shall
think about this.
--
Alex Bligh
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
