I have a suspect: May it be that rndc signing nsec3param adds the
NSEC3PARAM RR internally to the unsigned zone file. Thus, calling rndc
signing nsec3param does not work before the initial zone transfer.
This would mean I have to check when the initial transfer succeeded
before calling rndc
Are SPF RR types finally dead or not? I’ve read through rfc7208 it appears that
they are:
SPF records MUST be published as a DNS TXT (type 16) Resource Record
(RR) [RFC1035] only. The character content of the record is encoded
as [US-ASCII]. Use of alternative DNS RR types was
-Original Message-
From: Nicholas F Miller nicholas.mil...@colorado.edu
Date: Thursday, June 5, 2014 at 10:25 AM
To: bind-users@lists.isc.org bind-users@lists.isc.org
Subject: SPF RR type
Are SPF RR types finally dead or not? I¹ve read through rfc7208 it
appears that they are:
SPF
Hi
how is that below possible?
* ns2.thelounge.net = Master
* ns1.thelounge.net = Slave
* both are using the same packages (VMwware clones)
* i removed the zone file on the slave and restarted named
* the zone was transferred for sure again with that new binary format
* that affactes *any* zone
uhm - look at the bottom - *they have* a zero TTL after named-compilezone
Am 05.06.2014 16:48, schrieb Reindl Harald:
Hi
how is that below possible?
* ns2.thelounge.net = Master
* ns1.thelounge.net = Slave
* both are using the same packages (VMwware clones)
* i removed the zone file on
what the hell invents $TTL 0 ; 0 seconds lines before
each CNAME block while on the master there is exactly
one TTL line with 86400 on top of the file?
_
master-zone:
[root@ns2:~]$ cat
On Thu, Jun 05, 2014 at 05:21:47PM +0200, Reindl Harald wrote:
what the hell invents $TTL 0 ; 0 seconds lines before
each CNAME block while on the master there is exactly
one TTL line with 86400 on top of the file?
The way named writes a zone file is not the way I would do it.
Records are
SPF records are not going away. It is the SPF RRTYPE (99) that may or not be
deprecated. The whole reason the SPF RRTYPE (99) may be deprecated is due to
the fact that most email providers honor the TXT RRTYPE (16) SPF and ignore the
SPF RRTYPE (99).
Your point about the delay until adoption
On 6/5/2014 10:34 AM, Mike Hoskins (michoski) wrote:
-Original Message-
From: Nicholas F Miller nicholas.mil...@colorado.edu
Date: Thursday, June 5, 2014 at 10:25 AM
To: bind-users@lists.isc.org bind-users@lists.isc.org
Subject: SPF RR type
Are SPF RR types finally dead or not? I¹ve
Am 05.06.2014 17:58, schrieb /dev/rob0:
On Thu, Jun 05, 2014 at 05:21:47PM +0200, Reindl Harald wrote:
what the hell invents $TTL 0 ; 0 seconds lines before
each CNAME block while on the master there is exactly
one TTL line with 86400 on top of the file?
The way named writes a zone file
Thanks for the link. It is an amusing read. I had no idea the SPF record was so
contentious.
_
Nicholas Miller, OIT, University of Colorado at Boulder
On Jun 5, 2014, at 10:18 AM, Kevin Darcy k...@chrysler.com wrote:
On 6/5/2014 10:34
Cisco routers do have the ability to doctor DNS packets when doing NAT.
When it doctors it sets the TTL to 0 but I dont know why it would only do
it on CNAME records.
On Jun 5, 2014 12:43 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 05.06.2014 17:58, schrieb /dev/rob0:
On Thu, Jun 05,
Am 05.06.2014 18:48, schrieb Ben Croswell:
Cisco routers do have the ability to doctor DNS packets when doing NAT
argh - and it is on by default
no ip nat service alg udp dns
no ip nat service alg tcp dns
When it doctors it sets the TTL to 0 but
I dont know why it would only do it on CNAME
In article mailman.348.1401978387.26362.bind-us...@lists.isc.org you write:
Are SPF RR types finally dead or not? I�ve read through rfc7208 it appears
that they are:
They're dead as in nobody looks at them other than legacy software
that hasn't been updated. The SPF record was a screwup from
In message 20140605230244.5929.qm...@joyce.lan, John Levine writes:
In article mailman.348.1401978387.26362.bind-us...@lists.isc.org you write:
Are SPF RR types finally dead or not? I've read through rfc7208 it appears
that they are:
They're dead as in nobody looks at them other than
15 matches
Mail list logo