In message <20140605230244.5929.qm...@joyce.lan>, "John Levine" writes:
>
> In article 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.
In article 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 beginning
to end. By the time 4408 came out, there wa
On Thu, Jun 05, 2014 at 08:18:00PM +0200, Reindl Harald wrote:
> 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
Interesting -- go figure.
> "no ip nat service alg udp dns"
> "no ip nat
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 o
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" wrote:
>
>
> Am 05.06.2014 17:58, schrieb /dev/rob0:
> > On Thu, Jun 05, 2014 at 05:21:
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 wrote:
> On 6/5/2014 10:34 AM, Mike Hoskins
Hi Nicholas,
At 07:25 05-06-2014, Nicholas F Miller wrote:
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
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
On 6/5/2014 10:34 AM, Mike Hoskins (michoski) wrote:
-Original Message-
From: Nicholas F Miller
Date: Thursday, June 5, 2014 at 10:25 AM
To: "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:
"S
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 is
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 ar
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 /var/named/chroot/var/named/zones
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 f
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
-Original Message-
From: Nicholas F Miller
Date: Thursday, June 5, 2014 at 10:25 AM
To: "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 records MUST be published as a DNS TXT (type 16)
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 support
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 s
Hi!
Today I managed that Bind 9.9.5 created a signed zone with all RRs
signed except the SOA. The private RRs showed "finshed signing". Only
after another "rndc loadkeys" also the SOA was signed.
Unfortunately I can not reproduce the problem, but I suspect it may be
related to the order how I add
18 matches
Mail list logo
