Re: dnssec validation issue

[dhungyel]

Hi Mukund

> Are you able to reproduce the bug with the latest stock version of BIND 
> 9.9?  9.9.4 is very old and that branch has had numerous bugfixes since. 

> I'm not able to reproduce such a validation failure with 9.9.11: 

At the moment the latest patched version of bind available for CentOS 7 is
9.9.4-50. The policy has been to stick with the patches / versions
distributed by the Distro rather than getting the latest. So, I will have to
try the new version and see if the problem persists.

I have looked around a bit more and this is where it starts getting
interesting. For hosts that are not mapped to CNAME, this works perfectly
fine. See below for host ns.icann.org

# dig @localhost ns.icann.org A +dnssec

; <<>> DiG 9.9.4-RedHat-9.9.4-50.el7_3.1 <<>> @localhost ns.icann.org A
+dnssec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31866
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 9

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;ns.icann.org.  IN  A

;; ANSWER SECTION:
ns.icann.org.   3600IN  A   199.4.138.53
ns.icann.org.   3600IN  RRSIG   A 7 3 3600 20170914022301 
20170824010741 56445
icann.org. DFfGY0h65bDzMHNSkf9cmM8vHbIeOyupdw5HeagBiWzQMAbzvtc4w5et
N+1P2zeOPvCvYiBcUsHi+JGqyB0q6gpyZMcXFbMGRPnp931B+F6MUnZL
H2+2PDhkBrZ1EtyVaS8s8IyZ9XOuzJKNwOQBt4mNdFhpvrpWmXMc1zTQ OYX1Kqg=

;; AUTHORITY SECTION:
icann.org.  86393   IN  NS  a.iana-servers.net.
icann.org.  86393   IN  NS  ns.icann.org.
icann.org.  86393   IN  NS  c.iana-servers.net.
icann.org.  86393   IN  NS  b.iana-servers.net.
icann.org.  86393   IN  RRSIG   NS 7 2 86400 20170915091737 
20170825024031 56445
icann.org. P7offNJTV/zX8mZVC7x6uwvhZrdLzLNM/r1tsp4g7yaprD6LY//TLbNc
tIdbFjZdml7CYYZxZSecmb5Uzo8O7sHS+1xdandh6KxPfo47mO+Ge6JI
JmspnEaOxOlK7Vp3RGCqdeUasxIpwjHlNa+4rZ30ImmKxsAGC9oq01ey d/JE8j8=

;; ADDITIONAL SECTION:
a.iana-servers.net. 172793  IN  A   199.43.135.53
a.iana-servers.net. 172793  IN  2001:500:8f::53
b.iana-servers.net. 172793  IN  A   199.43.133.53
b.iana-servers.net. 172793  IN  2001:500:8d::53
c.iana-servers.net. 172793  IN  A   199.43.134.53
c.iana-servers.net. 172793  IN  2001:500:8e::53
ns.icann.org.   86393   IN  2001:500:89::53
ns.icann.org.   3600IN  RRSIG    7 3 3600 20170913162548 
20170824010741
56445 icann.org. cSpl1KEIPeFTzXBhjn9CMA+Y4iVG92++kdzxoTzRhgEMsH2Xud/s8Mg1
DBEc07xMgou5OqyGvlbOxP1F2c/dOFrQBMBuojBmG4ltIj663GYshyFy
3sxqNJGATHDDJ7Sk8eiYFazct09Z2wQ73UdwKGXuzM4bD9LrXUYP0rnJ l0xEen8=

However, when I try the same thing for www.icann.org, I get SERVFAIL like
below:

# dig @localhost www.icann.org A +dnssec

; <<>> DiG 9.9.4-RedHat-9.9.4-50.el7_3.1 <<>> @localhost www.icann.org A
+dnssec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 30814
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.icann.org. IN  A

;; Query time: 4237 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Aug 31 10:06:23 +06 2017
;; MSG SIZE  rcvd: 42

So, I am beginning to wonder if there is issue between dissed and CNAME in
9.9.4-50 version of bind. With checking disabled (as suggested by Tony), it
resolves correctly:

# dig @localhost www.icann.org A +cd

; <<>> DiG 9.9.4-RedHat-9.9.4-50.el7_3.1 <<>> @localhost www.icann.org A +cd
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53618
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 7

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.icann.org. IN  A

;; ANSWER SECTION:
www.icann.org.  3386IN  CNAME   www.vip.icann.org.
www.vip.icann.org.  30  IN  A   192.0.32.7

