slave zone header in bind8
Hello, IIRC, slave zones transferred to BIND8 had header that informed us when was the zone transferred and from where. Do I remember correctly? If so, when was this feature removed and why? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. If Barbie is so popular, why do you have to buy her friends? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DNS server works but keep getting host unreachable resolving error
Hi there,
I've setup a DNS server running bind9 in my LAN and set it up to ISP provided
DNS servers as the forwarders. Currently this DNS server works in the sense
both internal and external names are resolved without any problem. However, for
each DNS query, the syslog shows entries of
dhcp-dns named[18638]: host unreachable resolving 'google.com/A/IN':
216.171.238.66#53
Where the IP 216.171.238.66 is the ISP provided DNS server.
My named.conf.options looks like
forwarders {
216.171.238.66;
216.171.238.67;
};
listen-on-v6 { none; };
When I run dig, I get
/etc/bind# dig
; DiG 9.5.1-P2
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 48733
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 435420 IN NS K.ROOT-SERVERS.NET.
. 435420 IN NS A.ROOT-SERVERS.NET.
. 435420 IN NS H.ROOT-SERVERS.NET.
. 435420 IN NS M.ROOT-SERVERS.NET.
. 435420 IN NS E.ROOT-SERVERS.NET.
. 435420 IN NS J.ROOT-SERVERS.NET.
. 435420 IN NS D.ROOT-SERVERS.NET.
. 435420 IN NS L.ROOT-SERVERS.NET.
. 435420 IN NS G.ROOT-SERVERS.NET.
. 435420 IN NS F.ROOT-SERVERS.NET.
. 435420 IN NS B.ROOT-SERVERS.NET.
. 435420 IN NS C.ROOT-SERVERS.NET.
. 435420 IN NS I.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET. 521820 IN A 198.41.0.4
A.ROOT-SERVERS.NET. 521820 IN 2001:503:ba3e::2:30
B.ROOT-SERVERS.NET. 297362 IN A 192.228.79.201
C.ROOT-SERVERS.NET. 297362 IN A 192.33.4.12
D.ROOT-SERVERS.NET. 297362 IN A 128.8.10.90
E.ROOT-SERVERS.NET. 297362 IN A 192.203.230.10
F.ROOT-SERVERS.NET. 347113 IN A 192.5.5.241
F.ROOT-SERVERS.NET. 521820 IN 2001:500:2f::f
G.ROOT-SERVERS.NET. 297362 IN A 192.112.36.4
H.ROOT-SERVERS.NET. 297362 IN A 128.63.2.53
H.ROOT-SERVERS.NET. 297362 IN 2001:500:1::803f:235
I.ROOT-SERVERS.NET. 297362 IN A 192.36.148.17
J.ROOT-SERVERS.NET. 330463 IN A 192.58.128.30
J.ROOT-SERVERS.NET. 330463 IN 2001:503:c27::2:30
;; Query time: 0 msec
;; SERVER: 192.168.1.127#53(192.168.1.127)
;; WHEN: Mon Sep 21 14:11:54 2009
;; MSG SIZE rcvd: 500
The IP 192.168.1.127 is the IP address of the LAN DNS server I've setup.
The has NAT firewall enabled so it is able to access to the ISP provided DNS
server directly. However, it looks to me like the ISP provided DNS server
(216.171.238.66) was not able to resolve any of the names and all the resolving
is done at the top level servers. Is my understanding correct?
More importantly, is this the correct behavior I should expect and how to I
solve the host unreachable resolving problem?
I appreciate you help. Thank you very much.
--
Shi Jin, PhD
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS server works but keep getting host unreachable resolving error
On Montag 21 September 2009 Shi Jin wrote: However, it looks to me like the ISP provided DNS server (216.171.238.66) was not able to resolve any of the names and all the resolving is done at the top level servers. Is my understanding correct? Try dig @216.171.238.66 hp.com to see if the .66 host answers to your queries. Maybe you got a wrong IP there? Try the same for .67, the other DNS. mfg zmi -- // Michael Monnerie, Ing.BSc- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: curl -s http://zmi.at/zmi.asc | gpg --import // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursion on auth-only server
On Sep 21 2009, Matus UHLAR - fantomas wrote: I have moved authoritative server to new IP address. I have changed the DNS name pointing to it so the NS would point to the new IP. Now I looked at the traffic and it seems that there are ~4 of 1000 recursive requests sent to it. And do you know that this was not the case before the move? Are there any known resolvers that can iterate through NS hierarchy, or iterative DNS servers that send resursive requests anywhere? There are all sorts of reasons, from misconfigured resolvers to manual use of dig (do you always remember to specify +norec when appropriate?). Query logging will help you track them down if you are really concerned. At 0.4%, I wouldn't worry. -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Need help on delegation to subdomain/external servers
What is unfortunate about BIND picking a forwarder based on real,
up-to-date information about the thing that the end-user ultimately
cares about -- how quickly the queries get answered?
Surely this is better than hardcoding a bunch of assumptions into your
forwarding configs, assumptions that can be trivially invalidated by
such factors as nameserver failures, nameserver performance bottlenecks,
network congestion, route flapping and other topographical anomalies,
query usage patterns, etc.
If you want more fine-grained control of your query traffic, for reasons
other than pure query performance (e.g. you might pay per-byte on link A
but a flat rate on link B), then you might have to resort to devices
and/or mechanisms outside of named in order to accomplish it, e.g.
traffic shapers, transparent DNS proxies and the like.
- Kevin
Merton Campbell Crockett wrote:
When I was transferred into our corporate IT Networks group, I
inherited a DNS architecture based on forwarding DNS queries to
regional name servers. The regional name servers had access to the
Internet and were able to provide name and address resolution for both
Intranet and Internet queries.
The designers of the DNS architecture carefully configured the
forwarders statement on each name server so that the name server for
the region was listed first. It was followed by the other regional
name servers ordered by distance from the local name server.
Had this been implemented under BIND 8, it would have worked as the
designers had expected. Unfortunately, it was implemented under BIND
9.3. The list of name servers in the forwarders statement was no
longer treated as a sequential list as it had been in BIND 8. Under
BIND 9.3 and later releases, the selection of name server from the
forwarders list is performed the same way as the selection of name
server for a DNS zone: its round-robin with a preference given to the
name server with the smallest RTT.
Another item that the designers didn't anticipate was how RTT is
calculated. It is not based on the RTT to the forwarder but on the
time that it takes for the forwarder to return a result. Given the
physical locations of the regional name servers, the calculated RTT is
roughly identical even at sites where there is a local name server
co-located with the regional name server. In our particular
environment, the primary forwarder changes approximately every 20-30
seconds.
Given this behavior, I'm not sure what advantage there is in having
online and offline name servers. I would opt for having all name
servers online and let BIND select the more desirable name server.
On 17 Sep 2009, at 11:15:59, Ben Croswell wrote:
I have done some testing of the RTT forwarding and found that as long
as only one, or the other of the two nameservers that you forward
to is active at any given time the switch over is actually very quick.
The exception being the first query when the currently active
forwarder dies and the second comes up. The reason being that the
first query has to wait for a timeout cycle before trying the second
forwarder and readjusting the RTT values for both.
So theoretically if your forwarders are 10.1.1.1 and 10.2.1.1 as long
as only one will answer queries at a given time with their own
right answer it should failover fairly quickly. If both answer
then you will be at the mercy of the RTT as to which answer you will get.
--
-Ben Croswell
On Thu, Sep 17, 2009 at 12:27 PM, Kevin Darcy k...@chrysler.com
mailto:k...@chrysler.com wrote:
RUOFF LARS wrote:
[mailto:bind-users-boun...@lists.isc.org
mailto:bind-users-boun...@lists.isc.org] On Behalf Of
Kevin Darcy
BTW, at the moment I am experimenting a solution usign a
forward zone:
zone dummy.ts IN {
type forward;
forward only;
forwarders { 172.25.32.171; 192.168.2.3; };
};
It seems to work.
I guess that the requests are not sent simultaneously though?
Correct, it's similar to the algorithm that a stub resolver uses:
try one forwarder, if it times out, try another, and so on.
In fact, the way I like to think of forwarding is: when you
forward, you're turning named *into* a stub resolver with a
cache, at least for part of the namespace. If you forward
globally (i.e. in options), and have some authoritative zones
and/or stub zones with forwarders { } defined, then those are
just selective overrides of your stub-resolver+cache function.
And if you have forward first anywhere, then you're just giving
named a second chance to resolve names iteratively, in case the
initial stub-resolver+cache approach fails (because the
Re: DNS server works but keep getting host unreachable resolving error
In message 865284.37771...@web36203.mail.mud.yahoo.com, Shi Jin writes: host unreachable is one of the clearer error messages, so you need to do some digging. From the box that you've set up bind9 on you'll need to use dig to query the ISP's name servers. If that works, then you'll have to use tcpdump on that box to find out what named is doing. Doug Thank you very much. Your suggestion to use tcpdump actually is very helpful. It clearly shows: ICMP host 216.171.238.67 unreachable - admin prohibited, length 87 Yet you claim that dig to 216.171.238.67 works. I think you need to provide a full trace not the summary that a plain tcpdump gives. Add -Xvvv to the set of flags you used with tcpdump. So I think this most likely has to do with the firewall setup. Probably I should enable ICMP redirect? Could anyone confirm? And is this safe? Thank you very much. Shi ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
bind-9.7.0a3 genkey.sh and dnssec-signzone missing check
Hi, When using 9.7.0a3 with dnssec-signzone and PKCS#11, one can use the genkey.sh as a tool to generate keys. It is however hardcoded to RSASHA1. (We needed NSECRSASHA1) The below tiny patch addresses this. Related, the dnssec-signzone command created a zone with algo 5 DNSKEY's with NSEC3 records, which is a bogus zone that stupid people like me should not be allowed to create :) Paul --- genkey.sh.org 2009-09-21 19:40:17.0 -0400 +++ genkey.sh 2009-09-21 19:40:45.0 -0400 @@ -1,8 +1,8 @@ #!/bin/bash -usage=Usage: $0 -z zone -x ext -p pin -b bits -e engine [-f] -k key_path +usage=Usage: $0 -z zone -x ext -p pin -a algonum -b bits -e engine [-f] -k key_path tmp_file=/tmp/cur_key.$$ -while getopts :z:x:p:t:k:b:e:f opt; do +while getopts :z:x:p:t:k:b:e:a:f opt; do case $opt in z ) zone=$OPTARG ;; x ) ext=$OPTARG ;; @@ -12,6 +12,7 @@ while getopts :z:x:p:t:k:b:e:f opt; do e ) engine=$OPTARG ;; b ) bits=$OPTARG ;; k ) key_path=$OPTARG ;; +a ) algo=$OPTARG ;; \? ) echo $usage exit 1 ;; esac @@ -42,9 +43,9 @@ if [ $? -ne 0 ] ; then exit 1 ; fi echo Generating DNSKEY RR if [ $flag ] ; then - keytag=`$mypath/keyconv.pl -a 5 -k -e $engine -l $label -p $key_path -i $tmp_file $zone` + keytag=`$mypath/keyconv.pl -a $algo -k -e $engine -l $label -p $key_path -i $tmp_file $zone` else - keytag=`$mypath/keyconv.pl -a 5 -e $engine -l $label -p $key_path -i $tmp_file $zone` + keytag=`$mypath/keyconv.pl -a $algo -e $engine -l $label -p $key_path -i $tmp_file $zone` fi if [ ! $keytag ] ; then rm $tmp_file; exit 1 ; fi ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS server works but keep getting host unreachable resolving error
Thank you all. I've confirmed that the problem is firewall related. I've replaced my current Untangle firewall with a simplest Linux NAT iptables firewall and everything works perfectly, without any complains. Thank you very much for your kind help/suggestions. Shi ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
