Subject: [dnsext] RETRY and EXPIRE clarification

From: Lubos Slovak <[email-masked]>
Date: Wed, 05 Oct 2011 10:18:20 +0200

Hi,

I find the definition of RETRY and EXPIRE intervals in RFC 1035 quite 
vague and did not find any other RFC clarifying it.

1) Should the RETRY interval start when the REFRESH event occurred (this 
is a bit more deterministic) or when it is clear that the transfer 
failed, i.e. on timeout or error during transfer (this is maybe closer 
to the definition of RETRY in RFC 1035, part 3.3.13)?

2) What should happen if the EXPIRE interval elapses before the transfer 
is finished (assume large zone, transfer lasts for several minutes and 
EXPIRE is set too low - i.e. 1 minute)? Should the server cease to serve 
the zone? If yes, should it serve the zone again after the transfer is 
finished?

Thanks a lot,
Lubos
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Edward Lewis <[email-masked]>
Date: Wed, 5 Oct 2011 08:45:30 -0400

At 10:18 +0200 10/5/11, Lubos Slovak wrote:
>Hi,
>
>I find the definition of RETRY and EXPIRE intervals in RFC 1035 
>quite vague and did not find any other RFC clarifying it.

First lesson in reading RFC 1034/1035 - don't take them that 
literally.  They were descriptions of the system, not specifications. 
This was explained to me by one of the folks involved in writing them.

>is a bit more deterministic) or when it is clear that the transfer failed,
>i.e. on timeout or error during transfer (this is maybe closer to the
>definition of RETRY in RFC 1035, part 3.3.13)?

Doesn't really matter, I mean, how long does it take to fail a 
transfer?  Let's say it's 90 seconds - if the retry is 43200 (12 
hours), whether you try 1/2 a day later or 1/2 day plus 90 seconds 
later isn't going to change things.  It looks cooler in the logs if 
the retries happen at the stroke of 1/2 day intervals, but it doesn't 
matter in the long run.

>2) What should happen if the EXPIRE interval elapses before the transfer is
>finished (assume large zone, transfer lasts for several minutes and EXPIRE is
>set too low - i.e. 1 minute)? Should the server cease to serve the zone? If
>yes, should it serve the zone again after the transfer is finished?

Could and yeah.  I suspect that while you are transferring the zone 
you can suspend checking the timer if you want and no one would 
complain.

EXPIRE shouldn't be that low though.  DNS wasn't built to be real 
time, when you have a server-cache-client architecture you can expect 
it to be that fast.

(There's nothing wrong in trying to make DNS be real time.  But 
you'll have to realize it takes some work as that wasn't the design 
goal.  Kind of like trying to drag race pickup trucks.  You can do 
it, but it isn't as easy or efficient as drag racing speedsters.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Vote for the word of the day:
"Papa"razzi - father that constantly takes photos of the baby
Corpureaucracy - The institution of corporate "red tape"
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Chris Thompson <[email-masked]>
Date: 05 Oct 2011 14:50:06 +0100

>At 10:18 +0200 10/5/11, Lubos Slovak wrote:
[..anip..]
>the retries happen at the stroke of 1/2 day intervals, but it doesn't 

That is in any case the sort of thing that leads to different processes
getting into lock step and generating load spikes. It is better to
dither the intervals a bit, as NIND has done for, lo, these many years:

 432.   [func]          Added refresh/retry jitter.  The actual refresh/
                        retry time is now a random value between 75% and
                        100% of the configured value.

[That was already in BIND 9.1, at least.]

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Edward Lewis <[email-masked]>
Date: Wed, 5 Oct 2011 11:46:24 -0400

>dither the intervals a bit, as NIND has done for, lo, these many years:

Unless a customer wants it to be precisely when they expect it to be.

There's a lot to be said for predictability (and against dithering 
intervals in this case).  If it results in spikes, you know why and 
you can take verifiable steps avoid it.  OTOH, predictability isn't 
always desirable and dithering intervals is the answer.  A lot 
depends on the problem domain's characteristics.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 7 Oct 2011 10:06:24 -0400

http://www.ietf.org/mail-archive/web/i-d-announce/current/msg40107.html

Out of frustration trying to locate information on the more obscure 
RR type registrations at IANA, I drew up this draft.  Comments?

Yes, there are spelling errors...in the abstract.  From the announcement:

     Title         : IANA Allocated DNS RRtyp Codes without Documentation
     Author(s)     : E. Lewis
     Filename      : draft-lewis-dns-undocumented-types-00.txt
     Pages         : 3
     Date          : 2011-10-06
    
In the IANA registry of Resource Record (RR) TYPEs, as of October 1,
2011, there are 10 type code values allocated with references that
are individual email boxes and not stable documents.  Some of the
registrations represent works in progress and such a reference is
viable.  Some registrations are dormant or dead efforts.  In all
cases it would be helpful to have some refernce to material
describing the type.

---

From: [email-masked]
Date: Fri, 7 Oct 2011 18:51:56 -0400 (EDT)