;; AUTHORITY SECTION:
vip.icann.org.  3382IN  NS  gtm1.dc.icann.org.
vip.icann.org.  3382IN  NS  gtm1.mdr.icann.org.
vip.icann.org.  3382IN  NS  gtm1.lax.icann.org.

with +cd and +sigchase, the resolver is able to find the RRSIG data fine but
once checking is enabled, it just fails:


/# dig @localhost www.icann.org A +cd +sigchase
;; RRset to chase:
www.icann.org.  3039IN  CNAME   www.vip.icann.org.


;; RRSIG of the RRset to chase:
www.icann.org.  3039IN  RRSIG   CNAME 7 3 3600 20170914195717 
20170824110741
56445 icann.org. GoSDthX9s2BsyaT/AYyfNKixR8UMVF/fx3zz5U9XPIVJUkpp3g9xyuZy
wxO7aTVgiPaESUOttGGn4xs9KMzZ4BcI6bmOAehYubS6AaAb6YdbweR4
S6O3qiNMT5Sai4BrfmvITGjigyNXSb3vc8fsSeUPJVdR8gmObfzbJbdn 

Re: dnssec validation issue

[Mukund Sivaraman]

Hi Ganga

On Thu, Aug 24, 2017 at 09:33:32AM +0600, Ganga R. Dhungyel wrote:
> With dnssec-validation turned on, resolving sites like www.icann.org
>  fails. The alternative is to remove validation
> which of course is not the desired solution.

Are you able to reproduce the bug with the latest stock version of BIND
9.9?  9.9.4 is very old and that branch has had numerous bugfixes since.

I'm not able to reproduce such a validation failure with 9.9.11:

[muks@jurassic bind9]$ bin/dig @127.0.0.1 -p 53000 www.icann.org

; <<>> DiG 9.9.11 <<>> @127.0.0.1 -p 53000 www.icann.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28837
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.icann.org. IN  A

;; ANSWER SECTION:
www.icann.org.  3497IN  CNAME   www.vip.icann.org.
www.vip.icann.org.  30  IN  A   192.0.32.7

;; Query time: 464 msec
;; SERVER: 127.0.0.1#53000(127.0.0.1)
;; WHEN: Wed Aug 30 18:59:51 IST 2017
;; MSG SIZE  rcvd: 80

[muks@jurassic bind9]$

Both dig and named are from BIND 9.9.11. AD bit is set indicating
validation was performed.

Mukund
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec validation issue

[Stephane Bortzmeyer]

On Thu, Aug 24, 2017 at 09:33:32AM +0600,
 Ganga R. Dhungyel  wrote 
 a message of 677 lines which said:

> # dig @localhost www.icann.org A +dnssec

When you suspect a DNSSEC issue, always retry dig with +cd (Checking
Disabled). And post the result.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec validation issue

[Tony Finch]

Ganga R. Dhungyel  wrote:
>
> **debug log
>
> 23-Aug-2017 16:17:57.567 dnssec: debug 3:
>   validating @0x7f3ffc96e4d0: www.vip.icann.org A:
>   attempting insecurity proof
>
> With dnssec-validation turned on, resolving sites like www.icann.org fails.

I think that line in the debug log indicates that something went wrong
earlier - looks like the resolver somehow got an unsigned answer. I can't
say why without a bit more context.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Faeroes: Variable, mainly north, 3 or 4. Moderate or rough. Mainly fair. Good.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

dnssec validation issue

[Ganga R. Dhungyel]

Hi All

I am running a bind 9.9.4-50 resolver on CentOS 7 (kernel 
3.10.0-514.26.2.el7.x86_64). I have enabled dnssec and made it into a 
validating resolver but I am facing issues with some sites that use CNAME and 
getting SERVFAIL. Configs are pretty simple as given below:

**configs
options {
listen-on port 53 { 127.0.0.1; x.x.x.x; };
listen-on-v6 port 53 { ::1; ::::d; };
directory   "/var/named";
pid-file"/var/run/named/named.pid";
dump-file   "data/cache_dump.db";
empty-zones-enable yes;
   zone-statistics yes;
querylog yes;
recursion yes;
allow-recursion {localhost; my-net; };
statistics-file "data/named_stats.txt";
   memstatistics-file "data/named_mem_stats.txt";
allow-query {localhost; my-net; };
allow-query-cache {localhost; my-net; };
flush-zones-on-shutdown yes;
version "UNNECESSARY";
dnssec-enable yes;
dnssec-validation auto; ## tried with yes but no difference
random-device "/dev/urandom";
managed-keys-directory "/var/named/dynamic”;
};

