Re: Bind ignoring signing -nsec3param when inline-signing a zone
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 signing nsec3param - this is not nice.
Are there any workarounds for that? IMO it would be cool if Bind would
store NSEC3 options outside of the zone.
Thanks
Klaus
On 05.06.2014 14:02, Klaus Darilion wrote:
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 the zone for signing to Bind, as up to
now I sent lots of rndc commands to Bind.
Therefore I simplified my provision to only:
1. Create the keys
2. Add the zone to Bind via rndc:
zone pernau.at {
type slave;
file /etc/bind/zones/p/pernau.at/pernau.at;
masters { 88.198.53.113; };
key-directory /etc/bind/keys/p/pernau.at;
auto-dnssec maintain;
inline-signing yes;
};
Is it safe to consider that this will start the incoming zone transfer
and signing (without the need for an rndc sign command)?
3. Configure NSEC3:
rndc signing -nsec3param 1 0 10 E1BDC7F3624A9508 pernau.at
The problem is, that the nsec3param command is received by Bind but
ignored: as you can see there is no zone_addnsec3chain() logging:
11:47:53: received control channel command 'addzone pernau.at {...}'
11:47:53: zone pernau.at added to view _default via addzone
11:47:53: received control channel command 'signing -nsec3param 1 0 10
F2195A3D604B7EC8 pernau.at'
11:47:53: zone pernau.at/IN (unsigned): Transfer started.
11:47:53: transfer of 'pernau.at/IN (unsigned)' from 88.198.53.113#53:
connected using 83.136.34.28#53286
11:47:53: zone pernau.at/IN (unsigned): transferred serial 85
11:47:53: transfer of 'pernau.at/IN (unsigned)' from 88.198.53.113#53:
Transfer completed: 1 messages, 78 records, 2007 bytes, 0.033 secs
(60818 bytes/sec)
11:47:53: zone pernau.at/IN (signed): loaded serial 85
11:47:53: zone pernau.at/IN (signed): receive_secure_serial: unchanged
11:47:53: zone pernau.at/IN (signed): receive_secure_serial: unchanged
11:47:53: zone pernau.at/IN (signed): sending notifies (serial 85)
11:47:53: zone pernau.at/IN (signed): reconfiguring zone keys
11:47:53: zone pernau.at/IN (signed): next key event: 05-Jun-2014
12:47:53.563
# rndc signing -nsec3param 1 0 10 E1BDC7F3624A9508 pernau.at
request queued
11:48:23: received control channel command 'signing -nsec3param 1 0 10
E1BDC7F3624A9508 pernau.at'
11:48:23: zone pernau.at/IN (signed):
zone_addnsec3chain(1,CREATE,10,E1BDC7F3624A9508)
11:48:23: zone pernau.at/IN (signed): sending notifies (serial 106)
As you see, only after the second rndc signing -nsec3param command
Bind switched to NSEC3. I think this is due to the nsec3 command is sent
immediately after the add zone command.
So, is this a bug in Bind or do I have to provision Bind different?
Another question: is it possible to instruct Bind to use NSEC3 from the
beginning? I read this can be done with dynamic updates, but in my setup
with inline-signing I suspect this is not possible.
Thanks
Klaus
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
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) Resource Record (RR) [RFC1035] only. The character content of the record is encoded as [US-ASCII]. Use of alternative DNS RR types was supported in SPF's experimental phase but has been discontinued. ...but to confuse the issue rfc7208 goes on to say: If a future update to SPF were developed that did not reuse existing SPF records, it could use the SPF RR type. SPF's use of the TXT RR type for structured data should in no way be taken as precedent for future protocol designers.” Bind-9.10.0-P1 still reports errors if you don’t have SPF RRs defined with the SPF TXT records or are not using 'check-spf ignore’. Should one keep existing SPF RRs or remove them? Will future versions of bind stop reporting errors when SPF RRs don’t exist? _ Nicholas Miller, OIT, University of Colorado at Boulder ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SPF RR type
-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 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 supported in SPF's experimental phase but has been discontinued. ...but to confuse the issue rfc7208 goes on to say: If a future update to SPF were developed that did not reuse existing SPF records, it could use the SPF RR type. SPF's use of the TXT RR type for structured data should in no way be taken as precedent for future protocol designers.² Bind-9.10.0-P1 still reports errors if you don¹t have SPF RRs defined with the SPF TXT records or are not using 'check-spf ignore¹. Should one keep existing SPF RRs or remove them? Will future versions of bind stop reporting errors when SPF RRs don¹t exist? RFC 7208 is dated April 2014... Even if/when BIND stops complaining, how long will it take for the Internet to align with the new standard? :-) Look how long BCP38's existed and how many networks don't align despite obvious benefits to the Internet at large. I know it's a different ball of wax...but only kinda. During such transitional periods, I suggest maintaing the old form for at least awhile (probably a couple years) to give the world time to update its configuration. There used to be quite a few major mail providers who would bounce or at least flag as spam any mail from hosts not represented in the domain's SPF TXT record...so the choice of when to change depends on how much you care (or your users will complain) about misbehaved mail delivery. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Slave zero-TTL on CNAMES
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 on that both servers how can the slave give a different answer [root@ns1:~]$ rpm -qa | grep bind bind-license-9.9.3-15.P2.fc19.noarch bind-9.9.3-15.P2.fc19.x86_64 bind-utils-9.9.3-15.P2.fc19.x86_64 bind-chroot-9.9.3-15.P2.fc19.x86_64 bind-libs-9.9.3-15.P2.fc19.x86_64 bind-libs-lite-9.9.3-15.P2.fc19.x86_64 __ [harry@srv-rhsoft:~]$ dig www.rhsoft.net @ns1.thelounge.net ; DiG 9.9.4-P2-RedHat-9.9.4-12.P2.fc20 www.rhsoft.net @ns1.thelounge.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 54655 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 3072 ;; QUESTION SECTION: ;www.rhsoft.net.IN A ;; ANSWER SECTION: www.rhsoft.net. 0 IN CNAME proxy.thelounge.net. proxy.thelounge.net.86400 IN A 91.118.73.4 ;; Query time: 19 msec ;; SERVER: 85.124.176.242#53(85.124.176.242) ;; WHEN: Do Jun 05 16:43:38 CEST 2014 ;; MSG SIZE rcvd: 89 __ [harry@srv-rhsoft:~]$ dig www.rhsoft.net @ns2.thelounge.net ; DiG 9.9.4-P2-RedHat-9.9.4-12.P2.fc20 www.rhsoft.net @ns2.thelounge.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 2758 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 3072 ;; QUESTION SECTION: ;www.rhsoft.net.IN A ;; ANSWER SECTION: www.rhsoft.net. 86400 IN CNAME proxy.thelounge.net. proxy.thelounge.net.86400 IN A 91.118.73.4 ;; Query time: 12 msec ;; SERVER: 91.118.73.16#53(91.118.73.16) ;; WHEN: Do Jun 05 16:43:41 CEST 2014 ;; MSG SIZE rcvd: 89 __ signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slave zero-TTL on CNAMES
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 the slave and restarted named * the zone was transferred for sure again with that new binary format * that affactes *any* zone on that both servers how can the slave give a different answer [root@ns1:~]$ rpm -qa | grep bind bind-license-9.9.3-15.P2.fc19.noarch bind-9.9.3-15.P2.fc19.x86_64 bind-utils-9.9.3-15.P2.fc19.x86_64 bind-chroot-9.9.3-15.P2.fc19.x86_64 bind-libs-9.9.3-15.P2.fc19.x86_64 bind-libs-lite-9.9.3-15.P2.fc19.x86_64 __ [harry@srv-rhsoft:~]$ dig www.rhsoft.net @ns1.thelounge.net ; DiG 9.9.4-P2-RedHat-9.9.4-12.P2.fc20 www.rhsoft.net @ns1.thelounge.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 54655 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 3072 ;; QUESTION SECTION: ;www.rhsoft.net.IN A ;; ANSWER SECTION: www.rhsoft.net. 0 IN CNAME proxy.thelounge.net. proxy.thelounge.net.86400 IN A 91.118.73.4 ;; Query time: 19 msec ;; SERVER: 85.124.176.242#53(85.124.176.242) ;; WHEN: Do Jun 05 16:43:38 CEST 2014 ;; MSG SIZE rcvd: 89 __ [harry@srv-rhsoft:~]$ dig www.rhsoft.net @ns2.thelounge.net ; DiG 9.9.4-P2-RedHat-9.9.4-12.P2.fc20 www.rhsoft.net @ns2.thelounge.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 2758 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 3072 ;; QUESTION SECTION: ;www.rhsoft.net.IN A ;; ANSWER SECTION: www.rhsoft.net. 86400 IN CNAME proxy.thelounge.net. proxy.thelounge.net.86400 IN A 91.118.73.4 ;; Query time: 12 msec ;; SERVER: 91.118.73.16#53(91.118.73.16) ;; WHEN: Do Jun 05 16:43:41 CEST 2014 ;; MSG SIZE rcvd: 89 [root@ns1:~]$ named-compilezone -f raw -F text -o /var/named/chroot/var/named/slaves/rhsoft.net.dns rhsoft.net /var/named/chroot/var/named/slaves/rhsoft.net.dns zone rhsoft.net/IN: loaded serial 1226095186 dump zone to /var/named/chroot/var/named/slaves/rhsoft.net.dns...done OK [root@asterisk:~]$ cat /var/named/chroot/var/named/slaves/rhsoft.net.dns rhsoft.net. 86400 IN SOA ns2.thelounge.net. hostmaster.thelounge.net. 1226095186 3600 1800 1814400 3600 rhsoft.net. 86400 IN NS ns2.thelounge.net. rhsoft.net. 86400 IN NS ns1.thelounge.net. rhsoft.net. 86400 IN A91.118.73.4 rhsoft.net. 86400 IN MX 10 barracuda.thelounge.net. rhsoft.net. 86400 IN TXT v=spf1 ip4:91.118.73.0/24 ip4:89.207.144.27 ip4:62.178.103.85 -all rhsoft.net. 86400 IN SPF v=spf1 ip4:91.118.73.0/24 ip4:89.207.144.27 ip4:62.178.103.85 -all www.rhsoft.net. 0 IN CNAME proxy.thelounge.net. signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slave zero-TTL on CNAMES
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/rhsoft.net.dns | grep TTL $TTL 86400 3600; Negative-TTL [root@ns2:~]$ cat /var/named/chroot/var/named/zones/rhsoft.net.dns | grep TTL | wc -l 2 _ slave: [root@ns1:~]$ cat /var/named/chroot/var/named/slaves/rhsoft.net.dns | grep TTL $TTL 86400 ; 1 day $TTL 0 ; 0 seconds $TTL 86400 ; 1 day $TTL 0 ; 0 seconds $TTL 86400 ; 1 day $TTL 0 ; 0 seconds $TTL 86400 ; 1 day $TTL 0 ; 0 seconds [root@ns1:~]$ cat /var/named/chroot/var/named/slaves/rhsoft.net.dns $ORIGIN . $TTL 86400 ; 1 day rhsoft.net IN SOA ns2.thelounge.net. hostmaster.thelounge.net. ( 1226095186 ; serial 3600 ; refresh (1 hour) 1800 ; retry (30 minutes) 1814400; expire (3 weeks) 3600 ; minimum (1 hour) ) NS ns2.thelounge.net. NS ns1.thelounge.net. A 91.118.73.4 MX 10 barracuda.thelounge.net. TXT v=spf1 ip4:91.118.73.0/24 ip4:89.207.144.27 ip4:62.178.103.85 -all SPF v=spf1 ip4:91.118.73.0/24 ip4:89.207.144.27 ip4:62.178.103.85 -all $ORIGIN rhsoft.net. $TTL 0 ; 0 seconds autoconfig CNAME autoconfig.thelounge.net. autodiscoverCNAME autodiscover-non-tls.thelounge.net. Am 05.06.2014 17:02, schrieb Reindl Harald: 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 the slave and restarted named * the zone was transferred for sure again with that new binary format * that affactes *any* zone on that both servers how can the slave give a different answer [root@ns1:~]$ rpm -qa | grep bind bind-license-9.9.3-15.P2.fc19.noarch bind-9.9.3-15.P2.fc19.x86_64 bind-utils-9.9.3-15.P2.fc19.x86_64 bind-chroot-9.9.3-15.P2.fc19.x86_64 bind-libs-9.9.3-15.P2.fc19.x86_64 bind-libs-lite-9.9.3-15.P2.fc19.x86_64 __ [harry@srv-rhsoft:~]$ dig www.rhsoft.net @ns1.thelounge.net ; DiG 9.9.4-P2-RedHat-9.9.4-12.P2.fc20 www.rhsoft.net @ns1.thelounge.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 54655 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 3072 ;; QUESTION SECTION: ;www.rhsoft.net.IN A ;; ANSWER SECTION: www.rhsoft.net. 0 IN CNAME proxy.thelounge.net. proxy.thelounge.net.86400 IN A 91.118.73.4 ;; Query time: 19 msec ;; SERVER: 85.124.176.242#53(85.124.176.242) ;; WHEN: Do Jun 05 16:43:38 CEST 2014 ;; MSG SIZE rcvd: 89 __ [harry@srv-rhsoft:~]$ dig www.rhsoft.net @ns2.thelounge.net ; DiG 9.9.4-P2-RedHat-9.9.4-12.P2.fc20 www.rhsoft.net @ns2.thelounge.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 2758 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 3072 ;; QUESTION SECTION: ;www.rhsoft.net.IN A ;; ANSWER SECTION: www.rhsoft.net. 86400 IN CNAME proxy.thelounge.net. proxy.thelounge.net.86400 IN A 91.118.73.4 ;; Query time: 12 msec ;; SERVER: 91.118.73.16#53(91.118.73.16) ;; WHEN: Do Jun 05 16:43:41 CEST 2014 ;; MSG SIZE rcvd: 89 [root@ns1:~]$ named-compilezone -f raw -F text -o /var/named/chroot/var/named/slaves/rhsoft.net.dns rhsoft.net /var/named/chroot/var/named/slaves/rhsoft.net.dns zone rhsoft.net/IN: loaded serial 1226095186 dump zone to /var/named/chroot/var/named/slaves/rhsoft.net.dns...done OK [root@asterisk:~]$ cat /var/named/chroot/var/named/slaves/rhsoft.net.dns rhsoft.net. 86400 IN SOA ns2.thelounge.net. hostmaster.thelounge.net. 1226095186 3600 1800 1814400 3600 rhsoft.net. 86400 IN NS ns2.thelounge.net. rhsoft.net. 86400 IN NS
Re: Slave zero-TTL on CNAMES
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 strictly in alphabetic order, and $TTL blocks are made around all RRSETs where TTL varies. The zone FILE is not your problem. I don't know exactly what the problem might be. It seems that something is intercepting and filtering the zone transfers? You could try transfers manually from the slave: dig [key auth if required] rhsoft.net. axfr @91.118.73.16 Does that show any zero TTLs? If so I suggest you place a couple of sniffers at strategic spots, one leaving the master, another entering the slave, and force a zone transfer. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if /dev/rob0 is in the Subject: ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SPF RR type
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 spot one. I am just wondering if SPF RRTYPE (99) are deprecated and if/when Bind will stop alerting on them if they are. _ Nicholas Miller, OIT, University of Colorado at Boulder On Jun 5, 2014, at 8:34 AM, Mike Hoskins (michoski) micho...@cisco.com 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 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 supported in SPF's experimental phase but has been discontinued. ...but to confuse the issue rfc7208 goes on to say: If a future update to SPF were developed that did not reuse existing SPF records, it could use the SPF RR type. SPF's use of the TXT RR type for structured data should in no way be taken as precedent for future protocol designers.² Bind-9.10.0-P1 still reports errors if you don¹t have SPF RRs defined with the SPF TXT records or are not using 'check-spf ignore¹. Should one keep existing SPF RRs or remove them? Will future versions of bind stop reporting errors when SPF RRs don¹t exist? RFC 7208 is dated April 2014... Even if/when BIND stops complaining, how long will it take for the Internet to align with the new standard? :-) Look how long BCP38's existed and how many networks don't align despite obvious benefits to the Internet at large. I know it's a different ball of wax...but only kinda. During such transitional periods, I suggest maintaing the old form for at least awhile (probably a couple years) to give the world time to update its configuration. There used to be quite a few major mail providers who would bounce or at least flag as spam any mail from hosts not represented in the domain's SPF TXT record...so the choice of when to change depends on how much you care (or your users will complain) about misbehaved mail delivery. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SPF RR type
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 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 supported in SPF's experimental phase but has been discontinued. ...but to confuse the issue rfc7208 goes on to say: If a future update to SPF were developed that did not reuse existing SPF records, it could use the SPF RR type. SPF's use of the TXT RR type for structured data should in no way be taken as precedent for future protocol designers.² Bind-9.10.0-P1 still reports errors if you don¹t have SPF RRs defined with the SPF TXT records or are not using 'check-spf ignore¹. Should one keep existing SPF RRs or remove them? Will future versions of bind stop reporting errors when SPF RRs don¹t exist? RFC 7208 is dated April 2014... Even if/when BIND stops complaining, how long will it take for the Internet to align with the new standard? :-) Look how long BCP38's existed and how many networks don't align despite obvious benefits to the Internet at large. I know it's a different ball of wax...but only kinda. During such transitional periods, I suggest maintaing the old form for at least awhile (probably a couple years) to give the world time to update its configuration. There used to be quite a few major mail providers who would bounce or at least flag as spam any mail from hosts not represented in the domain's SPF TXT record...so the choice of when to change depends on how much you care (or your users will complain) about misbehaved mail delivery. Given the heated and bitter debates over the SPF record type (see http://www.ietf.org/mail-archive/web/dnsext/current/maillist.html, search SPF, around August of last year), I'm thinking that a couple years probably translates into indefinitely or even never. Some people seem to think the role of the IETF is merely to passively document terrible designs and/or implementations... - Kevin ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slave zero-TTL on CNAMES
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 is not the way I would do it. Records are strictly in alphabetic order, and $TTL blocks are made around all RRSETs where TTL varies. The zone FILE is not your problem. I don't know exactly what the problem might be. It seems that something is intercepting and filtering the zone transfers? You could try transfers manually from the slave: dig [key auth if required] rhsoft.net. axfr @91.118.73.16 Does that show any zero TTLs? If so I suggest you place a couple of sniffers at strategic spots, one leaving the master, another entering the slave, and force a zone transfer. as yolu can see clearly below any CNAME record comes with a zero TTL the dotted line are a lot of CNAMES, all with zero TTL after them the first A-record has again the desired 86400 the SOA at the end comes also with 86400 and the CNAME block before again has a TTL of zero i can't imagine anyhting which would sit between the transfer and change things - h wait there was a Zyxel router in front of ns1 which was exploitable and now is replaced by a small Cisco from the ISP oh, no, don't tell me that my ISP clutters DNS again :-( [root@ns2:~]$ dig rhsoft.net. axfr @91.118.73.16 ; DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-15.P2.fc19 rhsoft.net. axfr @91.118.73.16 ;; global options: +cmd rhsoft.net. 86400 IN SOA ns2.thelounge.net. hostmaster.thelounge.net. 1226095186 3600 1800 1814400 3600 rhsoft.net. 86400 IN MX 10 barracuda.thelounge.net. rhsoft.net. 86400 IN TXT v=spf1 ip4:91.118.73.0/24 ip4:89.207.144.27 ip4:62.178.103.85 -all rhsoft.net. 86400 IN SPF v=spf1 ip4:91.118.73.0/24 ip4:89.207.144.27 ip4:62.178.103.85 -all rhsoft.net. 86400 IN NS ns2.thelounge.net. rhsoft.net. 86400 IN NS ns1.thelounge.net. rhsoft.net. 86400 IN A 91.118.73.4 **.rhsoft.net. 0 IN CNAME **.rhsoft.net. **.rhsoft.net. 0 IN CNAME **.rhsoft.net. testserver.rhsoft.net. 86400 IN A 84.113.92.77 **.rhsoft.net. 0 IN CNAME **.rhsoft.net. rhsoft.net. 86400 IN SOA ns2.thelounge.net. hostmaster.thelounge.net. 1226095186 3600 1800 1814400 3600 ;; Query time: 22 msec ;; SERVER: 91.118.73.16#53(91.118.73.16) ;; WHEN: Do Jun 05 18:35:08 CEST 2014 ;; XFR size: 58 records (messages 1, bytes 1545) signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SPF RR type
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 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 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 supported in SPF's experimental phase but has been discontinued. ...but to confuse the issue rfc7208 goes on to say: If a future update to SPF were developed that did not reuse existing SPF records, it could use the SPF RR type. SPF's use of the TXT RR type for structured data should in no way be taken as precedent for future protocol designers.² Bind-9.10.0-P1 still reports errors if you don¹t have SPF RRs defined with the SPF TXT records or are not using 'check-spf ignore¹. Should one keep existing SPF RRs or remove them? Will future versions of bind stop reporting errors when SPF RRs don¹t exist? RFC 7208 is dated April 2014... Even if/when BIND stops complaining, how long will it take for the Internet to align with the new standard? :-) Look how long BCP38's existed and how many networks don't align despite obvious benefits to the Internet at large. I know it's a different ball of wax...but only kinda. During such transitional periods, I suggest maintaing the old form for at least awhile (probably a couple years) to give the world time to update its configuration. There used to be quite a few major mail providers who would bounce or at least flag as spam any mail from hosts not represented in the domain's SPF TXT record...so the choice of when to change depends on how much you care (or your users will complain) about misbehaved mail delivery. Given the heated and bitter debates over the SPF record type (see http://www.ietf.org/mail-archive/web/dnsext/current/maillist.html, search SPF, around August of last year), I'm thinking that a couple years probably translates into indefinitely or even never. Some people seem to think the role of the IETF is merely to passively document terrible designs and/or implementations... - Kevin ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slave zero-TTL on CNAMES
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, 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 strictly in alphabetic order, and $TTL blocks are made around all RRSETs where TTL varies. The zone FILE is not your problem. I don't know exactly what the problem might be. It seems that something is intercepting and filtering the zone transfers? You could try transfers manually from the slave: dig [key auth if required] rhsoft.net. axfr @91.118.73.16 Does that show any zero TTLs? If so I suggest you place a couple of sniffers at strategic spots, one leaving the master, another entering the slave, and force a zone transfer. as yolu can see clearly below any CNAME record comes with a zero TTL the dotted line are a lot of CNAMES, all with zero TTL after them the first A-record has again the desired 86400 the SOA at the end comes also with 86400 and the CNAME block before again has a TTL of zero i can't imagine anyhting which would sit between the transfer and change things - h wait there was a Zyxel router in front of ns1 which was exploitable and now is replaced by a small Cisco from the ISP oh, no, don't tell me that my ISP clutters DNS again :-( [root@ns2:~]$ dig rhsoft.net. axfr @91.118.73.16 ; DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-15.P2.fc19 rhsoft.net. axfr @91.118.73.16 ;; global options: +cmd rhsoft.net. 86400 IN SOA ns2.thelounge.net. hostmaster.thelounge.net. 1226095186 3600 1800 1814400 3600 rhsoft.net. 86400 IN MX 10 barracuda.thelounge.net . rhsoft.net. 86400 IN TXT v=spf1 ip4:91.118.73.0/24 ip4:89.207.144.27 ip4:62.178.103.85 -all rhsoft.net. 86400 IN SPF v=spf1 ip4:91.118.73.0/24 ip4:89.207.144.27 ip4:62.178.103.85 -all rhsoft.net. 86400 IN NS ns2.thelounge.net. rhsoft.net. 86400 IN NS ns1.thelounge.net. rhsoft.net. 86400 IN A 91.118.73.4 **.rhsoft.net. 0 IN CNAME **.rhsoft.net. **.rhsoft.net. 0 IN CNAME **.rhsoft.net. testserver.rhsoft.net. 86400 IN A 84.113.92.77 **.rhsoft.net. 0 IN CNAME **.rhsoft.net. rhsoft.net. 86400 IN SOA ns2.thelounge.net. hostmaster.thelounge.net. 1226095186 3600 1800 1814400 3600 ;; Query time: 22 msec ;; SERVER: 91.118.73.16#53(91.118.73.16) ;; WHEN: Do Jun 05 18:35:08 CEST 2014 ;; XFR size: 58 records (messages 1, bytes 1545) ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slave zero-TTL on CNAMES - no ip nat service alg udp dns
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 records. because that crap is broken, on our large wire in front of ns2 the Cisco 2 years ago even killed zone transfers at least from large zones at all as well as PTR answers from the NAT behind containing the public IP thanks and sorry for the noise i start now in case of any technical problem to consult my ISP because 98 out of 100 cases are their settings and changes [harry@srv-rhsoft:~]$ dig www.rhsoft.net @ns1.thelounge.net ;; ANSWER SECTION: www.rhsoft.net. 86400 IN CNAME proxy.thelounge.net. proxy.thelounge.net.86400 IN A 91.118.73.4 ;; Query time: 23 msec ;; SERVER: 85.124.176.242#53(85.124.176.242) ;; WHEN: Do Jun 05 20:15:13 CEST 2014 ;; MSG SIZE rcvd: 89 [harry@srv-rhsoft:~]$ dig www.rhsoft.net @ns2.thelounge.net ;; ANSWER SECTION: www.rhsoft.net. 86400 IN CNAME proxy.thelounge.net. proxy.thelounge.net.86400 IN A 91.118.73.4 ;; Query time: 14 msec ;; SERVER: 91.118.73.16#53(91.118.73.16) ;; WHEN: Do Jun 05 20:15:17 CEST 2014 ;; MSG SIZE rcvd: 89 On Jun 5, 2014 12:43 PM, Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net wrote: 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 is not the way I would do it. Records are strictly in alphabetic order, and $TTL blocks are made around all RRSETs where TTL varies. The zone FILE is not your problem. I don't know exactly what the problem might be. It seems that something is intercepting and filtering the zone transfers? You could try transfers manually from the slave: dig [key auth if required] rhsoft.net http://rhsoft.net. axfr @91.118.73.16 http://91.118.73.16 Does that show any zero TTLs? If so I suggest you place a couple of sniffers at strategic spots, one leaving the master, another entering the slave, and force a zone transfer. as yolu can see clearly below any CNAME record comes with a zero TTL the dotted line are a lot of CNAMES, all with zero TTL after them the first A-record has again the desired 86400 the SOA at the end comes also with 86400 and the CNAME block before again has a TTL of zero i can't imagine anyhting which would sit between the transfer and change things - h wait there was a Zyxel router in front of ns1 which was exploitable and now is replaced by a small Cisco from the ISP oh, no, don't tell me that my ISP clutters DNS again :-( [root@ns2:~]$ dig rhsoft.net http://rhsoft.net. axfr @91.118.73.16 http://91.118.73.16 ; DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-15.P2.fc19 rhsoft.net http://rhsoft.net. axfr @91.118.73.16 http://91.118.73.16 ;; global options: +cmd rhsoft.net http://rhsoft.net. 86400 IN SOA ns2.thelounge.net http://ns2.thelounge.net. hostmaster.thelounge.net http://hostmaster.thelounge.net. 1226095186 3600 1800 1814400 3600 tel:1814400%203600 rhsoft.net http://rhsoft.net. 86400 IN MX 10 barracuda.thelounge.net http://barracuda.thelounge.net. rhsoft.net http://rhsoft.net. 86400 IN TXT v=spf1 ip4:91.118.73.0/24 http://91.118.73.0/24 ip4:89.207.144.27 ip4:62.178.103.85 -all rhsoft.net http://rhsoft.net. 86400 IN SPF v=spf1 ip4:91.118.73.0/24 http://91.118.73.0/24 ip4:89.207.144.27 ip4:62.178.103.85 -all rhsoft.net http://rhsoft.net. 86400 IN NS ns2.thelounge.net http://ns2.thelounge.net. rhsoft.net http://rhsoft.net. 86400 IN NS ns1.thelounge.net http://ns1.thelounge.net. rhsoft.net http://rhsoft.net. 86400 IN A 91.118.73.4 **.rhsoft.net http://rhsoft.net. 0 IN CNAME **.rhsoft.net http://rhsoft.net. **.rhsoft.net http://rhsoft.net. 0 IN CNAME **.rhsoft.net http://rhsoft.net. testserver.rhsoft.net http://testserver.rhsoft.net. 86400 IN A 84.113.92.77 **.rhsoft.net http://rhsoft.net. 0 IN CNAME **.rhsoft.net http://rhsoft.net. rhsoft.net http://rhsoft.net. 86400 IN SOA ns2.thelounge.net http://ns2.thelounge.net. hostmaster.thelounge.net http://hostmaster.thelounge.net.
Re: SPF RR type
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 beginning to end. By the time 4408 came out, there was already a lot of running SPF software using the badly designed TXT record. The mail community never wanted the SPF record but it was added reluctantly to 4408 due to filibustering by the DNS crowd. There was never a plausible transition plan for publishing SPF records, and by the time 7208 came out it was clearly time to put type 99 out of its misery.* It's extremely unlikely that the RRTYPE will ever be reused, so you can publish them if you want, but don't expect anyone to pay attention to them. Perhaps they can be reused for steganography. R's, John * - Mark doubtless feels differently. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SPF RR type
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 legacy software that hasn't been updated. The SPF record was a screwup from beginning to end. By the time 4408 came out, there was already a lot of running SPF software using the badly designed TXT record. The mail community never wanted the SPF record but it was added reluctantly to 4408 due to filibustering by the DNS crowd. There was never a plausible transition plan for publishing SPF records, and by the time 7208 came out it was clearly time to put type 99 out of its misery.* It's extremely unlikely that the RRTYPE will ever be reused, so you can publish them if you want, but don't expect anyone to pay attention to them. Perhaps they can be reused for steganography. R's, John And there is no plan to transition from SPF back to TXT other than the exact same plan as there was to transition from TXT to SPF. i.e. publish a RFC and hope people follow it. It takes years to do transitions like this. TXT to SPF was actually ramping up but that is now water under the bridge. * - Mark doubtless feels differently. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
