Re: reject or drop AAAA queries
Hi Alan, Thanks for the help. Regards, Rock From: Alan Clegg acl...@isc.org To: bind-users@lists.isc.org Sent: Fri, July 23, 2010 11:45:08 AM Subject: Re: reject or drop queries On 7/22/2010 8:42 PM, Rock July wrote: This is my current setup right now and the reason why I want to reject or drop the queries; PC Clients: XP, Vista and 7 (Vista and 7 clients are sending both A and queries) send queries to DNS A. DNS A: will just forward the query to My DNS MyDNS: will query to DNS B in behalf of DNS A. DNS B: hosting the domain name (sample: xxx.test.com) DNS B only hosting A record for xxx.test.com so when it receive query, it respond no such name or NXDOMAIN. This result causes negative caching on MyDNS and name resolution will also fail for other client computers. I only have control on MyDNS so I am thinking if there is any way that I can reject/drop those queries so it will not query to DNS B. If the server at DNS B is responding with NXDOMAIN to a query for XXX.TEST.COM when XXX.TEST.COM A exists, then you need to find someone else to host TEST.COM as DNS B is broken. AlanC ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursing stop at about 1000 clients
I've test next configuration, which improve recursion performance of
isc-bind frontend.
bind listen on only on external interface and forward all recursive
queries to 127.0.0.1
=== named.conf ===
listen-on { 1.1.1.1; };
forward only;
forwarders {
127.0.0.1;
};
=== named.conf ===
Test without forward:
1 q - 23.362 s
rndc status 280/0/500
LA: 2
Test with
1 q - 24.162 s
rndc status 53/0/500
LA: 1.33
powerdns-recursor 3.2 listen on loopback interface.
sockstat:
USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
pdns_recursor pdns_recur64672 4 udp4 127.0.0.1:53 *:*
pdns_recursor pdns_recur64672 5 tcp4 127.0.0.1:53 *:*
bind named 1004 25 tcp41.1.1.1:53 *:*
bind named 1004 513 udp4 1.1.1.1:53 *:*
21.07.2010 03:31, Robert Mibus пишет:
Check that your underlying OS/environment is not limiting you - eg., you
may be getting limited to 1024 file descriptors via ulimit.
Robert.
On 15/07/2010, at 7:48 PM, Kebba Foon wrote:
i did i set my recursive-clients to 1 but it does not help.
On Thu, 2010-07-15 at 20:21 +1000, Noel Butler wrote:
UDP
___
bind-users mailing list
bind-users@lists.isc.org mailto:bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Robert Mibus rmi...@internode.com.au mailto:rmi...@internode.com.au
Systems Operations, Internode
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Рыбин Дмитрий
Эксперт по аварийному восстановлению сервисов
Отдел систем ШПД
Департамент ИТ- инфраструктуры
Группа компаний Вымпелком
Tel: +7(495) 7871000
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: IPv6 Records on an IPv4 Network
On 7/22/2010 11:33 AM, Phil Mayers wrote: On 22/07/10 12:19, Rock July wrote: Windows Vista and 7 clients will query both type A and query even The OS might make the query, but the application will (should) be using getaddrinfo, and this will return the IPv4 addresses first, so it doesn't matter. This is untrue. IPv6 addresses are normally returned first though the ordering depends on a) the order returned by the authorative nameserver and b) by the resolving server and if it reorders the list returned. There is no specific ordering of resource records specified in the protocol and servers are free to order them in any way they want. It is up to the application to specify what they need and to make decisions on which ones they will use. Danny ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: USADOTGOV.NET Root Problems?
On 7/22/2010 11:08 PM, Merton Campbell Crockett wrote: Thanks for the confirmation that the problem was related to DNSSEC. I didn't see your message until I got home from work; however, I did find the root of the problem late this afternoon. At each of our Internet egress and ingress points, we have Cisco ASA devices sitting in front of a pair of redundant firewalls. Each ASA is configured with the default DNS inspect policy that doesn't accept fragmented UDP packets. Why would any inspection policy not allow fragmented UDP packets? There's nothing wrong with that. Danny ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: IPv6 Records on an IPv4 Network
On 23/07/10 13:23, Danny Mayer wrote:
On 7/22/2010 11:33 AM, Phil Mayers wrote:
On 22/07/10 12:19, Rock July wrote:
Windows Vista and 7 clients will query both type A and query even
The OS might make the query, but the application will (should) be using
getaddrinfo, and this will return the IPv4 addresses first, so it
doesn't matter.
This is untrue. IPv6 addresses are normally returned first though the
ordering depends on a) the order returned by the authorative nameserver
and b) by the resolving server and if it reorders the list returned.
There is no specific ordering of resource records specified in the
protocol and servers are free to order them in any way they want. It is
up to the application to specify what they need and to make decisions on
which ones they will use.
Perhaps we are talking about two different things here?
Certainly there is no defined ordering of A versus records in DNS
replies.
However, on Linux and Windows at least, the getaddrinfo C library call
defaults to AI_ADDRCONFIG and RFC3484 address ordering rules; it does
sort the results, and will present IPv4 results first if there is no
local IPv6 global address present.
For example, in a Python interpreter session on a Windows XP machine:
socket.getaddrinfo('wildfire.net.ic.ac.uk', 22)
[(23, 0, 0, '', ('2001:630:12:1c2f:203:47ff:fee7:ddac', 22, 0, 0)), (2,
0, 0, '', ('155.198.51.19', 22))]
p = subprocess.call(['ipv6', 'uninstall'])
socket.getaddrinfo('wildfire.net.ic.ac.uk', 22)
[(2, 0, 0, '', ('155.198.51.19', 22))]
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: . SOA: got insecure response
Finally I caught one query/server that produces the . SOA: got insecure response; parent indicates it should be secure log each time: dig @ns ladeco.com. MX does this every time, where ns runs bind 9.7.1-P2, with only the root TA configured. The server serving that domain returns not exactly RFC-compliant answers: ; DiG 9.5.0-P2 @b.gtld-servers.net ladeco.com mx ;; QUESTION SECTION: ;ladeco.com.IN MX ;; AUTHORITY SECTION: ladeco.com. 172800 IN NS not-renewed.joker.com. ;; ADDITIONAL SECTION: not-renewed.joker.com. 172800 IN A 194.176.0.3 DiG 9.5.0-P2 @194.176.0.3 ladeco.com. MX ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 4159 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;ladeco.com.IN MX ;; AUTHORITY SECTION: . 2560IN SOA nxdomain.nrw.net. hostmaster. 1279119397 16384 2048 1048576 2560 ;; Query time: 22 msec ;; SERVER: 194.176.0.3#53(194.176.0.3) ;; WHEN: Fri Jul 23 15:17:33 2010 ;; MSG SIZE rcvd: 89 So bind is right in complaining, but the message is a bit misleading, in so far that it suggests a more serious issue. What I don't quite understand is why that obviously rubbish authority section is not discarded before it even comes near the validator? Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Script for verifying zone files
Thanks to everyone who replied to my questions yesterday. I gleaned some
very useful information from the conversations.
Using some of the suggestions, I kludged together another script. I'm
still fine tuning it. It works great for A and CNAME records, but I'm
tweaking the MX and NS record types.
Comments and critiques are appreciated.
Brian
=
BEGIN
=
#!/bin/bash
## named-checkzone_files.sh: verify records between two zone files.
###
## CHANGE LOG
## Author DateChange
## B. Atkins 20100723Started program...
###
## VARIABLES
PATH=$PATH:/usr/sbin/:/usr/local/bin/
###
## FUNCTIONS
usage() {
cat EOF
$0 : Verify records between two zone files.
USAGE: $0 -f {FILE} -F {FILE} -z {ZONE} [-A|-a|-c|-m|-n] [-h (Prints
help]
OPTIONS:
-a Check only A records
-A Check ALL record types
-c Check only CNAME records
-f {FILE} Primary zone file {FILE}
-F {FILE} Secondary zone file {FILE}
-m Check only MX records
-n Check only NS records
-z {ZONE} Specify zone to verify
-h Prints this help file
EOF
exit $EXIT
}
make_dump() {
FILE=$1
ZONE=$2
EXTN=`echo ${FILE} | awk -F\/ '{print $NF}'`
[[ -e /tmp/${EXTN}.dumpdb ]] rm -f /tmp/${EXTN}.dumpdb
echo -n Creating DB file for ${FILE} ...
named-checkzone -o /tmp/${EXTN}.dumpdb -D ${ZONE} ${FILE}
/dev/null
echo OK || ( echo FAIL echo -e Failed to create DB for
${FILE}\nExiting ... exit 5 )
}
parse_file() {
FILE1=$1
FILE2=$2
ZONE=$3
TYPE=$4
EXTN1=`echo ${FILE1} | awk -F\/ '{print $NF}'`
EXTN2=`echo ${FILE2} | awk -F\/ '{print $NF}'`
grep ${TYPE} /tmp/${EXTN1}.dumpdb |
awk '{print $1 $NF}' |
while read LINE1
do LINE2=(`grep ${TYPE} /tmp/${EXTN2}.dumpdb | awk
'{print $1 $NF}' | grep -i ${LINE1[*]}`)
if [[ -z ${LINE2} ]]
thenLINE2=(`grep ${TYPE} /tmp/${EXTN2}.dumpdb |
awk '{print $1 $NF}' | grep -i ${LINE1[0]}`)
if [[ -z ${LINE2} ]]
thenecho ${LINE1[*]} ${TYPE}
/tmp/${ZONE}.missing
else: ${LINE1[*]}
LAST1=$_
: ${LINE2[*]}
LAST2=$_
if [[ -z ${IGN} ]]
thenif [[ ${LAST1} != ${LAST2} ]]
thenecho ${LINE1[*]}
${TYPE} /tmp/${ZONE}.missing
echo -e \t${LINE2[*]}
/tmp/${ZONE}.missing
elsecontinue
fi
elsecontinue
fi
fi
elsecontinue
fi
done
}
###
## MAIN PROGRAM
while getopts :aAcf:F:hmnz: opt
do case $opt in
a) TYPE=IN A ;;
A) TYPE=ALL ;;
c) TYPE=CNAME ;;
f) FILE1=$OPTARG ;;
F) FILE2=$OPTARG ;;
m) TYPE=MX ;;
n) TYPE=NS ;;
z) ZONE=$OPTARG ;;
\?) usage
exit 99 ;;
:) echo $0 : Option -$OPTARG requires and
argument.
EXIT=99
usage ;;
esac
done
[[ -z ${TYPE} ]] TYPE=ALL
[[ -z $FILE1 ]] EXIT=1 usage
[[ -z $FILE2 ]] EXIT=2 usage
[[ -z $ZONE ]] EXIT=3 usage
for FILE in ${FILE1} ${FILE2}
do make_dump ${FILE} ${ZONE}
done
[[ -s /tmp/${ZONE}.missing ]] rm -f /tmp/${ZONE}.missing
if [[ ${TYPE} == ALL ]]
thenfor TYPE in IN A CNAME MX NS
do parse_file ${FILE1} ${FILE2} ${ZONE} ${TYPE}
done
elseparse_file ${FILE1} ${FILE2} ${ZONE} ${TYPE}
fi
if [[ -s /tmp/${ZONE}.missing ]]
thenecho There are `wc -l /tmp/${ZONE}.missing | awk '{print $1}'`
bad or missing entries for ${ZONE}.
echo Please review /tmp/${ZONE}.missing and take appropriate
action.
fi
exit 0
===
END
===
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: IPv6 Records on an IPv4 Network
Address selection configuration
In IPv6, each interface can have multiple addresses assigned to network and
tunneling interfaces intended for different purposes. For this reason,
RFC3484 provides a standardized method to choose source and destination IPv6
addresses with which to attempt connections.
Indeed this RFC defines two algorithms:
1) A destination address selection algorithm to sort the list of possible
destination addresses in order of preference.
2) A source address selection algorithm to choose the best source address to
use with a destination address.
This is implemented by the Operating System so applications do not need to
include their own address selection algorithms, reducing the development
burden on IPv6-capable applications. However, the algorithm can be
overridden by applications if either the source or destination address is
used rather its full qualified domain name (FQDN).
In Windows XP, 2003 and Vista, to have administrative control over the
precedence of the source and/or destination addresses, the local prefix
policy table can be managed with the netsh command as follows:
netsh interface ipv6 show prefixpolicy -- show the current local prefix
policy table
netsh interface ipv6 add prefixpolicy -- add new entries in the local
prefix policy table
netsh interface ipv6 set prefixpolicy -- set entries in the local prefix
policy table
netsh interface ipv6 delete prefixpolicy -- delete entries in the local
prefix policy table
Example
C:\netsh interface ipv6 show prefixpolicy
Precedence Label Prefix
5 5 2001::/32
10 4 :::0:0/96
20 3 ::/96
30 2 2002::/16
40 1 ::/0
50 0 ::1/128
The above prefix policy table shows the following:
1) If native IPv6 is available on the host, any IPv6 destination has more
precedence than any IPv4 destination:
10 4 :::0:0/96 == any IPv4 address (IPv4-mapped address)
40 1 ::/0 == any IPv6 address
2) If 6to4 is available on the host, any IPv6 destination has more
precedence than any IPv4 destination:
10 4 :::0:0/96 == any IPv4 address (IPv4-mapped address)
30 2 2002::/16 any 6to4 IPv6 address
3) If Teredo is available on the host, any IPv4 destination has more
precedence than any IPv6 destination:
5 5 2001::/32 == any Teredo IPv6 address
10 40 :::0:0/96 == any IPv4 address (IPv4-mapped address)
Changing the address selection precedence
If you want to change the precedence of one prefix, for example Teredo
prefix over IPv4 addresses according to the above prefix policy table you
should use:
C:\netsh interface ipv6 set prefixpolicy prefix=2001::/32 precedence=15
label=5
-Original Message-
From: bind-users-bounces+vyto=fnal@lists.isc.org [mailto:bind-
users-bounces+vyto=fnal@lists.isc.org] On Behalf Of Phil Mayers
Sent: Friday, July 23, 2010 7:50 AM
To: ma...@gis.net
Cc: bind-users@lists.isc.org
Subject: Re: IPv6 Records on an IPv4 Network
On 23/07/10 13:23, Danny Mayer wrote:
On 7/22/2010 11:33 AM, Phil Mayers wrote:
On 22/07/10 12:19, Rock July wrote:
Windows Vista and 7 clients will query both type A and query
even
The OS might make the query, but the application will (should) be
using
getaddrinfo, and this will return the IPv4 addresses first, so it
doesn't matter.
This is untrue. IPv6 addresses are normally returned first though the
ordering depends on a) the order returned by the authorative
nameserver
and b) by the resolving server and if it reorders the list returned.
There is no specific ordering of resource records specified in the
protocol and servers are free to order them in any way they want. It
is
up to the application to specify what they need and to make decisions
on
which ones they will use.
Perhaps we are talking about two different things here?
Certainly there is no defined ordering of A versus records in DNS
replies.
However, on Linux and Windows at least, the getaddrinfo C library call
defaults to AI_ADDRCONFIG and RFC3484 address ordering rules; it does
sort the results, and will present IPv4 results first if there is no
local IPv6 global address present.
For example, in a Python interpreter session on a Windows XP machine:
socket.getaddrinfo('wildfire.net.ic.ac.uk', 22)
[(23, 0, 0, '', ('2001:630:12:1c2f:203:47ff:fee7:ddac', 22, 0, 0)), (2,
0, 0, '', ('155.198.51.19', 22))]
p = subprocess.call(['ipv6', 'uninstall'])
socket.getaddrinfo('wildfire.net.ic.ac.uk', 22)
[(2, 0, 0, '', ('155.198.51.19', 22))]
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: USADOTGOV.NET Root Problems?
On 07/23/10 05:37, Danny Mayer wrote: On 7/22/2010 11:08 PM, Merton Campbell Crockett wrote: Thanks for the confirmation that the problem was related to DNSSEC. I didn't see your message until I got home from work; however, I did find the root of the problem late this afternoon. At each of our Internet egress and ingress points, we have Cisco ASA devices sitting in front of a pair of redundant firewalls. Each ASA is configured with the default DNS inspect policy that doesn't accept fragmented UDP packets. Why would any inspection policy not allow fragmented UDP packets? There's nothing wrong with that. Because the default DNS inspection policy for most Cisco ASAs/FWSMs/PIXes is brain-dead. It is on by default and, in older versions, only allows DNS messages up to 512 bytes in length. In some later versions it allows something larger (1024 or 1500?), but basically makes no exceptions for EDNS0 and UDP fragments. michael ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
top level zone file transfer fails from the slave
Hello,
I have a BIND 9.7.1 running on a Solaris 10 box. This node is slave to certain
zone for PTR records as shown in the named.conf file below
zone 10.in-addr.arpa in {
type slave;
check-names ignore;
file zones/internal/10.in-addr.arpa;
masters { 10.2.3.4; 10.5.6.7; };
So as can be seen we are using the top level domain as the PTR zone file for
all the 10.x.x.x (10/8)address.
However it appears in the masters nodes, they don't have a top level zone file
and have basically broken down the top level to numerous sub domain zone files
such as 1.10.in-addr.arpa 2.10.in-addr.arpa 3.10.in-addr.arpa
This issue is that with the above config in slave the zone file transfer fails.
So the question is does the name of the zone files in slave's config need to
match the name of those zone files in master? Can't a slave just use a top
level zone file domain? because that way one entry in the named.conf would
include everything in that 10.x address domain.
Any ideas to avoid having to add config for each subdomain level PTR zone file
in named.conf would be greatly appreciated.
Thanks
Prabhat
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Multiple masters expected behavior?
On 07/22/10 19:57, Barry Margolin wrote: In articlemailman.65.1279835965.15649.bind-us...@lists.isc.org, Peter Lawspl...@ou.edu wrote: I have multiple interfaces on my master and multiple interfaces on most of my slaves. Is that expected behavior? Yes. What if the first server stops getting updates, but the second one does and has a higher serial number? Don't you want the slaves to check the SOA record on it to pick up these changes? Except that the 2 masters are simply different interfaces on the same master ... so the serial number *better* always be the same! Looking at the logs, it appears that the choice of masters is a second-to-second thing because what I'm seeing is that one zone goes via one interface and then the next zone, perhaps only a few 10s of ms later, goes via the other interface. I would have expected that it would only ask the second-listed master if the first didn't answer ... but I didn't write the code (and haven't read it either! -- Peter Laws / N5UWY National Weather Center / Network Operations Center University of Oklahoma Information Technology pl...@ou.edu --- Feedback? Contact my director, Craig Cochell, cra...@ou.edu. Thank you! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: top level zone file transfer fails from the slave
On Fri, 23 Jul 2010, Prabhat Rana wrote: So as can be seen we are using the top level domain as the PTR zone file for all the 10.x.x.x (10/8)address. However it appears in the masters nodes, they don't have a top level zone file and have basically broken down the top level to numerous sub domain zone files such as 1.10.in-addr.arpa 2.10.in-addr.arpa 3.10.in-addr.arpa This issue is that with the above config in slave the zone file transfer fails. So the question is does the name of the zone files in slave's config need to match the name of those zone files in master? Can't a slave just use a top level zone file domain? Creative idea, but no. :) The zone statements on the masters and slaves need to match. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Multiple masters expected behavior?
On Fri, 23 Jul 2010, Peter Laws wrote: Except that the 2 masters are simply different interfaces on the same master Why do you think that would be helpful? Or are you just testing the multi-master configuration in the hopes of adding actual diversity down the road? Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Multiple masters expected behavior?
On Thu, 22 Jul 2010, Peter Laws wrote: BIND 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 9.3.x has been EOL for a long time now, FYI. -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: IPv6 Records on an IPv4 Network
On 7/23/2010 8:50 AM, Phil Mayers wrote: On 23/07/10 13:23, Danny Mayer wrote: On 7/22/2010 11:33 AM, Phil Mayers wrote: On 22/07/10 12:19, Rock July wrote: Windows Vista and 7 clients will query both type A and query even The OS might make the query, but the application will (should) be using getaddrinfo, and this will return the IPv4 addresses first, so it doesn't matter. This is untrue. IPv6 addresses are normally returned first though the ordering depends on a) the order returned by the authorative nameserver and b) by the resolving server and if it reorders the list returned. There is no specific ordering of resource records specified in the protocol and servers are free to order them in any way they want. It is up to the application to specify what they need and to make decisions on which ones they will use. Perhaps we are talking about two different things here? No. Certainly there is no defined ordering of A versus records in DNS replies. However, on Linux and Windows at least, the getaddrinfo C library call defaults to AI_ADDRCONFIG and RFC3484 address ordering rules; it does sort the results, and will present IPv4 results first if there is no local IPv6 global address present. Applications that depend on specific behaviors are broken. You should always code your applications to handle whatever gets returned. Be conservative in what you send and be liberal in what you accept. Otherwise it will break in unexpected ways. The fact that an implementation orders results in some way under one condition and a different way under some other condition is not a reason to believe that this is safe. Furthermore, provisioning of an IPv6 global address is no indication of IPv6 network connectivity. The ideas in RFC3484 and usage of AI_ADDRCONFIG are interesting but don't necessarily result in better behavior. Danny ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
