* 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
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
* 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 all?
All
--On 21 October 2009 08:34:39 + Florian Weimer fwei...@bfk.de 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
* Alex Bligh:
--On 21 October 2009 08:34:39 + Florian Weimer fwei...@bfk.de 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
Florian,
--On 21 October 2009 09:10:16 + Florian Weimer fwei...@bfk.de wrote:
--On 21 October 2009 08:34:39 + Florian Weimer fwei...@bfk.de
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
* 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 resolver
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 it
--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
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 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
On Oct 21 2009, Chris Thomson wrote:
On Oct 21 2009, Andrew Sullivan wrote:
Dear colleagues,
On Wed, Oct 21, 2009 at 05:54:18PM +1100, Mark Andrews wrote:
DNAME's placement is the same as any ordinary resource record (e.g.
MX, TXT). There is nothing special about where DNAME can or can't
Dear all,
there is a new version for the draft IDN TLD Variants Implementation
Guideline based on the dicussion from
DNSOP and DNSEXT mailing list. Thanks a lot to Andrew Sullivan, Paul
Hoffman, Alfred Hones and more for their kind comments.
any comments are welcome.
thanks a lot.
13 matches
Mail list logo
