All,
While working on the next version of the ANAME draft, one additional
question came up: When querying for A or , we want to include the
ANAME in the response as a signal to anticipate aliasing. Should we
include the ANAME record in the answer section or the additional section?
The main
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.
Title : Considerations for Large Authoritative DNS Servers
Operators
Authors : Giovane C. M. Moura
On Tue, Jun 11, 2019 at 4:32 AM Matthijs Mekking
wrote:
> All,
>
>
> While working on the next version of the ANAME draft, one additional
> question came up: When querying for A or , we want to include the
> ANAME in the response as a signal to anticipate aliasing. Should we
> include the AN
On Tue, Jun 11, 2019 at 8:46 AM wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain Name System Operations WG of the
> IETF.
>
> Title : Considerations for Large Authoritative DNS
> Servers Operat
Folks,
So we've presented the -03 version of our draft at IETF104 in Prague.
Thanks everybody for their feedback, sure help us to improve the document.
We worked on a new version of the draft, which yon can find at:
*
https://www.ietf.org/id/draft-moura-dnsop-authoritative-recommendations-04.
> I don't understand how changing to a shorter TTL (from 1 day to 5
> minutes) reduced the RTT. Seems backwards.
Good catch. You're right: it went from 5 minutes to 1 day. Will fix it.
/giovane
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.or
On 6/11/19 5:53 AM, Bob Harold wrote:
>
> If the camel was not already overloaded, then a cautious approach might
> be to put it in the additional section, *unless* there was a capability
> signal in the request that indicated that the requester would understand
> ANAME, or at least not have a pro
(context: The HOMENET WG will not meet in Montreal at IETF105)
The HOMENET front-end-naming design team will spend some unstructure time
together. This relates to
https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/
The exact time is to be determined as the unstruct
A new Request for Comments is now available in online RFC libraries.
RFC 8624
Title: Algorithm Implementation Requirements and Usage
Guidance for DNSSEC
Author: P. Wouters,
O. Sury
Status: Standards T
On Tue, Jun 11, 2019 at 10:31:55AM +0200, Matthijs Mekking wrote:
> The main argument for putting it in the answer section is that putting
> it in the additional section implies a lower trust level, and that the
> record is optional and can be removed when minimizing responses.
I'm inclined to fav
I'm a fan of Michael's suggestion of using EDNS to signal that the
authoritative should return ALIAS vs synthesizing. Any reason this won't
work?
-Anthony
On Tue, Jun 11, 2019 at 8:05 PM Evan Hunt wrote:
> On Tue, Jun 11, 2019 at 10:31:55AM +0200, Matthijs Mekking wrote:
> > The main argument f
On Jun 11, 2019, at 20:04, Evan Hunt wrote:
> MHO, the ANAME is the real answer we're sending; the A and records
> are just friendly hand-holding for legacy servers. It doesn't make sense
> to me to demote the real answer into the additional section, any more than
> it would have to move DN
On Jun 11, 2019, at 20:11, Anthony Eden
wrote:
> I'm a fan of Michael's suggestion of using EDNS to signal that the
> authoritative should return ALIAS vs synthesizing. Any reason this won't work?
It won't work unless it's implemented. On a grand scale, then, it
won't work unless it's implement
On Tue, Jun 11, 2019 at 6:35 PM Joe Abley wrote:
> On Jun 11, 2019, at 20:04, Evan Hunt wrote:
>
> > MHO, the ANAME is the real answer we're sending; the A and records
> > are just friendly hand-holding for legacy servers. It doesn't make sense
> > to me to demote the real answer into the
On Tue, Jun 11, 2019 at 08:11:51PM -0400, Anthony Eden wrote:
> I'm a fan of Michael's suggestion of using EDNS to signal that the
> authoritative should return ALIAS vs synthesizing. Any reason this won't
> work?
Not that I can think of, but it adds significant implementation complexity
in order
15 matches
Mail list logo
