Re: [DNSOP] Informal meeting about root KSK futures at IETF 103

Steve Crocker wrote: > I had advocated early and frequent rollovers for precisely the reason: keep > doing it until it’s easy, so we’re in strong agreement. Yes, I would like to see annual rollovers. Keep that hinge greased :-) Tony. -- f.anthony.n.finchhttp://dotat.at/ Shannon, Rockall:

[DNSOP] Last Call: (C-DNS: A DNS Packet Capture Format) to Proposed Standard

The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'C-DNS: A DNS Packet Capture Format' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send

[DNSOP] ANAME intro text

The introduction of draft-ietf-dnsop-aname-02 includes this text: If the web site is hosted by a third-party provider, the ideal way to provision its name in the DNS is using a CNAME record, so that the third party provider retains control over the mapping from names to IP

Re: [DNSOP] ANAME TTL vs GCD

Tony Finch writes: > In the first round, the ANAME processor will choose a 30s TTL. > > In the second round, 30s later, it will get the target address records > from the cache with a 15s TTL, so it'll choose a 15s TTL. > > The in the third round it'll be back to 30s. > > The TTL will flip-flop,

Re: [DNSOP] ANAME TTL vs GCD

I am still of the opinion that the expanded A and records should use the ANAME TTL*, and the target TTL should be ignored. That TTL is only useful for the cache that is used as part of the ANAME expansion process. The ANAME TTL may be subject to decreasing, if sibling A and

Re: [DNSOP] ANAME TTL vs GCD

Bjørn Mork wrote: > > Require DNSSEC for ANAME support That isn't going to be feasible, I'm afraid, because the tricky TTLs are down the ANAME+CNAME chain, so they aren't under the control of the ANAME owner. And many of the use cases for ANAME involve pointing it at targets that don't do

Re: [DNSOP] ANAME intro text

Ray Bellis wrote: > > AIUI, various protocols have at times required that when a CNAME record > is encountered that the target of that record (the "canonical name") be > the one subsequently used in protocol exchanges. [e.g. the apparently > obsolete text in §5.2.2 of RFC 1123]. Are there any

Re: [DNSOP] ANAME intro text

In article , Tony Finch wrote: >Are there any examples of that other than SMTP? Not that I know of, and these days few mail systems do so. The C in CNAME tells us what its intended application was, but as we've seen from time to time, here on the Internet what you expect and what you get are

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-extended-error

On 30/10/2018 16:57, Wes Hardaker wrote: > Well, the plan is to not allow it per the original EDNS0 spec. We > should have said that in the section and said "going once" or > something. IE, the plan is to disallow sending it back unless the > source indicates support. > > [In theory, it

Re: [DNSOP] ANAME intro text

Ray Bellis wrote: > > I have some issue with the use of the term "ideal" there. Anyway, since this is a value judgment that is probably out of place [WP:EDITORIAL {{Weasel}} etc.] I've rephrased in a more neutral style. Thanks for pointing out the weakness; the intro is important for setting the

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-extended-error

On 30 Oct 2018, at 12:57, Wes Hardaker wrote: >> With IANA registry requests, I may be wrong here, but I thought we had >> some (boilerplate?) language about how IANA is asked to operate the >> registry: what criteria judge acceptance. Is it like the OID and >> basically open (hair oil) slather,

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-extended-error

George Michaelson writes: > How can it go WGLC with section 6 an open question? Well, the plan is to not allow it per the original EDNS0 spec. We should have said that in the section and said "going once" or something. IE, the plan is to disallow sending it back unless the source

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-extended-error

On 24. 10. 18 8:41, Tim Wicinski wrote: > We've been talking with the authors of Extended Error and now that > they've gotten around to updating the document, and the chairs > feel it is ready for Working Group Last Call.  > > We're going to kick this WGLC off this week and run it through

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-extended-error

Ray Bellis wrote: FWIW, I really wish in retrospect that EDNS(0) had defined the extra rcode bits as being for a _sub-type_ of the primary RCODE, i.e. SERVFAIL is always "2" in those four bits in the main header, with the extended field in the EDNS response allowing for more detail (c.f.

Re: [DNSOP] Informal meeting about root KSK futures at IETF 103

Mark, but would regular rolls not put vendors into a 'habit' of getting updates onto their package managers? el On 2018-10-30 23:31 , Mark Andrews wrote: > Ultra frequent key rolls are not necessary. It takes years the latest > releases of name servers to make it into shipping OS’s. The last

Re: [DNSOP] Informal meeting about root KSK futures at IETF 103

Name server vendors have NO CONTROL over when down streams pick up changes. We would like OS vendors to pick up maintenance release sooner than they do. It would reduce the amount of time we spend diagnosing already fixed issues. We spend the time back porting fixes so people can have stable

Re: [DNSOP] KSK rollover choices

> On 31 Oct 2018, at 11:16 am, Jim Reid wrote: > > On 30 Oct 2018, at 22:31, Mark Andrews wrote: >> >> Ultra frequent key rolls are not necessary. It takes years the latest >> releases of name servers to make it into shipping OS’s. > > So what? Key rollover policies cannot and should not

Re: [DNSOP] draft-ietf-dnsop-rfc2845bis-01

When experimenting with what would happen if we defined a well known TSIG key to provide a crypto hash for DNS/UDP to prevent fragmentation attacks being accepted it became clear that RFC2845 was not clear enough in error condition handling. See

Re: [DNSOP] Informal meeting about root KSK futures at IETF 103

Ultra frequent key rolls are not necessary. It takes years the latest releases of name servers to make it into shipping OS’s. The last KSK worked so well in part because there was a large amount of time between publishing the new KSK and using the new KSK. This allowed name server vendors to

[DNSOP] KSK rollover choices

Just a brief note that the threads about KSK futures started on the ksk-rollo...@icann.org mailing list and should probably still be there. The only bit that was meant to be on this Working Group mailing list was an announcement of the side-meetings next week.

[DNSOP] KSK rollover choices

On 30 Oct 2018, at 22:31, Mark Andrews wrote: > > Ultra frequent key rolls are not necessary. It takes years the latest > releases of name servers to make it into shipping OS’s. So what? Key rollover policies cannot and should not be driven by vendor OS release schedules. Or the

Re: [DNSOP] Informal meeting about root KSK futures at IETF 103

I feel backup key, and alg, are sufficiently of wide benefit, that the qualms about frequency are second-order to the primary goal of an improved outcome 1) backups go to stability of unplanned events 2) new alg would permit a return to shorter packet sizes even across keyroll, which makes IPv6

[DNSOP] ANAME TTL vs GCD

One of the more complicated aspects of ANAME is working out how TTLs should work, because there are a bunch of tricky constraints. There's a fairly long rationale in an appendix about the various issues - https://tools.ietf.org/html/draft-ietf-dnsop-aname-02#appendix-D As a design guideline (to