// named.conf
//
include "/etc/named/acl.conf";
include "/etc/named/options.conf";
include "//etc/named/named-log.conf";
//include "/etc/named/named.rfc1912.zones";
include "/etc/rndc.key";
include "/etc/named.root.key";
zone "." IN {
type hint;
file "/var/named/data/named.root";
};
//
zone "0.0.127.in-addr.arpa" {
type master;
file "data/db.loopback.master";
notify no;
};
**end of configs
//
**dig results for A record of www.icann.org 

# dig @localhost www.icann.org . A +dnssec

; <<>> DiG 9.9.4-RedHat-9.9.4-50.el7_3.1 <<>> @localhost www.icann.org 
. A +dnssec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 25178
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.icann.org . IN  A


*** Dig for CNAME works fine
# dig @localhost www.icann.org . cname  +dnssec

; <<>> DiG 9.9.4-RedHat-9.9.4-50.el7_3.1 <<>> @localhost www.icann.org 
. cname +dnssec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62144
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 11

;www.icann.org . IN  CNAME

;; ANSWER SECTION:
www.icann.org .  1747IN  CNAME   
www.vip.icann.org .
www.icann.org .  1747IN  RRSIG   CNAME 7 
3 3600 20170830102924 20170809041125 56445 icann.org . 
VB1PWieuP3nZX9rpJ8WyA2G0DoV86NxkrgT6HNDsTHmDI0xLYdGvLPCj 
H4m3lRg1YVxmpwFEJPDHG9TRcqo39T4TDFe+SIyMI/2ERFRhgorggaok 
zATAs35lDiLpoO7S1LLSWl/L+QmT/bK/XXq1VP/ZUjX3t6belB/GBnZW ZsL/NAU=

;; AUTHORITY SECTION:
icann.org .  84541   IN  NS  
b.iana-servers.net .
icann.org .  84541   IN  NS  
c.iana-servers.net .
icann.org .  84541   IN  NS  ns.icann.org 
.
icann.org .  84541   IN  NS  
a.iana-servers.net .
icann.org .  84541   IN  RRSIG   NS 7 2 86400 
20170831033936 20170810001125 56445 icann.org . 
jylCSOpN18PNZcDYghGrYky8NsR1Pt7Rpm+c564QQobdd6u8Q1cQtVZZ 
a+m8wDQtgb0LQCQ9FEXT7Sm9+/p+hGottj4YUuv1TDnLSztSkUqV5DOV 
ptqG7TCFqsF482AMEmqW8OKNMiapAX6NAbO1hl5gDm+BX0ro2XrCaqzU 8RrdHNE=

;; ADDITIONAL SECTION:
a.iana-servers.net .170941  IN  A   
199.43.135.53
a.iana-servers.net .170941  IN  
2001:500:8f::53
b.iana-servers.net .170941  IN  A   
199.43.133.53
….
...
ns.icann.org .84541   IN  A   
199.4.138.53
ns.icann.org .84541   IN  
2001:500:89::53
ns.icann.org .1741IN  RRSIG   A 7 3 
3600 20170830005731 20170808155836 56445 icann.org . 
vcUjGAOoJj2nomVKLuigIJAYIOaauYWFN++wqcAYfwO6ayOXPxXMq4j6 
jvc8W5r+aLl4jQlHHTZ5L2TghdrH2ngFl5YlXKJSCjcAwifcvASrr5rv 
+5nmC41L66ueEafDLCBV1vUD2KlaHro1Om1vxZkl9zLCPQc3ESRkHE74 5Nr+nY8=
ns.icann.org .1741IN  RRSIG    7 
3 3600 20170830012209 20170809081125 56445 icann.org . 
rPURe+sfaBHZccMmpr1sqTzKgxnehYE5D4jt+ndGLKS0yq91EvX/Ktmk 

Re: dnssec validation issue

[Jaap Akkerhuis]

 Eray Aslan writes:

  On Thu, Jun 18, 2015 at 07:26:28PM -0700, Carl Byington wrote:
   On Fri, 2015-06-19 at 11:10 +1000, Mark Andrews wrote:
