Thanks, Daune,
> From: "Wessels, Duane"
> I understood Fujiwara’s proposal to be slightly different:
>
> If you are a DNS provider (hosting other zones) then the provider should use
> in-domain name servers.
> DW
This is what I would like to propose.
I would like good texts.
As Shumon pointe
With DNS, there are several things to consider, such as the number and
number of times that can complicate name resolution or cause DoS.
For example, number of CNAME chains or number of chains of "unrelated"
name server names are not limited. (Each implementations limit.)
"KeyTrap" also seems to
<>
+1.
p vixie
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
It appears that Paul Vixie said:
>-=-=-=-=-=-
><
>I think it would be better to compile them all into one draft.>>
I agree a draft describing the places where DNS evaluators
should set limits would be a good idea.
I am considerably less enthusastic about specific limits, since
the use of the DN
> On 13 Mar 2024, at 03:46, John Levine wrote:
>
> It appears that Paul Vixie said:
>> -=-=-=-=-=-
>> <>
>> I think it would be better to compile them all into one draft.>>
>
> I agree a draft describing the places where DNS evaluators
> should set limits would be a good idea.
>
> I am con
On 13Mar24, Mark Andrews apparently wrote:
> > ways. For applications like CDNs, you need two or three link CNAME
> > chains and nobody appears to find that a problem.
>
> Actually it is a problem. It results in lots of additional lookups.
> of this. All of the CNAMES could be done in the backg
On Wed, 13 Mar 2024, Mark Andrews wrote:
The obvious example is CNAME chains. In 1034/1035 the only use
contemplated for CNAME was temporary forwarding when a host name
changed, and for that use, chained CNAMEs made no sense. Now they
delegate authority to different points of control in many diff
