b
If someone would kindly explain what this error message means, I would appreciate it. I'm running BIND 9.6.2-P1 and I get quite a few of these: 28-Mar-2010 21:02:27.467 dnssec: warning: client 200.160.7.134#6363: view external: expected covering NSEC3, got an exact match Thank you, Nate Itkin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Intermittent failures resolving .org domains in BIND 9.7.0 with DLV enabled
On 2010/03/28, at 18:48, Roy Badami wrote: configured). The queries are resulting in SERVFAIL, and I'm pretty sure the failures are DNSSEC-related, as when I've seen problems as they occur (dig failing from the command line) then repeating the query with the CD bit allowed it to succeed. It looks to me like your example, freebsd.org, is insecure. There are no DS records for freebsd.org in the org zone, so BIND can't follow the trust chain from the org.dlv.isc.org DLV record. ; DiG 9.6.0-APPLE-P2 +norec +dnssec IN DS freebsd.org @a0.org.afilias-nst.info ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 52863 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 [...] There also appears to be no DLV record for freebsd.org: ; DiG 9.6.0-APPLE-P2 +norec +dnssec IN DLV freebsd.org.dlv.isc.org @ns.isc.afilias-nst.info ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 23858 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;freebsd.org.dlv.isc.org. IN DLV ;; AUTHORITY SECTION: dlv.isc.org.3600IN SOA ns-int.isc.org. hostmaster.isc.org. 2010032802 7200 3600 2419200 3600 dlv.isc.org.3600IN RRSIG SOA 5 3 3600 20100427130003 20100328130003 64263 dlv.isc.org. IbRdfwxFInY6FuHtsfVatqrNvMIoifQTrohzEZF1UsTx9XAowU1Zz57L YcHPu3ReAdYOL+IwkG8syNQ/LSLnpZY3K3Av/HSmPV524KWbm39J+k+G BMmIIsnvC4I40UUr7f/AXF14JgdAu9eokvvLvqR0CcAY0dq9HGHjdXC1 HbI= flame.org.dlv.isc.org. 3600IN NSEC863.freenum.org.dlv.isc.org. RRSIG NSEC DLV flame.org.dlv.isc.org. 3600IN RRSIG NSEC 5 5 3600 20100427130003 20100328130003 64263 dlv.isc.org. KZRZadIqTS8p6V3fRz7bsOrP3A/gTqJzeVtWTOqhrRbChLt0jVbhY4fR 1pBogkhc84xcv7i0odHMzWCIpmQdv4Q/ODnophPdgrfPcxB93s3dMQ/D j0o2KTYsx1qJo0O1RWqhicUdwGoVYm5rZFLxy/uBV0dJe0KGrSmY21Gw U/c= org.dlv.isc.org.3600IN NSEC1mg.org.dlv.isc.org. RRSIG NSEC DLV org.dlv.isc.org.3600IN RRSIG NSEC 5 4 3600 20100427130003 20100328130003 64263 dlv.isc.org. YCe9L3iuJ5YD5hj7s1Z9wGsDkhLhqchNki+bSffHGxoYZVaQnMZXgWpS fYJZsFyJA3h1uEs5FvuLeLv1Poej2EhDyXucMHAgTJy4fbDjaw3Q8/MP et17Ki0TSNvMFdusCJl93aSZBnKponKR67ofvb8wwt5SDCYrR41EgvzE WZs= ;; Query time: 58 msec ;; SERVER: 199.254.63.254#53(199.254.63.254) ;; WHEN: Mon Mar 29 04:22:48 2010 ;; MSG SIZE rcvd: 721 Note both the NXDOMAIN status and the NSEC record covering flame.org.dlv.isc.org through 863.freenum.org.dlv.isc.org. The NSEC record is used to prove that no domains which sort between those two names exist in the dlv.isc.org zone. Just to make sure, I looked for RRSIGs in the freebsd.org zone, wondering if maybe the DLV record has simply disappeared from the dlv.isc.org zone somehow.. but it doesn't look like freebsd.org has been signed at all: ; DiG 9.6.0-APPLE-P2 +norec +dnssec IN mx2.freebsd.org @ns2.isc-sns.com ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 17599 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 11 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;mx2.freebsd.org. IN ;; ANSWER SECTION: mx2.freebsd.org.3600IN 2001:4f8:fff6::35 Note the absence of an RRSIG in the ANSWER section. If freebsd.org were signed, you'd expect to see an answer similar to this: ; DiG 9.6.0-APPLE-P2 +norec +dnssec IN ns1.isc-sns.net @ns1.isc-sns.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 52801 ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;ns1.isc-sns.net. IN ;; ANSWER SECTION: ns1.isc-sns.net.3600IN 2001:470:1a::1 ns1.isc-sns.net.3600IN RRSIG 5 3 3600 2010042620 2010032720 10377 isc-sns.net. qk8txlEYx6d8Mor155Rz0Te2vdQSPDoaJZM5FaXLfyNpruv7z3gdwtAI BrmDCKhzmyYni4GQmqZPYmceVjp1rcD17B5O+2/NET+obm3pcHKuzRZs e0PyP1LITahboUZzBoIyd7/jqs2+EwFKJgUs7v41UNp5oIz2vs0YuBo6 1Hc= Have you checked the other domains you're having problems with to see that they're actually secured? If you supply some info from your resolver configuration, someone here might be able to help debug the problem. Matt ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
please explain error: expected covering NSEC3, got an exact match
Sorry about that truncated subject line. Let's try that again. If someone would kindly explain what this error message means, I would appreciate it. I'm running BIND 9.6.2-P1 and I get quite a few of these: 28-Mar-2010 21:02:27.467 dnssec: warning: client 200.160.7.134#6363: view external: expected covering NSEC3, got an exact match Thank you, Nate Itkin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
invalid requests for dns_registration.*
Hello, on one of my nameservers I see many of these messages in log files: Mar 29 07:59:07 gtssk1 named[5012]: security: error: client 195.168.29.200#65293: view gtsi: check-names failure dns_registration.in.nextra.sk/A/IN I'm curious of the reason because they are going to sevrer authoritative for nextra.sk, but not for in.nextra.sk, so I think there's a broken DNS resolver/updater somewhere. Has anyone an idea what kind of devices or cofnigurations can issue these requests? -- 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. The only substitute for good manners is fast reflexes. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Intermittent failures resolving .org domains in BIND 9.7.0 with DLV enabled
It looks to me like your example, freebsd.org, is insecure. Yes, I agree freebsd.org is insecure, but I still want to be able to resolve it :-) .org is signed with NSEC3 and (I think, but could be misremembering) is using opt-out. org is registered in DLV, so BIND still has to do some work to verify that nothing is amiss with the (insecure) delegation. If it can't verify that it is correct for freebsd.org to be insecure then it would be correct for it to fail resolution. As I say the failures are intermittent - sometimes freebsd.org resolves fine - sometimes it fails. I don't think this is specific to freebsd.org, and problably not even to .org - .org is just one of the higher-profile DNSSEC-signed TLDs. -roy ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Intermittent failures resolving .org domains in BIND 9.7.0 with DLV enabled
On Mon, 29 Mar 2010, Matthew Pounsett wrote: On 2010/03/28, at 18:48, Roy Badami wrote: configured). The queries are resulting in SERVFAIL, and I'm pretty sure the failures are DNSSEC-related, as when I've seen problems as they occur (dig failing from the command line) then repeating the query with the CD bit allowed it to succeed. It looks to me like your example, freebsd.org, is insecure. I have seen this happen when bind for some reason (eg mtu issues with vpn) cannot query for the DLV key at dlv.isc.org. I have not figured out the exact failure mode there. Check the logs to see errors for DNSKEY queries for dlv.isc.org to see if this is happening here too. However in that case, no queries at all make it. Paul ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Reverse DNS on a /27 delegation and zone files
Hello,
Sufficient resources on the Internet may be helpful.
For example, http://www.indelible.org/ink/classless/
Searching for RFC2317 or classless in-addr.arpa delegation may result in
additional references.
Hope this helps.
- Original Message
From: Alex mysqlstud...@gmail.com
To: bind-users@lists.isc.org
Sent: Sun, March 28, 2010 9:52:38 PM
Subject: Re: Reverse DNS on a /27 delegation and zone files
Hi,
To follow up with my own email, I found a mistake that I made have corrected it.
Do I also need to provide PTR records for these name servers? If so,
how can I modify my reverse zone file to include that information? My
It seems I do need to provide PTR records. I confused the CNAMEs that
my provider creates with the PTRs that I create.
I'd still be interested in knowing:
zone 0/27.yy.3.64.in-addr.arpa {
On a somewhat-related note, does bind-v9.4.2 support the '-' zone
syntax notation? I was getting bad data (check-names) (from memory)
Was there a change between 9.4.2 and the current that provided the
ability to use the hypens versus the slash as a subnet separator?
Does anyone know if this format is documented well in O'Reilly's
DNSBIND v5? Do you know up to what specific version it's applicable,
or perhaps even it's current?
Thanks again,
Alex
___
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: Re: Delegation - what needs to be there?
On 01/-10/37 13:59, Barry Margolin wrote: Or do I need to provide glue records in the delegated zone ... probably not, but thought I'd better ask. The only time you're required to provide glue is when a subzone is delegated to a nameserver whose name is in the subzone, to prevent a chicken-and-egg problem. This is what I thought but thought I'd make doubly certain. Thanks! Peter -- 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: Intermittent failures resolving .org domains in BIND 9.7.0 with DLV enabled
Yes, I agree freebsd.org is insecure, but I still want to be able to
resolve it :-)
The point was, you should not be getting DNSSEC-related errors from
a domain that is not secured.
I disagree. In order for a validating resolver to resolve freebsd.org
(or any other insecure domain under .org) BIND still needs to verify
the RRSIG on the covering NSEC for freebsd.org.dlv.isc.org to prove
that freebsd.org doesn't have a DLV record. It has to verify the
RRSIG on the DLV record for org.dlv.isc.org, and check that the hash
in the DLV record matches the DNSKEY record of the KSK at .org. It
has to check that the RRSIG on the DNSKEY RRset is correctly signed
with the KSK, and then it has to check that the RRSIG on the NSEC3
opt-out record that covers freebsd.org is correctly signed with the
ZSK. Only after doing all this does it know that freebsd.org is
really, legitimately, an insecure zone.
If any of these steps fail, the resolver should give an error, unless
the CD bit is set on the query.
As requested, please supply configuration information... without
that, it's unlikely anyone is going to be able to help you. Matt
It's pretty basic. Here's the substantive config - I've omited some
TSIG keys and a bunch of zones the server is authoritative for:
logging {
channel dnssec_log {
file logs/dnssec.log versions 2 size 2m;
print-time yes;
print-category yes;
print-severity yes;
severity debug 9;
};
category dnssec { dnssec_log; };
};
options {
directory /etc/namedb;
pid-file/var/run/named/pid;
dump-file /var/dump/named_dump.db;
statistics-file /var/stats/named.stats;
listen-on { any; };
listen-on port 5353 { any; };
listen-on-v6{ any; };
allow-recursion { any; };
dnssec-lookaside auto;
};
include /etc/namedb/rndc.key;
controls {
inet 127.0.0.1 allow { localhost; } keys { rndc-key; };
};
zone . {
type hint;
file named.root;
};
zone 0.0.127.IN-ADDR.ARPA {
type master;
file master/localhost.rev;
};
// RFC 3152
zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
{
type master;
file master/localhost-v6.rev;
};
zone google.com {
type forward;
forwarders {
74.82.42.42;
};
};
zone google.co.uk {
type forward;
forwarders {
74.82.42.42;
};
};
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Intermittent failures resolving .org domains in BIND 9.7.0 with DLV enabled
I have seen this happen when bind for some reason (eg mtu issues with vpn) cannot query for the DLV key at dlv.isc.org. I have not figured out the exact failure mode there. Check the logs to see errors for DNSKEY queries for dlv.isc.org to see if this is happening here too. However in that case, no queries at all make it. Hmm, I wonder whether it could be related to my tunnelled IPv6 connectivity. I still don't see why, though. Resolution definitely works sometimes. When it starts failing 'rndc flush' has fixed it for me. -roy ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Reasonable setup of a dnssec aware recursive resolver
On Mon, 2010-03-29 at 11:17 +0200, Mark Elkins wrote: I'm trying to come up with an interim solution for my ISP's DNS Recursive Resolver that is DNSSEC aware. My thoughts so far:- Use BIND 9.6.1-P3 (this is the latest version named that Gentoo Linux gives me). Ouch! - bitten by the signing of ARPA /etc/bind/named.conf.trust:225: configuring trusted key for 'ARPA.': algorithm is unsupported. -and- * No specific action is requested of operators. This message is * for your information only. * The ARPA zone is about to be signed using DNSSEC. The technical * parameters by which ARPA will be signed are as follows: * KSK Algorithm and Size: 2048 bit RSA I thought unrecognised algorithms were meant to be ignored? Time to try Bind 9.7.0-P1 ?? In order to fetch both iTAR and DLV signatures - use a patched version of WGET that is dnssec aware. Once a week (is this frequent enough?) fetch the DNSSEC signatures from iTAR and ISC/DLV, convert the iTAR xml stuff into Signatures, append the DLV signature and then include this file into my named.conf configuration. (named.conf: include named.conf.trust-anchors; ) In named.conf -- options, add: dnssec-enable yes; dnssec-validation yes; dnssec-lookaside . trust-anchor dlv.isc.org.; This appears to be working for me. Questions are - how frequently should one fetch these trust-anchors? I'd have though once a week was enough but have read of situations where people using ISC's DLV have had past problems. I'm hoping that by using both iTAR and DLV - that I won't have this problem - have not noticed anything personally yet. I call this an interim solution - interim until the root is signed with live data and contains the data that ITAR is currently being used to store. I don't see ISC's DLV disappearing overnight just because the root is signed either... I'm only doing the 'wget-ting' from one location, then distributing internally from there - in order to reduce loads. What other suggestions do people have to achieve something similar? ps - I find the CZ DNSSEC Validator (addon) plugin to Firefox very inspiring! Anyone aware of something similar for IE? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- . . ___. .__ Posix Systems - Sth Africa. e.164 VOIP ready /| /| / /__ m...@posix.co.za - Mark J Elkins, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 smime.p7s Description: S/MIME cryptographic signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Subdomain delegation only returns SOA on dig
Hello all,
I'm running BIND 9.6.1-P1 on a Solaris box. This DNS (ns1.spx.net) is
authoritative to domain spx.net (this is just example). And I'm trying to
delegate nse.spx.net to ns1.nse.spx.net. I think I have configured correctly
but when I run a dig from a different DNS node for a subdoamin within
nse.spx.net like mil.nse.spx.net, it responds only SOA in the Auth section. Its
missing the NS from the zone files. The snapshot of my named.conf file
zone spx.net {
type master;
file /opt/named/db.spx.net;
};
zone nse.spx.net {
type master;
file /opt/named/db.nse.spx.net;
};
Here are the snapshot of consecutive zone files
$ttl 38400
spx.net. IN SOA ns1.spx.net. ns2.spx.net. (
1189784076
86400
3600
604800
38400 )
spx.net. IN NS ns1
spx.net. IN NS ns2
ns2.spxdns.net. IN A 10.1.2.3
ns1.spxdns.net. IN A 10.4.5.6
ns1.nse.spx.net. INA10.7.8.9
;there are other entries here
$ORIGIN nse.spx.net.
@ IN NS ns1.nse.spx.net.
And the 2nd zone file for submdomain nse.spx.net
$TTL 3600 ; 1 hour
@ IN SOA ns1.nse.spx.net email (
2008081812 ; serial
1800 ; refresh (30 minutes)
900; retry (15 minutes)
604800 ; expire (1 week)
3600 ; minimum (1 hour)
)
;
nse.spx.net. IN NS ns1.nse.spx.net.
ns1.nse.spx.net. IN A 10.25.130.75
Now when I run a dig for say mml.nse.spx.net I get only the SOA of the above
zone file and no NS information that the query is being delegated to.
#dig @ns1.spx.net mil.nse.spx.net
; DiG 9.6.1-P1 @ns1.spx.net mil.nse.spxdns.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 1717
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;mil.nse.spxdns.net.IN A
;; AUTHORITY SECTION:
nse.spx.net. 3600IN SOA ns1.nse.spx.net email .
2008081812 1800 900 604800 3600
;; Query time: 3 msec
;; SERVER: ns1.spx.net#53(10.1.2.3)
;; WHEN: Mon Mar 29 19:26:45 2010
;; MSG SIZE rcvd: 108
How would the querying DNS find out about the nameserver that this subdomain is
being delegated to? Why the query answer doesn't include NS sections. I've
tried to change few things but nothing works. The only information I get is SOA
and no NS in the AUTHORITY SECTION.
Any help would be much appreciated.
Thanks
Prabhat.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
dnssec-signzone error after updating to 9.6.2-P1
Seeing this after upgrading to 9.6.2-P1. We've made no other changes to the host or any configuration files, etc. /var/named # dnssec-signzone -g -o xxx.xxx.gov.au db.xxx.xxx.gov.au dnssec-signzone: fatal: no self signed KSK's found No idea what's going on here and we need advice on how to go about fixing it ASAP. Thanks. Chris. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Reasonable setup of a dnssec aware recursive resolver
In message 1269885784.31597.68.ca...@mjenet.posix.co.za, Mark Elkins writes: On Mon, 2010-03-29 at 11:17 +0200, Mark Elkins wrote: I'm trying to come up with an interim solution for my ISP's DNS Recursive Resolver that is DNSSEC aware. =20 My thoughts so far:- Use BIND 9.6.1-P3 (this is the latest version named that Gentoo Linux gives me). You want to have newer if you are using DNSSEC. Ouch! - bitten by the signing of ARPA /etc/bind/named.conf.trust:225: configuring trusted key for 'ARPA.': algorithm is unsupported. -and-=20 * No specific action is requested of operators. This message is * for your information only. * The ARPA zone is about to be signed using DNSSEC. The technical * parameters by which ARPA will be signed are as follows:=20 * KSK Algorithm and Size: 2048 bit RSA I thought unrecognised algorithms were meant to be ignored? Just don't blindly import trust anchors. Zone with unknown algorithms will be treated as insecure when you transition to them from a secure zone by following a delegation where all the DS records are for unknown algorithms. However when you add a trust anchor you are saying treat this zone as secure and here are your starting points. Time to try Bind 9.7.0-P1 ?? BIND 9.6.2-P1 and BIND 9.7.0-P1 both support RSASHA256 and RSASHA512. In order to fetch both iTAR and DLV signatures - use a patched version of WGET that is dnssec aware. =20 Once a week (is this frequent enough?) fetch the DNSSEC signatures from iTAR and ISC/DLV, convert the iTAR xml stuff into Signatures, append the DLV signature and then include this file into my named.conf configuration. (named.conf: include named.conf.trust-anchors; ) =20 In named.conf -- options, add: dnssec-enable yes; dnssec-validation yes; dnssec-lookaside . trust-anchor dlv.isc.org.; =20 This appears to be working for me. Questions are - how frequently should one fetch these trust-anchors? I'd have though once a week was enough but have read of situations where people using ISC's DLV have had past problems. =20 I'm hoping that by using both iTAR and DLV - that I won't have this problem - have not noticed anything personally yet. ITAR is already imported into DLV. You really don't want to have lots of trust anchors in named.conf. Just more places to go wrong. A the root when it is signed however. =20 I call this an interim solution - interim until the root is signed with live data and contains the data that ITAR is currently being used to store. I don't see ISC's DLV disappearing overnight just because the root is signed either... =20 I'm only doing the 'wget-ting' from one location, then distributing internally from there - in order to reduce loads. =20 What other suggestions do people have to achieve something similar? =20 ps - I find the CZ DNSSEC Validator (addon) plugin to Firefox very inspiring! Anyone aware of something similar for IE? =20 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users --=20 . . ___. .__ Posix Systems - Sth Africa. e.164 VOIP ready /| /| / /__ m...@posix.co.za - Mark J Elkins, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 --=-zyQOFLsrjw8nMxXVg+CV Content-Type: application/x-pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWfjCCB0gw ggYwoAMCAQICAgLSMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMDkxMDMxMDAwMDAxWhcNMTExMDMxMTU0MTEwWjCBujELMAkGA1UEBhMCWkExEDAOBgNVBAgT B0dhdXRlbmcxETAPBgNVBAcTCFByZXRvcmlhMSEwHwYDVQQKExhQb3NpeCBTeXN0ZW1zIChQVFkp IEx0ZC4xLTArBgNVBAsTJFN0YXJ0Q29tIFZlcmlmaWVkIENlcnRpZmljYXRlIE1lbWJlcjEUMBIG A1UEAxMLTWFyayBFbGtpbnMxHjAcBgkqhkiG9w0BCQEWD21qZUBwb3NpeC5jby56YTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6KS+4WC5M29OOVGAcVUn/z90w4aoMidneOPY16Bnuo 6V+8C4kcZrVKoyIYRG55Uln2lKRHeSAhPNBTSMRkkQ1kGNSnmH5jCPhdL+VBN1+CAWeiPvblnsX+ 5wOoEM6v/i2FdBcsdMmssYnG7WFhn4BsyFQe0bQgDNHgbbnJbSMFCaiqAICoQljL0ha/Z3SU+Dgz 2IKTo5fe8vN9P6z5QsETqeBgmsLET+MhwnQ8CRNYhq3vjrYqqie31COgE28Cn5+ez08MDnULB/5I cQFzZ5g1ORtaLrRg6VYHITnMn0EedOb9+iz/WF/nstqVwrKlJsp1hGsOeTjqCoOq6ASH3McCAwEA AaOCA4IwggN+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQUFPCcDnQQWUlHl8TRFshEBYXoA6IwgagGA1UdIwSBoDCBnYAUrlWD b+wxyrn3HfqvazHzyB3jrLuhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQ4wGgYDVR0RBBMwEYEPbWplQHBv
Re: Subdomain delegation only returns SOA on dig
Thanks for the response Kevin. However when I flush the cache and snoop the
interface on this recursive DNS I don't see any request going to the nameserver
(ns1.nse.spx.net) of the child zone. It appears it is just displaying the
output it received from the ns1.spx.net nameserver. I don't have any port 53
connectivity from ns1.spx.net to ns1.nse.spx.net. Would that cause any issues?
--- On Mon, 3/29/10, Kevin Darcy k...@chrysler.com wrote:
From: Kevin Darcy k...@chrysler.com
Subject: Re: Subdomain delegation only returns SOA on dig
To: bind-users@lists.isc.org
Date: Monday, March 29, 2010, 4:56 PM
The nameserver is recursive (RA in
the header of the response means
Recursion Available). It recursed to the nameservers of
the child
zone, which returned NXDOMAIN for the name mil.nse.spx.net,
and it
passed that answer back.
Everything is working the way it is supposed to, including
your new
delegation.
If you want to see a referral response from the same
nameserver, try a
non-recursive query, e.g. dig +norec, against an empty
cache.
-
Kevin
On 3/29/2010 3:34 PM, Prabhat Rana wrote:
Hello all,
I'm running BIND 9.6.1-P1 on a Solaris box. This DNS
(ns1.spx.net) is authoritative to domain spx.net (this is
just example). And I'm trying to delegate nse.spx.net to
ns1.nse.spx.net. I think I have configured correctly but
when I run a dig from a different DNS node for a subdoamin
within nse.spx.net like mil.nse.spx.net, it responds only
SOA in the Auth section. Its missing the NS from the zone
files. The snapshot of my named.conf file
zone spx.net {
type master;
file
/opt/named/db.spx.net;
};
zone nse.spx.net {
type master;
file
/opt/named/db.nse.spx.net;
};
Here are the snapshot of consecutive zone files
$ttl 38400
spx.net. IN
SOA ns1.spx.net. ns2.spx.net.
(
1189784076
86400
3600
604800
38400 )
spx.net. IN
NS ns1
spx.net. IN
NS ns2
ns2.spxdns.net. IN A
10.1.2.3
ns1.spxdns.net. IN A
10.4.5.6
ns1.nse.spx.net. IN A
10.7.8.9
;there are other entries here
$ORIGIN nse.spx.net.
@ IN NS
ns1.nse.spx.net.
And the 2nd zone file for submdomain nse.spx.net
$TTL 3600 ; 1 hour
@
IN SOA
ns1.nse.spx.netemail (
2008081812 ; serial
1800 ; refresh (30
minutes)
900 ; retry (15 minutes)
604800 ; expire (1 week)
3600 ; minimum (1
hour)
)
;
nse.spx.net.
IN NS
ns1.nse.spx.net.
ns1.nse.spx.net. IN
A 10.25.130.75
Now when I run a dig for say mml.nse.spx.net I get
only the SOA of the above zone file and no NS information
that the query is being delegated to.
#dig @ns1.spx.net mil.nse.spx.net
; DiG
9.6.1-P1 @ns1.spx.net
mil.nse.spxdns.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status:
NXDOMAIN, id: 1717
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY:
1, ADDITIONAL: 0
;; QUESTION SECTION:
;mil.nse.spxdns.net.
IN A
;; AUTHORITY SECTION:
nse.spx.net.
3600 IN
SOA ns1.nse.spx.netemail .
2008081812 1800 900 604800 3600
;; Query time: 3 msec
;; SERVER: ns1.spx.net#53(10.1.2.3)
;; WHEN: Mon Mar 29 19:26:45 2010
;; MSG SIZE rcvd: 108
How would the querying DNS find out about the
nameserver that this subdomain is being delegated to? Why
the query answer doesn't include NS sections. I've tried to
change few things but nothing works. The only information I
get is SOA and no NS in the AUTHORITY SECTION.
Any help would be much appreciated.
Thanks
Prabhat.
___
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
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec-signzone error after updating to 9.6.2-P1
On Tue, Mar 30, 2010 at 01:50:23PM +1100, chris liesfield wrote: Here's the output ... /var/named # named-checkzone sro.vic.gov.au db.sro.vic.gov.au zone sro.vic.gov.au/IN: loaded serial 2010033001 OK I chose level 7 debugging to yield as much information as possible, so sorry for the size ... /var/named # dnssec-signzone -z -v 7 -g -o xxx.xxx.xxx.au db.xxx.xxx.xxx.au dnssec-signzone: using 2 cpus dnssec-signzone: debug 1: decrement_reference: delete from rbt: 81f2688 [ snip.. ] Is there a key signing key (KSK) in the zone file? db.xxx.xxx.xxx.au should have an entry something like this: $include Kxxx.xxx.xxx.au.+007+12345.key ; KSK Does that file (Kxxx.xxx.xxx.au.+007+12345.key) and its corresponding private key (Kxxx.xxx.xxx.au.+007+12345.private) exist with read permission on? Also, how are you specifying which key is the KSK (typically the -k option with dnssec-signzone)? I can replicate your symptoms and the error message by removing the KSK from a zone file. Nate Itkin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
