Re: Query denied errors on PTR records for delegated zone
On 22.02.10 17:21, Geoff Sweet wrote:
The problem is that editing the options list to:
options {
directory /var/named;
dump-file /var/named/data/cache_dump.db;
statistics-file /var/named/data/named_stats.txt;
memstatistics-file /var/named/data/named_mem_stats.txt;
allow-query { any; };
allow-recursion { wemadenets; };
};
Allows anyone to make recursive requests for any name against my server.
I don't want that.
You want anyone not to send you recursive? Well, call them by phone and ask
them not to do so.
You want the recursive requests not to reach your server? Put a DNS
inspecting firewall in front of your server...
You want the recursive requests not to be resolved? That is exactly the
options above say. Anyone can query, but recursive requests will be answered
only if they come from wemadenets.
By leaving the options list to allow-query {
localhost; localnets; wemadenets; }; I prevent any ole recursive query
(www.google.com for instance) except from my network while still allowing
queries to the zones that I host.
No, you prevent ALL queries to be responded this way.
Read the docs, you apparently do not understand the difference between
allow-query and allow-recursion.
And, btw. bind 9.3 will send answers from cache to anyone who has
allow-query enabled. It won't do the recursion, but will answer if it's
cached. Maybe this is what made you think the above.
bind 9.4 and later has new option allow-query-cache that allows tune this
behaviour too and the default is same as allow-recursion.
(actually they cross-inherit each other, if either is not set)
--
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.
Linux - It's now safe to turn on your computer.
Linux - Teraz mozete pocitac bez obav zapnut.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Query denied errors on PTR records for delegated zone
On 22.02.10 16:26, Geoff Sweet wrote:
I have an on-going problem that has totally stumped me. I have a CentOS
5.3 server that I am using the builtin Bind (9.3) to serve our zones. Our
ISP has provisioned us a block of IP's and has delegated our name servers
as authoritative for the reverse zone info for that block. Name
resolution for A records works perfect. What has me totally baffled at
this point is that I can not get PTR records to work. All queries to my
reverse zone are answered with denied errors:
Feb 22 04:10:14 ns1 named[19789]: client 72.247.123.69#52683: query (cache)
'14.173.150.66.in-addr.arpa/PTR/IN' denied
Feb 22 05:15:26 ns1 named[19789]: client 72.247.123.69#61264: query (cache)
'50.173.150.66.in-addr.arpa/PTR/IN' denied
Feb 22 10:12:03 ns1 named[19789]: client 72.246.192.167#52219: query (cache)
'39.173.150.66.in-addr.arpa/PTR/IN' denied
Feb 22 11:05:11 ns1 named[19789]: client 96.17.73.207#61038: query (cache)
'24.173.150.66.in-addr.arpa/PTR/IN' denied
Feb 22 11:33:23 ns1 named[19789]: client 72.247.123.69#61049: query (cache)
'55.173.150.66.in-addr.arpa/PTR/IN' denied
Feb 22 13:41:45 ns1 named[19789]: client 96.17.166.181#60054: query (cache)
'31.173.150.66.in-addr.arpa/PTR/IN' denied
zone 0-59.173.150.66.in-addr.arpa {
they are not asking for your zone. They are asking for zone
173.150.66.in-addr.arpa which I don't see on your nameserver.
All those IPs are from akamai and they should not even go to your server, if
you are watching at ns1.wemadeusa.com. or ns2.wemadeusa.com.
either akamai has broken dns clients, or someone (you?) has been asking them
to query your servers directly for reverse zone you don't provide.
And here is the 0-59.173.150.66.in-addr.arpa.zone file (I have deleted some
of the name information for security):
$TTL 3600
@ IN SOA ns1.wemadeusa.com.
hostmaster.wemadeusa.com. (
2010021501 ; serial
600 ; refresh after 10
minutes
3600; retry after 1 hour
604800 ; expire after 1 week
86400 ) ; minimum TTL of 1 day
IN NS ns1.wemadeusa.com
IN NS ns2.wemadeusa.com
You are missing trailing dots here. Note that without them the current
$ORIGIN is appended, which results in:
0-59.173.150.66.in-addr.arpa. 3600 IN NS
ns2.wemadeusa.com.0-59.173.150.66.in-addr.arpa.
0-59.173.150.66.in-addr.arpa. 3600 IN NS
ns1.wemadeusa.com.0-59.173.150.66.in-addr.arpa.
Try fixing this first, maybe this is your real problem.
--
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.
Linux is like a teepee: no Windows, no Gates and an apache inside...
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
IPv6 client and negative cache - some doubts
Hello Everyone I have a problem with Bind 9.3.6-P1 (included in Solaris 10) but honestly I don't even understand if it is wrong Bind behaviour or my ignorance. It does apply only to some specific cases when external domain delegation is also somewhat broken. My server is caching only. Let me show it by the example: Host www.goleszow.pl has bad NS delegation on country root servers level because virtual.sincom.pl is not resolvable: goleszow.pl.86400INNSvirtual.sincom.pl. goleszow.pl.86400INNSvirtual.jasnet.pl. ;; Received 91 bytes from 149.156.1.6#53(G-DNS.pl) in 19 ms When dns client asks my server for A record of www.goleszow.pl - everything is fine. But when first query (after cache is flushed) asks for record - my server seems to cache negative answer and all subsequent queries for A record also fails. My server is recursive and I've many IPv6 clients on the network. I checked what is going on when server receives first query for : 1 0.00 192.168.1.71 - 192.33.4.12 DNS Standard query TXT _nfsv4idmapdomain 2 0.002775 192.168.1.71 - 192.33.4.12 DNS Standard query NS Root 3 0.028379 192.33.4.12 - 192.168.1.71 DNS Standard query response, No such name 4 0.033050 192.33.4.12 - 192.168.1.71 DNS Standard query response NS G.ROOT-SERVERS.NET NS A.ROOT-SERVERS.NET NS D.ROOT-SERVERS.NET NS F.ROOT-SERVERS.NET NS C.ROOT-SERVERS.NET NS E.ROOT-SERVERS.NET NS L.ROOT-SERVERS.NET NS B.ROOT-SERVERS.NET NS H.ROOT-SERVERS.NET NS K.ROOT-SERVERS.NET NS I.ROOT-SERVERS.NET NS J.ROOT-SERVERS.NET NS M.ROOT-SERVERS.NET 5 2.801810 192.168.1.71 - 192.228.79.201 DNS Standard query goleszow.pl 6 2.982864 192.228.79.201 - 192.168.1.71 DNS Standard query response 7 2.989858 192.168.1.71 - 195.47.235.226 DNS Standard query goleszow.pl 8 3.009941 195.47.235.226 - 192.168.1.71 DNS Standard query response 9 3.015835 192.168.1.71 - 195.80.237.162 DNS Standard query A virtual.jasnet.pl 10 3.018273 192.168.1.71 - 195.80.237.162 DNS Standard query virtual.jasnet.pl 11 3.019792 195.80.237.162 - 192.168.1.71 DNS Standard query response 12 3.021021 192.168.1.71 - 195.80.237.162 DNS Standard query A virtual.sincom.pl 13 3.022049 195.80.237.162 - 192.168.1.71 DNS Standard query response 14 3.023746 192.168.1.71 - 195.80.237.162 DNS Standard query virtual.sincom.pl 15 3.024858 195.80.237.162 - 192.168.1.71 DNS Standard query response 16 3.027626 195.80.237.162 - 192.168.1.71 DNS Standard query response 17 3.028502 192.168.1.71 - 62.146.113.3 DNS Standard query A virtual.jasnet.pl 18 3.031538 192.168.1.71 - 62.146.113.3 DNS Standard query virtual.jasnet.pl 19 3.035423 192.168.1.71 - 62.146.113.3 DNS Standard query A virtual.sincom.pl 20 3.038242 192.168.1.71 - 62.146.113.3 DNS Standard query virtual.sincom.pl 21 3.057608 62.146.113.3 - 192.168.1.71 DNS Standard query response A 85.202.208.254 22 3.061034 192.168.1.71 - 85.202.208.254 DNS Standard query goleszow.pl 23 3.062109 62.146.113.3 - 192.168.1.71 DNS Standard query response CNAME jasnet.pl 24 3.065739 62.146.113.3 - 192.168.1.71 DNS Standard query response, No such name 25 3.066057 62.146.113.3 - 192.168.1.71 DNS Standard query response, No such name 26 3.080053 85.202.208.254 - 192.168.1.71 DNS Standard query response At the end jasnet.pl ( 85.202.208.254 - authoritative NS for goleszow.pl) answer with empty reply (no error) which is - in my opinion - is correct. Then when any client asks my server for A record for www.goleszow.pl it gets NXDOMAIN. My server doesn't even contact external network - so I suppose the answer comes from cache. I don't really know why Bind refuses subsequent queries for A of www.goleszow.pl? This is what I found in the Bind cache: # rndc dumpdb -all # cat /var/named/log/named_dump.db | grep virt goleszow.pl.85994 NS virtual.jasnet.pl. 85994 NS virtual.sincom.pl. virtual.jasnet.pl. 3194A 85.202.208.254 virtual.sincom.pl. 3194\-ANY ;-$NXDOMAIN ; virtual.jasnet.pl alias jasnet.pl [v4 TTL 3194] [target TTL 3194] [v4 success] [v6 unexpected] ; virtual.sincom.pl [v4 TTL 3194] [v6 TTL 3194] [v4 nxdomain] [v6 nxdomain] Which for me doesn't explain this behaviour. Please advice. Regards Michal ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: IPv6 client and negative cache - some doubts
In article mailman.529.1266923597.21153.bind-us...@lists.isc.org, Michal Wesolowski gmic...@gmail.com wrote: Hello Everyone I have a problem with Bind 9.3.6-P1 (included in Solaris 10) but honestly I don't even understand if it is wrong Bind behaviour or my ignorance. It does apply only to some specific cases when external domain delegation is also somewhat broken. My server is caching only. Let me show it by the example: Host www.goleszow.pl has bad NS delegation on country root servers level because virtual.sincom.pl is not resolvable: goleszow.pl.86400INNSvirtual.sincom.pl. goleszow.pl.86400INNSvirtual.jasnet.pl. ;; Received 91 bytes from 149.156.1.6#53(G-DNS.pl) in 19 ms That may be part of the problem, and it needs to be fixed, but I don't think that's all of it. When dns client asks my server for A record of www.goleszow.pl - everything is fine. But when first query (after cache is flushed) asks for record - my server seems to cache negative answer and all subsequent queries for A record also fails. ... [snip] This is what I found in the Bind cache: # rndc dumpdb -all # cat /var/named/log/named_dump.db | grep virt goleszow.pl.85994 NS virtual.jasnet.pl. 85994 NS virtual.sincom.pl. virtual.jasnet.pl. 3194A 85.202.208.254 virtual.sincom.pl. 3194\-ANY ;-$NXDOMAIN ; virtual.jasnet.pl alias jasnet.pl [v4 TTL 3194] [target TTL 3194] [v4 success] [v6 unexpected] ; virtual.sincom.pl [v4 TTL 3194] [v6 TTL 3194] [v4 nxdomain] [v6 nxdomain] Which for me doesn't explain this behaviour. Please advice. Note that line beginning virtual.jasnet.pl alias jasnet.pl. jasnet.pl is delegated to ns10.az.pl and ns11.az.pl. If you ask them for an A record for virtual.jasnet.pl you get an A record; if you ask for you get a CNAME pointing to jasnet.pl. I can't imagine what sort of configuration could cause that to happen. I'm also not sure how that might be screwing up your lookups, but it's certainly weird. On the 'fix what you know to be broken' principle I'd try to get that and the broken delegation sorted first before looking any further. Sam $ dig virtual.jasnet.pl @ns11.az.pl ; DiG 9.3.6-APPLE-P2 virtual.jasnet.pl @ns11.az.pl ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 47757 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;virtual.jasnet.pl. IN A ;; ANSWER SECTION: virtual.jasnet.pl. 3600IN A 85.202.208.254 ;; Query time: 43 msec ;; SERVER: 62.146.68.200#53(62.146.68.200) ;; WHEN: Tue Feb 23 12:24:05 2010 ;; MSG SIZE rcvd: 51 $ dig virtual.jasnet.pl @ns11.az.pl ; DiG 9.3.6-APPLE-P2 virtual.jasnet.pl @ns11.az.pl ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 13425 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;virtual.jasnet.pl. IN ;; ANSWER SECTION: virtual.jasnet.pl. 3600IN CNAME jasnet.pl. ;; AUTHORITY SECTION: jasnet.pl. 3600IN SOA ns10.az.pl. admin.az.pl. 2009091500 10800 3600 604800 3600 ;; Query time: 44 msec ;; SERVER: 62.146.68.200#53(62.146.68.200) ;; WHEN: Tue Feb 23 12:24:09 2010 ;; MSG SIZE rcvd: 99 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Query denied errors on PTR records for delegated zone
I'm running 9.3 on RHEL 5.4.
My options are:
options {
directory /var/named;
query-source address 10.0.0.3;
allow-query { internaldns; externaldns; dswadnsalias; };
allow-recursion { internaldns; externaldns; };
blackhole { blackhats; };
version none;
};
In each of my zones including arpa zones I have
allow-query { any; };
This works fine for blocking recursion for sites such as google from
outside my network yet still allowing lookups of my zones from outside
and sounds like what the OP says he is intending to do.
The above worked before I upgraded from 5.3 to 5.4 so should work on
CentOS as well since it is a binary compile of RHEL source.
I did run into some oddities in setting up arpa zones to be able to
query them inside my network and outside my network so I have things
like:
# Special notation required for internet delegation (e.g. dig -x ...)
#
zone 192/27.84.44.12.IN-ADDR.ARPA {
type master;
file arpa.12.44.84;
allow-query { any; };
};
# Standard notation required for direct lookups (e.g. dig @dswands1 -x
...)
#
zone 84.44.12.IN-ADDR.ARPA {
type master;
file arpa.12.44.84;
allow-query { any; };
};
Note this is not the difference in views but difference in how I get to
the server. I later implemented views which probably obviated the
above since I'd only see one or the other depending on where I came
from. However, I note it as originally I was pulling my hair out trying
to figure out why digs directly to my DNS server via the internal facing
interface wouldn't resolve like the ones on the external facing
interface.
-Original Message-
From: bind-users-bounces+jlightner=water@lists.isc.org
[mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf
Of Matus UHLAR - fantomas
Sent: Tuesday, February 23, 2010 4:19 AM
To: bind-users@lists.isc.org
Subject: Re: Query denied errors on PTR records for delegated zone
On 22.02.10 16:26, Geoff Sweet wrote:
I have an on-going problem that has totally stumped me. I have a
CentOS
5.3 server that I am using the builtin Bind (9.3) to serve our zones.
Our
ISP has provisioned us a block of IP's and has delegated our name
servers
as authoritative for the reverse zone info for that block. Name
resolution for A records works perfect. What has me totally baffled
at
this point is that I can not get PTR records to work. All queries to
my
reverse zone are answered with denied errors:
Feb 22 04:10:14 ns1 named[19789]: client 72.247.123.69#52683: query
(cache) '14.173.150.66.in-addr.arpa/PTR/IN' denied
Feb 22 05:15:26 ns1 named[19789]: client 72.247.123.69#61264: query
(cache) '50.173.150.66.in-addr.arpa/PTR/IN' denied
Feb 22 10:12:03 ns1 named[19789]: client 72.246.192.167#52219: query
(cache) '39.173.150.66.in-addr.arpa/PTR/IN' denied
Feb 22 11:05:11 ns1 named[19789]: client 96.17.73.207#61038: query
(cache) '24.173.150.66.in-addr.arpa/PTR/IN' denied
Feb 22 11:33:23 ns1 named[19789]: client 72.247.123.69#61049: query
(cache) '55.173.150.66.in-addr.arpa/PTR/IN' denied
Feb 22 13:41:45 ns1 named[19789]: client 96.17.166.181#60054: query
(cache) '31.173.150.66.in-addr.arpa/PTR/IN' denied
zone 0-59.173.150.66.in-addr.arpa {
they are not asking for your zone. They are asking for zone
173.150.66.in-addr.arpa which I don't see on your nameserver.
All those IPs are from akamai and they should not even go to your
server, if
you are watching at ns1.wemadeusa.com. or ns2.wemadeusa.com.
either akamai has broken dns clients, or someone (you?) has been asking
them
to query your servers directly for reverse zone you don't provide.
And here is the 0-59.173.150.66.in-addr.arpa.zone file (I have deleted
some of the name information for security):
$TTL 3600
@ IN SOA ns1.wemadeusa.com.
hostmaster.wemadeusa.com. (
2010021501 ; serial
600 ; refresh
after 10 minutes
3600; retry after
1 hour
604800 ; expire after
1 week
86400 ) ; minimum TTL
of 1 day
IN NS ns1.wemadeusa.com
IN NS ns2.wemadeusa.com
You are missing trailing dots here. Note that without them the current
$ORIGIN is appended, which results in:
0-59.173.150.66.in-addr.arpa. 3600 IN NS
ns2.wemadeusa.com.0-59.173.150.66.in-addr.arpa.
0-59.173.150.66.in-addr.arpa. 3600 IN NS
ns1.wemadeusa.com.0-59.173.150.66.in-addr.arpa.
Try fixing this first, maybe this is your real problem.
--
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.
Linux is like a teepee: no Windows, no
Fwd: IPv6 client and negative cache - some doubts
sorry for replying directly, still have some problems with gmail UI. -- Forwarded message -- From: Michal Wesolowski gmic...@gmail.com Date: Tue, Feb 23, 2010 at 2:47 PM Subject: Re: IPv6 client and negative cache - some doubts To: Sam Wilson sam.wil...@ed.ac.uk On Tue, Feb 23, 2010 at 1:33 PM, Sam Wilson sam.wil...@ed.ac.uk wrote: In article mailman.529.1266923597.21153.bind-us...@lists.isc.org, Michal Wesolowski gmic...@gmail.com wrote: Hello Everyone I have a problem with Bind 9.3.6-P1 (included in Solaris 10) but honestly I don't even understand if it is wrong Bind behaviour or my ignorance. It does apply only to some specific cases when external domain delegation is also somewhat broken. My server is caching only. Let me show it by the example: Host www.goleszow.pl has bad NS delegation on country root servers level because virtual.sincom.pl is not resolvable: goleszow.pl.86400INNSvirtual.sincom.pl. goleszow.pl.86400INNSvirtual.jasnet.pl. ;; Received 91 bytes from 149.156.1.6#53(G-DNS.pl) in 19 ms That may be part of the problem, and it needs to be fixed, but I don't think that's all of it. When dns client asks my server for A record of www.goleszow.pl - everything is fine. But when first query (after cache is flushed) asks for record - my server seems to cache negative answer and all subsequent queries for A record also fails. ... [snip] This is what I found in the Bind cache: # rndc dumpdb -all # cat /var/named/log/named_dump.db | grep virt goleszow.pl.85994 NS virtual.jasnet.pl. 85994 NS virtual.sincom.pl. virtual.jasnet.pl. 3194A 85.202.208.254 virtual.sincom.pl. 3194\-ANY ;-$NXDOMAIN ; virtual.jasnet.pl alias jasnet.pl [v4 TTL 3194] [target TTL 3194] [v4 success] [v6 unexpected] ; virtual.sincom.pl [v4 TTL 3194] [v6 TTL 3194] [v4 nxdomain] [v6 nxdomain] Which for me doesn't explain this behaviour. Please advice. Note that line beginning virtual.jasnet.pl alias jasnet.pl. jasnet.pl is delegated to ns10.az.pl and ns11.az.pl. If you ask them for an A record for virtual.jasnet.pl you get an A record; if you ask for you get a CNAME pointing to jasnet.pl. I can't imagine what sort of configuration could cause that to happen. I'm also not sure how that might be screwing up your lookups, but it's certainly weird. On the 'fix what you know to be broken' principle I'd try to get that and the broken delegation sorted first before looking any further. Sam Thank you Sam for pointing this out. This is probably real source of the problem. I looked over what could cause such situation and so far found old bug in PowerDNS (but don't know if they use it!) which generated such answers when using wildcards. After some reading my present understanding is that correct response to query when there is such record in the zone and there exists another record of different type for the same name - is to reply with empty answer and no error (this applies to authoritative NS). So what ns10.az.pl does is not consistent with specification. However I'm still not sure if bind shouldn't cope with this somehow. I understand that if it applied to final query for www.goliszew.pl than it would be correct for bind to cache it as negative for all types of records. But if it concerns bad respond for NS? - I don't know. Thanks Michal ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
no hostname become unresolvable.
Hi everybody, I just setup my dns using bind-9.6.1-P2 when I try to ping the server with a hostname, that's ok. i.e. #ping www.superease.net PING www.superease.net (202.68.195.36) 56(84) bytes of data. But when I try to ping the server without hostname, #ping superease.net ping: unknown host superease.net Can someone tell me what's up?!?!?!? Here the zone file $TTL86400 $ORIGIN superease.net. @ IN SOA dns1.man169.com. root.dns1.man169.com. ( 2010022307 ; serial (d. adams) 10800 ; refresh 900 ; retry 604800 ; expiry 86400 ) ; minimum @ IN NS dns1.man169.com. @ IN NS dns2.man169.com. @ IN MX 10 mail.man169.com. www IN A 202.68.195.36 z IN A 202.131.69.99 service IN A 202.131.69.98 newsIN A 202.131.69.98 * IN CNAME www ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: no hostname become unresolvable.
You need an A record for the domain itself: superease.net. IN A 202.68.195.36 www IN A 202.68.195.36 The first one (terminated by the dot) tells it lookup for the domain name superease.net itself. The dot is important - without it this would try to lookup superease.net.superease.net. The second one www (without a dot) tells it to lookup www.superease.net by appending the domain to the entry. -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of Cefull Lo Sent: Tuesday, February 23, 2010 9:42 AM To: bind-users@lists.isc.org Subject: no hostname become unresolvable. Hi everybody, I just setup my dns using bind-9.6.1-P2 when I try to ping the server with a hostname, that's ok. i.e. #ping www.superease.net PING www.superease.net (202.68.195.36) 56(84) bytes of data. But when I try to ping the server without hostname, #ping superease.net ping: unknown host superease.net Can someone tell me what's up?!?!?!? Here the zone file $TTL86400 $ORIGIN superease.net. @ IN SOA dns1.man169.com. root.dns1.man169.com. ( 2010022307 ; serial (d. adams) 10800 ; refresh 900 ; retry 604800 ; expiry 86400 ) ; minimum @ IN NS dns1.man169.com. @ IN NS dns2.man169.com. @ IN MX 10 mail.man169.com. www IN A 202.68.195.36 z IN A 202.131.69.99 service IN A 202.131.69.98 newsIN A 202.131.69.98 * IN CNAME www Proud partner. Susan G. Komen for the Cure. Please consider our environment before printing this e-mail or attachments. -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: nsec3 in bind 9.7
On Sat, Feb 20, 2010 at 12:31:38AM +, Evan Hunt e...@isc.org wrote a message of 36 lines which said: To answer the question, those values are the NSEC3PARAM data for the zone, as defined in RFC 5155. [...] flags of 1 means opt-out and 0 means no opt-out; It is not exactly what the RFC says: The Opt-Out flag is not used and is set to zero. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Scripts for zsk rollover in 9.7
On Sat, Feb 20, 2010 at 09:15:23PM +, Evan Hunt e...@isc.org wrote a message of 22 lines which said: We have plans to improve this in 9.7.x (where x probably equals 1) in a couple of ways: first, by making it possible to assign each key an explicit successor key and warn the user if a key is set to expire without a successor; second, by making it possible to configure named itself to generate new keys. I'm not sure it is a good idea. BIND is already quite loaded in features. Why not relying on dedicated free software such as OpenDNSSEC http://www.opendnssec.org/? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: no hostname become unresolvable.
On Tue, Feb 23, 2010 at 10:41:37PM +0800, Cefull Lo cef...@gmail.com wrote a message of 89 lines which said: But when I try to ping the server without hostname, [Technicality: there *is* a hostname, superease.net *is* an hostname.] Here the zone file There is no A or record for @ (superease.net). @ IN NS dns1.man169.com. @ IN NS dns2.man169.com. @ IN MX 10 mail.man169.com. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: no hostname become unresolvable.
In article mailman.538.1266936679.21153.bind-us...@lists.isc.org, Lightner, Jeff jlight...@water.com wrote: You need an A record for the domain itself: superease.net. IN A 202.68.195.36 www IN A 202.68.195.36 The first one (terminated by the dot) tells it lookup for the domain name superease.net itself. The dot is important - without it this would try to lookup superease.net.superease.net. The second one www (without a dot) tells it to lookup www.superease.net by appending the domain to the entry. Better yet use @, as the OP already does for NS and MX records - it means the current origin as set by the zone name that the file is loaded into from named.conf or as set by $ORIGIN (which is probably superfluous in this case), and is shorter and easier to type. Sam -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of Cefull Lo : : $TTL86400 $ORIGIN superease.net. @ IN SOA dns1.man169.com. root.dns1.man169.com. ( 2010022307 ; serial (d. adams) 10800 ; refresh 900 ; retry 604800 ; expiry 86400 ) ; minimum @ IN NS dns1.man169.com. @ IN NS dns2.man169.com. @ IN MX 10 mail.man169.com. ... [etc.] ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: no hostname become unresolvable.
On Tue, Feb 23, 2010 at 09:50:29AM -0500, Lightner, Jeff jlight...@water.com wrote a message of 66 lines which said: superease.net. IN A 202.68.195.36 ... The dot is important Using @ would be simpler and would allow the zone file to be used for other zones as well. http://www.bortzmeyer.org/identical-domains-with-bind.html ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Differences between 9.3 and later versions
On Tue, Feb 23, 2010 at 09:53:37AM -0500, jcarrol...@cfl.rr.com jcarrol...@cfl.rr.com wrote a message of 9 lines which said: However, whenever someone tries to nslookup (or dig) an external site (i.e. cnn.com) they get REFUSED. If I back down to the 9.3 version all is well. allow-query and allow-query-cache are obvious suspects. I wonder if, at one moment between 9.3 and 9.7, allow-query switched to default No access except for localhost, for reasons explained in RFC 5358? Anyway, check their current value and see also the log of named. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: no hostname become unresolvable.
Right - Thanks for pointing it out. I inherited a lot of zones and never went back and changed them. The @ is something I do use in alias zones - we have a couple hundred domains and many of them go to the same IP and using @ I'm able to use a single zone file to incorporate the ones that all go to the same IP for the domain. -Original Message- From: Stephane Bortzmeyer [mailto:bortzme...@nic.fr] Sent: Tuesday, February 23, 2010 10:01 AM To: Lightner, Jeff Cc: Cefull Lo; bind-users@lists.isc.org Subject: Re: no hostname become unresolvable. On Tue, Feb 23, 2010 at 09:50:29AM -0500, Lightner, Jeff jlight...@water.com wrote a message of 66 lines which said: superease.net. IN A 202.68.195.36 ... The dot is important Using @ would be simpler and would allow the zone file to be used for other zones as well. http://www.bortzmeyer.org/identical-domains-with-bind.html Proud partner. Susan G. Komen for the Cure. Please consider our environment before printing this e-mail or attachments. -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Scripts for zsk rollover in 9.7
Stephane Bortzmeyer wrote: We have plans to improve this in 9.7.x (where x probably equals 1) in a couple of ways: first, by making it possible to assign each key an explicit successor key and warn the user if a key is set to expire without a successor; second, by making it possible to configure named itself to generate new keys. I'm not sure it is a good idea. BIND is already quite loaded in features. Why not relying on dedicated free software such as OpenDNSSEC http://www.opendnssec.org/? I've looked at OpenDNSSEC, and while I think it is a great product that will do good things for lots of people, I think that it is complex, adds many additional dependencies to the system on which it runs and makes the maintainer responsible for yet another set of complicated configuration files. The additions to BIND will allow the automatic maintenance of the zones and keys without adding database management software, etc. AlanC (and yes, I work for ISC, so I'm a bit prejudiced) signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Differences between 9.3 and later versions
On Tue, 23 Feb 2010, jcarrol...@cfl.rr.com wrote: Due to an security audit I have been given the task of upgrading our BIND from 9.3 to a new version (9.7 is preferred). Using the package from sunfreeware.com (Solaris 10/X86) the upgrade seem to work well. However, whenever someone tries to nslookup (or dig) an external site (i.e. cnn.com) they get REFUSED. If I back down to the 9.3 version all is well. I've tried to find what new security feature is required, but alas I can't seem to get it. What changes affect resolving outside sites? The allow-query* options might be pertinent. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Summary: Differences between 9.3 and later versions
This mailing list rocks. Many thanks to Stephane Bortzmeyer and Jay Ford. Both where spot on with allow-query. Now BIND 9.7 resolves to the outside. JC jcarrol...@cfl.rr.com wrote: Please do not crucify me. Due to an security audit I have been given the task of upgrading our BIND from 9.3 to a new version (9.7 is preferred). Using the package from sunfreeware.com (Solaris 10/X86) the upgrade seem to work well. However, whenever someone tries to nslookup (or dig) an external site (i.e. cnn.com) they get REFUSED. If I back down to the 9.3 version all is well. I've tried to find what new security feature is required, but alas I can't seem to get it. What changes affect resolving outside sites? JC ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: no hostname become unresolvable.
@ IN MX 10 mail.man169.com. Try adding here: @ IN A 202.68.195.36 www IN A 202.68.195.36___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: cache hit rate/ratio
Try caused recursion / non authorative. On Feb 23, 2010 3:47 PM, Timothy Holtzen t...@nebrwesleyan.edu wrote: I have seen references out there about cache hit rates of 50-70% being normal. However I'm confused as to how to measure/calculate hit ratio? I can't seem to find any good references on how to find it. The only thing I've been able to find is to do (responses sent) - (queries caused recursion) but this would include queries for local authoritative zones. In our particular case if I divide by the total number of queries I end up with a number around 66%. Is this the correct way? In our particular case I suspect that the majority of those responses are for local authoritative zones. Wouldn't a more accurate way to measure cache performance be to take (non authoritative answer)-(queries caused recursion)/Total Queries? In our case calculating this way would yield a number closer to 13% which looks low when compared to the normal range listed above. How are others calculating hit rate/ratio and what do you tend to see as normal? Obviously normal can vary wildly depending on configuration and what kind of queries a system receives. I'm just trying to get a handle on how our cache is performing and what I should expect. Cache hit rate seems to be an important metric when considering overall DNS performance. -- Timothy A. Holtzen Campus Network Administrator Nebraska Wesleyan University ___ 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: Differences between 9.3 and later versions
On 23.02.10 09:53, jcarrol...@cfl.rr.com wrote:
Due to an security audit I have been given the task of upgrading our BIND
from 9.3 to a new version (9.7 is preferred). Using the package from
sunfreeware.com (Solaris 10/X86) the upgrade seem to work well. However,
whenever someone tries to nslookup (or dig) an external site (i.e.
cnn.com) they get REFUSED. If I back down to the 9.3 version all is well.
I've tried to find what new security feature is required, but alas I can't
seem to get it. What changes affect resolving outside sites?
since 9.4, the allow-query-cache was introduced, which controls if
non-recursive clients may fetch your cache content. Until then, clients who
were allowed to query might see your cache, which was lowering the effect of
disabling recursion to them.
the allow-euery-cache and allow-recursion cross-inherit each other - if
only one is set, the other one is assumed to be the same.
This means that you don't have to disable anyone from querying your server
and then enable querying local zones to prevent them from using server as
semi-recursive.
since 9.5, the default for allow-recursion is { localhost; localnets; };
previous versions used iirc { all; }; - if you didn't have recursion
enabled, you may need to do so now. Note that enabling recursion to anyone
is security risk.
--
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.
REALITY.SYS corrupted. Press any key to reboot Universe.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Differences between 9.3 and later versions
On Feb 23 2010, Matus UHLAR - fantomas wrote:
since 9.5, the default for allow-recursion is { localhost; localnets; };
previous versions used iirc { all; };
Actually, that change was made in 9.4. (Some of the cross-inheritance of
the different query-* access controls wasn't there until 9.4.2, though).
--
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: nsec3 in bind 9.7
To answer the question, those values are the NSEC3PARAM data for the zone, as defined in RFC 5155. [...] flags of 1 means opt-out and 0 means no opt-out; It is not exactly what the RFC says: The Opt-Out flag is not used and is set to zero. True. I oversimplified a bit. When you send an NSEC3PARAM record via DDNS, it may be modified before it actually appears in the zone. The record you send is a signal to named that you want to change from NSEC to NSEC3, or change from one NSEC3 chain to another one with different parameters. The opt-out flag in the record you send is part of that signal; it indicates whether the new chain should use opt-out or not. On receiving such a record, named carries out the NSEC3 transition. The last step in that transition is placing an NSEC3PARAM record at the zone apex. *That* record always has opt-out set to zero, per the RFC. -- 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
Cannot use dnssec-settime with old keys
I try to play with the new toy, DNSSEC timing meta-data in key files. % dnssec-settime -v 3 Ktoto.fr.+008+42555 dnssec-settime: fatal: Key toto.fr/RSASHA256/42555 has incompatible format version 1.2, use -f to force upgrade to new version. OK, I upgrade: % dnssec-settime -v 3 -f Ktoto.fr.+008+42555 dnssec-settime: toto.fr/RSASHA256/42555 But it changed nothing, ls -l shows that the file did not change and I still get the message incompatible format version 1.2. 9.7.0 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Scripts for zsk rollover in 9.7
I'm not sure it is a good idea. BIND is already quite loaded in features. Why not relying on dedicated free software such as OpenDNSSEC http://www.opendnssec.org/? AFAIK, OpenDNSSEC works fine with 9.7. (And it rocks and everyone should check it out.) But there's room for both approaches. -- 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
Re: Update returns FORMERR: ran out of space
On Tue, Feb 23, 2010 at 02:56:15PM +0100, Stephane Bortzmeyer bortzme...@nic.fr wrote a message of 17 lines which said: Trying to add/delete DNSSEC keys with dynamic update (first time I try that), the nsupdate client gets a FORMERR and BIND logs: Some details: * I use NSEC3 with opt-out * I checked with a completely new zone, with an empty history (same problem) * I checked the ARM which says that dynupdating DNSKEY is supported ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
`named' uses 32-bit capabilities
In production I am running BIND 9.6.1-P3 on Solaris 9, sun4u sparc SUNW,Sun-Fire-V240. When I start BIND I get this message: Jan 25 11:03:17 dns1 named[9673]: [ID 873579 daemon.notice] built with '--prefix=/export/home/named/bind' '--with-openssl=/krb5' '--sysconfdir=/export/home/named' '--enable-threads' '--localstatedir=/var' I am testing the same version of BIND on an Ubuntu Karmic system, x86_64 GNU/Linux. Both are built from the ISC source. When I start BIND I get these messages: Feb 19 10:08:01 karmic kernel: [146949.294524] warning: `named' uses 32-bit capabilities (legacy support in use) Feb 19 10:08:01 karmic named[22678]: starting BIND 9.6.1-P3 -c /etc/iscbind/named.conf Feb 19 10:08:01 karmic named[22678]: built with '--prefix=/etc/iscbind/bind/' '--sysconfdir=/etc/iscbind' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-gssapi=/usr' What is causing the `named' uses 32-bit capabilities (legacy support in use) message on this Ubuntu karmic build? What do I need to specify to avoid the 32-bit code? Thanks. -- Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone:+1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 240, Room 5.B.8 Internet: bsfin...@anl.gov Argonne, IL 60439-4828 IBMMAIL: I1004994 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC: Configuring auto-signed dynamic zone HOWTO
Stephane Bortzmeyer wrote: There is nothing about key rollover, it seems? How do you handle it? I don't. (Well, for now the plan is to do it once a year by hand. Then, we'll see...) Regards, Eugene signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC: Configuring auto-signed dynamic zone HOWTO
On Tue, 2010-02-23 at 23:40 +0300, Eugene Crosser wrote: (Well, for now the plan is to do it once a year by hand. Then, we'll see...) For the record, NIST recommends to roll the ZSK every three months, and the KSK every two years. Thanks, -- Nicholas signature.asc Description: This is a digitally signed message part ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC: Configuring auto-signed dynamic zone HOWTO
Nicholas Wheeler wrote: On Tue, 2010-02-23 at 23:40 +0300, Eugene Crosser wrote: (Well, for now the plan is to do it once a year by hand. Then, we'll see...) For the record, NIST recommends to roll the ZSK every three months, and the KSK every two years. And there are lots of other opinions on this timing as well. Rolling ZSK using BIND 9.7 is amazingly easy - I'm planning on writing a short paper on this as time permits. Rolling KSK is a bit more difficult as there aren't a lot of registrars that have the ability to accept DS records at this point anyway, and I don't see them implementing RFC-5011 personally... It's coming, it's just not here quite yet. 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: DNSSEC: Configuring auto-signed dynamic zone HOWTO
On Tue, 23 Feb 2010, Alan Clegg wrote: For the record, NIST recommends to roll the ZSK every three months, and the KSK every two years. And there are lots of other opinions on this timing as well. Note that you cannot really talk about rolling key recommendations without mentioning the key sizes (and algorithms) involved. I believe the above NIST recommendation is for 1024 bit RSASHA1 ZSK's and 2048 bit RSASHA1 2048 bit keys. They might also apply to RSASHA256 keys. Paul ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC: Configuring auto-signed dynamic zone HOWTO
Date: Tue, 23 Feb 2010 16:02:27 -0500 From: Alan Clegg acl...@isc.org Sender: bind-users-bounces+oberman=es@lists.isc.org Nicholas Wheeler wrote: On Tue, 2010-02-23 at 23:40 +0300, Eugene Crosser wrote: (Well, for now the plan is to do it once a year by hand. Then, we'll see...) For the record, NIST recommends to roll the ZSK every three months, and the KSK every two years. My copy of SP800-81r1 says ZSK 1 month and KSK 1-2 years. It also recommends a 2048 bit key for both KSK and ZSK. It was still draft when I printed it out, but I suspect that the final draft will match these recommendations. -- 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
Re: Fwd: IPv6 client and negative cache - some doubts
In message f677fefa1002230600n4694161cu315e5dd4beaaa...@mail.gmail.com, Micha
l Wesolowski writes:
sorry for replying directly, still have some problems with gmail UI.
-- Forwarded message --
From: Michal Wesolowski gmic...@gmail.com
Date: Tue, Feb 23, 2010 at 2:47 PM
Subject: Re: IPv6 client and negative cache - some doubts
To: Sam Wilson sam.wil...@ed.ac.uk
On Tue, Feb 23, 2010 at 1:33 PM, Sam Wilson sam.wil...@ed.ac.uk wrote:
In article mailman.529.1266923597.21153.bind-us...@lists.isc.org,
Michal Wesolowski gmic...@gmail.com wrote:
Hello Everyone
I have a problem with Bind 9.3.6-P1 (included in Solaris 10) but honestly
I
don't even understand if it is wrong Bind behaviour or my ignorance. It
does
apply only to some specific cases when external domain delegation is also
somewhat broken. My server is caching only. Let me show it by the
example:
Host www.goleszow.pl has bad NS delegation on country root servers
level
because virtual.sincom.pl is not resolvable:
goleszow.pl.86400INNSvirtual.sincom.pl.
goleszow.pl.86400INNSvirtual.jasnet.pl.
;; Received 91 bytes from 149.156.1.6#53(G-DNS.pl) in 19 ms
That may be part of the problem, and it needs to be fixed, but I don't
think that's all of it.
When dns client asks my server for A record of www.goleszow.pl -
everything is fine. But when first query (after cache is flushed) asks
for
record - my server seems to cache negative answer and all subsequent
queries for A record also fails. ...
[snip]
This is what I found in the Bind cache:
# rndc dumpdb -all
# cat /var/named/log/named_dump.db | grep virt
goleszow.pl.85994 NS virtual.jasnet.pl.
85994 NS virtual.sincom.pl.
virtual.jasnet.pl. 3194A 85.202.208.254
virtual.sincom.pl. 3194\-ANY ;-$NXDOMAIN
; virtual.jasnet.pl alias jasnet.pl [v4 TTL 3194] [target TTL 3194] [v4
success] [v6 unexpected]
; virtual.sincom.pl [v4 TTL 3194] [v6 TTL 3194] [v4 nxdomain] [v6
nxdomain]
Which for me doesn't explain this behaviour. Please advice.
Note that line beginning virtual.jasnet.pl alias jasnet.pl. jasnet.pl
is delegated to ns10.az.pl and ns11.az.pl. If you ask them for an A
record for virtual.jasnet.pl you get an A record; if you ask for
you get a CNAME pointing to jasnet.pl. I can't imagine what sort of
configuration could cause that to happen. I'm also not sure how that
might be screwing up your lookups, but it's certainly weird. On the
'fix what you know to be broken' principle I'd try to get that and the
broken delegation sorted first before looking any further.
Sam
Thank you Sam for pointing this out. This is probably real source of the
problem. I looked over what could cause such situation and so far found old
bug in PowerDNS (but don't know if they use it!) which generated such
answers when using wildcards.
After some reading my present understanding is that correct response to
query when there is such record in the zone and there exists another record
of different type for the same name - is to reply with empty answer and no
error (this applies to authoritative NS). So what ns10.az.pl does is not
consistent with specification.
However I'm still not sure if bind shouldn't cope with this somehow. I
understand that if it applied to final query for www.goliszew.pl than it
would be correct for bind to cache it as negative for all types of records.
But if it concerns bad respond for NS? - I don't know.
Thanks
Michal
Well one of the nameservers does not exist and the other is a CNAME.
Both of these are fatal errors for the particular nameserver and
as there are only two nameservers for the zone lookups fail.
Add A records to the sincom.pl and jasnet.pl zones for virtual.sincom.pl
and virtual.jasnet.pl respectively.
Mark
; DiG 9.3.6-P1 virtual.sincom.pl @ns11.az.pl
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 45587
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;virtual.sincom.pl. IN
;; AUTHORITY SECTION:
sincom.pl. 3600IN SOA ns10.az.pl. admin.az.pl.
2009101603 10800 3600 604800 3600
;; Query time: 356 msec
;; SERVER: 62.146.68.200#53(62.146.68.200)
;; WHEN: Wed Feb 24 09:12:16 2010
;; MSG SIZE rcvd: 85
; DiG 9.7.0rc1 virtual.jasnet.pl @ns11.az.pl
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 11702
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;virtual.jasnet.pl. IN
;; ANSWER SECTION:
virtual.jasnet.pl. 3600IN CNAME jasnet.pl.
;; AUTHORITY SECTION:
jasnet.pl.
Re: Update returns FORMERR: ran out of space
In message 20100223135615.ga30...@nic.fr, Stephane Bortzmeyer writes: Trying to add/delete DNSSEC keys with dynamic update (first time I try that), the nsupdate client gets a FORMERR and BIND logs: Feb 23 14:53:24 jezabel named[10174]: client ::1#29411: updating zone 'bortzm eyer.fr/IN': RRSIG/NSEC/NSEC3 update failed: ran out of space I checked the disk space (plenty) but I suspect that the problem is more complicated. Turn the debugging up to 3. The log message is a result of update_signatures() detecting a error. ran out of space usually means a fixed sized buffer is not big enough or the change exceeded a architectual limit of the protocol. Mark I can add A records just fine: Feb 23 14:55:46 jezabel named[10174]: client ::1#51231: updating zone 'bortzm eyer.fr/IN': adding an RR at 'created-dyn-1266933346-8636.bortzmeyer.fr' A BIND 9.7.0 built with '--without-idnlib' '--without-dlz' '--without-idn' '--w ith-libxml2=yes' '--enable-openssl' ___ 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
OpenDNS today announced it has adopted DNSCurve to secure DNS
Now that OpenDNS the largest provider of public DNS supports DNSCurve http://twitter.com/joebaptista/status/9555178362 Would it be possible to include DNScurve support in bind? thanks joe baptista ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Blacklisting private address range
Hi! Have any sense to blacklist the private address ranges on a server that is facing Internet? I mean, this address ranges is not even routed on the Internet. There is a trick about this? Thanks in advance! -- Diosney ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: OpenDNS today announced it has adopted DNSCurve to secure DNS
On 02/23/10 18:31, Joe Baptista wrote: Now that OpenDNS the largest provider of public DNS supports DNSCurve http://twitter.com/joebaptista/status/9555178362 Would it be possible to include DNScurve support in bind? thanks joe baptista I'd love to see BIND adopt DNScurve...when it becomes an RFC. Until then, I'd prefer that BIND stick to the existing body of RFCs. If DNScurve is important enough for the whole Internet to use, then it's important enough to drag it through the whole IETF process, political as it may or may not be. Personally, I think DNScurve misses the mark. My concern, as someone who operates both authoritative and recursive servers, is that the data on the authority side be authentic end-to-end. With DNSSEC, I can validate that that's true. DNScurve advocates, on the other hand, point out that DNS isn't encrypted. Well, neither is the phone book. So what? I regard DNS as a public database, and it's more important to me that it be authentic--from the source--than obscurified. While I think the OpenDNS people (especially David U., their founder) have a huge amount of clue, I think they're barking up the wrong tree here. michael ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: OpenDNS today announced it has adopted DNSCurve to secure DNS
It would be nice to see it as an RFC. I agree with that. But from what I know it will be a pretty cold day in hell before it becomes an RFC. I humbly suggest Dr. Bernstein who is behind DNScurve thinks the IETF is full of wackos. So it is unlikely he will ever be bothered to dance the IETF RFC jig. I do disagree with you that bind should only implement what is in the RFC. Lets not forget the IETF has had 15 years to secure the DNS. The result is the DNSSEC abortion. It has failed. This announcement today is a stiff well deserved kick in the balls to the DNSSEC crowd. We can not rely on the IETF for security. Commerce and simple common sense communications are screaming for security solutions today. DNSCurve is perfect and it works out of the box. Folks. OpenDNS has set the DNS standard. We can start securing the DNS with every new dnscurve upgrade to bind. Imagine how much money is being spent on the DNSSEC make work project - time and energy wasted. DNScurve installs - configures and runs. No need for a make work project. agreed? regards joe baptista On Tue, Feb 23, 2010 at 10:28 PM, Michael Sinatra mich...@rancid.berkeley.edu wrote: On 02/23/10 18:31, Joe Baptista wrote: Now that OpenDNS the largest provider of public DNS supports DNSCurve http://twitter.com/joebaptista/status/9555178362 Would it be possible to include DNScurve support in bind? thanks joe baptista I'd love to see BIND adopt DNScurve...when it becomes an RFC. Until then, I'd prefer that BIND stick to the existing body of RFCs. If DNScurve is important enough for the whole Internet to use, then it's important enough to drag it through the whole IETF process, political as it may or may not be. Personally, I think DNScurve misses the mark. My concern, as someone who operates both authoritative and recursive servers, is that the data on the authority side be authentic end-to-end. With DNSSEC, I can validate that that's true. DNScurve advocates, on the other hand, point out that DNS isn't encrypted. Well, neither is the phone book. So what? I regard DNS as a public database, and it's more important to me that it be authentic--from the source--than obscurified. While I think the OpenDNS people (especially David U., their founder) have a huge amount of clue, I think they're barking up the wrong tree here. michael ___ 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: OpenDNS today announced it has adopted DNSCurve to secure DNS
I humbly suggest Dr. Bernstein who is behind DNScurve thinks the IETF is full of wackos. So it is unlikely he will ever be bothered to dance the IETF RFC jig. Is there a requirement that Dr. Bernstein must personally do the dancing? Let someone else write the RFC, if it needs writing. While the existence of an RFC isn't an absolute requirement for BIND to implement something, it certainly helps. But what helps a lot more is evidence that the thing in question is getting widespread use, or that there's significant user demand for it. So far, we're not seeing either of those things with DNSCurve. When we do, I'll be happy to write the code. -- 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
Re: OpenDNS today announced it has adopted DNSCurve to secure DNS
On 02/23/10 19:54, Joe Baptista wrote: It would be nice to see it as an RFC. I agree with that. But from what I know it will be a pretty cold day in hell before it becomes an RFC. I humbly suggest Dr. Bernstein who is behind DNScurve thinks the IETF is full of wackos. So it is unlikely he will ever be bothered to dance the IETF RFC jig. I do disagree with you that bind should only implement what is in the RFC. Lets not forget the IETF has had 15 years to secure the DNS. The result is the DNSSEC abortion. It has failed. This announcement today is a stiff well deserved kick in the balls to the DNSSEC crowd. We can not rely on the IETF for security. Commerce and simple common sense communications are screaming for security solutions today. DNSCurve is perfect and it works out of the box. Folks. OpenDNS has set the DNS standard. We can start securing the DNS with every new dnscurve upgrade to bind. Imagine how much money is being spent on the DNSSEC make work project - time and energy wasted. DNScurve installs - configures and runs. No need for a make work project. agreed? As someone who both signs his production zones and does DNSSEC validation, I can assure you that DNSSEC works. But you've done as good job as I can imagine in making the case for DNScurve. michael ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Fwd: IPv6 client and negative cache - some doubts
On Tue, Feb 23, 2010 at 11:19 PM, Mark Andrews ma...@isc.org wrote: In message f677fefa1002230600n4694161cu315e5dd4beaaa...@mail.gmail.com, Micha l Wesolowski writes: sorry for replying directly, still have some problems with gmail UI. -- Forwarded message -- From: Michal Wesolowski gmic...@gmail.com Date: Tue, Feb 23, 2010 at 2:47 PM Subject: Re: IPv6 client and negative cache - some doubts To: Sam Wilson sam.wil...@ed.ac.uk On Tue, Feb 23, 2010 at 1:33 PM, Sam Wilson sam.wil...@ed.ac.uk wrote: In article mailman.529.1266923597.21153.bind-us...@lists.isc.org, Michal Wesolowski gmic...@gmail.com wrote: Hello Everyone I have a problem with Bind 9.3.6-P1 (included in Solaris 10) but honestly I don't even understand if it is wrong Bind behaviour or my ignorance. It does apply only to some specific cases when external domain delegation is also somewhat broken. My server is caching only. Let me show it by the example: Host www.goleszow.pl has bad NS delegation on country root servers level because virtual.sincom.pl is not resolvable: goleszow.pl.86400INNSvirtual.sincom.pl. goleszow.pl.86400INNSvirtual.jasnet.pl. ;; Received 91 bytes from 149.156.1.6#53(G-DNS.pl) in 19 ms That may be part of the problem, and it needs to be fixed, but I don't think that's all of it. When dns client asks my server for A record of www.goleszow.pl - everything is fine. But when first query (after cache is flushed) asks for record - my server seems to cache negative answer and all subsequent queries for A record also fails. ... [snip] This is what I found in the Bind cache: # rndc dumpdb -all # cat /var/named/log/named_dump.db | grep virt goleszow.pl.85994 NS virtual.jasnet.pl. 85994 NS virtual.sincom.pl. virtual.jasnet.pl. 3194A 85.202.208.254 virtual.sincom.pl. 3194\-ANY ;-$NXDOMAIN ; virtual.jasnet.pl alias jasnet.pl [v4 TTL 3194] [target TTL 3194] [v4 success] [v6 unexpected] ; virtual.sincom.pl [v4 TTL 3194] [v6 TTL 3194] [v4 nxdomain] [v6 nxdomain] Which for me doesn't explain this behaviour. Please advice. Note that line beginning virtual.jasnet.pl alias jasnet.pl. jasnet.pl is delegated to ns10.az.pl and ns11.az.pl. If you ask them for an A record for virtual.jasnet.pl you get an A record; if you ask for you get a CNAME pointing to jasnet.pl. I can't imagine what sort of configuration could cause that to happen. I'm also not sure how that might be screwing up your lookups, but it's certainly weird. On the 'fix what you know to be broken' principle I'd try to get that and the broken delegation sorted first before looking any further. Sam Thank you Sam for pointing this out. This is probably real source of the problem. I looked over what could cause such situation and so far found old bug in PowerDNS (but don't know if they use it!) which generated such answers when using wildcards. After some reading my present understanding is that correct response to query when there is such record in the zone and there exists another record of different type for the same name - is to reply with empty answer and no error (this applies to authoritative NS). So what ns10.az.pl does is not consistent with specification. However I'm still not sure if bind shouldn't cope with this somehow. I understand that if it applied to final query for www.goliszew.pl than it would be correct for bind to cache it as negative for all types of records. But if it concerns bad respond for NS? - I don't know. Thanks Michal Well one of the nameservers does not exist and the other is a CNAME. Both of these are fatal errors for the particular nameserver and as there are only two nameservers for the zone lookups fail. Add A records to the sincom.pl and jasnet.pl zones for virtual.sincom.pl and virtual.jasnet.pl respectively. Mark My server is caching only, I don't administer ns*.az.pl servers. I'm just trying to understand if binds copes well with such an external error. As you pointed out both servers fails in some (different) way but second one does this only when queried for something other than A record. For A everything is ok. THERE IS A record for virtual.jasnet.pl. Why bad response from external server for record affects subsequent queries for A? Which entry of cache is responsible for this: r...@kellys # cat named_dump.db| egrep 'vir|gol|jas|sin|az' ns10.az.pl. 86397 A 62.146.113.3 ns11.az.pl. 86397 A 62.146.68.200 goleszow.pl.86397 NS virtual.jasnet.pl. 86397 NS virtual.sincom.pl. www.goleszow.pl.3597CNAME goleszow.pl.
hosts or subnet number in delegation?
Hello, for a 192.168.199.64/26 in zone file to delegate to a customer; should i put subnet number: 64/26 IN NS ns1.example.com. 64/26 IN NS ns2.example.com. or host ranges: 64-126 IN NS ns1.example.com. 64-126 IN NS ns2.example.com. . . $GENERATE 65-126 $ CNAME $.65-126 thanks Sasa ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: hosts or subnet number in delegation?
On Wed, Feb 24, 2010 at 2:01 PM, sasa sasa sasasa20...@yahoo.com wrote: Hello, for a 192.168.199.64/26 in zone file to delegate to a customer; should i put subnet number: 64/26 IN NS ns1.example.com. 64/26 IN NS ns2.example.com. or host ranges: 64-126 IN NS ns1.example.com. 64-126 IN NS ns2.example.com. Doesn't really matter. With the former, the client needs to create a zone called 64/26.199.169.192.in-addr.arpa, while in the later the zone would be 64-126.199.169.192.in-addr.arpa See http://www.zytrax.com/books/dns/ch9/reverse.html for example. -- Fajar ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Automatic key rollover (Was: DNSSEC: Configuring auto-signed dynamic zones HOWTO)
Nicholas Wheeler wrote: On Tue, 2010-02-23 at 23:40 +0300, Eugene Crosser wrote: (Well, for now the plan is to do it once a year by hand. Then, we'll see...) For the record, NIST recommends to roll the ZSK every three months, and the KSK every two years. Let me put it this way: by the time I become bothered with automatic key rollover, hopefully bind 9.7 will become part of the distribution that I use. Then I'll figure things out. BTW, I feel wary about letting named do everything related to zone signing for me. For one, private KSK, and probably 'top' zone ZSK, are not going to be readable by named. And maybe even not going to live on the same host. Eugene signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
