TTL not default for single RRset

[jschlyter]

It seems that if you specify TTL for the first RR of an RRset, the TTL is not propagated to the rest of the RRset, e.g.:

@       300     MX      0 spg.kirei.se.
                MX      5 spg-ipv4.kirei.se.

results in:

"TTL values differ within an RR set"

[tobez]

On Wed, Nov 02, 2011 at 06:59:24AM -0700, Jakob Schlyter wrote:

It seems that if you specify TTL for the first RR of an RRset, the TTL is not propagated to the rest of the RRset, e.g.:

@       300     MX      0 spg.kirei.se.
                MX      5 spg-ipv4.kirei.se.

results in:

"TTL values differ within an RR set"

Could you quickly point me to a relevant standard that says it should be
like this?

Thanks,

\Anton.

Our society can survive even a large amount of irrational regulation.
-- John McCarthy

[jschlyter]

On 2 nov 2011, at 15:02, Anton Berezin wrote:

On Wed, Nov 02, 2011 at 06:59:24AM -0700, Jakob Schlyter wrote:

It seems that if you specify TTL for the first RR of an RRset, the TTL is not propagated to the rest of the RRset, e.g.:

@ 300 MX 0 spg.kirei.se.
MX 5 spg-ipv4.kirei.se.

results in:

"TTL values differ within an RR set"

Could you quickly point me to a relevant standard that says it should be
like this?

RFC 1035 says:

contents take one of the following forms:

[<TTL>] [<class>] <type> <RDATA>

[<class>] [<TTL>] <type> <RDATA>

The RR begins with optional TTL and class fields, followed by a type and
RDATA field appropriate to the type and class. Class and type use the
standard mnemonics, TTL is a decimal integer. Omitted class and TTL
values are default to the last explicitly stated values. Since type and
class mnemonics are disjoint, the parse is unique. (Note that this
order is different from the order used in examples and the order used in
the actual RRs; the given order allows easier parsing and defaulting.)

This can of course be interpreted in different ways, but at least BIND parses the zone file as I want it :-)

jakob

[miekg]

One of the reasons validns is (was?) so fast, is that things like this aren't implemented! I have no problem with a tool that only works correctly with a zone (re)formated with 'named-compilezone -s full'

[tobez]

On Wed, Nov 02, 2011 at 07:07:50AM -0700, Jakob Schlyter wrote:

On 2 nov 2011, at 15:02, Anton Berezin wrote:

On Wed, Nov 02, 2011 at 06:59:24AM -0700, Jakob Schlyter wrote:

It seems that if you specify TTL for the first RR of an RRset, the TTL is not propagated to the rest of the RRset, e.g.:

@ 300 MX 0 spg.kirei.se.
MX 5 spg-ipv4.kirei.se.

results in:

"TTL values differ within an RR set"

Could you quickly point me to a relevant standard that says it should be
like this?

RFC 1035 says:

contents take one of the following forms:

[<TTL>] [<class>] <type> <RDATA>

[<class>] [<TTL>] <type> <RDATA>

The RR begins with optional TTL and class fields, followed by a type and
RDATA field appropriate to the type and class. Class and type use the
standard mnemonics, TTL is a decimal integer. Omitted class and TTL
values are default to the last explicitly stated values. Since type and
class mnemonics are disjoint, the parse is unique. (Note that this
order is different from the order used in examples and the order used in
the actual RRs; the given order allows easier parsing and defaulting.)

This can of course be interpreted in different ways, but at least BIND parses the zone file as I want it :-)

The problem with this is my reading of RFC 2038:

The Master File format [RFC 1035 Section 5] is extended to include
the following directive:

                       $TTL <TTL> [comment]

All resource records appearing after the directive, and which do not
explicitly include a TTL value, have their TTL set to the TTL given
in the $TTL directive.

The current implementation of validns behaves as RFC 1035 specifies
if there is no $TTL, and as RFC 2038 specifies if there is one:

$ cat ttl.zone
$ORIGIN example.com.
@ IN 200 SOA ns hostmaster 1 10800 3600 2592000 1200
IN NS ns
ns IN A 192.0.2.1

@ 300 MX 0 spg.kirei.se.
MX 5 spg-ipv4.kirei.se.
$ validns -v ttl.zone
-> ttl.zone:1: origin is now example.com.
-> ttl.zone:2: example.com. IN 200 SOA ns.example.com. hostmaster.example.com. 1 10800 3600 2592000 1200
-> ttl.zone:3: example.com. IN 200 NS ns.example.com.
-> ttl.zone:4: ns.example.com. IN 200 A 192.0.2.1
-> ttl.zone:6: example.com. IN 300 MX 0 spg.kirei.se.
-> ttl.zone:7: example.com. IN 300 MX 5 spg-ipv4.kirei.se.

$ cat ttl1.zone
$ORIGIN example.com.
@ IN 200 SOA ns hostmaster 1 10800 3600 2592000 1200
IN NS ns
ns IN A 192.0.2.1
$TTL 600
@ 300 MX 0 spg.kirei.se.
MX 5 spg-ipv4.kirei.se.
$ validns -v ttl1.zone
-> ttl1.zone:1: origin is now example.com.
-> ttl1.zone:2: example.com. IN 200 SOA ns.example.com. hostmaster.example.com. 1 10800 3600 2592000 1200
-> ttl1.zone:3: example.com. IN 200 NS ns.example.com.
-> ttl1.zone:4: ns.example.com. IN 200 A 192.0.2.1
-> ttl1.zone:5: default ttl is now 600
-> ttl1.zone:6: example.com. IN 300 MX 0 spg.kirei.se.
-> ttl1.zone:7: example.com. IN 600 MX 5 spg-ipv4.kirei.se.
ttl1.zone:7: TTL values differ within an RR set

I guess I will have to investigate how BIND behaves and emulate
its behavior.

\Anton.

Our society can survive even a large amount of irrational regulation.
-- John McCarthy