At Mon, 7 Mar 2016 09:58:46 +0900,
Manabu Sonoda wrote:
> > So I'm wondering: is this something odd you just happen to find in a
> > test environment or something, or is there any practical issue because
> > of that?
> That found product environment...
> Our full resolver was sometimes return the
On Fri, 4 Mar 2016 10:49:50 -0800
神明達哉 wrote:
> I'm not sure whether we should do something about it, though. As you
> pointed out, the configuration is already so broken: there's even no
> delegation from the parent (or ancestor) to the child zone, so I'm not
> sure if we can define any valid b
In message
, =?UTF-8?B?56We5piO6YGU5ZOJ?= writes:
> At Sat, 05 Mar 2016 07:23:46 +1100,
> Mark Andrews wrote:
>
> > There is nothing strange here beyond a missing delegation.
>
> I'm not opposed to this conclusion itself, but:
>
> > > If so, I agree it looks odd, and we might say it's against
At Sat, 05 Mar 2016 07:23:46 +1100,
Mark Andrews wrote:
> There is nothing strange here beyond a missing delegation.
I'm not opposed to this conclusion itself, but:
> > If so, I agree it looks odd, and we might say it's against Section
> > 2.2.1.2 of RFC3658 (if we superficially applied this se
In message
, =?UTF-8?B?56We5piO6YGU5ZOJ?= writes:
> At Fri, 4 Mar 2016 14:07:03 +0900,
> Manabu Sonoda wrote:
>
> > I find the the strange response to the DS request.
> > That response answer type is CNAME.
> >
> > This can happen if Child and Parent zone in same nameserver and
> > Parent zone
At Fri, 4 Mar 2016 14:07:03 +0900,
Manabu Sonoda wrote:
> I find the the strange response to the DS request.
> That response answer type is CNAME.
>
> This can happen if Child and Parent zone in same nameserver and
> Parent zone does not have NS recode for Child zone and
> Parent zone have CNAME
6 matches
Mail list logo
