How can I get the default ttl.

[hanbaga]

ttl is the _MasterReader 's attribute.
but how can I get it.

[rthalley]

On Apr 2, 2014, at 20:03, hanbaga notifications@github.com wrote:

ttl is the _MasterReader 's attribute.
but how can I get it.

What are you trying to do? "default TTL" is meaningful only when reading a masterfile, and is set with a $TTL statement in the masterfile.

/Bob

[hanbaga]

I want to parse a zone file, and want to know everything of the zone file.

[rthalley]

On Apr 2, 2014, at 20:42, hanbaga notifications@github.com wrote:

I want to parse a zone file, and want to know everything of the zone file.

After you parse the zone file, all rdatasets in the zone will have TTLs. There is no meaning to "default TTL" once the masterfile has been read.

/Bob

[spacekpe]

Another problem is that you can have multiple $TTL values in one master file. What value should be returned as "default"?

However I can see hanbaga's point. I personally do zone file -> LDIF conversions and I will have to solve the same problem in future.

Bob, would you accept a patch adding "default_ttl" attribute to the Zone class?

I would initialize it to None and fill it with an value only if zone file contained $TTL directives with the same value (and set None otherwise). It seems like pretty straightforward patch. I think I can write it...

[rthalley]

On Apr 4, 2014, at 11:35, spacekpe notifications@github.com wrote:

Another problem is that you can have multiple $TTL values in one master file. What value should be returned as "default"?

However I can see hanbaga's point. I personally do zone file -> LDIF conversions and I will have to solve the same problem in future.

Bob, would you accept a patch adding "default_ttl" attribute to the Zone class?

I would initialize it to None and fill it with an value only if zone file contained $TTL directives with the same value (and set None otherwise). It seems like pretty straightforward patch. I think I can write it..

I've got some issues with it.

As you said, there can be multiple $TTL values in masterfiles, why is one of them "the default TTL" and the others forgotten?

What are you going to do with this information? Use it when adding new RRs to the zone?

I wouldn't recommend using such a value for generating masterfiles as it can cause a subtle problem. Consider:

masterfile 1

$TTL 30
a 30 in a 10.0.0.1
b in a 10.0.0.2

In this masterfile, 'a' has been explicitly given a TTL of 30, and 'b' is given the default TTL (at the time!) which happens to be 30. If we used this "default TTL" value to regenerate the masterfile we'd get

masterfile 2

$TTL 30
a in a 10.0.0.1
b in a 10.0.0.2

which is subtly different. In the first file if someone changes $TTL to 300, then only 'b' is affected, but in the second file both 'a' and 'b' are changed. That may be OK, or it may be bad!

[spacekpe]

why is one of them "the default TTL" and the others forgotten?

I propose to return default_ttl if and only if all $TTL values in a master file are equal (which typically means that there is single instance of $TTL). I would return None if multiple conflicting $TTL directives are present.

What are you going to do with this information?

As I said before, I'm converting master files from format defined in RFC 1035 to LDIF format (used for import to LDAP database).

I wouldn't recommend using such a value for generating masterfiles as it can cause a subtle problem.

I agree that it can create interesting problems. However, I'm interested only in reading.

[rthalley]

I'm still concerned about the default_ttl proposal as it doesn't differentiate between "I set the TTL on this record by using the value of $TTL", and "the value of the TTL on this record was explicitly specified but happens to be the same as the current value of $TTL". In the later case, when converting you will say something has the "default value", which potentially destroys information in the target format.

Nevertheless, I'll merge the fix spacekpe proposes if it gets written. I'd request that the comment on the default_ttl zone attribute carefully describes the risks.

[tungstencarbide]

Late to the party here, but it seems as though even the current way it's handled some information is lost about the zone "as-written" even though all the "as-it-functions" information is preserved (obviously the most important part). For a given record, was that the TTL assigned to it, or was it from a previous $TTL directive?

Perhaps each record in in a record set can be marked with "ttl" as it is now (the "effective" TTL), and then the "default_ttl" and the "specified_ttl" if you're interested in the "as-written" information. Still not the whole "as-written" picture, but perhaps more than was captured previously. Perhaps the default_ttl could even be a simple object instead of just the int value so that individual records could be tied back to the actual $TTL directive that commanded them and perhaps be changed as a group. Still might not even capture the whole intent of a given zone file, but theres only so much we can do given the limitations of $TTL as descriptor of the "why".

I'll give it consideration and maybe when I'm done with my current push at work circle around to this.