To use the keys in /etc/named.iscdlv.key set dnssec-validation
auto;
   New centos rpms at http://www.five-ten-sg.com/mapper/bind with a default
   named.conf that should actually work.
  
  With the root zone and most TLDs signed, I do not think it makes sense
  to use DLV anymore.  While a typical DNSSEC resolver configuration has
  DLV enabled, I personally make the effort to disable it.

Furthermore, the whole dlv register is going to disappear in 2017
as announced at https://www.isc.org/blogs/dlv/.

jaap
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

dnssec validation issue

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I have multiple centos6 boxes running 9.10.2-P1, and almost everything
looks good. However, one box seems to not be doing dnssec validation. It
is possible that this behavior predates the latest updates and I just
never noticed it.

A and B have essentially identical configuration, except that A is the
master for some zones, and B is the slave pulling from A. Other than
that, the /etc/named.conf is identical. A also has ipv6 connectivity,
and B does not. The authoritative side works nicely on both. The
recursive resolver is where the difference shows up.

On A:

dig www.dnssec-failed.org  @localhost
;; -HEADER- opcode: QUERY, status: NOERROR, id: 19813
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 11
;; ANSWER SECTION:
www.dnssec-failed.org.  7178IN  A   68.87.109.242
www.dnssec-failed.org.  7178IN  A   69.252.193.191



On B:
dig www.dnssec-failed.org  @localhost
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 4969
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1


/etc/named.conf:

options {
directory /var/named;
allow-recursion { friends; };
dnssec-enable yes;
dnssec-validation yes;
bindkeys-file /etc/named.iscdlv.key;
managed-keys-directory /var/named/dynamic;
listen-on-v6 {any;};
ixfr-from-differences yes;
max-journal-size 2m;
notify yes;
response-policy { zone rpz.five-ten-sg.com;}
qname-wait-recurse no;
filter--on-v4 yes;
filter- { brokenv6; };
rate-limit {
responses-per-second 5;
errors-per-second5;
nxdomains-per-second 40;
qps-scale300;
exempt-clients { friends; };
};
};


A is neither master nor slave for dnssec-failed.org, and that domain is
not mentioned in the rpz zone.




-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAlWDYtAACgkQL6j7milTFsHClQCeLKkTuQYlM4liB0UECG5Z4pui
ujMAnj4wnUWqJj258pIlUFo0IONtkkEP
=/QDW
-END PGP SIGNATURE-


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec validation issue

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 2015-06-19 at 11:10 +1000, Mark Andrews wrote:

 You don't have any trust anchors active.

 To use the keys in /etc/named.iscdlv.key set dnssec-validation
 auto;

Thanks!!

New centos rpms at http://www.five-ten-sg.com/mapper/bind with a default
named.conf that should actually work.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAlWDfboACgkQL6j7milTFsEsYgCcDCJgzbdD4quzkp8tI+hFIsfq
oQAAnRTCvYt4K9t98AjGnruiJqTxAj5y
=DOlX
-END PGP SIGNATURE-


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec validation issue

[Mark Andrews]

In message 1434674101.18744.119.ca...@ns.five-ten-sg.com, Carl Byington write
s:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 I have multiple centos6 boxes running 9.10.2-P1, and almost everything
 looks good. However, one box seems to not be doing dnssec validation. It
 is possible that this behavior predates the latest updates and I just
 never noticed it.
 
 A and B have essentially identical configuration, except that A is the
 master for some zones, and B is the slave pulling from A. Other than
 that, the /etc/named.conf is identical. A also has ipv6 connectivity,
 and B does not. The authoritative side works nicely on both. The
 recursive resolver is where the difference shows up.
 
 On A:
 
 dig www.dnssec-failed.org  @localhost
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 19813
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 11
 ;; ANSWER SECTION:
 www.dnssec-failed.org.  7178IN  A   68.87.109.242
 www.dnssec-failed.org.  7178IN  A   69.252.193.191
 
 
 
 On B:
 dig www.dnssec-failed.org  @localhost
 ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 4969
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
 

You don't have any trust anchors active.

