> > [S4.1, comment]
> >
> > * "Resolvers and other DNS clients should be aware that some servers
> > might not be reachable over TCP. For this reason, clients MAY want
> > to track and limit the number of TCP connections and connection
> > attempts to a single server."
> >
> > I think the s
On 11/1/2021 11:58 AM, Eric Orth wrote:
The important part for preserving compatibility with potential future
changes is the "recipients MUST ignore any SvcParams that are present"
part.
I don't understand what would be different if the record sender SHOULD
became a MUST. Recipients wouldn
On 11/1/2021 11:58 AM, Eric Orth wrote:
The important part for preserving compatibility with potential future
changes is the "recipients MUST ignore any SvcParams that are present"
part.
I don't understand what would be different if the record sender SHOULD
became a MUST. Recipients wouldn
This text is a "SHOULD NOT" because there has been some discussion of
potential future uses for SvcParams in AliasMode. If implementations
follow the current text, this kind of extension can be backwards-compatible.
I agree that the resulting behavior creates a typo hazard for zone
administrators
> On 1 Nov 2021, at 21:57, libor.peltan wrote:
>
> Hi,
>
> I'm just not sure if this requested SHOULD->MUST change would actually have
> any consequences.
The primary would refuse to load the record and it would have been corrected.
The primary would refuse to accept in as part of an UPDAT
Hi,
I'm just not sure if this requested SHOULD->MUST change would actually
have any consequences.
It still doesn't say anything about what authoritative, and recursive
servers should do.
The draft's sections about authoritative server behavior are somewhat
brief, but that may be OK.
In g
