Bind 9.5.2-P1 and rrset-order
Hi,
I have multiple ip adresses for one server:
www.mydomain.comhttp://www.mydomain.com A
10.0.0.1
www.mydomain.comhttp://www.mydomain.com A
10.0.0.2
www.mydomain.comhttp://www.mydomain.com A
10.0.0.3
I need bind (I'm using 9.5.2-P1 on RedHat Linux Enterprise 5.4) to always
return the first one (10.0.0.1) for everyone. So I check the Bind9 ARM and
discovered the rrset-order option. It seems that using this option I can force
bind to do what I want for that host.
The problem is that Bind9 does not support fixed ordering by default, unless I
use -enable-fixed-rrset at compile time. When I add that to configure, I get
several warnings:
# ./configure --enable-fixed-rrset --prefix=/usr/local --sysconfdir=/etc
--localstatedir=/var
...
=== configuring in lib/bind (/root/named/bind-9.5.2-P1/lib/bind)
configure: running /bin/sh ./configure '--prefix=/usr/local'
'--enable-fixed-rrset' '--sysconfdir=/etc' '--localstatedir=/var'
--cache-file=/dev/null --srcdir=.
configure: WARNING: Unrecognized options: --enable-fixed-rrset
...
configure: creating ./config.status
...
configure: WARNING: Unrecognized options: --enable-fixed-rrset
They are just warning, so I ignored them and tried the rrset-order option like
in the ARM example in my named.conf:
rrset-order {
class IN type A name www.mydomain.com order fixed;
order cyclic;
};
If I try to start bind I get this error:
Error in named configuration:
/var/named/conf/options:20: unknown option 'rrset-order'
If I remove the option there's no error starting named.
What am I doing wrong???
Thanks,
Denis Laventure
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind 9.5.2-P1 and rrset-order
Denis Laventure wrote:
Hi,
I have multiple ip adresses for one server:
www.mydomain.com http://www.mydomain.com
A 10.0.0.1
www.mydomain.com http://www.mydomain.com
A 10.0.0.2
www.mydomain.com http://www.mydomain.com
A 10.0.0.3
I need bind (I’m using 9.5.2-P1 on RedHat Linux Enterprise 5.4) to
always return the first one (10.0.0.1) for everyone. So I check the
Bind9 ARM and discovered the rrset-order option. It seems that using
this option I can force bind to do what I want for that host.
It may not do everything that you are expecting, however. Only the
authoritative server will be required to pass the ordering of your RRSET
out as you specify. All intervening caching servers will re-order the
records as they see fit. The ordering of the RRSET is not guaranteed by
the RFCs so if what you are trying to do works, you will be lucky, and
the behavior may change at any time.
configure: WARNING: Unrecognized options: --enable-fixed-rrset
They are just warning, so I ignored them and tried the rrset-order
option like in the ARM example in my named.conf:
My guess is that you may not have done a make clean after you
re-configured. If you just ./configure blah make, not all of the
dependencies are re-compiled...
rrset-order {
class IN type A name www.mydomain.com order fixed;
order cyclic;
};
signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Strange issue - please enlighten me
Hi, I run into an unclear situation while trying to resolve certain domains. It happened when I tried with 9.7.0rc1, 9.7.0b and also with 9.7.0. I dont's have a whole lot of other BIND versions at my disposal, but I found an older one, 9.3.4-P1.2, and that one works fine. One of the domains that suffers from this issue is www.airfrance.fr. It gives a SERVFAIL: ; DiG 9.7.0rc1 www.airfrance.fr @localhost ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 65377 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.airfrance.fr. IN A ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Feb 19 19:03:35 2010 ;; MSG SIZE rcvd: 34 Anyone any clue? I am trying to understand why some resolvers handle this query well, while BIND 9.7.x returns a SERVFAIL. dig +trace www.airfrance.fr works as expected. logging says: lame-servers: info: lame server resolving 'www.airfrance.fr' (in 'www.airfrance.fr'?): 193.57.219.253#53 Thank you. Regards, -- Marco Davids ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Strange issue - please enlighten me
Marco Davids (SIDN) wrote: Anyone any clue? I am trying to understand why some resolvers handle this query well, while BIND 9.7.x returns a SERVFAIL. acl...@yellow:~$ dig +short airfrance.fr ns webaf1.airfrance.fr. lasvegas.airfrance.fr. proof.rain.fr. acl...@yellow:~$ dig +short @webaf1.airfrance.fr. www.airfrance.fr acl...@yellow:~$ dig +short @lasvegas.airfrance.fr. www.airfrance.fr acl...@yellow:~$ dig +short @proof.rain.fr. www.airfrance.fr All three of these servers, however, provide NS responses: www.airfrance.fr. 87600 IN NS ns2isp2.airfrance.fr. www.airfrance.fr. 87600 IN NS ns2isp1.airfrance.fr. That's not right... all three of the servers are lame (as you noted from your logfile). airfrance.fr needs to fix their delegations. AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC BIND 9.7.0 is now available
Hi Doug, I just installed from a local compiled bind-9.7.0.tar.gz with all ISC defalt settings and the issue is gone. Thank you, Julian - Original Message - From: Doug Barton do...@dougbarton.us To: ic.nssip ic.ns...@northwestel.net Cc: Mark Andrews ma...@isc.org; bind-users@lists.isc.org Sent: Thursday, February 18, 2010 7:19 PM Subject: Re: ISC BIND 9.7.0 is now available On 02/18/10 16:20, ic.nssip wrote: Hi Mark, This is what I suspect too. Syslog gives me this record when I start BIND: named[14380]: [ID 873579 daemon.notice] built with '--with-openssl=yes' '--enable-largefile' '--sysconfdir=/usr/local/etc' '--localstatedir=/usr/local/var' Since no PREFIX was specified, and those two items are in /usr/local ... The safest thing to do is probably to create symlinks in /usr/local/etc to at least named.conf, and rndc.*, and make sure all the paths in named.conf are fully specified. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC BIND 9.7.0 syslog recorded notices
I just installed ISC 9.7.0 on one of our x86 SUN Solaris 10 machines. I did a fresh local compiled install with all default settings. It looks that DNS is working fine for customers (anyway the time is too short to conclude that), but my syslog suddenly got populated with tones of daemon.notice messages about all kind of DNS format errors from different other servers. Is it something wrong with my DNS server? Were no notices like these before when I was running BIND 9.6.1-P1. I attached a short capture from syslog. Any advice would be appreciated. Thank you, Julian Feb 19 14:39:46 my.domain.net named[20234]: [ID 873579 daemon.notice] DNS format error from 209.235.30.142#53 resolving stats.surfaid.ihost.com/ for client 216.108.16.225#2025: invalid response Feb 19 14:39:46 my.domain.net last message repeated 1 time Feb 19 14:39:46 my.domain.net named[20234]: [ID 873579 daemon.notice] DNS format error from 204.77.28.20#53 resolving stats.surfaid.ihost.com/ for client 216.108.16.225#2025: invalid response Feb 19 14:39:46 my.domain.net last message repeated 1 time Feb 19 14:39:47 my.domain.net named[20234]: [ID 873579 daemon.notice] DNS format error from 66.179.173.211#53 resolving stats.surfaid.ihost.com/ for client 216.108.16.225#2025: invalid response Feb 19 14:39:47 my.domain.net last message repeated 2 times Feb 19 14:39:47 my.domain.net named[20234]: [ID 873579 daemon.notice] DNS format error from 204.77.28.20#53 resolving stats.surfaid.ihost.com/ for client 216.108.16.225#2025: invalid response Feb 19 14:39:47 my.domain.net named[20234]: [ID 873579 daemon.notice] DNS format error from 209.235.30.142#53 resolving stats.surfaid.ihost.com/ for client 216.108.16.225#2025: invalid response Feb 19 14:39:47 my.domain.net named[20234]: [ID 873579 daemon.notice] DNS format error from 61.235.117.75#53 resolving ns1.dayeither.com/ for client 216.108.160.30#53683: invalid response Feb 19 14:39:47 my.domain.net last message repeated 1 time Feb 19 14:39:48 my.domain.net named[20234]: [ID 873579 daemon.notice] DNS format error from 222.241.12.32#53 resolving ns5.chordhurry.ru/ for client 216.108.160.30#18164: invalid response Feb 19 14:39:48 my.domain.net named[20234]: [ID 873579 daemon.notice] DNS format error from 218.10.19.172#53 resolving ns5.chordhurry.ru/ for client 216.108.160.30#18164: invalid response Feb 19 14:39:48 my.domain.net named[20234]: [ID 873579 daemon.notice] DNS format error from 222.241.12.32#53 resolving ns5.chordhurry.ru/ for client 216.108.160.30#48687: invalid response Feb 19 14:39:48 my.domain.net named[20234]: [ID 873579 daemon.notice] DNS format error from 61.235.117.75#53 resolving ns1.dayeither.com/ for client 216.108.160.30#31770: invalid response Feb 19 14:39:48 my.domain.net named[20234]: [ID 873579 daemon.notice] DNS format error from 218.10.19.172#53 resolving ns5.chordhurry.ru/ for client 216.108.160.30#48687: invalid response Feb 19 14:39:51 my.domain.net named[20234]: [ID 873579 daemon.notice] DNS format error from 212.217.1.12#53 resolving adsl196-171-180-217-196.adsl196-14.iam.net.ma/A for client 216.108.160.30#11987: sideways referral Feb 19 14:39:51 my.domain.net named[20234]: [ID 873579 daemon.notice] DNS format error from 212.217.1.1#53 resolving adsl196-171-180-217-196.adsl196-14.iam.net.ma/A for client 216.108.160.30#11987: sideways referral Feb 19 14:39:52 my.domain.net named[20234]: [ID 873579 daemon.notice] DNS format error from 212.217.0.1#53 resolving adsl196-171-180-217-196.adsl196-14.iam.net.ma/A for client 216.108.160.30#11987: sideways referral Feb 19 14:40:08 my.domain.net named[20234]: [ID 873579 daemon.notice] DNS format error from 209.235.30.142#53 resolving stats.surfaid.ihost.com/ for client 216.108.16.225#2064: invalid response Feb 19 14:40:08 my.domain.net last message repeated 1 time Feb 19 14:40:08 my.domain.net named[20234]: [ID 873579 daemon.notice] DNS format error from 204.77.28.20#53 resolving stats.surfaid.ihost.com/ for client 216.108.16.225#2064: invalid response Feb 19 14:40:08 my.domain.net last message repeated 1 time Feb 19 14:40:09 my.domain.net named[20234]: [ID 873579 daemon.notice] DNS format error from 66.179.173.211#53 resolving stats.surfaid.ihost.com/ for client 216.108.16.225#2064: invalid response Feb 19 14:40:09 my.domain.net last message repeated 2 times Feb 19 14:40:09 my.domain.net named[20234]: [ID 873579 daemon.notice] DNS format error from 204.77.28.20#53 resolving stats.surfaid.ihost.com/ for client 216.108.16.225#2064: invalid response Feb 19 14:40:09 my.domain.net named[20234]: [ID 873579 daemon.notice] DNS format error from 209.235.30.142#53 resolving stats.surfaid.ihost.com/ for client 216.108.16.225#2064: invalid response Feb 19 14:40:13 my.domain.net named[20234]: [ID 873579 daemon.notice] DNS format error from 200.142.130.10#53 resolving 227.136.98.189.in-addr.arpa/PTR for client 216.108.31.252#29100:
Re: ISC BIND 9.7.0 syslog recorded notices
On Fri, 19 Feb 2010, ic.nssip wrote: I just installed ISC 9.7.0 on one of our x86 SUN Solaris 10 machines. I did a fresh local compiled install with all default settings. It looks that DNS is working fine for customers (anyway the time is too short to conclude that), but my syslog suddenly got populated with tones of daemon.notice messages about all kind of DNS format errors from different other servers. Is it something wrong with my DNS server? Were no notices like these before when I was running BIND 9.6.1-P1. I attached a short capture from syslog. Any advice would be appreciated. Hi. This is a new feature as listed in CHANGES file: 2770. [cleanup] Add log messages to resolver.c to indicate events causing FORMERR responses. [RT #20526] Yes, it does seem busy for you. Some loggings maybe could be made more clear, for example: stats.surfaid.ihost.com/ no SOA returned ns6.chordhurry.ru./ In SOA . is not chordhurry.ru. ns1.dayeither.com. In SOA . is not dayeither.com ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC BIND 9.7.0 syslog recorded notices
On Fri, 19 Feb 2010, Jeremy C. Reed wrote: Some loggings maybe could be made more clear, for example: stats.surfaid.ihost.com/ no SOA returned Not sure why I saw that. Looking again I see com. But I have other problems there too. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: nsec3 in bind 9.7
If you wish to sign using NSEC3 instead of NSEC, you should add an NSEC3PARAM record to the initial update request. If you wish the NSEC3 chain to have the OPTOUT bit set, set it in the flags field of the NSEC3PARAM record. % nsupdate ttl 3600 --- cut dnskey stuff --- update add example.net NSEC3PARAM 1 1 100 1234567890 send But it doesn't explain what all those param values do. I just want nsec3 so the zone cannot be walked from the outside. Not sure what optout is or what that 1234567890 is doing. Sorry the doc was unclear there. If it's convenient, would you please send that as a bug report to bind9-b...@isc.org? We'll revist the doc in a future release. To answer the question, those values are the NSEC3PARAM data for the zone, as defined in RFC 5155. In order, they are hash algorithm, flags, iterations, and salt. Hash algorithm of 1 means use SHA-1 for hashing names; flags of 1 means opt-out and 0 means no opt-out; iterations indicates how many times to repeat the hash function (and personally I wouldn't recommend that many); salt is a chunk of binary data (represented in hexidecimal) that gets appended to the name before hashing it. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
A question with forwarder and listen-on
From /etc/bind/named.conf
forwarders {
212.27.53.252;
212.27.54.252;
};
listen-on {
192.168.0.1;
127.0.0.1;
};
What do these lines do?
http://www.unfreeze.net/?p=84
Thank you.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: A question with forwarder and listen-on
Date: Fri, 19 Feb 2010 20:30:27 -0800 (PST)
From: gmspro gms...@yahoo.com
Sender: bind-users-bounces+oberman=es@lists.isc.org
From /etc/bind/named.conf
forwarders {
212.27.53.252;
212.27.54.252;
};
Queries will be forwarded to these to name servers rather than be
resolved locally. Commonly used on internal servers to handle queries
for external information.
listen-on {
192.168.0.1;
127.0.0.1;
};
Accept and respond to queries received for these addresses. The first is
in private address space, indicating it is on a server in a NATed
address space. The second is loopback.
The configuration is intended for a local server answering
authoritatively for internal, NATed addresses and forwarding all other
queries to servers in public space.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: ober...@es.net Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Duplicating queries??
I have a couple of BIND servers that I have inherited. I'm getting some upstream complaints that one of them is issuing duplicate queries on occasions - probably about a dozen times a day. When it happens, sure enough I find this in the logs: named[6905]: 18-Feb-2010 22:31:41.201 client 82.70.24.237#55710: query: 28.214.138.70.itx.munged.org.uk IN TXT + named[6905]: 18-Feb-2010 22:31:42.560 client 82.70.24.237#52806: query: 28.214.138.70.itx.munged.org.uk IN TXT + Here the last query is identical to the first buy made just over a second later. I'm not sure this is an issue with BIND and I suspect that it may be the program (Postfix) that is querying the server firing off occasional duplicate queries? I'm clutching at straws to understand what is going on here - can anyone offer me some advice? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