To use the keys in /etc/named.iscdlv.key set dnssec-validation auto;

 /etc/named.conf:
 
 options {
 directory /var/named;
 allow-recursion { friends; };
 dnssec-enable yes;
 dnssec-validation yes;
 bindkeys-file /etc/named.iscdlv.key;
 managed-keys-directory /var/named/dynamic;
 listen-on-v6 {any;};
 ixfr-from-differences yes;
 max-journal-size 2m;
 notify yes;
 response-policy { zone rpz.five-ten-sg.com;}
 qname-wait-recurse no;
 filter--on-v4 yes;
 filter- { brokenv6; };
 rate-limit {
 responses-per-second 5;
 errors-per-second5;
 nxdomains-per-second 40;
 qps-scale300;
 exempt-clients { friends; };
 };
 };
 
 
 A is neither master nor slave for dnssec-failed.org, and that domain is
 not mentioned in the rpz zone.
 
 
 
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.14 (GNU/Linux)
 
 iEYEARECAAYFAlWDYtAACgkQL6j7milTFsHClQCeLKkTuQYlM4liB0UECG5Z4pui
 ujMAnj4wnUWqJj258pIlUFo0IONtkkEP
 =/QDW
 -END PGP SIGNATURE-
 
 
 ___
 Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
  from this list
 
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec validation issue

[Eray Aslan]

On Thu, Jun 18, 2015 at 07:26:28PM -0700, Carl Byington wrote:
 On Fri, 2015-06-19 at 11:10 +1000, Mark Andrews wrote:
  To use the keys in /etc/named.iscdlv.key set dnssec-validation
  auto;
 New centos rpms at http://www.five-ten-sg.com/mapper/bind with a default
 named.conf that should actually work.

With the root zone and most TLDs signed, I do not think it makes sense
to use DLV anymore.  While a typical DNSSEC resolver configuration has
DLV enabled, I personally make the effort to disable it.

-- 
Eray
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND DNSSEC-Validation issue sceggs.nsw.edu.au

[Michael Sinatra]

On 09/12/11 22:12, Neil wrote:

Hi BIND Users
I am currently trialing Bind v9.8.1 and have come across a issue with 1
particular domain.
For some reason when I query the below domain on bind resolver-cache
nothing gets returned.?
dig @server sceggs.nsw.edu.au ns
The debug logs show
13-Sep-2011 10:11:27.272 query-errors: debug 1: client
203.134.1.70#10309: view host_resolver_trusted: query failed (SERVFAIL)
for sceggs.nsw.edu.au/IN/NS at query.c:6195
13-Sep-2011 10:11:27.272 query-errors: debug 2: fetch completed at
resolver.c:3160 for sceggs.nsw.edu.au/NS in 30.000122: timed out/success
[domain:sceggs.nsw.edu.au,referral:0,restart:7,qrysent:7,timeout:6,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]
named.conf has the below settings for dnssec
dnssec-enable yes;
dnssec-validation auto;
Even with the below and managed-keys still does not work
dnssec-enable yes;
dnssec-validation yes;
The only way a result is given is to turn off dnssec-validation then it
works!
dnssec-validation no;
Only then a result is given for the query. The domain is in the AU space
which is not
currently signed. So I don't know why this would affect sec-validation
and the queried domain?
Also noticed its happening in 9.7.2-P3
Any ideas why this is happening and how to fix it without loosing
dnssec-validation?
Does anyone else have the same issue with the above scenario?


A quick glance shows two problems:

1. The three authoritative DNS servers for sceggs.nsw.edu.au are 
dns1.sceggs.nsw.edu.au, dns2.sceggs.nsw.edu.au, and ns2.netstrategy.net. 
 dns1.sceggs.. and dns2.sceggs.. have no glue records in their parent zone.


2. ns2.netstrategy.net has glue in the parent, but it's the WRONG glue, 
and it points to a server that doesn't respond.


All three servers for the zone are effectively glue-less.  How cute.

I can consistently make the queries work properly, even with 
dnssec-validation set to 'yes', by flushing the cache, doing a priming 
query for ns2.netstrategy.net, and THEN querying for 'sceggs.nsw.edu.au 
ns'.  I can also make it consistently fail by flushing the cache and 
then only querying for 'sceggs.nsw.edu.au ns'.


As to why it only happens when dnssec-validation is turned on: It 
appears that BIND continues to use the broken glue record address for 
ns2.netstrategy.net when querying for the sceggs.nsw.edu.au zone, even 
after it receives an authoritative, but unsigned, response with the 
correct A for ns2.netstrategy.net (see the end of this message).  This 
behavior only occurs when dnssec-validation is turned on, not when it is 
turned off.  It's possible that the presence of the glue record in a 
signed zone (even though the glue record itself is not signed) takes 
precedence over the same A record in the authoritative zone.  However, 
that doesn't seem right to me.


