On Fri, Nov 9, 2018 at 12:09 PM Paul Vixie wrote:
> Brian Dickson wrote:
> > Paul Vixie wrote:
>
i don't love the dnssec implications of this, including proof of
> nonwildcard.
>
I'm not 100% sure, but I think the generic DNSSEC response handling already
covers this.
If the response does not
Brian Dickson wrote:
Paul Vixie wrote:
...
i regret not adding ANY as an RR type (not just a Q type) back when
the DNS was small and i supported 90% of it. what we actually needed
is a wildcard on types so that if there's no more-specific type you
get thatone, which
I have finally reviewed the latest draft directly, and like the overall
direction but have a small number of issues (however, the issues
theirselves are somewhat fundamental). They broadly break down into
concerns about zone transfers and TTL stretching, and ultimately seem to
stem from a
On 09/11/2018 09:30, Paul Vixie wrote:
i regret not adding ANY as an RR type (not just a Q type) back when
the DNS was small and i supported 90% of it. what we actually needed
is a wildcard on types so that if there's no more-specific type you
get that one, which would have an rdata of
Ray Bellis wrote:
On 09/11/2018 07:14, Tony Finch wrote:
But remember: the goal is to make the DNS easier to use for people
who don’t know about the restrictions on CNAMEs.
I'd say the goal is to make the DNS *possible* to use for people who
don't know about the restrictions on CNAMEs.
On 09/11/2018 07:14, Tony Finch wrote:
But remember: the goal is to make the DNS easier to use for people
who don’t know about the restrictions on CNAMEs.
I'd say the goal is to make the DNS *possible* to use for people who
don't know about the restrictions on CNAMEs.
I concede that ANAME
> On 8 Nov 2018, at 20:13, Mark Andrews wrote:
>
>> On 9 Nov 2018, at 5:27 am, Tony Finch wrote:
>>
>> HTTP RRs risk adding a third option, where the web provider has to have
>> documentation asking whether the DNS provider supports HTTP RRs and if so
>> the site admin needs both these
It should be pointed out that the Autodiscover subsystem of Microsoft
Office uses SRV in a very *degenerate* way. It ignores all fields other
than target. In my testing, I believe I also proved that it doesn't fail
over if presented multiple SRV RRs in a response. So, basically it's a
one-to-one
> On 9 Nov 2018, at 5:27 am, Tony Finch wrote:
>
> Ray Bellis wrote:
>> On 08/11/2018 11:47, Dan York wrote:
>>
>>> For that reason, wouldn't all the resolvers (or at least an extremely high
>>> %) need to be upgraded to support the new record?
>>
>> They don't _have_ to be, but performance
Ray Bellis wrote:
> On 08/11/2018 11:47, Dan York wrote:
>
> > For that reason, wouldn't all the resolvers (or at least an extremely high
> > %) need to be upgraded to support the new record?
>
> They don't _have_ to be, but performance is improved when they are (since only
> an upgraded resolver
Subject: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME Date:
Thu, Nov 08, 2018 at 09:30:44AM +0700 Quoting Brian Dickson
(brian.peter.dick...@gmail.com):
> I'm going to start a clean, related thread, to discuss a bunch of
> questions, that I think can help with the ongoing
11 matches
Mail list logo
