Joe Abley wrote:
If a format is going to be specified that specifically prohibits a
zone cut, doesn't it make more sense to choose one that can't
possibly involve one because there are no potential label
boundaries?
+1.
--
P Vixie
___
DNSOP mailin
On 31 Oct 2017, at 11:01, Ray Bellis wrote:
> On 31/10/2017 14:56, Joe Abley wrote:
>
>> Perhaps I missed something, but how do you ensure that _ta is an
>> empty non-terminal?
>
> By having that be part of the required server logic to implement the
> sentinel mechanism?
If a format is going t
> On 31 Oct 2017, at 6:34 pm, Tony Finch wrote:
>
> Ray Bellis wrote:
>> On 30/10/2017 17:40, Evan Hunt wrote:
>>
>>> IIRC we discussed it, and were concerned that _ta. could be cached as
>>> nonexistent by servers implementing QNAME minimization.
>>
>> How would that happen, at least so long
> On 31 Oct 2017, at 6:34 pm, Tony Finch wrote:
>
> Ray Bellis wrote:
>> On 30/10/2017 17:40, Evan Hunt wrote:
>>
>>> IIRC we discussed it, and were concerned that _ta. could be cached as
>>> nonexistent by servers implementing QNAME minimization.
>>
>> How would that happen, at least so long
On 31/10/2017 14:56, Joe Abley wrote:
> Perhaps I missed something, but how do you ensure that _ta is an
> empty non-terminal?
By having that be part of the required server logic to implement the
sentinel mechanism?
That said, I'm not sure this would be consistent with the draft's
proposed use
On 31/10/2017 14:34, Tony Finch wrote:
> It's NXDOMAIN. (It'll also fall foul of RFCs 8020 and 8198.)
>
> The problem occurs if you have a validator behind a cache. The cache will
> prevent downstream id._ta. queries from reaching the root, so any
> downstream trust anchor variation will be los
On Oct 31, 2017, at 07:27, Ray Bellis wrote:
>> On 30/10/2017 17:40, Evan Hunt wrote:
>>
>> IIRC we discussed it, and were concerned that _ta. could be cached as
>> nonexistent by servers implementing QNAME minimization.
>
> How would that happen, at least so long as _ta responds like any other
Ray Bellis wrote:
> On 30/10/2017 17:40, Evan Hunt wrote:
>
> > IIRC we discussed it, and were concerned that _ta. could be cached as
> > nonexistent by servers implementing QNAME minimization.
>
> How would that happen, at least so long as _ta responds like any other
> empty non-terminal?
It's N
On 30/10/2017 17:40, Evan Hunt wrote:
> IIRC we discussed it, and were concerned that _ta. could be cached as
> nonexistent by servers implementing QNAME minimization.
How would that happen, at least so long as _ta responds like any other
empty non-terminal?
Ray
__
> I see that this draft uses a syntax similar to RFC 8145 Trust Anchor
> Telemetry RFC (which uses _ta-) albeit without the leading
> underscore, i.e. .ta-.
>
> I'd like to propose instead ._ta.
>
> This would allow _ta to be registered as a standalone entry in the
> underscore label registry, wh
I see that this draft uses a syntax similar to RFC 8145 Trust Anchor
Telemetry RFC (which uses _ta-) albeit without the leading
underscore, i.e. .ta-.
I'd like to propose instead ._ta.
This would allow _ta to be registered as a standalone entry in the
underscore label registry, whilst also avoid
11 matches
Mail list logo