Definitely, the zone delegation is seriously broken, due to issues #1 
and #2.  However, BIND's behavior doesn't seem right to me when 
validation is turned on.  Given the 'insecure' (in DNSSEC parlance) 
status of glue records, it seems to make sense to trust authoritative 
records over glue.  marka, do you know why BIND is doing this?


michael

dnscap output below.  Note that the server continues to query 
203.22.128.6 even after it receives an authoritative answer showing 
203.19.73.24 is the address for ns2.netstrategy.ne.


[121] 2011-09-13 06:41:43.429408 [#11 em0 0] \
[139.130.4.5].53 [10.33.22.1].58454  \
dns QUERY,NOERROR,40967,qr|aa|cd \
1 ns2.netstrategy.net,IN, 0 \
1 
netstrategy.net,IN,SOA,3600,ns2.netstrategy.net,helpdesk.netstrategy.net,584,3600,600,1209600,86400 
\

1 .,CLASS4096,OPT,32768,[0]
[182] 2011-09-13 06:41:43.429473 [#12 em0 0] \
[139.130.4.5].53 [10.33.22.1].52414  \
dns QUERY,NOERROR,42323,qr|aa|cd \
1 ns2.netstrategy.net,IN,A \
1 ns2.netstrategy.net,IN,A,86400,203.19.73.241 \
3 netstrategy.net,IN,NS,86400,ns2.netstrategy.net \
netstrategy.net,IN,NS,86400,ns1.telstra.net \
netstrategy.net,IN,NS,86400,ns3.netstrategy.net \
3 ns1.telstra.net,IN,A,3600,139.130.4.5 \
ns3.netstrategy.net,IN,A,86400,203.19.73.242 \
.,CLASS4096,OPT,32768,[0]
[74] 2011-09-13 06:41:45.576191 [#13 em0 0] \
[10.33.22.1].53097 [203.22.128.6].53  \
dns QUERY,NOERROR,60640,cd \
1 sceggs.nsw.edu.au,IN,NS 0 0 \
1 .,CLASS512,OPT,32768,[0]
[63] 2011-09-13 06:41:48.386073 [#14 em0 0] \
[10.33.22.1].51867 [203.22.128.6].53  \
dns QUERY,NOERROR,5198 \
1 sceggs.nsw.edu.au,IN,NS 0 0 0
[63] 2011-09-13 06:41:51.596035 [#15 em0 0] \
[10.33.22.1].63212 [203.22.128.6].53  \
dns QUERY,NOERROR,25663 \
1 sceggs.nsw.edu.au,IN,NS 0 0 0
[63] 2011-09-13 06:41:58.005930 [#16 em0 0] \
[10.33.22.1].62111 [203.22.128.6].53  \
dns QUERY,NOERROR,36882 \
1 sceggs.nsw.edu.au,IN,NS 0 0 0
[63] 2011-09-13 06:42:08.015611 [#17 em0 0] \

BIND DNSSEC-Validation issue sceggs.nsw.edu.au

[Neil]

Hi BIND Users

I am currently trialing Bind v9.8.1 and have come across a issue with 1 
particular domain.

For some reason when I query the below domain on bind resolver-cache nothing 
gets returned.?

dig @server sceggs.nsw.edu.au ns

The debug logs show 

13-Sep-2011 10:11:27.272 query-errors: debug 1: client 203.134.1.70#10309: view 
host_resolver_trusted: query failed (SERVFAIL) for sceggs.nsw.edu.au/IN/NS at 
query.c:6195
13-Sep-2011 10:11:27.272 query-errors: debug 2: fetch completed at 
resolver.c:3160 for sceggs.nsw.edu.au/NS in 30.000122: timed out/success 
[domain:sceggs.nsw.edu.au,referral:0,restart:7,qrysent:7,timeout:6,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]

named.conf has the below settings for dnssec

   dnssec-enable yes;
   dnssec-validation auto;

Even with the below and managed-keys still does not work

   dnssec-enable yes;
   dnssec-validation yes;

The only way a result is given is to turn off dnssec-validation then it works!

dnssec-validation no;

Only then a result is given for the query. The domain is in the AU space which 
is not
currently signed. So I don't know why this would affect sec-validation and the 
queried domain?

Also noticed its happening in 9.7.2-P3

Any ideas why this is happening and how to fix it without loosing 
dnssec-validation?
Does anyone else have the same issue with the above scenario?

Thanks
Neil
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users