Ask Your Question

How can I display DNS time to live (TTL) in Days Hours Minutes Seconds format?

asked 2019-12-07 16:57:43 +0000

decuser gravatar image

updated 2019-12-08 00:36:58 +0000

In some videos pertaining to Wireshark (see screenshot below), I have seen TTL values such as: 20 hours, 50 minutes, 25 seconds, but in the interface I cannot figure out how to get this format of display, it is always a single number representing seconds. Am I missing a setting somewhere?


edit retag flag offensive close merge delete


Can you post a link to one of the videos showing this?

Chuckc gravatar imageChuckc ( 2019-12-07 19:48:08 +0000 )edit

@bubbasnmp added screenshot of Chappell video segment showing the DNS ttl.

decuser gravatar imagedecuser ( 2019-12-08 00:37:56 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2019-12-07 22:37:21 +0000

Guy Harris gravatar image

Do those videos show Wireshark displaying the TTL in that fashion or do they just describe the raw numeric value in that fashion in, for example, slides shown in the video?

There's no setting in the shipping version of Wireshark to cause the TTL to be shown in that form, so you'd have to request a change to Wireshark to cause it to show them in that fashion; please file an enhancement request on the Wireshark Bugzilla.

edit flag offensive delete link more


I posted a screenshot. it's of an old video, ca. 2009, perhaps it used to work this way? I'll file an enhancement (regression, maybe) request.

decuser gravatar imagedecuser ( 2019-12-08 00:41:45 +0000 )edit

It used to work this way; commit 42c52d86127263dcb84791f7213726964a3ef025 was checked in on 2013-10-18, and that changed the format.

It can be changed back without too much effort by changing the field type from FT_UINT32 to FT_RELATIVE_TIME and arranging that relative time values have both "signed" and "unsigned" versions of the various representations (DNS TTLs are unsigned, although any TTL value with the uppermost bit set is not guaranteed to be handled correctly by all recipients - RFC 1035 said "signed" in one place and "unsigned' in another, and RFC 2181 resolves the ambiguity by saying "unsigned, but limit values to 0 to 2^31-1).

Guy Harris gravatar imageGuy Harris ( 2019-12-08 01:27:43 +0000 )edit

image description

There are fields for SOA and RRSIG that have the format you're looking for.

ti = proto_tree_add_item(rr_tree, hf_dns_rrsig_original_ttl, tvb, cur_offset, 4, ENC_BIG_ENDIAN);
proto_item_append_text(ti, " (%s)", signed_time_secs_to_str(wmem_packet_scope(), tvb_get_ntohl(tvb, cur_offset)));

Also image description hf_dns_soa_refresh_interval, hf_dns_soa_retry_interval, hf_dns_soa_expire_limit, hf_dns_soa_minimum_ttl

Chuckc gravatar imageChuckc ( 2019-12-08 02:13:15 +0000 )edit

The examples above are from the existing code so might help in your bugzilla request.

Chuckc gravatar imageChuckc ( 2019-12-08 02:22:36 +0000 )edit

Some time fields get a detailed breakdown after them, some don't. They should probably all be converted to FT_RELATIVE_TIME (or maybe we should have separate signed and unsigned versions of that type), which will automatically put the detailed breakdown into the field.

Guy Harris gravatar imageGuy Harris ( 2019-12-08 03:33:54 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2019-12-07 16:57:43 +0000

Seen: 370 times

Last updated: Dec 08 '19