Hello, I have a zonefile like this: ### snip ### $TTL 1d example.com. SOA ( .... ) example.com. NS ns1.example.com. example.com. NS ns2.example.com. example.com. 300 MX 42 mail.example.com. example.com. TXT "v=spf1 +all" ns1.example.com. A 192.0.2.1 ns2.example.com. A 192.0.2.1 mail.example.com. A 192.0.2.3 ### snap ### Notice the intension to lower only the ttl for the mx. The SOA and NS-Record use $TTL Valie 1d. But all records *after* the mx have also a TTL of 300s. What's my fault? Who do I write a zonefile containing only those ttl which are different from $TTL ? Is there a formal definition for zonefiles? Thanks ... -- Andreas Schulze Internetdienste | P532 DATEV eG 90329 N?rnberg | Telefon +49 911 319-0 | Telefax +49 911 319-3196 E-Mail info @datev.de | Internet www.datev.de Sitz: 90429 N?rnberg, Paumgartnerstr. 6-14 | Registergericht N?rnberg, GenReg Nr.70 Vorstand Prof. Dieter Kempf (Vorsitzender) Dipl.-Kfm. Wolfgang Stegmann (stellvertretender Vorsitzender) Dipl.-Kfm. Michael Leistenschneider J?rg Rabe v. Pappenheim Dipl.-Vw. Eckhard Schwarzer Vorsitzender des Aufsichtsrates: Reinhard Verholen
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Andreas, This is according to spec. RFC 1035 says that omitted class and TTL values are default to the last explicitly stated values. If you want the records after the MX to have a TTL of 1d, you should add explicitly say so; either by adding the line: $TTL 1d after the MX record, or by giving the TXT record an explicit TTL of 1d. Best regards, Matthijs On 11/09/2010 01:42 PM, Andreas Schulze wrote:> Hello, > > I have a zonefile like this: > > ### snip ### > $TTL 1d > > example.com. SOA ( > .... ) > example.com. NS ns1.example.com. > example.com. NS ns2.example.com. > example.com. 300 MX 42 mail.example.com. > example.com. TXT "v=spf1 +all" > ns1.example.com. A 192.0.2.1 > ns2.example.com. A 192.0.2.1 > mail.example.com. A 192.0.2.3 > > ### snap ### > > Notice the intension to lower only the ttl for the mx. > > The SOA and NS-Record use $TTL Valie 1d. > But all records *after* the mx have also a TTL of 300s. > > What's my fault? > Who do I write a zonefile containing only those ttl which are different from $TTL ? > Is there a formal definition for zonefiles? > > Thanks ... >-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJM2UZfAAoJEA8yVCPsQCW5C70IAMr7dS/3yOH5JdMnnPRp7HM/ rjyVhEZS7j6o9uVfHIS9tdtCLADrQ7s93T03SBpoMTkL71IfpN0gnfMgtHkwUrQE EqE/qfo9q2+5Il22YczYUn3v2Fum1215IYcGl96bseyGhHSgiqyxw8wS9qS2pabX 3oxBxzvy26nXNm8bekramK1jk+JJPM2DeOcnFKDhUKFvELsHGpt8GjnTWN95gpzC i9z3gvqUx9Io8W7yA8tqgvkW9O+lxO3oDioay+Ic5v3PmpslcifI/PeO6nxEoZsy 5GNsjplngIHdc1dL4D5+W3QLSC2JGM0e7gbp8xutrmilttkG24Zz/eMJsB4XFlk=qwOa -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hmm, May I ask you what version NSD you are using? I tried to load a similar zone in the latest version and all records except the MX have a TTL of 1d. Best regards, Matthijs On 11/09/2010 01:42 PM, Andreas Schulze wrote:> Hello, > > I have a zonefile like this: > > ### snip ### > $TTL 1d > > example.com. SOA ( > .... ) > example.com. NS ns1.example.com. > example.com. NS ns2.example.com. > example.com. 300 MX 42 mail.example.com. > example.com. TXT "v=spf1 +all" > ns1.example.com. A 192.0.2.1 > ns2.example.com. A 192.0.2.1 > mail.example.com. A 192.0.2.3 > > ### snap ### > > Notice the intension to lower only the ttl for the mx. > > The SOA and NS-Record use $TTL Valie 1d. > But all records *after* the mx have also a TTL of 300s. > > What's my fault? > Who do I write a zonefile containing only those ttl which are different from $TTL ? > Is there a formal definition for zonefiles? > > Thanks ... >-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJM2WRpAAoJEA8yVCPsQCW5vE4IAL34abuFiuBw9MBkJ3h6MBug YCO4EIMbfS8FsBXs9v83cF72jH7UfSlYO2bpwsg7DObMlEGfgJIVoIGTsM5W05Fm JPibxMwK2yZPoiXrmTsMyOr5Y3/Tfgj1Y+NJG/MCrPfscdDN7jnmzUN4yj5smIdD Eaz8w13xNV0w1y4UZhzhX+lNPUNui1Zj5jUdYdj2ru8bXTs+/aFyx/2qn5TvJhoJ ZhfFdioYQpTtGDlLzWzL8k0C7yMP8X7I2wB/nvYYoJLDxw+oU5zNJnP5qgd9r9R6 1+xqW7FKA5NrRjoeRBqYLSlRo1vbd3D2W5lO6hq7emRM3RUU+v9srALzeGWJyAA=rYXy -----END PGP SIGNATURE-----