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.
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 DN
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
13 matches
Mail list logo
