On Wed, Oct 21, 2009 at 08:32:49AM +0100, ray.bel...@nominet.org.uk wrote:
> > Mark, I din't think this is true given how the proposed protocol
> > works. For a start, you often cannot fetch the DNSKEY RR for ARPA
> > before running the protocol.
>
> Indeed LOCAL.ARPA would need to be unsigned.
On 2009-10-21, at 09:39, David Conrad wrote:
On Oct 21, 2009, at 1:34 AM, Florian Weimer wrote:
Indeed LOCAL.ARPA would need to be unsigned.
Not really. Why would it need to exist in the public tree at all?
All we need is agreement from both ICANN and IETF that LOCAL.ARPA is
reserved and not
Hi,
On Oct 21, 2009, at 1:34 AM, Florian Weimer wrote:
>> Indeed LOCAL.ARPA would need to be unsigned.
> Not really. Why would it need to exist in the public tree at all?
> All we need is agreement from both ICANN and IETF that LOCAL.ARPA is
> reserved and not to be delegated in the official tree
--On 21 October 2009 11:24:08 +0100 ray.bel...@nominet.org.uk wrote:
We could simply propose NXDOMAIN.LOCAL.ARPA. as well.
If the answer for that comes back the same as for DOMAIN.LOCAL.ARPA, we
know we've got an "evil" resolver. :)
True - and that has obvious benefits. However, testing the
> That's easily remedied, and would be a good addition to the protocol.
The
> first thing the client does is send a query to the candidate new
nameserver
> (possibly with "Christmas tree" options, e.g. DO set and so forth), and
> check the reply looks sensible. If not, it doesn't use it. That way
--On 21 October 2009 09:55:06 + Florian Weimer wrote:
Ah. I think I now understand what you mean. Well yes they can do that,
but they could do it anyway.
There's an additional twist: If I have got a client device (not DNS
proxy) which supports the proposed protocol, it will not work whe
* Alex Bligh:
> Clearly a validating recursive nameserver not supporting
> DOMAIN.LOCAL.ARPA may get a signed denial of existence for
> LOCAL.ARPA, but that's just fine. LOCAL.ARPA doesn't
> exist "there".
Great, then we are in agreement actually.
>> As I've tried to explain, spoofing by the res
Florian,
--On 21 October 2009 09:10:16 + Florian Weimer wrote:
--On 21 October 2009 08:34:39 + Florian Weimer
wrote:
Mark, I din't think this is true given how the proposed protocol
works. For a start, you often cannot fetch the DNSKEY RR for ARPA
before running the protocol.
Ind
* Alex Bligh:
> --On 21 October 2009 08:34:39 + Florian Weimer wrote:
>
Mark, I din't think this is true given how the proposed protocol
works. For a start, you often cannot fetch the DNSKEY RR for ARPA
before running the protocol.
>>>
>>> Indeed LOCAL.ARPA would need to be un
--On 21 October 2009 08:34:39 + Florian Weimer wrote:
Mark, I din't think this is true given how the proposed protocol
works. For a start, you often cannot fetch the DNSKEY RR for ARPA
before running the protocol.
Indeed LOCAL.ARPA would need to be unsigned.
Not really. Why would it
* Ray Bellis:
>> Mark, I din't think this is true given how the proposed protocol
>> works. For a start, you often cannot fetch the DNSKEY RR for ARPA
>> before running the protocol.
>
> Indeed LOCAL.ARPA would need to be unsigned.
Not really. Why would it need to exist in the public tree at al
> Mark, I din't think this is true given how the proposed protocol
> works. For a start, you often cannot fetch the DNSKEY RR for ARPA
> before running the protocol.
Indeed LOCAL.ARPA would need to be unsigned. That needs to be added to
the draft.
Since (as Bill points out) LOCAL.ARPA would be
* Mark Andrews:
> For LOCAL.ARPA to be accepted you need a break in the DNSSEC trust
> chain.
Mark, I din't think this is true given how the proposed protocol
works. For a start, you often cannot fetch the DNSKEY RR for ARPA
before running the protocol.
--
Florian Weimer
BFK ed
In message <1f61dd04-14a6-4349-8650-9cf27d27c...@hopcount.ca>, Joe Abley writes
:
>
> On 2009-10-20, at 19:29, Mark Andrews wrote:
>
> >> ARPA will soon be signed, so I don't think this is much to worry
> >> about. If the powers that be finally agree to make NXDOMAIN/NODATA
> >> synthesis the d
On Tue, Oct 20, 2009 at 07:38:19PM -0400, Joe Abley wrote:
>
> On 2009-10-20, at 19:29, Mark Andrews wrote:
>
> >>ARPA will soon be signed, so I don't think this is much to worry
> >>about. If the powers that be finally agree to make NXDOMAIN/NODATA
> >>synthesis the default in the upcoming mino
On 2009-10-20, at 19:29, Mark Andrews wrote:
ARPA will soon be signed, so I don't think this is much to worry
about. If the powers that be finally agree to make NXDOMAIN/NODATA
synthesis the default in the upcoming minor DNSSEC revision, this
will
also help to cut down the number of request
In message <82ljj61gle@mid.bfk.de>, Florian Weimer writes:
> * Alex Bligh:
>
> > 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) ca
* Alex Bligh:
> 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 rec
Florian,
--On 20 October 2009 06:52:22 + Florian Weimer 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 vendo
> This will work for a short time only because those proxies will likely
> be changed to return their own address for DOMAIN.LOCAL.ARPA.
The draft specifically prohibits this. Of course vendors _do_ ignore
RFCs, otherwise this draft wouldn't be necessary. However we'd be in a
good position to
* Ray Bellis:
> 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.
You cannot rely on a NXDOMAIN response for DOMAIN.LOCAL.ARPA when the
resolver does not support this proto
I've just submitted the following draft.
--8<--8<--
A new version of I-D, draft-bellis-dns-recursive-discovery-00.txt has been
successfuly submitted by Ray Bellis and posted to the IETF repository.
Filename: draft-bellis-dns-recursive-discovery
Revision: 00
Title:
22 matches
Mail list logo
