Ray,
I have read the draft, found no problems other than the missing security
considerations
( I don't see any particular security considerations ), and fully support it.
Did you consider a "referral" model using NS records?
LOCAL.ARPA.9000NSA.LOCAL.ARPA.
LOCAL.ARPA.9000NS
On Oct 16 2009, Alfred Hönes wrote:
On Oct 16 2009, Chris Thompson wrote:
On Oct 16 2009, Alfred Hönes wrote:
Another point:
The draft is speaking abut "DNAME _in_ the root".
According to my surficial knowledge, DNAME RRs 'live'
at the _apex_ of the zone that shall be redirected, not
at th
On Oct 16 2009, Chris Thompson wrote:
> On Oct 16 2009, Alfred Hönes wrote:
>
>> Another point:
>>
>> The draft is speaking abut "DNAME _in_ the root".
>>
>> According to my surficial knowledge, DNAME RRs 'live'
>> at the _apex_ of the zone that shall be redirected, not
>> at the delegation point
A couple clarifying questions and remarks inline.
On Fri, Oct 16, 2009 at 10:42:05AM +0800, YAO Jiankang wrote:
> if we dname is used in the root, all dns administrator of the names below the
> TLD should have the dname knowledge.
Ah, so your worry is that, if we have example. and
variantexamp
On Oct 16 2009, Alfred Hönes wrote:
Another point:
The draft is speaking abut "DNAME _in_ the root".
According to my surficial knowledge, DNAME RRs 'live'
at the _apex_ of the zone that shall be redirected, not
at the delegation point -- or did I miss something?
Within each zone, there may be
Alfred � wrote:
Another point:
The draft is speaking abut "DNAME _in_ the root".
According to my surficial knowledge, DNAME RRs 'live'
at the _apex_ of the zone that shall be redirected, not
at the delegation point -- or did I miss something?
Within each zone, there may be at most one DNAME RR,
Another point:
The draft is speaking abut "DNAME _in_ the root".
According to my surficial knowledge, DNAME RRs 'live'
at the _apex_ of the zone that shall be redirected, not
at the delegation point -- or did I miss something?
Within each zone, there may be at most one DNAME RR,
and if so, it mus
Authors:
I fear that Sections 3 ff. of draft-yao-dnsop-idntld-implementation-00
have entirely missed the evolution of the dnesext-rfc2672-dname draft.
The "Understand DNAME" bit, and hence the dependence on EDNS has been
removed in June, and it has been reinforced that support for DNAME
does not