On Fri, 7 Oct 2011, Edward Lewis wrote:

> In all cases it would be helpful to have some refernce to material 
> describing the type.

I agree, but a new draft may not be the right way to do it.

Several of these assignments were made under the RFC5395/6195 rules, and 
those RFCs say "IANA shall maintain a public archive of approved 
templates."  The registry should point at that archive, not the names of 
people.  And the archive should include static copies of documents cited 
(e.g. i-d's).  I don't know if IANA is actually maintaining that archive 
or, if so, where.

> ... there are 10 type code values allocated with references that
> are individual email boxes and not stable documents.

The TA RR is a slightly different beast, since the citation in the 
registry is to a stable doc.  (You can get it in hardcopy through 
inter-library loan if you're desperate.)

I think the TA RR (32768) is one of only two type codes allocated under 
the RFC2929 "Specification Required" rules, and the only one with a 
non-RFC reference.  For ease of reference, I'd suggest that IANA just 
archive the specification document in the same place as the docs 
describing RRs assigned under 5395/6195.

-- Sam

---

From: Edward Lewis <[email-masked]>
Date: Sat, 8 Oct 2011 16:39:11 -0400

>I agree, but a new draft may not be the right way to do it.

The reason I submitted this draft was that I feel "something is 
better than nothing."  All I said above is "it would helpful."

>
>Several of these assignments were made under the RFC5395/6195 rules, 
>and those RFCs say "IANA shall maintain a public archive of approved 
>templates."  The registry should point at that archive, not the 
>names of people.  And the archive should include static copies of 
>documents cited (e.g. i-d's).  I don't know if IANA is actually 
>maintaining that archive or, if so, where.
>
>I think the TA RR (32768) is one of only two type codes allocated 
>under the RFC2929 "Specification Required" rules, and the only one 
>with a non-RFC reference.  For ease of reference, I'd suggest that 
>IANA just archive the specification document in the same place as 
>the docs describing RRs assigned under 5395/6195.

Ok, there's more frustration in me than I put into the draft.  I've 
been trying to get IANA to clean up the citations for DNS parameters 
longer than I've had my current job, which means it's been at least 7 
years.

The ATMA record took quite a while to iron out (and it was).  That 
record was defined in a document owned by the ATM Association and 
available on that website.  (I discovered the document by doing a web 
search and hitting a Microsoft page with the reference.)  I tried to 
get the document listed at IANA.  But then the ATM association 
website disappeared, "bought up" by the MPLS association.  I began to 
try to get IANA to escrow the document.  Later on the MPLS website 
went away too, replaced by another.  Finally, IANA got "permission" 
from the owners of the document (whomever bought the MPLS-A that 
bought the ATM=A) to escrow the document.  That is why you now see 
this:

[ATMDOC]   ATM Forum Technical Committee, "ATM Name System, V2.0",
            Doc ID: AF-DANS-0152.000, July 2000. Available from
 
http://broadband-forum.org/ftp/pub/approved-specs/af-saa-0069.000.pdf
            and held in escrow by IANA.

So, now, in this draft I'm just putting in some data (names of 
documents, brief syntax descriptions) and dropping the hint that it 
would be good to have better references in the registry.

As far as trying to request IANA do this - I have and, well, life's 
too short.  So I'm just trying to chip in, as a volunteer, and say to 
anyone coming along later, if you want to find these types, try these 
documents and these locations.  No guarantees, no promises, and I'm 
not trying to change the world.

This was the second or third time in my career I've had to track 
these down.  I did this writing prototype code for RFC 2065 and 2535 
versions of DNSSEC.  I did it for my previous job for some reason. 
I'm doing it now for bookkeeping purposes.  I figure if I had written 
this down the first time, I would have saved me some time.

I'm just dropping bread crumbs.

---

From: Shane Kerr <[email-masked]>
Date: Mon, 10 Oct 2011 10:58:02 +0200

Ed,

I think this document is useful, and support it going forward.

>      Title         : IANA Allocated DNS RRtyp Codes without Documentation

s/RRtyp/RRtype/

>      Filename      : draft-lewis-dns-undocumented-types-00.txt

We did some digging recently when documenting RRTypes for BIND 10.

For EID and NIMLOC, there is this document:

http://ana-3.lcs.mit.edu/~jnc/nimrod/dns.txt

Which seems to be a -01 version of the draft listed in your document.
There are some differences in the text (for example it says "protocol
spec [[[ref to be supplied]]]" rather than "protocol [[[ref to be
supplied]]]"), but I don't know if these are meaningful. (Surely not for
such a vintage routing architecture.)

For the rest, you came up with the same references we did.

FWIW, our list of lower-priority RR types is here:

http://bind10.isc.org/wiki/RRTypes

We don't have all the ones you list, because I considered many of them
to be works in progress (CDS, URI, CAA, ...).

--
Shane

---

From: Edward Lewis <[email-masked]>
Date: Tue, 11 Oct 2011 14:15:46 -0400

Thanks for the update.  Note that I'm not calling these 
"unimportant", just "undocumented." ;)