Re: Deleting a key

[Casey Deccio]

> On Aug 7, 2024, at 12:02 AM, Casey Deccio  wrote:
> 
> I'm probably missing something obvious here, but I'm trying to figure out how 
> to "delete" a DNSKEY from zone that uses inline signing.

So I finally just did the following:

$ sudo rm /var/cache/bind/Kdns-lab.info.+013+50277.*
$ sudo /etc/init.d/named reload

That doesn't feel clean, but it did the job.

*shrug*

Casey
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Deleting a key

[Casey Deccio]

> On Aug 7, 2024, at 12:02 AM, Casey Deccio  wrote:
> 
> Hi all,
> 
> I'm probably missing something obvious here, but I'm trying to figure out how 
> to "delete" a DNSKEY from zone that uses inline signing.  The zone statement 
> looks like this:
> 
>   zone "dns-lab.info" {
>   type master;
>   file "/var/cache/bind/db.dns-lab.info";
>   dnssec-policy alg8;
>   inline-signing yes;
>   };

Forgot to include this snippet:

dnssec-policy "alg8" {
keys {
csk lifetime unlimited algorithm rsasha256;
};
};

Casey
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Deleting a key

[Casey Deccio]

Hi all,

I'm probably missing something obvious here, but I'm trying to figure out how 
to "delete" a DNSKEY from zone that uses inline signing.  The zone statement 
looks like this:

zone "dns-lab.info" {
type master;
file "/var/cache/bind/db.dns-lab.info";
dnssec-policy alg8;
inline-signing yes;
};

This is the current state:

https://dnsviz.net/d/dns-lab.info/ZrMLNw/dnssec/

Or:

$ sudo rndc dnssec -status dns-lab.info
dnssec-policy: alg8
current time:  Tue Aug  6 23:48:14 2024

key: 50277 (ECDSAP256SHA256), CSK
  published:  yes - since Thu Oct 19 09:59:06 2023
  key signing:yes - since Thu Oct 19 09:59:06 2023
  zone signing:   yes - since Thu Oct 19 09:59:06 2023

  Rollover is due since Thu Oct 26 16:11:03 2023
  - goal:   hidden
  - dnskey: omnipresent
  - ds: unretentive
  - zone rrsig: omnipresent
  - key rrsig:  omnipresent

key: 48266 (RSASHA256), CSK
  published:  yes - since Thu Oct 26 16:11:03 2023
  key signing:yes - since Thu Oct 26 16:11:03 2023
  zone signing:   yes - since Thu Oct 26 16:11:03 2023

  No rollover scheduled
  - goal:   omnipresent
  - dnskey: omnipresent
  - ds: rumoured
  - zone rrsig: omnipresent
  - key rrsig:  omnipresent

Note that keys with two DNSSEC algorithms are in the zone, which might be 
complicating things... ?

Now I use dnssec-settime to give key 50277 a "delete date":

$ sudo -u bind dnssec-settime -D+5mi /var/cache/bind/Kdns-lab.info.+013+50277.
/var/cache/bind/Kdns-lab.info.+013+50277.key
/var/cache/bind/Kdns-lab.info.+013+50277.private

It seems to work:

$ sudo cat /var/cache/bind/Kdns-lab.info.+013+50277.key | grep Delete
; Delete: 20240807054556 (Tue Aug  6 23:45:56 2024)

$ sudo /etc/init.d/named reload
Reloading named configuration (via systemctl): named.service.

I'm not really sure what the following lines mean in the log because they don't 
seem to correspond to the times in the key file.

$ sudo tail -100 /var/log/syslog | grep key
2024-08-06T23:41:10.353023-06:00 bass named[216234]: zone 
dns-lab.info/IN/authoritative-only (signed): reconfiguring zone keys
2024-08-06T23:41:10.356705-06:00 bass named[216234]: keymgr: retire DNSKEY 
dns-lab.info/ECDSAP256SHA256/50277 (CSK)
2024-08-06T23:41:10.356888-06:00 bass named[216234]: zone 
dns-lab.info/IN/authoritative-only (signed): next key event: 07-Aug-2024 
00:41:10.345

However, nothing ever changes with key 50277.  I've done all this multiple 
times over several days.  It continues to sign records when I add records to 
the zone.  If someone has ideas to point me in the right direction, that would 
be great.

$ /usr/sbin/named -v
BIND 9.18.28-1~deb12u2-Debian (Extended Support Version) 


Thanks,
Casey-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: nslookup issues

[Casey Deccio]

> On Sep 13, 2022, at 3:35 PM, Graham Clinch  wrote:
> 
> I suspect nrpe-ng is closing stdin before launching nslookup.
> 
> 
> With mac homebrew's build of bind 9.18.6 and a bit of shell redirection to 
> close stdin, I get:
> 
> ---
> $ /opt/homebrew/bin/nslookup -version
> nslookup 9.18.6
> 
> $ /opt/homebrew/bin/nslookup example.net 0<&-
> [... usual output snipped ...]
> 
> Assertion failed: (fd > STDERR_FILENO), function uv__close, file core.c, line 
> 602.
> Abort trap: 6
> 
> $ echo $?
> 134
> ---
> 

Nice find!!

> This might count as a regression of sorts from the migration to libuv, as 
> older nslookup doesn't fail in the same way:

Could be.  At the very least it's a behavioral difference, which affects some 
packages that depend on it.  I'll leave it to the BIND devs to determine if/how 
to handle it.

> (dig & delv are also affected in the same way)
> 
> The cmake group came across the same situation with libuv and open missing 
> standard fds against /dev/null to compensate:
> https://gitlab.kitware.com/cmake/cmake/-/merge_requests/3282

I've patched the code for nrpe_ng, and it works!

$ diff -u /usr/lib/python3/dist-packages/nrpe_ng/commands.py{.old,}
--- /usr/lib/python3/dist-packages/nrpe_ng/commands.py.old  2017-08-08 
13:05:02.0 -0600
+++ /usr/lib/python3/dist-packages/nrpe_ng/commands.py  2022-09-13 
17:00:36.767239885 -0600
@@ -85,6 +85,7 @@
 
 proc = tornado.process.Subprocess(
 run_args,
+stdin=subprocess.DEVNULL,
 stdout=tornado.process.Subprocess.STREAM,
 close_fds=True,
 env=env)

I'll request that something get pushed upstream.  Many thanks for help tracking 
that down!

Casey
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

nslookup issues

[Casey Deccio]

I am trying to track down a bug.  I think it is in nslookup (which is why I'm 
asking here), but there are so many pieces required to reproduce it that I 
cannot tell for sure.  Let me explain my setup:

All hosts are running Debian bullseye.  None of the problems happened *until* I 
upgraded from buster.

Host A (monitoring):
 - Installed: nagios4 (4.4.6-4), nrpe-ng (0.2.0-1)
 - IP address: 192.0.2.1

Host B (monitored):
 - Installed: nrpe-ng (0.2.0-1), monitoring-plugins-standard (2.3.1-1), 
bind9-dnsutils (9.16.27-1~deb11u1)
 - IP address: 192.0.2.2

Host C (monitored through host B):
 - Installed: bind9
 - IP address: 192.0.2.3
 - Configured to answer authoritatively for example.com on port 53.


I run the following on Host B:
$ /usr/lib/nagios/plugins/check_dns -H example.com -s 192.0.2.3 -A -w 0.1 -c 1.0
DNS OK: 0.070 seconds response time. example.com returns 
192.0.2.10,2001:db8::10|time=0.069825s;0.10;1.00;0.00

Then I run the following on Host B.  check_dns (part of 
monitoring-plugins-standard) invokes nslookup.  The response looks good.

When I run nslookup explicitly, it also looks good:
$ /usr/bin/nslookup -sil example.com 192.0.2.3
Server: 192.0.2.3
Address:192.0.2.3#53

Name:   example.com
Address: 192.0.2.10
Name:   example.com
Address: 2001:db8::10

Now I set things up for monitoring using nrpe-ng with the following 
configuration:

 nrpe
over HTTPs  DNS
Host A --> Host B -> Host C


On Host B, I run the following:
sudo /usr/bin/python3 /usr/sbin/nrpe-ng --debug -f --config 
/etc/nagios/nrpe-ng.cfg

While that is running, I run the following on Host A:
/usr/lib/nagios/plugins/check_nrpe_ng -H 192.0.2.2 -c check_dns -a example.com 
192.0.2.3 0.1 1.0

I can see the DNS request and response on the wire (i.e., using tcpdump).

The result of running the command on Host A is:
DNS CRITICAL - '/usr/bin/nslookup -sil' msg parsing exited with no address

On Host B, I see the following debug output:
200 POST /v1/check/check_dns (192.0.2.1) 78.05ms
Executing: /usr/lib/nagios/plugins/check_dns -H example.com -s 192.0.2.3 -A -w 
0.1 -c 1.0

(The output matches what I manually ran to test earlier.)

After rerunning nrpe-ng with the following:
sudo strace --read=4 -F /usr/bin/python3 /usr/sbin/nrpe-ng --debug -f --config 
/etc/nagios/nrpe-ng.cfg

I see the following in the debug output on Host B:

[pid 1390861] read(4, "nslookup: ./src/unix/core.c:570:"..., 4096) = 83
 | 0  6e 73 6c 6f 6f 6b 75 70  3a 20 2e 2f 73 72 63 2f  nslookup: ./src/ |
 | 00010  75 6e 69 78 2f 63 6f 72  65 2e 63 3a 35 37 30 3a  unix/core.c:570: |
 | 00020  20 75 76 5f 5f 63 6c 6f  73 65 3a 20 41 73 73 65   uv__close: Asse |
 | 00030  72 74 69 6f 6e 20 60 66  64 20 3e 20 53 54 44 45  rtion `fd > STDE |
 | 00040  52 52 5f 46 49 4c 45 4e  4f 27 20 66 61 69 6c 65  RR_FILENO' faile |
 | 00050  64 2e 0a  d..  |

So it appears that the nslookup process is reporting an error, specifically 
from this line of code:

https://github.com/libuv/libuv/blob/fb76f210eb6f093bc06a2f07646e56851818ccf2/src/unix/core.c#L602

However, I cannot reproduce it outside of nrpe-ng/check_dns/nslookup.  I need 
the help of someone more knowledgeable.  Thoughts?  Suggestions?

Thanks,
Casey-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: getting not authoritative with some notifies

[Casey Deccio]

On Thu, Jul 28, 2016 at 10:34 AM, Paul A  wrote:

> Yes on both server and the slave and primary are listed on the NS RR. I'm
> really at a loss here, the zone updates on the slave but I keep getting
> that
> message.
>

There's a difference between a server being listed in the NS RRset and a
server being authoritative for the zone.  Is there a "zone" statement for
that zone in your named.conf?

Casey
___
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: any tool or command to find/verify the closest encloser NSEC3 record

[Casey Deccio]

On Tue, Jun 28, 2016 at 6:29 AM, rams  wrote:

> Hi,
> Greetings 
> Is anyone can help me to verify the NSEC3 record in response is correct or
> not.
> Do we have any tool or command to check closet encloser NSEC3 record or
> Correct NSEC3 record returned in response.
>

DNSViz:
https://github.com/dnsviz/dnsviz

Web:
http://dnsviz.net/

Command line:
$ dnsviz query adfadfa.sandia.gov
. [.]
  [.]  DNSKEY: 8/19036/257 [.], 8/60615/256 [.], 8/46551/256 [.]
  [.]RRSIG: ./8/19036 (2016-06-20 - 2016-07-05) [.]
gov [.] [.]
  [.]  DS: 8/7698/1 [.], 8/7698/2 [.]
  [.]RRSIG: ./8/60615 (2016-06-29 - 2016-07-09) [.]
  [.]  DNSKEY: 8/7698/257 [.], 8/26663/256 [.]
  [.]RRSIG: gov/8/7698 (2016-06-21 - 2016-07-06) [.]
sandia.gov [.] [.]
  [.]  DS: 7/20739/1 [.], 7/20739/2 [.], 7/36033/1 [.], 7/36033/2 [.]
  [.]RRSIG: gov/8/26663 (2016-06-29 - 2016-07-06) [.]
  [.]  DNSKEY: 7/36033/257 [.], 7/20739/257 [.], 7/9839/256 [.]
  [.]RRSIG: sandia.gov/7/20739 (2016-06-23 - 2016-07-23) [.]
  [.]RRSIG: sandia.gov/7/36033 (2016-06-23 - 2016-07-23) [.]
adfadfa.sandia.gov
  [.]  A: NXDOMAIN
  [.]SOA: taurus.sandia.gov. dnsadmin.sandia.gov. 592346 1800 900
604800 3600
  [.]  RRSIG: sandia.gov/7/9839 (2016-06-29 - 2016-07-29) [.]
  [.]PROOF:  [.]
  [.]  NSEC3: IQIT58B5DEJU7CM802R9M0K37KGD6FJV.sandia.gov. 1 0 2 ee273f
IQLASPCCG7RB9IJ31KQ3BE8VLVKCSNNJ A RRSIG
  [.]RRSIG: sandia.gov/7/9839 (2016-06-23 - 2016-07-23) [.]
  [.]  NSEC3: 8ESL8VMDE3FA40KLDRDG9H71ICSI90C8.sandia.gov. 1 0 2 ee273f
8EVC5PSC3L4BV78NQR6RSSRF2LCEMVAT A RRSIG
  [.]RRSIG: sandia.gov/7/9839 (2016-06-23 - 2016-07-23) [.]
  [.]  NSEC3: FGBEAQHT3FQKVO0IFO0EGIFPOE0J53PT.sandia.gov. 1 0 2 ee273f
FGC7SC2U6LPHLH6V0JJ8OGN3JI810F6J A NS SOA MX TXT  RRSIG DNSKEY
NSEC3PARAM
  [.]RRSIG: sandia.gov/7/9839 (2016-06-23 - 2016-07-23) [.]

(See "man dnsviz" for more information, including documentation)

Casey
___
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: dnskey algorithm update

[Casey Deccio]

On Thu, Jan 7, 2016 at 3:00 PM, Carl Byington  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Thu, 2016-01-07 at 08:34 -0600, Jeremy C. Reed wrote:
> > On Wed, 6 Jan 2016, Carl Byington wrote:
>
> > > Is there a more authoritative document that describes the algorithm
> > > roll over procedure? It seems that I need to:
>
> > ISC has a DNSSEC Guide. See this section:
>
> > http://users.isc.org/~jreed/dnssec-guide/dnssec-guide.html#advanced-
> > discussions-DNSKEY-algorithm-rollovers
>
> > (Also in PDF format at the same directory.)
>
> > We still have some feedback to integrate into the guide, but if anyone
> > would like to participate, also see the GitHub site:
> > https://github.com/isc-projects/isc-dnssec-guide
>
>
> Based on RIPE experience at https://labs.ripe.net/Members/anandb/dnssec-
> algorithm-roll-over, where Unbound and Verisign make assumptions about
> the DS record set, we need to ensure that:
>
> adding an algorithm - you need to generate both KSK and ZSKs for the new
> algorithm, publish them in the DNSKEY rrset, and sign the zone with
> them.


No, the RRSIGs for the algorithm need to be published in the zone *before*
the keys, at least for the value of the largest TTL in the zone, plus
propagation time.  This is because you don't want a resolver to find a set
of DNSKEYs and have to try to validate an RRset with only a subset of the
algorithms found in those keys.


> Then wait one TTL cycle before updating the DS records in the
> parent.
>

> removing an algorithm - you need to remove the old algorithm DS records
> from the parent, then wait one TTL cycle before removing the old KSK and
> ZSKs using that algorithm, and resigning the zone using only the new
> algorithm.
>
>
>
> Also, based on https://tools.ietf.org/html/rfc6781#page-31, it seems we
> need to be able to sign the zone with a key that is not published in the
> DNSKEY rrset. Consider the case of adding a ZSK with the new algorithm,
> where we publish that ZSK in the DNSKEY rrset and resign the zone using
> both old and new ZSKs. A resolver might have an old cached MX rrset only
> signed with the old algorithm; and then retrieve the new DNSKEY rrset
> which mentions both algorithms.
>
> RFC6781 implies that this will break validation. Is that correct?


Yes, in certain cases.  Validators with strict validation policies or
validators that understand one algorithm but not the other will fail to
validate the RRset.

Casey
___
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: [OT] Re: configuration error in lists.isc.org

[Casey Deccio]

On Fri, Aug 7, 2015 at 11:23 AM, Heiko Richter 
wrote:

> Correction:
> - 
> All implementations of SPF always check 2 addresses:
>   - Envelope-From address
>   - From address
>
> SPF will fail whenever the client is not authorized to send for either
> the Envelope-From address or the From address. So while the list
> server changes the envelope from address, SPF will still fail as the
> client is not authorized for the From address.


I think you're confusing SPF and DMARC.  DMARC uses the results of SPF,
which authenticates the "Mail From" domain, aligning that domain with that
of the "From" header.

Casey
___
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: configuration error in lists.isc.org

[Casey Deccio]

On Fri, Aug 7, 2015 at 2:57 AM, Reindl Harald 
wrote:

>
> Am 07.08.2015 um 01:25 schrieb Heiko Richter:
>
>> So ISC: please fix your list servers, let them rewrite the From headers!
>>
>
> please try to understand the topic before blaming!
> http://wiki.list.org/DEV/DMARC
>
> * SPF is about envelopes and *never* from-headers
> * the envelope is @lists.isc.org
>
>
...but DMARC is about mapping the domain in the "From" header to the domain
authenticated in SPF or DKIM.  From RFC7489:

"Identifier Alignment:  When the domain in the RFC5322.From address
  matches a domain validated by SPF or DKIM (or both), it has
  Identifier Alignment."

and

"DMARC authenticates use of the RFC5322.From domain by requiring that
   it match (be aligned with) an Authenticated Identifier."

See also:
https://dmarc.org/wiki/FAQ#What_is_the_difference_between_the_.22Mail_From.22_and_.22From_Header.22.2C_aren.27t_they_the_same.3F
where it states:

"DMARC protects the domain name of the RFC5322:From field against spoofing."

Here are the headers from one message sent to this list:

spf=pass (google.com: best guess record for domain of
bind-users-boun...@lists.isc.org designates 2001:4f8:0:2::23 as permitted
sender) smtp.mail=bind-users-boun...@lists.isc.org;
   dmarc=fail (p=REJECT dis=NONE) header.from=heikorichter.name

SPF passes, but DMARC fails because the domain in the "From" header (
heikorichter.name) doesn't match the domain authenticated for SPF (
lists.isc.org).  And the REJECT policy makes the handling of this more
severe by a receiving MTA that implements DMARC.

The link referenced above:
http://wiki.list.org/DEV/DMARC
indicates that mailman (v 2.1.18 and greater) has a setting
(dmarc_moderation_action) to munge the From header when the sender's DMARC
policy is set to REJECT or QUARANTINE, but leave it in tact otherwise.

This is among the recommended solutions in:
https://dmarc.org/wiki/FAQ#I_operate_a_mailing_list_and_I_want_to_interoperate_with_DMARC.2C_what_should_I_do.3F

Casey
___
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: do not stupidly delete ZSK files

[Casey Deccio]

On Thu, Aug 6, 2015 at 7:55 PM, Lawrence K. Chen, P.Eng. 
wrote:

> Ok, so way back thenthey were running servers that didn't support
> NSEC3 RRs and it had nothing to do with what algorithm we were using5
> for RSASHA1 or 7 for RSASHA1-NSEC3-SHA1.
>

DNSSEC introduces: new records (and types) into a zone; new protocol
requirements on servers; and a variety of crypto algorithms.  As far as the
new records are concerned, they are transferred between authoritative
servers (primaries and secondaries) like other records in the zone--even
servers that aren't fully DNSSEC aware should be able to handle this.  With
regard to protocol requirements, even if an authoritative server has the
appropriate DNSSEC records, it must know how to serve them in response to
queries.  This includes serving the RRSIGs with RRsets, serving NSEC or
NSEC3 for authenticated denial of existence (negative responses and
wildcards), serving DS records from the parent zone, etc.  However, some of
these protocol requirements have been incremental (e.g, NSEC3), which is
why algorithms 6 and 7 were introduced--same algorithms as 3 and 5, new
protocol requirements for servers.  So... while algorithms don't
necessarily need to be understood by the authoritative servers (because
they're not doing the validating), protocol requirements do.

In short: the DNSSEC records were probably being transferred correctly, and
the secondaries probably supported DNSSEC but not NSEC3, but the algorithms
themselves didn't matter to the authoritative server.

Casey
___
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: expired KSK, other domains failed to resolve?

[Casey Deccio]

On Thu, Aug 6, 2015 at 4:16 AM, Lawrence K. Chen, P.Eng. 
wrote:

> So, in running some testsI found that "dig +trace kstatesports.com"
> would get to ns-1.ksu.edu show couple NSEC3 records and stop.
>

$ dig +short kstatesports.com ns
ns-2.ksu.edu.
ns-3.ksu.edu.
ns-1.ksu.edu.

Because the kstatesports.com name servers are in the edu zone, they are
considered "out of bailiwick".  A resolver must resolve those names in
order to learn the addresses of the servers it must communicate with for
kstatesports.com queries.  Thus, kstatesports.com depends on ns-{1,2,3}.
ksu.edu resolving (and validating) properly.

Cheers,
Casey
___
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: named[1095]: error (unexpected RCODE REFUSED)

[Casey Deccio]

On Mon, May 4, 2015 at 9:38 AM, Chris  wrote:

> I've just finished setting up Bind as a local caching name server to
> work in conjunction with my Spamassassin setup. I did this because
> queries to uribl.com were getting blocked probably due to my ISPs
> reputation for spam. It seems to be working great, no more of the
> blocked queries to uribl.com however I am seeing a lot of this:
>
> error (unexpected RCODE REFUSED) resolving
> 'b4d44f4bcc9ddf0e61605920116ce915.ctyme.ixhash.net/A/IN':
> 62.75.209.50#53
> error (unexpected RCODE REFUSED) resolving 'getcreations.com//IN':
> 192.185.149.195#53
> error (connection refused) resolving
> '185.130.201.205.dnsbl.sorbs.net/A/IN': 67.228.187.34#53
> error (connection refused) resolving
> '185.130.201.205.dnsbl.sorbs.net/A/IN': 174.36.235.174#53
>
>
> this is a query to a domain I own
>
> error (unexpected RCODE REFUSED) resolving 'toadnet.com//IN':
> 207.218.247.135#53
>
> Do I have something in my setup incorrect?
>

Hi Chris,

The problem is not with your resolver, but with the zones/servers it is
contacting.  Take toadnet.com, for example.  The delegation records in the
.com zone are these:

$ dig +noall +authority @a.gtld-servers.net toadnet.com ns
toadnet.com.172800INNSns2.ev1servers.net.
toadnet.com.172800INNSns1.ev1servers.net.
toadnet.com.172800INNSns1.ecdiscounts.com.

and the authoritative records in the toadnet.com zone are these:

$ dig +noall +answer @ns1.ecdiscounts.com toadnet.com ns
toadnet.com.86400INNSns2.usdcservers.net.
toadnet.com.86400INNSns1.usdcservers.net.

But the ev1servers.net servers are not properly set up to respond for the
toadnet.com zone:

$ dig +noall +comments @ns1.ev1servers.net toadnet.com ns
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 43670
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096

In your case, looks like you probably need to clean up the delegation
records in the parent zone through your registrar to match the ones in your
child zone.  Others would need to do similarly, depending on their
situation.

Cheers,
Casey
___
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] BIND validates but not Unbound: who is right?

[Casey Deccio]

On Mon, Feb 16, 2015 at 11:34 AM, Stephane Bortzmeyer 
wrote:

> With Unbound, I get a SERVFAIL:
>
> ...


> But BIND accepts it (and so does Google Public DNS):
>
> ...

DNSviz, like Unbound, says the domain is broken:
>
> 


"Broken" is a loaded term.  There are definitely errors with cepn.asso.fr,
namely that because both algorithms 5 and 8 show up in the DS RRset, the
zone MUST be signed with both, i.e., RRSIGs for each algorithm should be
MUST accompany any RRset in the response.  This is specified in RFC 4035,
Sec 2.2.

However, this requirement is clarified in RFC 6840, Sec. 5.11 as follows:

   This requirement applies to servers, not validators.  Validators
   SHOULD accept any single valid path.  They SHOULD NOT insist that all
   algorithms signaled in the DS RRset work, and they MUST NOT insist
   that all algorithms signaled in the DNSKEY RRset work.

Thus, as Mark pointed out, these particular errors should not affect the
validation of cepn.asso.fr, for validators that understand both algorithms
5 and 8.

Note that DNSViz handles such cases by displaying the errors (i.e., with
the red error sign), but still showing the validation status of the RRsets
as "secure" (denoted by the blue-ish color).

http://dnsviz.net/d/cepn.asso.fr/VOGwhA/dnssec/

However, you can "see" the reason for the requirement of the signer (i.e.,
that it contains RRSIGs for each algorithm in the DS) in the following
example.  Suppose a validator does not support algorithm 5 (e.g., due to
implementation deficiency, administrative policy, or because algorithm has
been declared obsolete for some reason).  The chain of trust now looks like
this:

http://dnsviz.net/d/cepn.asso.fr/VOGwhA/dnssec/?rr=all&a=8&ds=all&ta=.&ta=dlv.isc.org.&tk=

As far as the validator is concerned, there should be a secure path for
both algorithms (as indicated by the algorithms in the DS records).  It
can't choose one or the other because algorithm 5 is not an option.  So it
turns to algorithm 8.  However, because there is no path for algorithm 8,
the chain is broken.

Cheers,
Casey
___
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: How to alias a domain

[Casey Deccio]

On Fri, Jan 16, 2015 at 10:49 AM, Casey Deccio  wrote:

> ... The CNAME requires to RRSIG...
>

Typo:
That should read: "... The CNAME requires no RRSIG..."

Cheers,
Casey
___
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: How to alias a domain

[Casey Deccio]

Hi John,

On Fri, Jan 16, 2015 at 10:36 AM, John  wrote:

>  DNAME will not work with DNSSEC.
>

Not true.  DNAMEs enable CNAME synthesis to other domains, after which
synthesis the response works just like regular CNAME response would.  The
authentication works by authenticating the DNAME (using the RRSIG covering
the DNAME).  The CNAME requires to RRSIG because it is known that all names
under the DNAME are synthesized (to the target domain), which has been
proven by the existence of the DNAME record itself.

DNSSEC will try to find keys for klam.biz NOT klam.com, which results in
> DNSSEC failure.
>
>
Actually, it must try to find authentication chains for the appropriate
records in *both* klam.biz and klam.com.

http://dnsviz.net/d/www.klam.biz/VLkuUA/dnssec/

Again, this is not unlike regular (non-DNAME) out-of-zone CNAME examples,
such as:

http://dnsviz.net/d/seas-web-test.huque.com/VLkyFA/dnssec/

Cheers,
Casey
___
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: Glue records for secondary NS

[Casey Deccio]

On Fri, Dec 5, 2014 at 3:23 PM, Mark Andrews  wrote:

>
> There are other cases where glue is necessary.  RFC 1034 unfortunately
> does not list them.  It only lists the most obvious case.
>
>
Good point.  Of course, the general principle is to avoid cyclic
dependencies and simplify/minimize your resolution path [1].

Casey

[1] http://spirit.cs.ucdavis.edu/pubs/conf/measuring_infocom_2010.pdf
___
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: DNS: how to verify glue NS records?

[Casey Deccio]

Hi Alexei,

On Fri, Dec 5, 2014 at 2:31 PM, Alexei Malinin 
wrote:

> Thank you for the explanation.
>
> I'm sorry for the misleading Subject of this thread, of course I meant
> "delegation NS records".
>
>
No problem.  I knew what you meant :)


> I understand from your reply that there are no technical means, tools,
> etc for verifying delegation NS records in the parent zone if the child
> and parent zone are on the same authoritative name server and zone
> transfers from that server are prohibited. Is my conclusion correct?
>
>
Yes.  If any parent authoritative server is *not* authoritative for the
child, then the delegation records can be identified by querying *that
server* for a referral.  Otherwise, the delegation NS RRset cannot be
gleaned from outside queries.

There is one slight exception to this.  You *can* learn if the parent has
*no* delegation records at all by using a DS query.  This is a corner case
but sometimes happens if the operator has neglected to place the
appropriate delegation records in the parent zone and doesn't see the
problem because, excepting a DS query (for which the *parent* is
authoritative, for DNSSEC purposes), the NS response always come from the
child when both parent and child zones are hosted on the same server.  If
you query a server authoritative for both parent and child for DS, an
NXDOMAIN response means that the parent has no delegation records for the
child.

For example:

$ dig +noall +comments +authority @ns1.agtel.net
0-15.66.233.212.in-addr.arpa ds
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30614
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; AUTHORITY SECTION:
66.233.212.in-addr.arpa. 3600INSOAns1.agtel.net.
hostmaster.agtel.net. 2014120402 86400 3600 604800 86400

The SOA record indicates that the response indeed came from the parent zone
(66.233.212.in-addr.arpa), and the NOERROR response indicates that there
are delegation NS records for in the parent zone.

Casey
___
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: Glue records for secondary NS

[Casey Deccio]

On Fri, Dec 5, 2014 at 1:00 PM, Robert Moskowitz 
wrote:

>
> On 12/05/2014 12:30 PM, Casey Deccio wrote:
>
> Short answer: you don't need, nor should you configure glue, for the
> servers run by the other domains.
>
>
> It would be nice, then, if all these DNS tool sites would know this and
> not report missing glue records over NS servers in other domains.
>
>
I can only speak for my own, which shows "N/A" when this is the case.  For
example:

http://dnsviz.net/d/example.com/VIFzRA/servers/

Casey
___
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: Glue records for secondary NS

[Casey Deccio]

On Fri, Dec 5, 2014 at 11:47 AM, Robert Moskowitz 
wrote:

> I have 3 secondaries run by other domains.  This was to give me some
> geo-diversity.  How do I create glue records for them?  My registrar only
> lets me create glue records within my domain (the web form pre-provides the
> domain part of the fqdn).
>

Short answer: you don't need, nor should you configure glue, for the
servers run by the other domains.

Glue is only necessary if the server names (i.e., the NS targets) are
subdomains of the child zone.  The reason why they are necessary is to
prevent a resolution loop.  Here is the relevant text from RFC 1034
(section 4.2.1) [1]:

"In particular, if the name of the name server is itself in the subzone, we
could be faced with the situation where the NS RRs tell us that in order to
learn a name server's address, we should contact the server using the
address we wish to learn. To fix this problem, a zone contains "glue" RRs
which are not part of the authoritative data, and are address RRs for the
servers. These RRs are only necessary if the name server's name is "below"
the cut, and are only used as part of a referral response."

If the server names are not subdomains of the delegated child zone (e.g.,
your case), then the resolver learns the addresses of the names using the
normal resolution process.  Here is the relevant text from RFC 1034
(section 5.3.3) [1]:

"These NS RRs list the names of hosts for a zone at or above SNAME.  Copy
the names into SLIST.  Set up their addresses using local data.  It may
be the case that the addresses are not available.  The resolver has many
choices here; the best is to start parallel resolver processes looking
for the addresses while continuing onward with the addresses which are
available."

Cheers,
Casey

[1] http://tools.ietf.org/html/rfc1034
___
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: DNS: how to verify glue NS records?

[Casey Deccio]

Hi Alexei,

On Fri, Dec 5, 2014 at 10:16 AM, Alexei Malinin 
wrote:

> I would like to resolve this problem:
> - I have a child DNS zone served by my ISP slave name server;
> - the parent zone is served by my ISP master name server;
> - the question is - how and with what tools (dig, host, nslookup, or
> maybe C or Perl libs) can I verify the NS glue records in the parent
> zone of my ISP (zone transfers are denied)?
>

The delegation NS records (i.e., the NS records in the parent zone) cannot
be determined using simple queries because the parent zone is also
authoritative for the child zone, as you mentioned.  Thus, when one of
those servers (e.g., ns1.agtel.net) is queried for
0-15.66.233.212.in-addr.arpa/NS, the server will (should) always send the
authoritative NS RRset in (i.e., from the child) preference to the
delegation NS RRset (i.e., in the parent), and in fact the latter may be
different.

There are by definition no glue records for your zone.  Glue A/ records
are only required in the parent for NS targets that are subdomains of the
delegated child zone to bootstrap resolution.  For example, ns1.example.com
as an NS target for example.com.  That is not the case with yours (and
usually isn't with in-addr.arpa zones).


> My child zone is 0-15.66.233.212.in-addr.arpa. I tried "dig -4
> +multiline +showsearch +trace 0-15.66.233.212.in-addr.arpa ns" but it
> was not possible to make any conclusions about NS glue records from the
> dig output.
>
> I found some tools in the Internet (for example
> http://www.intodns.com/0-15.66.233.212.in-addr.arpa, see "Missing
> nameservers reported by parent") but these are inconvenient, I would
> like to use OS tools.
>

That's unfortunately a misleading error, as this cannot be determined, as I
mentioned above.


>
> Please give me some good advise.
>
>
You'll need to take the word of the operator of your parent zone.

Casey
___
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: Wrong NSEC3 for wildcard cname

[Casey Deccio]

On Wed, Nov 19, 2014 at 7:03 PM, Graham Clinch 
wrote:

> Thanks - that's certainly looking less red.  DNSViz is an exceptionally
> useful tool!
>
>
Thanks!


> ...
>
> delv +vtrace continues to report "NSEC3 at super-domain" only for
> foo.cnametest2.palatine.ac.uk records, and not for
> foo.cnametest2.lancs.ac.uk.  Is this a similar
> miscalculating-the-owner-name as for DNSViz?


Don't know, but I would guess that this is simply recognizing the fact that
in addition to covering the non-existent name, the NSEC3 record also
happens to correspond to palatine.ac.uk.

I think this might be one of those cases where I should have trusted my
> gut instinct (to blame the validating resolver), but the more I
> investigated the more red and missing lines in output...
>

What version is your validating resolver?  For example, there are some
earlier versions of BIND that required that inclusion of the closest
encloser NSEC3, even though the closest encloser could be derived from the
RRSIG covering the wildcard.  As such, they would fail validation when the
authoritative server didn't send that (normally unnecessary) record.

At the start of the year, I received a piece of wisdom regarding NSEC3
> "It is much harder to understand and debug".  At the time I was sure
> that I could outsmart it.  Maybe not so much now.
>

Join the crowd :)  There is probably a local NSEC3 support group in your
area.

Casey
___
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: Wrong NSEC3 for wildcard cname

[Casey Deccio]

Hi Graham,

On Wed, Nov 19, 2014 at 11:59 AM, Graham Clinch 
wrote:

> Using bind 9.9.5 with inline-signing, I have a test wildcard cname
> record in two zones:
>
> *.cnametest.lancs.ac.uk CNAME www.lancs.ac.uk
> *.cnametest.palatine.ac.uk CNAME www.palatine.ac.uk
>
> dnsviz is showing the error
> "NSEC3 proving non-existence of foo.cnametest.lancs.ac.uk./CNAME:
> QNAME_NOT_COVERED"
> for the lancs.ac.uk version (but the palatine.ac.uk version is fine).
>
>
My apologies - this was actually a bug in DNSViz.  The NSEC3 computation
was being performed on the wrong name (the wrong origin was being
applied).  It should be fixed now, as shown in:

http://dnsviz.net/d/foo.cnametest.lancs.ac.uk/VGzlkA/dnssec/
http://dnsviz.net/d/foo.cnametest.palatine.ac.uk/VGzrqg/dnssec/


> ...
> For palatine.ac.uk:
>
> AEP7P2GGD4GEBNRMSBP4I97SU0MKR5R9.palatine.ac.uk. 3600 IN NSEC3 1 0 10
> BB1150B39E44B92F E92VAEN6BQ1T2N54AA2RSA1V49RM394S
>
> (AEP... is the hash of cnametest.palatine.ac.uk)
>
>
Yes, but more importantly it happens to be the owner name of the NSEC3
record that covers the NSEC3 hash of the next closest encloser (
foo.cnametest.palatine.ac.uk, whose hash starts with E8T9...).  The fact
that it also matches the NSEC3 hash of the closest encloser (
cnametest.palatine.ac.uk) is coincidental (and also probabilistic,
depending on the size of the zone).


>
> For lancs.ac.uk:
>
> RA9FSQ8NSK36A6568UHF8L26UFV2B1PG.lancs.ac.uk. 3600 IN NSEC3 1 0 10
> 9B6EFFBA177399A0 RA9V2QS7NE6Q5VLKU2EF4QONHP5CGIJR A RRSIG
>
> (RA9... isn't the hash of cnametest.lancs.ac.uk, and it's claiming there
> are A and RRSIG records!?).
>

Correct - this is the hash of some other record, the record that covers the
hash of the next closest encloser (foo.cnametest.lancs.ac.uk).  The hash of
the closest encloser is not necessary as this is for a wildcard response,
and the closest encloser (cnametest.lancs.ac.uk) can be inferred from the
labels field in the RRSIG.  In this case, the number of labels (i.e., in
the RRSIG) is 4, so the closest encloser is cnametest.lancs.ac.uk.


>
> Both cnametest records were added today, so the signature inception time
> of the lancs.ac.uk NSEC3's RRSIG being yesterday (20141118125729), is
> very odd...
>

Again, the NSEC3 in question corresponds to some other (most likely)
preexisting name, so it is not surprising that the inception date on its
RRSIG is older than today.


>
> What's going on?  Both zones are being signed by the same instance of
> bind and there are no interesting log messages.
>

Hope that helps.

Cheers,
Casey
___
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: problem resolving ardownload.adobe.com

[Casey Deccio]

On Wed, Jul 2, 2014 at 2:51 PM, Carl Byington  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> version: 9.10.0-P2
>
> dig ardownload.adobe.com. @localhost
>
> ;; ANSWER SECTION:
> ardownload.adobe.com.   8743IN  CNAME   ardownload.wip4.adobe.com.
>
>
What is the rest of the dig output?  Specifically, what status is your
resolver giving you (NOERROR or NXDOMAIN)?

When queried for type NS, the adobe load balancer returns NXDOMAIN:

$ dig @du1gtm001.adobe.com  ardownload.wip4.adobe.com ns

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @du1gtm001.adobe.com
ardownload.wip4.adobe.com ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42533
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;ardownload.wip4.adobe.com.INNS

;; AUTHORITY SECTION:
wip4.adobe.com.30INSOAsj1gtm001.adobe.com.
hostmaster.sj1gtm001.adobe.com. 1283 10800 3600 604800 60

;; Query time: 116 msec
;; SERVER: 193.104.215.247#53(193.104.215.247)
;; WHEN: Mon Jul  7 16:58:37 2014
;; MSG SIZE  rcvd: 100


Even though A queries yield NOERROR:

$ dig @du1gtm001.adobe.com  ardownload.wip4.adobe.com a

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @du1gtm001.adobe.com
ardownload.wip4.adobe.com a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21275
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;ardownload.wip4.adobe.com.INA

;; ANSWER SECTION:
ardownload.wip4.adobe.com. 300INCNAME
ardownload.adobe.com.edgesuite.net.

;; Query time: 119 msec
;; SERVER: 193.104.215.247#53(193.104.215.247)
;; WHEN: Mon Jul  7 16:59:25 2014
;; MSG SIZE  rcvd: 91

Your cache might be adversely affected by this behavior if your cache is
sending NS queries to authoritative servers (for example, RPZ with NS
lookup), which would cause the name to be cached as NXDOMAIN.

Casey
___
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: localhoast A record?

[Casey Deccio]

On Fri, Mar 21, 2014 at 8:50 AM, Mitchell Kuch  wrote:

> Hello -
>
> I've adopted a number of zones and most of them contain "localhost in
> a 127.0.0.1" records. I'm curious what current RFC standards state and
> what the community considers best practice. RFC1537 states that zones
> should contain a localhost record, but it seems that practice was
> obsoleted by RFC1912. Is anyone aware of negative consequences with
> leaving such records in place, perhaps a XSS vulnerability?
>
> I'm itching to remove the records but thought I'd check to see if
> there was a legacy use case.
>
>
I would take a look at the query logs for the zones in question.  You might
be surprised at how many queries are being made by systems that are
applying a suffix from the search list because of the lack of of an entry
for localhost in the hosts file or the mishandling thereof.

Casey
___
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: Insecurity proof failed resolving newsletter.postbank.de - but why?

[Casey Deccio]

On Mon, Jan 20, 2014 at 12:46 PM, Graham Clinch wrote:

> Thanks for the replies - and noticing the missing 'NS'!
>
> From my rather brain-busting afternoon reading, I believe this situation
> is covered by section 4.4 of RFC 6840, which requires a validator to ensure
> the NS type bit is set for an insecure delegation's NSEC(3) (or that it's
> covered by opt-out, but as Chris pointed out, that doesn't seem to be the
> case here).
>
I've left feedback for the dnsviz maintainer in the hopes that this case
> can be picked up in future.
>

Should be fixed now.  Not sure why I hadn't implemented that check before,
but I have now.

Casey
___
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: Synthesized CNAME from NXDOMAIN

[Casey Deccio]

On Thu, Oct 3, 2013 at 5:52 PM, Mark Andrews  wrote:

> Then I suggest that you just add CNAMEs whenever you remove other record.
> Once a part of the namespace only have CNAME/DNAME below it replace it
> with a DNAME.  You will converge on the earlier example.
>

Thanks - I'll start there.

Casey
___
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: Synthesized CNAME from NXDOMAIN

[Casey Deccio]

On Thu, Oct 3, 2013 at 5:42 PM, Mark Andrews  wrote:

>
> Use a DNAME record.  That works with DNSSEC.
>
>
Thanks for the suggestion.  I would use DNAME, except the old namespace
will still have names under it, and names are not allowed to exist below a
DNAME.  In other words, we're not replacing the old namespace, we're just
minimizing its scope and use.

Casey
___
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: Synthesized CNAME from NXDOMAIN

[Casey Deccio]

On Thu, Oct 3, 2013 at 2:54 PM, Paul Wouters  wrote:

> You are why we can't have nice things :P
>
> We had enough Sitewinders. With DNSSEC on the endnode, your lies won't
> be believed anway. What you are trying is wrong, bad and broken.
>
>
This might be a fair statement in the right context.  But it was taken out
of context--because I really didn't provide any.  Not that I need to
justify my question, but since you brought it up, what I am looking to do
is decrease the risk of DNS resolution failures resulting from a namespace
transition by creating a fallback from the old to the new namespace.  For
some definite period of time after the change, an NXDOMAIN in the old
namespace would result in a synthesized CNAME pointing to the same name in
the new namespace.  Anyway, there might not be an easy way to to do it, and
we might just have to lose our safety net, but I wanted to ask users on the
list if there's some obscure configuration that might be helpful.

If it's not already clear from my development of DNSSEC helper tools (e.g.,
DNSViz), I'm an advocate of secure DNS. :)

Cheers,
Casey
___
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

Synthesized CNAME from NXDOMAIN

[Casey Deccio]

Hi all,

I'm looking to get RPZ-like behavior in a non-RPZ context.  From the BIND9
ARM (9.9.4), this is a snippet from an RPZ zone:

; redirect x.bzone.domain.com to x.bzone.domain.com.garden.example.com
*.bzone.domain.com  CNAME   *.garden.example.com.

I would like to apply something similar to a "redirect" zone (for NXDOMAIN
responses), but it doesn't appear to be supported.  Can this be confirmed?
Does anyone recommend any alternatives?

Thanks,
Casey
___
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: ZSK rollover weirdness

[Casey Deccio]

On Fri, Sep 6, 2013 at 1:32 PM, Lawrence K. Chen, P.Eng. wrote:

>
>
> --
>
>
>
> So, can I just remove the Revoke line (is there an option in
> dnssec-settime to do this?) and have things fixed...
>
>
> guess dnssec-settime -A none -R none will remove itbut guessing
> there's more to fixing my current mess?
>

Adding the revoke bit was not useful, but wasn't in and of itself harmful.
The harmful part, and what likely was the cause of validation errors, was
that you began exclusively signing your zone contents before it had been
pre-published long enough for versions of the DNSKEY RRset without the key
to expire in cache.  Here's what I see:

2013-09-04 19:15 UTC
only ZSK with id 14565 exists and is signing zone
http://dnsviz.net/d/ksu.edu/UieG7w/dnssec/

2013-09-05 01:38 UTC
new ZSK with id 44538 is signing, as is now revoked key 14565 (now with id
14693)
http://dnsviz.net/d/ksu.edu/UifggA/dnssec/

Somewhere between that roughly six-hour period, the new ZSK was introduced
and the RRSIGs made by the new ZSK became the only useful ones since the
old key had been marked as revoked.  Now consider a validating resolver
that retrieved the DNSKEY RRset at 2013-09-04 19:15 UTC.  The TTL suggests
it can be cached for 24 hours--that is, 18 hours after DNSViz first notes
the presence of the new ZSK and RRSIGs that can only be validated by that
new ZSK.  This example validating resolver will now have issues validating
names in ksu.edu until the cache expires 24 hours after new ZSK was
introduced.  Such is the window for failure.

Regards,
Casey
___
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: ZSK rollover weirdness

[Casey Deccio]

On Fri, Sep 6, 2013 at 10:22 AM, Evan Hunt  wrote:

> The revoke bit has no defined meaning for a ZSK.


While it's true the revoke bit really has no use for a true ZSK (i.e., a
key where there's another key, a KSK, that is used to authenticate it), RFC
5011 doesn't distinguish based on either signing roles (ZSK/KSK) or
presence of the SEP bit [1]:

   A key is considered revoked when the resolver sees the key in a
   self-signed RRSet and the key has the REVOKE bit (see Section 7

   below) set to '1'.  Once the resolver sees the REVOKE bit, it MUST
   NOT use this key as a trust anchor or for any other purpose except to
   validate the RRSIG it signed over the DNSKEY RRSet specifically for
   the purpose of validating the revocation.

In other words, if the revoke bit is set, that key is no good for signing
anything other than itself, which is why DNSViz complains about it.  And
just to clarify, the use of the SEP bit is purely an administrative/user
convention or "hint", but is not considered during validation [2,3].  Thus
whether a key is action as a "ZSK" or a "KSK" really depends on how they
are used.

Casey

[1] http://tools.ietf.org/html/rfc5011#section-2.1
[2] http://tools.ietf.org/html/rfc6840#section-6.2
[3] http://tools.ietf.org/html/rfc4034#section-2.1.1


> It's used for updating
> trust anchors via RFC 5011. The code allows you to set it (just as it
> allows you to use a ZSK as a KSK), but I don't recommend it.
>
> Unless there are resolvers that have managed-key trust anchors configured
> for ksu.edu, you shouldn't bother with the revoke bit for your KSK either.
>
> --
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
> ___
> 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
>
___
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: Validation succeeds when keys with multiple algorithms present, but not RRSIGs for both

[Casey Deccio]

On Fri, Aug 2, 2013 at 5:25 AM, Mark Andrews  wrote:
>
> In message <51fb9c18.23133.401e...@tmorizot.sd.is.irs.gov>, "Scott Morizot" 
> wri
> tes:
>> The BIND 9 resolver returns an answer with the AD bit set. Unbound
>> returns SERVFAIL. Secure64 Caches also return SERVFAIL. Those are the
>> only three nameservers I've tested.
>
> Version 1.4.8 onwards should validate the zone.  Earlier versions were
> broken.  http://www.unbound.net/documentation/info_algo.html
>

Actually, while unbound has loosened their requirements as per the
reference above, they are still stricter than BIND--and RFC for that
matter, though the basis for their strictness is actually lack of
specification for some circumstances.  There was a recent thread on
the unbound-users mailing list on just this topic and the same DNS
name (though I can't seem to get to the site over v4 or v6 at the
moment to reference it).  RFC 6840 (DNSSEC clarifications) says the
following, paraphrased from section 5.11:

- all the algorithms in the DS RRset must be present in the DNSKEY RRset
- addition algorithms are allowed in the DNSKEY RRset, but not vice-versa
- the zone RRsets must be signed by all algorithms in the DNSKEY RRset
- a validator must support any valid path (i.e., don't require that a
path with all algorithms)

dfas.mil is violating the third rule above, which could potentially
hinder some implementations from creating a chain of trust all the way
to the RRset.  unbound (capable of both algorithms in the DNSKEY
RRset) is violating the fourth rule above.

The second rule above is what creates the apparent underspecification.
 What about validators that don't support the algorithm with which the
(extra) RRset is signed?  Insecure delegations happen at the zone cut,
not mid-zone.  A delegation might be "secure" because the algorithm at
the DS is understood, but if an additional algorithm from the DNSKEY
RRset is used to exclusively sign an RRset, the behavior is undefined.
 IMO, the outcome would need to be "bogus" (as opposed to "insecure"),
but it's simply not defined.

Casey
___
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: Troubleshooting DNSSEC issue w/ ic.fbi.gov

[Casey Deccio]

On Wed, Jul 17, 2013 at 10:58 AM, Bill Owens  wrote:
> This is one of the weirder ones I've seen. . . there are TXT and MX records 
> for ic.fbi.gov, both correctly signed:
>
> ...
> However, that NSEC3 record is not signed.

FWIW, DNSViz checks the chain of trust for authenticated
denial-of-existence, but it doesn't display it by default.  If you
select "denial of existence" from the "DNSSEC options" then you see
some errors on the left (maybe we could have it shown by default if
there are errors).

http://dnsviz.net/d/ic.fbi.gov/Ueea1Q/dnssec/?rr=all&a=all&ds=all&doe=on&ta=.&tk=

However, it seems the graph is missing corresponding red, dashed
arrows that are usually used to show when *some* servers are missing
RRSIGs--that will need to be looked into.  Because two of the servers
are returning RRSIGs for NSEC3, it does show arrows on the
authentication chain.  The rest, however, are certainly lacking
RRSIGs:

http://dnsviz.net/d/fbi.gov/UeeFmQ/servers/

Cheers,
Casey
___
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: Stop of logging of No Valid Signature Found

[Casey Deccio]

On Mon, Feb 25, 2013 at 5:09 AM, Robert Moskowitz wrote:

> Yes, I know lots of places don't have DNSSEC signed zones.  **I** have not
> done mine yet, but I turned on DNSSEC checking on my server and I am
> getting all too many messages like:
>
>   validating @0xb4247b50: 117.in-addr.arpa NSEC: no valid signature
> found: 1 Time(s)
>   validating @0xb4247b50: 117.in-addr.arpa SOA: no valid signature
> found: 1 Time(s)
>

Yes, but 117.in-addr.arpa *is* signed [1], so if you're not getting
signatures, that's problematic.


> How can I stop the logging of only " no valid signature found"?  So I can
> watch for more meaningful events and not so quickly grow /var/log/messages?
>

Logging can be tuned on a per-category (e.g., DNSSEC) basis, including the
location to which log messages are sent (e.g., file, syslog, etc.).  See
the section on logging in the BIND 9 Configuration Reference for more
information on how to do this [2].

Casey

[1]  http://dnsviz.net/d/117.in-addr.arpa/USuy_w/dnssec/
[2]  http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch06.html
___
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: question about dns query distribution

[Casey Deccio]

On Wed, Feb 6, 2013 at 11:32 AM, M. Meadows  wrote:

>
> Recently noticed that for 2 nameservers ns1.tbd.com and ns2.tbd.com(names are 
> changed to protect the innocent) the first nameserver
> consistently receives twice as many queries as the 2nd nameserver.
> Who can tell me why queries are distributed this way?
>

I assume you are comparing queries for names within the same zone on both
servers?  If so, do either (or both) of the name servers have glue?  Are
the names of the servers as similar as you suggest (e.g., within the same
domain), or are they different?  How different are the servers in terms of
their network connectivity (i.e., to compare response time)?

Casey

>
___
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] Dealing with an inconsistent NSEC

[Casey Deccio]

On Tue, Oct 23, 2012 at 6:36 AM, Stephane Bortzmeyer wrote:

> On Tue, Oct 23, 2012 at 06:27:12AM -0700,
>  Casey Deccio  wrote
>  a message of 88 lines which said:
>
> > The issue here is that no delegation NS records exist for
> > v1.pcextreme.nlin its parent zone, pcextreme.nl.  Thus when any
> > server (authoritative for both zones) is queried for
> > v1.pcextreme.nl/DS, NXDOMAIN is returned because there are no
> > records by that name in the parent (no DS or NS).
>
> But it should reply NOERROR,DATA=0, no NXDOMAIN. Indeed,
> pcextreme.nl's name servers reply NXDOMAIN for DS queries but not for
> other QTYPES.
>
> So, no bug in BIND and Unbound, only in the zone?
>

Yes.  Prior to DNSSEC, it used to be that if all servers authoritative for
a parent were also authoritative for the delegated child, then they could
get away with not having any delegation records in the parent.  With DNSSEC
this omission causes these NXDOMAIN issues with validating resolvers when
child is signed and parent has no DS.

Casey
___
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] Dealing with an inconsistent NSEC

[Casey Deccio]

On Tue, Oct 23, 2012 at 1:08 AM, Stephane Bortzmeyer wrote:

> It may be a bug in BIND and it is certainly a bug in the zone
> pcextreme.nl.
>
> BIND validating resolvers are unable to get the IP address of
> v1.pcextreme.nl.
>
> I believe this is because of the strange NSEC:
>
> tools-newerst.pcextreme.nl. 2315 IN NSECv2.pcextreme.nl. 
> RRSIG NSEC
>
> which says there is nothing between tools-newerst.pcextreme.nl and
> v2.pcextreme.nl (and therefore no v1).
>
> This is inconsistent since there are also A and  records for
> v1.pcextreme.nl.
>
>
The issue here is that no delegation NS records exist for
v1.pcextreme.nlin its parent zone,
pcextreme.nl.  Thus when any server (authoritative for both zones) is
queried for v1.pcextreme.nl/DS, NXDOMAIN is returned because there are no
records by that name in the parent (no DS or NS).  Because BIND looks
upward for DS RRs after validating RRSIGs in v1.pcextreme.nl, it gets the
NXDOMAIN response, which changes the cache's understandingof
v1.pcextreme.nl--specifically that the name doesn't exist.  The results
from your resolver are reflecting that behavior.  unbound perhaps handles
authentication differently, e.g., top-down, so it doesn't ever perform the
DS query and thus never receives NXDOMAIN for the name.

See also the delegation warning at:
http://dnsviz.net/d/v1.pcextreme.nl/UIY0lg/dnssec/

Casey
___
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: DS record TTL question.

[Casey Deccio]

On Wed, Aug 8, 2012 at 9:36 AM, GS Bryan  wrote:

> My question is how can I control the TTL of the DS record inserted into a
> signed zone via inline signing? I'm using BIND 9.9.1 P2.
>
> My zone file has a default TTL of 3600 a.k.a. 1 hour, but it seems the 2
> DS records put into the signed version of the zone has the TTL of 1 day. I
> would like that the zone default TTL be obeyed when the DS records are
> being inserted during inline signing.
>

I don't know about BIND's default behavior for DS TTL or its options for
customizing the TTL, but according to RFC 4035 (Section 2.4):

The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
   (that is, the NS RRset from the same zone containing the DS RRset).

Casey
___
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 troubles (no valid NSEC) ?

[Casey Deccio]

On Wed, Jul 25, 2012 at 10:07 AM, Frantisek Hanzlik wrote:

> I solve problem with delivering mail to address  "x...@br.ds.mfcr.cz".
> MTA obviously isn't able resolve MX records for this domain.
> "dig @localhost -t MX br.ds.mfcr.cz" ends with SERVFAIL error:
>
> ...
>
> and in BIND (v9.7.4 i686) log are after this query three records:
>
> error (no valid NSEC) resolving 'br.ds.mfcr.cz/MX/IN': 80.95.254.4#53
> error (no valid NSEC) resolving 'br.ds.mfcr.cz/MX/IN': 193.86.123.22#53
> error (no valid NSEC) resolving 'br.ds.mfcr.cz/MX/IN': 193.86.123.21#53
>
>
The result for br.ds.mfcr.cz/MX is an expansion of a wildcard (*.
ds.mfcr.cz/MX).  Signed responses that include expanded wildcards require
that NSEC(3) RRs are included in the authority section to show that the
QNAME (e.g., br.ds.mfcr.cz) doesn't exist, so the wildcard expansion is
legitimate.  The NSEC3 for the closest encloser of the QNAME is not
necessary because it can be inferred from the RRSIG, so only a single NSEC3
is sufficient.  However, earlier versions of BIND both served the
superfluous NSEC3 and expected it.  See this thread, for example:

http://dnssec-deployment.org/pipermail/dnssec-deployment/2011-October/005486.html

$ dig +dnssec +noall +authority @ns1.mfcr.cz br.ds.mfcr.cz mx
mfcr.cz. 10800 IN NS ns1.mfcr.cz.
mfcr.cz. 10800 IN NS ns3.mfcr.cz.
mfcr.cz. 10800 IN NS ns2.mfcr.cz.
mfcr.cz. 10800 IN RRSIG NS 7 2 10800 20120812074507 20120712074507 14339
mfcr.cz. NGNS8CkP5Gg/cvUTsTrxoDuRiGeaoixJ5+optBhK1gRYinpHZ3cx9y/i
w5WOAKYy/uOpMhvAiOIzA59yDnGOhG/2ewH/S/G8+TcISBk0//KcYSuf
xs7bkBm+YFzVG8YEqwESvKklAkdplraWHH2uxMX4NYBWKeOyjG+PgyW2 AdM=
R9UBJMRSM8SMDHCFR97VNPPNVP6GBB2U.mfcr.cz. 3600 IN NSEC3 1 1 10
BDD515FB9B1238C4 RF50NKKASDGSBSRGBI8T72N9EEH5KBIO A RRSIG
R9UBJMRSM8SMDHCFR97VNPPNVP6GBB2U.mfcr.cz. 3600 IN RRSIG NSEC3 7 3 3600
20120812074507 20120712074507 14339 mfcr.cz.
2VXv7Hudu2iHjwp75fxv9wwH5CZx35upl/iYfe8HZDHj3badkQbi6CH4
IAyJuOA9gUttoRogXtwCNJV0BwTl5iPlpl/QqEeTu1B7e2oWr829CweK
+v42sHh5SuBmaB5rlJS+GhVm6MQe+nqZMe1nG48O1VV2PPGEvETYBI+V SzI=

Note that only a NSEC3 RR is returned above.  This is correct behavior
(though an extra NSEC3 RR shouldn't matter), but the older resolver doesn't
handle it well.

I tried find some info about this error message, but without luck.
> Problem will be perhaps something with DNSSEC. What is interesting,
> BIND v9.9.1, essentially with the same configuration (relevant
> "options" paragraph part of named.conf is in both:
>

I don't know what versions it has been fixed in, but I assume at least that
this is the bug fix referred to in the changelog for 9.9.0:

"named now correctly validates DNSSEC positive wildcard responses from
NSEC3 signed zones. [RT #26200]" [1].

Of course, now there is some mix of older validating BIND resolvers that
expect the extra NSEC3 RR and BIND (and other) authoritative server
implementations that don't send it.  So, this issue might show itself
occasionally.

Casey

[1] https://kb.isc.org/article/AA-00631/0/BIND-9.9.0-Release-Notes.html
___
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: named validating @0x...: ... SOA: no valid signature found

[Casey Deccio]

On Fri, Jul 20, 2012 at 6:03 AM, Brian J. Murrell wrote:

> On 12-07-20 08:34 AM, Brian J. Murrell wrote:
> >
> > The problem here seems to be fragmented UDP.
>
> I seem to have misdiagnosed this due to tcpdump peculiarities.  I only
> initially saw/suspected the problem since my capture for port 53
> packets was including (only the first) ipv4 fragments.  When adding a
> capture specifically to get all ipv4 fragments in addition to my port
> 53 packets, I do see all of the fragments.
>
>
Just because you see the fragments on the wire doesn't mean they're getting
past the local firewall and being reassembled.  For example, if you're
using ip6tables on a Linux kernel <= 2.6.20 IPv6 fragments aren't allowed
through properly [1].  What OS/kernel are you using?

Casey

[1] See https://dnssec.surfnet.nl/?p=464
___
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: Problem with DNSSEC signing zone

[Casey Deccio]

On Fri, Jul 20, 2012 at 2:52 AM, William Thierry SAMEN <
thierry.sa...@gmail.com> wrote:

> i just have a problem with my zone signing output i made all the steps to
> obtain a good result.

...

> my zone name is *willzik.co.uk*
>
**
>
I'm getting an NXDOMAIN response from the co.uk servers, rather than a
delegation referral:

$ dig @nsa.nic.uk willzik.co.uk | grep status
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 63301

It appears that you don't have delegation (NS) records in co.uk for
willzik.co.uk.

Casey
___
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: www.glb.hud.gov

[Casey Deccio]

On Thu, Apr 19, 2012 at 5:59 AM, Chris Thompson  wrote:

> On Apr 19 2012, Richard Laager wrote:
>
>  Are others timing out trying to resolve www.glb.hud.gov? This seems
>> (though I haven't done extensive testing) to only happen to me with
>> BIND.
>>
>> http://dnsviz.net/d/www.glb.**hud.gov/dnssec/shows
>>  a couple of DNSKEY
>> warnings, so maybe that's it. I always suspect DNSSEC when I have
>> problems with .gov domains, but I commented out "dnssec-enable yes" in
>> my named.conf and it didn't help.
>>
>
> There is no DS record in the parent zone, so the zone contents could
> not be validated anyway.
>
>
Yes, but there's a difference between "could not be validated", meaning
there is no chain of trust extending to glb.hud.gov (the hud.gov zone
securely proves that the trust does not extend to glb.hud.gov) and "could
not be validated", meaning there should be a chain, but the necessary
DNSKEYs and RRSIGs are not available to validate it.  The first should
yield an insecure (i.e., unauthenticated) response, the second SERVFAIL.
 BIND gets hung up on the fact that the DNSKEY RRset for glb.hud.gov cannot
be retrieved to validate the RRSIGs covering glb.hud.gov names and returns
SERVFAIL, even though technically it should simply return an insecure
response.  Note that unbound responds appropriately:

$ dig +dnssec @localhost www.glb.hud.gov

; <<>> DiG 9.7.3 <<>> +dnssec @localhost www.glb.hud.gov
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61547
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.glb.hud.gov. IN A

;; ANSWER SECTION:
www.glb.hud.gov. 30 IN A 170.97.67.13
www.glb.hud.gov. 30 IN RRSIG A 7 4 30 20120425192819 20120418192819 18872
glb.hud.gov. qeuaykqCRmDoJ/b7+MayUC4LB5GCoJ00931CS8w+Ta6tuT/qv3dGsR1i
NVP5Xh5x/kJVyM6M3red1b2e4zrw930xe5gegPxGyWZqT8CVF7clouOJ
nPr3D+JGre46lvsi62ibhCfS82gfuNLg+028D6EasnWiQgcG70ONI2yU a+w=
www.glb.hud.gov. 30 IN RRSIG A 7 4 30 20120424171101 20120417171101 27647
glb.hud.gov. kVWQcOoRa2BPK+K4mMQQ+SsFKk2F6F2euVS2xrzlKyYMmOHytouRq6LK
En8edmPbm5iYDGnW/Hc7jPLQgqpRYVxkdjKTvjYNf+yjqBK1aBblVZ4b
Y/hDCcbfO5DsVEmJ/HuEg9vlQ65inWB2xpLul0FOXC7xLn7ch/h8A8Jv UfQ=

;; Query time: 85 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Apr 19 07:34:06 2012
;; MSG SIZE  rcvd: 402

Casey
___
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: NS record for subzone definition

[Casey Deccio]

On Tue, Mar 13, 2012 at 9:33 AM, hugo hugoo  wrote:

>  Thanks for this interesting feedback.
> Now I have the problem to detect this kind of bad configuration.
>
> If I have:
>
> Zone toto.be:
>
> toto.be.
>
> NS  ns1.xxx.be
>
> + some records
>
>
> Zone titi.toto.be:
>
>
> titi.toto.be.
>
>  NS   ns1.xxx.be
>
>   + some records.
>
>
> What will be the command to detect that zone toto.be has no NS for
> titi.toto.be ??
>
>

Here's one command, given that ns1.xxx.be is authoritative for both toto.beand
titi.toto.be:

dig +noall +comments @ns1.xxx.be titi.toto.be ns | grep "status: NOERROR"
&& \
  dig +noall +comments @ns1.xxx.be titi.toto.be ds | grep "status: NXDOMAIN"

A zero exit status for the above command indicates that the NS RRs are
missing from the parent.  Note, however, that a non-zero exit status
doesn't necessarily mean that the NS records exist.

Casey
___
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 and CVE-2012-1033 (Ghost domain names)

[Casey Deccio]

On Mon, Feb 13, 2012 at 2:31 PM, Tony Finch  wrote:

> Florian Weimer  wrote:
> >
> > Doesn't the DNSSEC-based mitigation rely on RRSIGs whose validity does
> > not extend too far into the future?
>
> It depends on the TTL of the DS record or its proof of nonexistence.
>
>
Of course, the TTL is also bounded by the expiration of the RRSIG.

Casey
___
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 and CVE-2012-1033 (Ghost domain names)

[Casey Deccio]

On Fri, Feb 10, 2012 at 2:27 PM, Casey Deccio  wrote:

> Unless future specification or implementation designated that delegation
> follow the same model as trust--that is, that a delegation only last as
> long as the parent said it did.


I hadn't previously read Paul's resimprove draft on this topic, but it was
newly posted on dns-operations, and it describes this very behavior.

http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00

Casey
___
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 and CVE-2012-1033 (Ghost domain names)

[Casey Deccio]

On Fri, Feb 10, 2012 at 7:37 AM, Stephane Bortzmeyer wrote:

> On Thu, Feb 09, 2012 at 12:38:42PM -0800,
>  Casey Deccio  wrote
>  a message of 67 lines which said:
>
> > Actually, it should, in the spirit of DNSSEC.
>
> OK, so there is nothing that can be done at the registry level.


No.


> Only
> the resolver admin can use DNSSEC to solve the ghost domain problem,
> by enabling DNSSEC validation. Correct?
>

Yes.  Unless future specification or implementation designated that
delegation follow the same model as trust--that is, that a delegation only
last as long as the parent said it did.  But I'm not sure that's the right
approach, and this seems to me to be somewhat of a niche problem.

Casey
___
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 and CVE-2012-1033 (Ghost domain names)

[Casey Deccio]

On Thu, Feb 9, 2012 at 1:26 AM, Stephane Bortzmeyer wrote:

> Unless you make DNSSEC mandatory, how will
> you solve the ghost domain problem with DNSSEC? If the resolver is
> sticky (will not go to the parent to ask the NS RRset), it won't check
> the NSEC at the parent either...
>
>
Actually, it should, in the spirit of DNSSEC.  With a trusted anchor,
DNSSEC provides a chain of trust--whether it terminates in an insecure
delegation (i.e., with NSEC or NSEC3 RRs) or continues all the way to the
RRset begin sought.  Once any records in that chain expire from cache, the
chain needs to be refreshed, or there is no way to tell if the name is
expected to have a secure validation path or not.  While I don't know if
the "how" is specified in RFCs, in my recent observation both bind and
unbound do exhibit that behavior, though with slight differences.


> Is it because the resolver, even if sticky, re-queries the parent when
> the negative TTL of the (missing) DS records ends? And chokes when it
> receives back a NXDOMAIN?
>

Actually, what I have observed in my limited testing is that the resolver
re-queries the parent after the TTL of the NS RRset in the parent, not the
negative TTL of the parent.  Upon receiving a NXDOMAIN response, it passes
that along to the client.

Casey
___
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: cannot resolve oppedahl.com from uspto.gov domain

[Casey Deccio]

On Fri, Feb 3, 2012 at 9:53 AM, Cricket Liu  wrote:

> This is consistent with something I noticed earlier:  DNSViz validates
> oppedahl.com's chain of trust without a problem, but Verisign Labs'
> DNSSEC Debugger reports no response from oppedahl.com's name servers.
>  DNSViz is hosted by Sandia, presumably in New Mexico, while Verisign Labs
> is in the D.C. area.
>
>
FWIW, DNSViz is actually hosted out of Sandia's Livermore, CA, site, in the
SF Bay Area :)

Geography aside, issues such as anycast instances and resolver perspective
are things I plan to address for DNSViz to make it a more useful tool.
 We're looking to procure funding to continue work on it in these areas and
others.

Casey
___
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 external validation issues

[Casey Deccio]

On Sun, Nov 13, 2011 at 1:50 PM, Eduardo Bonsi  wrote:

> Mark and everybody, Thanks for the checking. I had a suspicion that was
> the issue but I need a second opinion since when I checked my DNS from the
> inside the "refused" status is not happening. Here is what I am getting:
>
>
What does your named.conf on ns1/ns2 look like?  You should allowing
queries from "any" for bonsi.orgif you intend it to be advertised as an
authoritative server.  Something like:

zone "bonsi.org" {
  ...
  allow-query { any; };
};

Casey
___
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: Mixing Algorithms for DNSSEC

[Casey Deccio]

On Sat, Oct 15, 2011 at 1:31 PM, Mark Elkins  wrote:

> True - no problem with a handful of zones.
>
> Now assume a few thousand being automated from some script.
>
> Wonder if OpenDNSSEC handles this at all?
>
> OK - so I've rewritten my script to not worry (Don't Panic) - just keep
> using the monthly KSK's with RSASHA1 until it sees a ZSK with the
> RSASHA256 algorithm - then just switch over to creating KSK's with
> RSASHA256 as well.
>
>
There are some documented procedures for algorithm rollovers in RFC 4641bis
that you should probably look at.  The current draft is at:

http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis-07

see section 4.1.5.

Regards,
Casey
___
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: Mixing Algorithms for DNSSEC

[Casey Deccio]

On Sat, Oct 15, 2011 at 3:11 AM, Mark Elkins  wrote:

> Basically - create a KSK and ZSK with RSASHA1 - Sign - and visibly check
> the results.
> Add a new KSK using RSASHA256 - prep the zone and sign again.
> 1 - Signer is confused - can not sign (or generate a new Signed
> Zone)...
>Verifying the zone using the following algorithms: RSASHA1.
>Missing self signing KSK for algorithm RSASHA256
>The zone is not fully signed for the following algorithms:
>RSASHA256.
>dnssec-signzone: fatal: DNSSEC completeness test failed.
>
>
When you include DNSKEYS with multiple algorithms, both the DNSKEY RRset and
other RRsets in the zone must be signed with each algorithm [1].  Because
you designed your RSASHA256 DNSKEY as a KSK, dnssec-signzone is only using
it to sign the DNSKEY RRset, not other RRsets.  To resolve this, create a
ZSK with algorithm RSASHA256 to your zone.

Regards,
Casey

[1] See http://tools.ietf.org/html/rfc4035 - section 2.2
___
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: Master and slave on same host

[Casey Deccio]

On Tue, Oct 11, 2011 at 2:20 PM, Mark Andrews  wrote:

> To answer the original poster's question.  Use TSIG as has already
> been pointed out.  The following change makes doing this much easier
> as it allows you to send to multiple views by having multiple
> address/key pairs specified in also-notify.
>
> Mark
>
> 3109.   [func]  The also-notify option now uses the same syntax
>as a zone's masters clause.  This means it is
>now possible to specify a TSIG key to use when
>sending notifies to a given server, or to include
>an explicit named masters list in an also-notfiy
>statement.  [RT #23508]
>
>
This is helpful.  Which release(s) is this in?

Casey
___
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 not populating parent zone files with DS records

[Casey Deccio]

On Fri, Sep 30, 2011 at 6:16 PM, Hauke Lampe  wrote:

> Aside from the missing DS, I don't see why BIND complains about the
> NXDOMAIN response at first and then returns that cached record set in
> response to later queries for the same name. dig +sigchase validates it,
> if provided with the nau.edu DNSKEY:
>
>
The issue can be seen by querying the authoritative source, rather than what
the resolver returns.  As someone posted earlier, the cause of the issue is
the lack of NS RRs for extended.nau.edu in the nau.edu zone.  Prior to
DNSSEC deployment this wasn't really an issue (even though it was certainly
a misconfiguration) if all the authoritative servers for the parent zone
were also authoritative for the child zone.  In this case the parent
authoritative servers knew and could properly respond with the NS RRs.
However, the DS RR is a new beast, and even though it carries the name of
the child zone (e.g., extended.nau.edu), the parent zone (e.g., nau.edu)
answers authoritatively for that record type.  So when querying for DS vs.
other record types the responses are different:

$ dig @ns1.nau.edu extended.nau.edu ds | grep status
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 39613
$ dig @ns1.nau.edu extended.nau.edu ns | grep status
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28073

DS queries in this case result in NXDOMAIN for the name because the parent
zone has no records of that name (because of the lack of NS RRs for the
child).  NS records, however, return NOERROR because the response comes from
the child zone which has records of that name.  The resolver returns
inconsistent responses based on its configuration (validation, which causes
querying for DS RRs) and the state of its cache.  The lack of NS RRs in the
parent is also shown in the DNSViz output for extended.nau.edu:

http://dnsviz.net/d/extended.nau.edu/dnssec/

Regards,
Casey
___
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: another question about the glue

[Casey Deccio]

On Fri, Jul 1, 2011 at 12:31 PM, PANG J.  wrote:

> Why the "net" zone has the glue for the servers
> which are in the "com" zone?
>
>
Glue refers to address records for name servers of delegated child zones,
when the names of those servers are subdomains of the delegated zone itself,
e.g.,

example.net. IN NS ns1.example.net.
ns1.example.net. IN A 192.0.2.1

However, records in the additional section don't always correspond to glue
records contained in the delegating zone.  Servers may also return records
from other sources in their additional section, such as from other zones for
which they are authoritative.  Such is the case with the gTLD servers, which
are authoritative for net and com.  The address records returned for
ns{1,2}.dnsbed.com are not in the net zone, but they are "sibling" glue for
another zone delegated from the com zone.  That is, they are the names of
servers authoritative for a zone delegated from the com zone other than
dnsbed.com (ns{1,2}.dnsbed.com aren't among the authoritative server names
for dnsbed.com).

Casey
___
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: nameserver registration

[Casey Deccio]

On Sun, Jun 19, 2011 at 10:37 AM, Michael Sinatra
 wrote:
> On 06/18/11 19:22, Casey Deccio wrote:
>
>> In particular, if the
>> name of the name server is itself in the subzone, we could be faced with
>> the situation where the NS RRs tell us that in order to learn a name
>> server's address, we should contact the server using the address we wish
>> to learn.  To fix this problem, a zone contains "glue" RRs which are not
>> part of the authoritative data, and are address RRs for the servers.
>> These RRs are only necessary if the name server's name is "below" the
>> cut, and are only used as part of a referral response.
>
> How many levels "below the cut"?
>

It's arbitrary, but the context is names that are targets of NS RRs in
the delegating parent zone, e.g., edu to podunk.edu.  It was not clear
to me from your example, but it appeared to me that dns.podunk.edu was
not directly delegated from edu, but that the podunk.edu zone existed
between edu and dns.podunk.edu.  In that case, glue doesn't make sense
(to me, anyway) because it doesn't pertain to the zone being
delegated.  In other words, this seems more like "uncle/nephew" glue
than "sibling" glue.

>> Even if referring servers return such RRs, they are considered
>> out-of-bailiwick, and resolvers should resolve the names, rather than
>> trust the additional RRs.  i.e., .org servers should not be handing
>> out RRs under .edu.  Hence the dependencies, which can get long and
>> complicated, but they're part of the DNS.
>
> I didn't say that they should--only that the ORG registrar (or registry) may
> have to enforce that glue exist in EDU and vice versa.  That's the point of
> sibling glue.
>

Sorry, I misinterpreted your comments.

Casey
___
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: nameserver registration

[Casey Deccio]

On Sat, Jun 18, 2011 at 4:22 PM, Michael Sinatra
 wrote:
>  Consider:
>
> baz.org.  NS ns1.dns.podunk.edu.
> baz.org.  NS ns2.dns.podunk.edu.
>
> and
>
> dns.podunk.edu. NS ns1.dns.podunk.edu.
> dns.podunk.edu. NS ns2.dns.podunk.edu.
>
> In theory, you "should" only need glue in podunk.edu, but podunk.edu isn't
> under the control of any registry (or registrar for that matter).  If the
> registrar for baz.org wants to be sure that things are going to work--and
> that they will stay working--then you need appropriate glue at a higher
> level.
>

Unfortunately, that won't work.  It violates the principle of "glue".
>From RFC 1034 (emphasis on the last sentence):

In particular, if the
name of the name server is itself in the subzone, we could be faced with
the situation where the NS RRs tell us that in order to learn a name
server's address, we should contact the server using the address we wish
to learn.  To fix this problem, a zone contains "glue" RRs which are not
part of the authoritative data, and are address RRs for the servers.
These RRs are only necessary if the name server's name is "below" the
cut, and are only used as part of a referral response.

Even if referring servers return such RRs, they are considered
out-of-bailiwick, and resolvers should resolve the names, rather than
trust the additional RRs.  i.e., .org servers should not be handing
out RRs under .edu.  Hence the dependencies, which can get long and
complicated, but they're part of the DNS.

Casey
___
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: ? bad cache hit (eduftcdnsp01.ed.gov/DS)

[Casey Deccio]

On Fri, May 27, 2011 at 12:09 PM, Jim Glassford  wrote:

> Starting today got reports of unable to reach some student ad sites such as
> studentloans.gov
>
>
There are problems with this and related sites.  Specifically RRSIGs are not
being returned with some RRsets, resulting in a broken chain of trust and a
bogus validation status:

http://dnsviz.net/d/studentloans.gov/dnssec/
http://dnsviz.net/d/eduftcdnsp01.ed.gov/dnssec/

There's been some effort through this list and other DNS lists to contact
the DNS admins of these sites and make them aware of the problems, so they
can be resolved.

Regards,
Casey
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC, whitehouse, isc, and troubleshooting...

[Casey Deccio]

On Mon, Apr 18, 2011 at 11:07 AM, Evan Hunt  wrote:

> On Mon, Apr 18, 2011 at 10:51:04AM -0700, John Williams wrote:
> > From my signed domain when I query www.isc.org (w/ +dnssec) I get the ad
> > flag as expected.  I don't see that flag when I query whitehouse.gov (w/
> > +dnssec) and I know that zone is signed.
> >
> > Is anyone else seeing this behavior?  Also, is there a link that
> > addresses troubleshooting or diagnosing DNSSEC based queries?
>
> My guess is you're looking at www.whitehouse.gov, which is a CNAME to
> www.whitehouse.gov.edgesuite.net, which isn't signed, so the ad flag
> is unset.  Try "dig +dnssec ns whitehouse.gov" and you should see
> the ad flag.  (Anyway, it's working for me at the moment.)
>
>
As far as DNSSEC troubleshooting tools, this alias relationship is
illustrated using DNSViz, an online analysis tool:
http://dnsviz.net/d/www.whitehouse.gov/dnssec/ .  Note that the
www.whitehouse.gov RRset is "secure", but the name it aliases is "insecure"
(no chain of trust).  Thus, the resolver (as Evan mentioned) does not set
the AD flag when queried for www.whitehouse.gov.

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

Re: dns best practices

[Casey Deccio]

On Sun, Jan 23, 2011 at 10:30 PM,   wrote:
> Is there a document for dns & bind best practices?
> I googled but found nothing valueable.
>

NIST SP 800-81 Rev. 1:

http://csrc.nist.gov/publications/nistpubs/800-81r1/sp-800-81r1.pdf

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

Re: Does anyone know where to find the ISC signing keys for source packages?

[Casey Deccio]

On Tue, Dec 28, 2010 at 1:37 PM, Thomas Schulz  wrote:
>>
>> At Tue, 28 Dec 2010 15:50:23 -0500 (EST), Thomas Schulz wrote:
>> >
>> > It looks like I am a little dim today. Given gpg and the key, what steps
>> > do I do to verify a source package?
>>
>> General case:
>>
>> $ gpg --verify sigfile tarball
>>
>> Eg:
>>
>> $ gpg --verify bind-9.7.2-P3.tar.gz.sha256.asc bind-9.7.2-P3.tar.gz
>>
>> We probably should add this to the aforementioned web page.
>
> It looks like I have to somehow make the public key available. When I
> issue the above command I get:
>
> gpg: Can't check signature: public key not found
>

Before checking the signature, you need to import ISC's public key
into your key ring.  Something like this will work:

curl https://www.isc.org/files/pgpkey2009.txt | gpg --import

Then you can run gpg --verify.

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

Re: Does anyone know where to find the ISC signing keys for source packages?

[Casey Deccio]

On Thu, Dec 23, 2010 at 12:49 PM, Oisin McGuinness  wrote:
> I'm getting a new version of Bind to build etc.
>
> The download pages come with references to signatures (asc, and others).
>
> But I can't find any reference to current PGP or other signing keys; does
> anyone know where to find
> them on the www.isc.org web site or where to obtain them otherwise?
>

http://www.isc.org/about/openpgp

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

Re: US DNSSEC Key

[Casey Deccio]

On Wed, Dec 1, 2010 at 7:36 AM, John Williams  wrote:
> I'm being told there is an RSA verification failure on the .US domain.  I''m
> getting details from the following;  http://dnsviz.net/d/us/dnssec/  I have a
> signed zone under us.  How does this affect my domain and other signed zones
> under .US?
>

It shouldn't affect things, as it is currently configured, since the
invalid signature is not a necessary link in the chain of trust.  The
SEP key (id=2058) matching the DS RRs properly authenticates the
DNSKEY RRset, so the signature covering the DNSKEY RRset made by key
23777 is irrelevant.

However, the fact that the signature is invalid might raise some
eyebrows, as it might be a symptom of something else that may cause
errors in the future.  The .us support is probably the right group to
ask about it.

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

Re: error (broken trust chain) resolving

[Casey Deccio]

On Mon, Nov 22, 2010 at 5:28 AM, Brian J. Murrell  wrote:
> Casey Deccio  deccio.net> writes:
>>
>> After a review of NSEC3 showed that this particular behavior is
>> expected because org has been signed using NSEC3 with the opt-out bit
>> set.
>
> I'm afraid I'm getting a bit lost due to my real lack of understanding of the
> details of DNSSEC.  I wish I had the time to really sit down and understand 
> the
> concepts in complete detail.  :-(
>
> So does the RFC reference just explain why the AD bit (i.e. and not the bigger
> problem of the spew of log entries from named) is not set

yes, I was clarifying that my particular observation with respect to
the AD bit was not a useful insight into troubleshooting the other
issues.

> or does that explain
> the entire problem I am seeing (namely the continuous log spew from named)?
>

I still don't have the answer to this.  Perhaps a BIND developer may
have better insight into the log messages and what may be going on.

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

Re: error (broken trust chain) resolving

[Casey Deccio]

On Mon, Nov 15, 2010 at 6:31 AM, Casey Deccio  wrote:
>
> Well, I'm curious as to why you're not getting the AD bit set for the
> negative proof of existence for bondedsender.org/DS.

After a review of NSEC3 showed that this particular behavior is
expected because org has been signed using NSEC3 with the opt-out bit
set.  RFC 5155, section 9.2:

http://tools.ietf.org/html/rfc5155#section-9.2

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

Re: error (broken trust chain) resolving

[Casey Deccio]

On Mon, Nov 15, 2010 at 6:31 AM, Casey Deccio  wrote:
> On Mon, Nov 15, 2010 at 3:36 AM, Brian J. Murrell  
> wrote:
>>
>> Was any of that information I posted in the previous message useful?  If not,
>> I'd be happy to gather some more.
>>
>
> Well, I'm curious as to why you're not getting the AD bit set for the
> negative proof of existence for bondedsender.org/DS.  What happens if
> you disable DLV and run the DS query again?

I just realized that your debugging output involving DLV lookups is
related to a different query and shouldn't affect the result of
bondedsender.org/DS.  However, querying the original TXT RR with DLV
disabled might also give more insight.

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

Re: error (broken trust chain) resolving

[Casey Deccio]

On Mon, Nov 15, 2010 at 3:36 AM, Brian J. Murrell  wrote:
>
> Was any of that information I posted in the previous message useful?  If not,
> I'd be happy to gather some more.
>

Well, I'm curious as to why you're not getting the AD bit set for the
negative proof of existence for bondedsender.org/DS.  What happens if
you disable DLV and run the DS query again?

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

Re: error (broken trust chain) resolving

[Casey Deccio]

On Tue, Nov 9, 2010 at 8:10 PM, Brian J. Murrell  wrote:
> The only written to that file when one of those broken chain lookups happen 
> is:
>
> dnssec: validating @0x2295e9b0: 41.70.55.206.sa-trusted.bondedsender.org TXT:
> starting
> dnssec: validating @0x2295e9b0: 41.70.55.206.sa-trusted.bondedsender.org TXT:
> attempting negative response validation
> dnssec: validator @0x2295e9b0: dns_validator_destroy
>
> The dig query that produced that:
>
> $ dig @linux -p 1053 41.70.55.206.sa-trusted.bondedsender.org txt
>

What happens when you run the following queries:

dig +dnssec @linux -p 1053 org SOA

Do you get a NOERROR response with the AD bit set?

dig +dnssec @linux -p 1053 bondedsender.org DS

Do you get a NOERROR response with AD bit set and NSEC3 RRs and their
covering RRSIGs?

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

Re: error (broken trust chain) resolving

[Casey Deccio]

On Wed, Nov 3, 2010 at 4:44 AM, Brian J. Murrell  wrote:
> Casey Deccio  deccio.net> writes:
>>
>> However, a broken chain means that the validating resolver expects a
>> chain to exist, but the chain does not extend properly.
>
> How does a resolver come to this expectation?  What is happening that makes
> this situation any different than an insecure delegation?  If we take one of
> the examples from my original post:
>

This can happen in a number of different ways:  If any RRSIGs in the
chain of trust are bogus, expired, or missing.  If NSEC/NSEC3 records
are not provided or are insufficient to prove that no DS records exist
for an insecure delegation.  If DS RRs do exist, but none correspond
to any self-signing DNSKEYs in the child zone.  If DNSKEYs are not
returned by the resolver.

> named error (broken trust chain) resolving '133.168.163.66.sa-
> trusted.bondedsender.org/TXT/IN': 173.45.100.146#53
>
> Where/why does it break?  Who's is breaking it?  I can see that org. is rife
> with DNSSEC data but that bondedsender.org. is completely void of it.  But
> surely that would be the case of a plain insecure delegation, yes?
>

Yes, bondedsender.org is an insecure delegation.

Reproducing these errors and analyzing the debug-level log messages
would be helpful since everything looks consistent from a DNSSEC
perspective, as far as I can see.

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

Re: error (broken trust chain) resolving

[Casey Deccio]

On Tue, Nov 2, 2010 at 10:21 AM, Brian J. Murrell  wrote:
> Alan Clegg  isc.org> writes:
>>
>> On 11/2/2010 8:11 AM, Brian J. Murrell wrote:
>> >
>> > named error (broken trust chain) resolving '133.168.163.66.sa-
>> > trusted.bondedsender.org/TXT/IN': 173.45.100.146#53
>
>> There isn't a chain of signed DS records that lead from a trust anchor
>> to the thing that you are trying to resolve.
>
> So basically it just means that one or more zones from . down to the thing I'm
> trying to resolve has not been DNSSECized?  i.e. no zone keys, signing, etc.?
>

There is a difference between a "broken" trust chain and a trust chain
that securely "ends" before reaching the name being queried.  The
latter is referred to as an insecure delegation, and, as you suggest,
will be pervasive while DNSSEC deployment grows.  The result is an
answer that simply cannot be verified because there is provably no
path for validation.  Such is treated by the resolver as "insecure".

However, a broken chain means that the validating resolver expects a
chain to exist, but the chain does not extend properly.  This could be
because of expired signatures, missing DNSKEYs, etc.  This results in
SERVFAIL.

I'm assuming the error above refers to a broken chain, but it's hard
to tell why without looking at the context, including cache contents
at the time of the failure, etc.  The DNSSEC configuration (resulting
in insecure answer) looks okay from my perspective.  Is the error
persistent or was it a one-time deal?

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

Re: Key ID from DNSKEY - how?

[Casey Deccio]

On Wed, Oct 27, 2010 at 10:46 AM, Mark Elkins  wrote:
> I would like to calculate the Key-ID from a DNSKEY record. I'd prefer to
> do this in PHP as this is inside some existing PHP (Web) scripts but I
> guess calling a C program would not be too inconvenient.
>

See RFC 4034, Appendix B (http://tools.ietf.org/html/rfc4034#appendix-B )

> I'd like to index records (ie DNSKEY and DS Records) according to their
> Key-ID - and present them grouped by Key-ID. DS keys are usually
> presented with their Key-ID - so are less problematic.

The key tag field in a DS RR is the key tag value computed from the
DNSKEY RR to which it corresponds in the child zone.

>        Side issue - the RFC description for a DS Record on the wire
>        gives the first 16 bytes as the Key-ID, followed by (8-bit)
>        Algorithm, (8-bit) Digest type and (32 bytes - or so) Digest. Is
>        all this info encoded into the Base-64 stuff that one can see as
>        ascii in a zone? ... or is the base-64 ascii stuff just the
>        Digest?
>

See below for explanation of the following queries:

$ dig +short org ds
21366 7 2 96EEB2FFD9B00CD4694E78278B5EFDAB0A80446567B69F634DA078F0 D90F01BA

$ dig +noall +answer +multi org dnskey
;; Truncated, retrying in TCP mode.
org.383 IN DNSKEY 257 3 7 (
AwEAAZTjbIO5kIpxWUtyXc8avsKyHIIZ+LjC2Dv8naO+
Tz6X2fqzDC1bdq7HlZwtkaqTkMVVJ+8gE9FIreGJ4c8G
1GdbjQgbP1OyYIG7OHTc4hv5T2NlyWr6k6QFz98Q4zwF
IGTFVvwBhmrMDYsOTtXakK6QwHovA1+83BsUACxlidpw
B0hQacbD6x+I2RCDzYuTzj64Jv0/9XsX6AYV3ebcgn4h
L1jIR2eJYyXlrAoWxdzxcW//5yeL5RVWuhRxejmnSVnC
uxkfS4AQ485KH2tpdbWcCopLJZs6tw8q3jWcpTGzdh/v
3xdYfNpQNcPImFlxAun3BtORPA2r8ti6MNoJEHU=
) ; key id = 9795
org.383 IN DNSKEY 256 3 7 (
AwEAAa1gQwarOzgSbmhYj2eRUf/1RcHuAed0zlnAmqJY
ELF6iUGfPNSBfD0QDilro3Dxc307zVONrTK7qnWtaHXH
NDFVbB3+qDs1E+9tUjfKt9OuFQBQuGSlVvnM7O5ASbxs
Ex/8ms3mQFDCt4nTUmcELQGVE/EwLcDjxAUAmYBW9bQN
) ; key id = 61598
org.383 IN DNSKEY 256 3 7 (
AwEAAfyGacR9k8f85+1XqM6qLTLwdAEQDHUJJbScMrqq
XesZN6GFZDqn4zahg2GllxlHbGMuQJsWXSotq2Jp1Khe
/fp1547v0k2jnOaFv/18wLBmUGSQNNTWpBgp8Yzu8BOw
18kHmbXpQeju2mk6bHgiL7HkJfFoV1nsSTh15q92d5IR
) ; key id = 245
org.383 IN DNSKEY 257 3 7 (
AwEAAYpYfj3aaRzzkxWQqMdl7YExY81NdYSv+qayuZDo
dnZ9IMh0bwMcYaVUdzNAbVeJ8gd6jq1sR3VvP/SR36mm
GssbV4Udl5ORDtqiZP2TDNDHxEnKKTX+jWfytZeT7d3A
bSzBKC0v7uZrM6M2eoJnl6id66rEUmQC2p9DrrDg9F6t
XC9CD/zC7/y+BNNpiOdnM5DXk7HhZm7ra9E7ltL13h2m
x7kEgU8e6npJlCoXjraIBgUDthYs48W/sdTDLu7N59rj
CG+bpil+c8oZ9f7NR3qmSTpTP1m86RqUQnVErifrH8Kj
DqL+3wzUdF5ACkYwt1XhPVPU+wSIlzbaAQN49PU=
) ; key id = 21366

The first value in the DS RR (21366) is the 16-bit key tag value
computed from the org DNSKEY last in the list below. The second value
(7) corresponds to the algorithm of this DNSKEY RR.  The last field is
the hex representation of the SHA-256 digest (designated by value "2"
in the digest algorithm field of the DS RR) of DNSKEY RR 21366.

>        I'd love to be able to validate both DS and DNSKEY records that
>        people give me but I am still floundering around amongst the
>        DNSSEC RFC's...
>
> I understand that key-ID's are not necessarily unique but as I'd usually
> not have more than about 4 or so in any one domain - I'm hoping that
> statistics will be with me 99.95% of the time.
>

>From RFC 4034, section 8:
   The key tag is used to help select DNSKEY resource records
   efficiently, but it does not uniquely identify a single DNSKEY
   resource record.  It is possible for two distinct DNSKEY RRs to have
   the same owner name, the same algorithm type, and the same key tag.
   An implementation that uses only the key tag to select a DNSKEY RR
   might select the wrong public key in some circumstances.  Please see
   Appendix B for further details.

> Anyway - does anyone have existing code snippets that might assist me?

See the code snippet in the RFC for starters.

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

Re: Trouble with host and DNSSEC

[Casey Deccio]

On Wed, Sep 15, 2010 at 7:34 AM, Timothy Holtzen  wrote:
>  I am having trouble resolving the host name cod.ed.gov which I believe
> may be dnssec related

...

> in my logs I am getting the messages:
>
> validating @0x2ab727eb5810: cod.ed.gov A: got insecure response; parent
> indicates it should be secure
> dnssec: info: validating @0x2ab727eb5810: cod.ed.gov A: got insecure
> response; parent indicates it should be secure
> error (insecurity proof failed) resolving 'cod.ed.gov/A/IN': 63.150.74.34#53
>

There are DS RRs for cod.ed.gov in the parent zone (ed.gov),
indicating that cod.ed.gov should be signed with a DNSKEY
corresponding to the existing DS RR.  However, cod.ed.gov is not
signed, particularly not with the DNSKEY corresponding to the DS RR,
which DNSKEY doesn't seem to exist in the zone at all.
http://dnsviz.net/d/cod.ed.gov/dnssec/

To remedy the issue, the ed.gov administrators should remove the DS RR
for cod.ed.gov from the ed.gov zone, which will make cod.ed.gov an
insecure delegation (meaning that it can continue to be unsigned).  If
desired, the zone can then be resigned, and the appropriate DS RRs
added to the parent.

I can send them a note off-list.

Regards,
Casey
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: How do I do a zone transfer of two different views

[Casey Deccio]

On Fri, Aug 27, 2010 at 11:22 PM, Scott Simpson
 wrote:
> I have a master DNS server with two different views: "internal" and
> "external". How do I do a zone transfer of the two different views? The
> following on the slave only grabs the internal view:
>

Use two TSIG keys, one for each view, to request the data.  This will
both to distinguish which view you want as well as authenticate the
transfer.  See the following for an example:

http://www.isc.org/software/bind/faq
(search for "slave server for both an internal and an external view")

Regards,
Casey
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: RRSIGs without DNSKEYs in insecure zone

[Casey Deccio]

On Wed, Aug 18, 2010 at 4:33 PM, Paul Wouters  wrote:

> On Wed, 18 Aug 2010, Casey Deccio wrote:
>
>  Using BIND 9.6.2-P2 and 9.7.1.P2 configured for DNSSEC validation with DLV
>> I experience the following issue.  When I
>> attempt to resolve www.jobcorps.gov I get a SERVFAIL message.  The
>> authoritative servers return an RRSIG covering the
>> A RR, but the resolver is unable to validate it because it cannot retrieve
>> the DNSKEYs.  The servers are attempting to
>> send packets exceeding their PMTU and they apparently don't accept TCP
>> connections, which means that a resolver can't
>> get a complete response for DNSKEYs.
>>
>> Despite the server misconfigurations, the delegation from .GOV is
>> insecure, so ultimately the result should return a
>> insecure data, rather than failure.  Thoughts?
>>
>
> If the domain is in the DLV, then it is treated as having a secure entry
> point just as if the parent had a DS record, and any missing DNSKEY's
> is considered a downgrade attack to lure you into spoofed faked data.
>
>
True, but only .GOV is registered in the DLV, jobcorps.gov is not.

Incidentally, unbound returns an insecure response for this.

Regards,
Casey
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RRSIGs without DNSKEYs in insecure zone

[Casey Deccio]

Using BIND 9.6.2-P2 and 9.7.1.P2 configured for DNSSEC validation with DLV I
experience the following issue.  When I attempt to resolve
www.jobcorps.govI get a SERVFAIL message.  The authoritative servers
return an RRSIG
covering the A RR, but the resolver is unable to validate it because it
cannot retrieve the DNSKEYs.  The servers are attempting to send packets
exceeding their PMTU and they apparently don't accept TCP connections, which
means that a resolver can't get a complete response for DNSKEYs.

Despite the server misconfigurations, the delegation from .GOV is insecure,
so ultimately the result should return a insecure data, rather than
failure.  Thoughts?

Regards,
Casey
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: www.ncbi.nlm.nih.gov / pubmed

[Casey Deccio]

On Wed, Aug 18, 2010 at 10:55 AM, Dave Sparro  wrote:
> It seems to me that the OP wanted a work-around to the fact that his end
> users couldn't use the website due to a validation failure.
> It still seems to me that working around that situation misses the point of
> using DNSSEC.
>

I read your response only in the context of the quoted text and didn't
notice the text from the original post asking if there was a BIND
work-around.  Hence my lengthy discourse on insecure delegation...

Regarding the "work-around", I'm not sure how BIND's "keep trying"
algorithm is currently implemented and if it induces queries to other
servers to find NSEC/NSEC3 RRs if they aren't present in the first
response accompanying an NXDOMAIN or authoritative response with empty
answer section.

Regards,
Casey
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: www.ncbi.nlm.nih.gov / pubmed

[Casey Deccio]

On Wed, Aug 18, 2010 at 9:48 AM, Dave Sparro  wrote:
> On 8/18/2010 8:30 AM, Phil Mayers wrote:
>>
>> ...since the "ncbi" zone is an unsigned child zone, there needs to be an
>> NSEC/NSEC3 record to prove the absence of the DS record, and have a
>> secure delegation to an unsigned child zone.
>
>
> It sounds to me like DNSSEC validation is working as designed.  If your DNS
> server's users are complaining about not being able to resolve something
> that fails validation, the question you need to ask is do your end-users
> really want you to do DNSSEC validation for them?
>
> If you're asking for a workaround for when validation fails, there's not
> much point to doing the validation.
>

Insecure delegations are not a work-around, but are rather a provision
for delegated child zones that have not implemented DNSSEC.  The
parent zone (and its authoritative servers) must be properly
configured to handle authenticated denial of existence using NSEC or
NSEC3.  Specifically, they must use these RRs to prove the
non-existence of a DS RR for an unsigned child zone, whose existence
would otherwise indicate a secure delegation.  If the proper
NSEC/NSEC3 RRs are not returned, or are not thought to be authentic,
then there is a broken chain because the resolver cannot prove that
the delegation is insecure.  In the following diagram, note the
diamond-shaped NSEC3 node, whose presence (when properly
authenticated) proves the insecure delegation to ncbi.nlm.nih.gov:
http://dnsviz.net/d/www.ncbi.nlm.nih.gov/dnssec/

Regards,
Casey
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: www.ncbi.nlm.nih.gov / pubmed

[Casey Deccio]

On Wed, Aug 18, 2010 at 5:30 AM, Phil Mayers  wrote:
>
> After a bit of investigation, it seems that the problem is a missing
> NSEC/NSEC3 record in the empty reply for:
>
> $ dig +dnssec @165.112.4.230 ncbi.nlm.nih.gov ds
>
> ...since the "ncbi" zone is an unsigned child zone, there needs to be an
> NSEC/NSEC3 record to prove the absence of the DS record, and have a secure
> delegation to an unsigned child zone.
>

The problem was that three out of the five servers authoritative for
nlm.nih.gov were serving a version of the zone that did not include
DNSKEY RRs or any other DNSSEC-required RRs (RRSIG, NSEC3, etc).  If
your resolver queried any of those three it got a response, but it was
incomplete.

This has been a fairly common problem among new DNSSEC deployments.
Sometimes the problem is a slave that is not DNSSEC capable.
Sometimes it's a slave not NSEC3-capable serving a zone signed with
NSEC3 (which creates the issue for insecure delegations).  In this
case, I'm pretty sure the servers are capable of DNSSEC because they
are serving the signed nih.gov zone just fine, so perhaps they got
their nlm.nih.gov zone data from the wrong place.

Often, BIND users don't notice these types of errors because BIND
makes a special effort to find a valid response, if validation is
enabled.  However, if your validating server is behind an upstream
proxy DNS recursive server, you may not have that choice.  Likewise, a
zone may not have the redundancy administrators think it has if you're
only getting valid DNSSEC responses from a fraction of your
authoritative servers.

Regards,
Casey
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Script for verifying zone files

[Casey Deccio]

On Thu, Jul 22, 2010 at 10:01 AM, Atkins, Brian (GD/VA-NSOC)
 wrote:
>
> Several people suggested looking at named-checkzone, but my goal is to 
> compare an edited version of the zone file against the active zone file.
>

If you're just looking at changes, try something like:

named-checkzone -D -o zone1-canonical.txt example.com zone1.txt
named-checkzone -D -o zone2-canonical.txt example.com zone2.txt
diff -u zone{1,2}-canonical.txt

>
> The named-checkzone program, to my understanding, merely checks for syntax 
> and doesn't do anything with actual verification of the records.
>

>From 'man named-checkzone':

"[named-checkzone] performs the same checks as named does when loading
a zone [named-compilezone] applies stricter check levels by
default, since the dump output will be used as an actual zone file
loaded by named."

See options in the man page for checks that are done by default (e.g.,
-i, -k, -m, etc.)

Regards,
Casey
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: ad flag for RRSIG queries

[Casey Deccio]

I think the issue here is that the authenticity of an RRSIG RR doesn't
really make sense without the RRset it covers, and RRSIG themselves
are not signed (RFC 4035 section 2.2).  The RRSIGs returned by the
cache are there initially because they exist (as well as the RRsets
they cover), but not because the RRsets they cover have necessarily
been validated.   I believe that the BIND resolver sets the AD bit if
the RRset it covers has been validated (not simply exists in cache),
even though it technically is undefined.

Now some guesswork to explain the behavior... From a clean cache, I
make the following query:

$ dig +dnssec forfunsec.org rrsig

This returns two RRSIG RRs--one covering NS and one covering DS, and
not AD bit.  (Note that there are other RRSIGs returned if you query
the authoritative server directly, but because the RRsets they cover
aren't yet in cache, they are discarded [see RFC 4035 section 4.5]).

Next I query the following, which validates the DS RRset for forfunsec.org:

$ dig +dnssec forfunsec.org ds

Then re-try the RRSIG query:

$ dig +dnssec forfunsec.org rrsig

Same result as before--two RRSIG RRs and no AD bit because the NS
RRset is not yet validated.  Now I validate the NS RRset:

$ dig +dnssec forfunsec.org ns

Then re-try the RRSIG query:

$ dig +dnssec forfunsec.org rrsig

Now the cache contains three RRSIGs (the DNSKEY RRset had to be
validated to validate the NS RRset), and the RRsets covered by each
has been validated, so BIND sets the AD bit.  Of course, these RRSIGs
are not really an "RRset", nor are they authenticated, but the data
they cover is at this point.

Regards,
Casey
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: +, -, -E

[Casey Deccio]

On Mon, Jun 21, 2010 at 11:46 AM, Peter Laws  wrote:
> What do they mean?  I can't find them and yes, I've googled and also grepped
> the docs on isc.org ...
>
> I'm assuming it's some way of telling if the query was serviced or not ...
>

Hi Peter,

The following is from the section titled "logging Statement Definition
and Usage" in the BIND Configuration Reference [1]:

"The query log entry reports the client's IP address and port number,
and the query name, class and type. It also reports whether the
Recursion Desired flag was set (+ if set, - if not set), if the query
was signed (S), EDNS was in use (E), if DO (DNSSEC Ok) was set (D), or
if CD (Checking Disabled) was set (C).

client 127.0.0.1#62536: query: www.example.com IN  +SE
client ::1#62537: query: www.example.net IN  -SE"

Hope that helps.

Regards,
Casey

[1] http://ftp.isc.org/www/bind/arm95/Bv9ARM.ch06.html#id2575152
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: nsupdate, dnssec, minimum ttl

[Casey Deccio]

 On Thu, Jun 17, 2010 at 12:10 PM, Eric Ham  wrote:
>
> It would appear that the NSEC and RRSIG NSEC TTLs are set to my example.com 
> zone's minimum TTL which is 86400 instead of inheriting the TTL I set of 7200.
>

>From RFC 4034 (section 4):

   The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
   field.  This is in the spirit of negative caching ([RFC 2308]).

Regards,
Casey
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind 9.7, dnssec and multiple key directories and resalt NSEC3

[Casey Deccio]

On Fri, Jun 4, 2010 at 9:10 AM, Evan Hunt  wrote:

> The way it's supposed to work is: you add the new NSEC3PARAM record,
> then wait for the new NSEC3 chain to be built.  The newly inserted record
> will, at first, have its "flags" field set to a nonzero value; this
> indicates that the chain isn't complete yet.  When the server is finished
> building the chain, it updates the newly-added NSEC3PARAM record, and
> zeroes the flags field.  At that point, it's safe to remove the old
> NSEC3PARAM record, which will cause the server to remove the old NSEC3
> chain.
>
>
This is a much more elegant solution... :)

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

Re: bind 9.7, dnssec and multiple key directories and resalt NSEC3

[Casey Deccio]

On Fri, Jun 4, 2010 at 3:11 AM, Tim Verhoeven wrote:

>
> The second question. I've tried doing a resalt using dynamic updates
> but I can't get it to work. Just adding a new NSEC3PARAM RR crashes
> Bind and doing a delete and then a add (to replace the present RR)
> gives me a servfail but I see the updats in the log.
> What is the correct way to do a resalt when using automatic signing ?
>
>
This should work:

rndc freeze
dnssec-signzone ... # using same keys but with new NSEC3 salt
rndc reload
rndc thaw

Although, at least in earlier versions of BIND, if not all RRsets in the
zone are resigned with the resign (i.e., within "interval" specified with
-i), then the NSEC3 chain with the new salt is added to any existing NSEC3
chains.   There shouldn't be any ill effects from this, but it does increase
the size of the zone some.

Regards,
Casey
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC / DLV for 2001:8b0:151:1:e2cb:4eff:fe26:6481

[Casey Deccio]

On Wed, Jun 2, 2010 at 7:44 AM, Chris Thompson  wrote:

> On Jun 2 2010, Matthew Seaman wrote:
>
>  I'm DNSSEC enabling the .ip6.arpa zone for my IPv6 allocation and
>> registering it with dlv.isc.org.  Using bind-9.7.0-p2 dnssec tools.
>>
>> Everything seems to be working well, but when I test using the Sandia
>> Labs dnsviz.net tool I get inconsistent results.
>>
>> My mail, etc. server on 2001:8b0:151:1:e2cb:4eff:fe26:6481 appears as
>> 'bogus'
>>
>>
>> http://dnsviz.net/d/1.8.4.6.6.2.e.f.f.f.e.4.b.c.2.e.1.0.0.0.1.5.1.0.0.b.8.0.1.0.0.2.ip6.arpa/dnssec/
>>
>> Yet my personal laptop on 2001:8b0:151:1:fa1e:dfff:feda:c0bb is all good:
>>
>>
>> http://dnsviz.net/d/b.b.0.c.a.d.e.f.f.f.f.d.e.1.a.f.1.0.0.0.1.5.1.0.0.b.8.0.1.0.0.2.ip6.arpa/dnssec/
>>
>> What am I doing wrong?
>>
>
> Nothing that I can see. Maybe dnsviz can't cope with multiple PTR
> records in an RRset, as your first case has? (On the other hand it
> handles multiple A records in forward zones OK.)
>
>
This has been fixed.  The problem had to do with establishing a canonical
ordering of RRs within an RRset for the purposes of verifying an RRSIG.
dnspython's default comparison operators don't follow canonical ordering
from RFC 4034, so I had to make some provisions to order properly.  This
didn't affect A RRsets with multiple RRs because the order of A-type rdata
was the same using both orderings.

Thanks for bringing this to my attention.

Regards,
Casey
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC / DLV for 2001:8b0:151:1:e2cb:4eff:fe26:6481

[Casey Deccio]

On Wed, Jun 2, 2010 at 8:40 AM, Paul Vixie  wrote:

> Chris Thompson  writes:
>
> > Nothing that I can see. Maybe dnsviz can't cope with multiple PTR
> > records in an RRset, as your first case has? (On the other hand it
> > handles multiple A records in forward zones OK.)
>
> to be fair, multiple PTR RRs is something we added in BIND gethostbyaddr()
> in more or less direct contravention to RFC 1034. if dnsviz doesn't handle
> it (and i don't know if it doesn't) then it's not dnsviz's fault at all
> since the DNS RFC's say that there will only be one PTR RR at an in-addr.
>

Not to take this off topic, but RFC 2181 (sec 10.2) clarifies that a PTR
RRset *may* have multiple RRs, but each must point to a canonical name, as
opposed to an alias.

That being said, DNSViz is intended to consider multiple RRs in the PTR
RRset, but I'm still trying to track down the issue that is causing it to
report a bogus signature.  I'll report back when I have an answer.

Regards,
Casey
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC Status...

[Casey Deccio]

On Tue, Jun 1, 2010 at 6:55 AM, Heavy Man  wrote:

> A few questions about DNSSEC...
>
> I understand the root zones are currently getting signed.


The root zone is currently signed with a DURZ (deliberately unvalidatable
root zone) as part of its deployment.  See the following site for more
information:  http://www.root-dnssec.org/

Just for sanity sake, should I be able to DIG +dnssec a.gtld-servers.net and
> be able to see a RRSIG record (assume I have a valid dnssec recursive name
> server with a valid trust anchor configured).


(As a side note, gtld-servers.net is the domain corresponding to the names
of servers authoritative for TLD servers (e.g., edu, com, net), not the root
zone.)

There is a difference between the name of a zone and the names of the
servers authoritative for that zone, which are the "targets" of the NS
records.  For example:

$ dig . ns

; <<>> DiG 9.7.0-P1 <<>> . ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63188
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;.INNS

;; ANSWER SECTION:
.484118INNSd.root-servers.net.
.484118INNSl.root-servers.net.
.484118INNSi.root-servers.net.
.484118INNSh.root-servers.net.
.484118INNSe.root-servers.net.
.484118INNSj.root-servers.net.
.484118INNSm.root-servers.net.
.484118INNSg.root-servers.net.
.484118INNSa.root-servers.net.
.484118INNSf.root-servers.net.
.484118INNSc.root-servers.net.
.484118INNSk.root-servers.net.
.484118INNSb.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.144120INA198.41.0.4

The zone origin is ".", but the names of the authoritative server are [a-m].
root-servers.net.  In DNSSEC, signing is done on a per-zone basis, so the
signing of the root-servers.net zone is independent of (and unnecessary for)
the signing of the root zone (".").

This being said, if you now query the root servers for DNSSEC RRs pertaining
to the root zone, you will get the following:

$ dig @a.root-servers.net +dnssec . ns

; <<>> DiG 9.7.0-P1 <<>> @a.root-servers.net +dnssec . ns
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8463
;; flags: qr aa rd; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 21
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;.INNS

;; ANSWER SECTION:
.518400INNSa.root-servers.net.
.518400INNSh.root-servers.net.
.518400INNSj.root-servers.net.
.518400INNSm.root-servers.net.
.518400INNSg.root-servers.net.
.518400INNSe.root-servers.net.
.518400INNSk.root-servers.net.
.518400INNSd.root-servers.net.
.518400INNSc.root-servers.net.
.518400INNSi.root-servers.net.
.518400INNSb.root-servers.net.
.518400INNSl.root-servers.net.
.518400INNSf.root-servers.net.
.518400INRRSIGNS 8 0 518400 2010060707
2010053106 55138 .
xJyVQ+6RhZ7OQZFqFBY+z6xTeLWk7GpGljhp2zmkXVkK1bB3x0DZsdwA
MF7+pyXa3hkUvbG4+MBErWmhiJveV/DyU00kZXrWc8oma82uhLvgBjwf
/q7JArynxkbhrsbFoHT0IBQe9mQBhfJAta9myUEc01EGDVWwvpATMTTM Ktc=

which includes the RRSIG covering the NS RRset for the root zone.

Regards,
Casey
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Automated DNSSEC (command line)

[Casey Deccio]

On Fri, May 28, 2010 at 2:18 PM, Michelle Konzack <
linux4miche...@tamay-dogan.net> wrote:

> Hello DNSSEC Experts,
>
> I am ongoing to install 4 new Name Servers and increse my registrar  and
> hosting service...
>
> OK, I have tried to make my own 4 domains with 16 zones  signed  and  it
> took me one hour of my life!
>
> Since I have to re-sign the zones if something change it  will  give  me
> headaches up to the end of my life, so my queston is:
>
>Is there a command line tool (or a daemon) which
>check for changes and re-sign the zone automated?
>
>
Yes, and you really should use one.  The two most important things with
signed zones are that your signatures don't expire, and that the right
DNSSEC RRs are included in the zone.  So not only does it need to be
resigned after changes (to include the proper DNSSEC RRs), but also
periodically make sure signatures don't expire.  Here are a few of the tools
written for that purpose:

http://dnssec-tools.org/
http://www.opendnssec.org/
http://www.hznet.de/dns/zkt/
http://zonetool.sourceforge.net/


> I can not believe, that you are signing each zone by hand!  :-D
>
> Can an expert please check  'dig ANY tamay-dogan.net'  whether  this  is
> right?
>
>
Looks okay to me.  Here's what your signed zone looks like visually:

http://dnsviz.net/d/tamay-dogan.net/dnssec/

Although, it looks like you perhaps didn't increment the zone serial, as
only one of your authoritative servers is running a signed version of the
zone.

Also I am not realy sure whether I need  "dnssec-validation yes"  in  my
> "options".
>
>
No, this is only for resolvers that are validating answers, not
authoritative servers that are serving signed zones.

Of course, if you're using the server for both and you would like to enable
validation (i.e., of other signed zones), then you'll need to enable
validation and establish some trusted keys as anchors.

Regards,
Casey
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec-keygen is waiting endless...

[Casey Deccio]

On Fri, May 28, 2010 at 11:25 AM, Michelle Konzack <
linux4miche...@tamay-dogan.net> wrote:

>
> Currently I need to secure my bind9 since I had a massive attack  on  my
>  which is the master. Also I have had more then 30 million queries
> in less then one week and bind9 has eaten arround 2.4 GByte of memory...
>
>
DNSSEC is for securing your namespace, not your server. With DNSSEC a
validating resolver can prove the authenticity of an answer it receives, but
that won't help with attacks targeting your name server.

If you're looking to secure your server, you'll need to take other security
measures with regards to server/firewall configuration.

Regards,
Casey
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec-keygen is waiting endless...

[Casey Deccio]

On Fri, May 28, 2010 at 10:41 AM, Michelle Konzack <
linux4miche...@tamay-dogan.net> wrote:

> Hello Paul,
>
> Am 2010-05-28 12:34:16, hacktest Du folgendes herunter:
> > My bet is that this is a VM and you have no entropy. Either generate some
> > entropy (eg run in paralel something like: find / -type f | xargs grep
> KSdgajkgdaksdga)
> > or create the keys on real iron instead of a VM.
>
> No, this a real machine:AMD Sempron 2200+ (Socket A) with 3 GByte of
> memory and only standard Debian in stallation. The thing with the "find"
> does not work...
>
>
Running 'cat /proc/sys/kernel/random/entropy_avail' should show you what
your available entropy is during the keygen process.

There are a variety of things you can do to increase the size of the entropy
pool, but if you're willing to accept less entropy at this point to get
things going, pass '-r /dev/urandom' to dnssec-keygen (see 'man urandom').

Regards,
Casey
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Resolving .gov w/dnssec

[Casey Deccio]

On Thu, Apr 22, 2010 at 4:25 PM, Michael Sinatra <
mich...@rancid.berkeley.edu> wrote:

> On 04/22/10 15:22, Casey Deccio wrote:
>
>  Actually, what seems interesting to me is that the cutoff seems to be at a
>> payload size of 1736, which happens to be the exact size of the complete
>> response.  Is this just coincidence?
>>
>
> Yes it is.  With the bufsize set to 1735, the response that will actually
> come back will be truncated on an RR boundary.
>

Ah, makes sense.  Thanks!

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

Re: Resolving .gov w/dnssec

[Casey Deccio]

On Thu, Apr 22, 2010 at 11:36 AM, Michael Sinatra <
mich...@rancid.berkeley.edu> wrote:

> But it doesn't contain the RRSIGs for the DNSKEY.  'dig +norec +cdflag
> dnskey uspto.gov @dns1.uspto.gov' does not contain RRSIGs so it is only
> 1131 bytes.  A non-EDNS0 query will receive the TC bit and will retry in
> TCP.  'dig +dnssec +norec dnskey uspto.gov @sns2.uspto.gov' has a response
> that includes the RRSIGs and is 1736 bytes, which on most ethernets will
> cause UDP fragmentation.  I get a timeout when using dig with +dnssec and
> without +vc.  However, 'dig +bufsize=1024 +dnssec +norec dnskey uspto.gov@
> dns1.uspto.gov' which sets an EDNS0 buffer size of 1024, does get a
> response, after retrying in TCP mode.
>
> In other words, uspto.gov's DNS servers and network are able to send
> responses longer than 512 bytes, but if the response is longer than 1500
> bytes, something in the network between those DNS servers and the rest of us
> is blocking the UDP fragments.
>
>
Actually, what seems interesting to me is that the cutoff seems to be at a
payload size of 1736, which happens to be the exact size of the complete
response.  Is this just coincidence?

$ dig +bufsize=1735 +dnssec @dns1.uspto.gov uspto.gov dnskey

;; Truncated, retrying in TCP mode.

$ dig +bufsize=1736 +dnssec @dns1.uspto.gov uspto.gov dnskey

; <<>> DiG 9.6.1-P3 <<>> +bufsize=1736 +dnssec @dns1.uspto.gov uspto.govdnskey
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

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

Re: Resolving .gov w/dnssec

[Casey Deccio]

On Thu, Apr 22, 2010 at 11:17 AM, Nate Itkin wrote:

>
> Not specifically, but I log a lot of errors resolving in usps.gov. USPS
> clearly has configuration issues.  A representative sample from my logs:
>
> 19-Apr-2010 11:04:23.072 lame-servers: no valid RRSIG resolving '
> EGQ1REIRR8NVE4U6I97RO3PC2CRUU1A5.usps.gov/DS/IN': 56.0.82.25#53
> 19-Apr-2010 11:04:24.099 lame-servers: no valid RRSIG resolving '
> samtcatwe0d3.usps.gov/DS/IN': 56.0.82.25#53
> 19-Apr-2010 11:04:24.890 lame-servers: no valid DS resolving '
> samtcatwe0d3.usps.gov//IN': 56.0.100.25#53
> 19-Apr-2010 11:04:27.975 lame-servers: no valid NSEC resolving '
> samtcatwe0d3.usps.gov/MX/IN': 56.0.100.25#53
>
>
The usps.gov servers are not returning all the appropriate RRSIGs to cover
the NSEC3 RRs returned for denial of existence.  This is consistent with all
their servers.

$ dig @dns100.usps.com +dnssec usps.gov 

; <<>> DiG 9.6.1-P3 <<>> @dns100.usps.com +dnssec usps.gov cname
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40506
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;usps.gov.  IN  CNAME

;; AUTHORITY SECTION:
usps.gov.   1800IN  SOA dns141.usps.com.
domainadmin.imail.usps.gov. 285717992 3600 1800 1209600 1800
usps.gov.   1800IN  RRSIG   SOA 7 2 3600 20100502025431
20100422015431 43133 usps.gov.
grQ5+JGDwezIsv2g5jAEXARLnW/leCieA/13Uxt8zZVZmUlozObsxHEo
r3NuB1cF9MOg1NppkJbwKswC4AFg1lT9RZ3hAVEvFL4clLzgFYUlEmpN
3hdqJ+1ZO05zramz9loaP1TWcJPSUtLosFQaD4OuJHimxCxmMk0Qnke5 EAs=
EGQ1REIRR8NVE4U6I97RO3PC2CRUU1A5.usps.gov. 1800 IN NSEC3 1 0 100 -
EHU10MMN93MNBII1G8R5MUSB0EKKKFPK NS SOA MX TXT RRSIG DNSKEY NSEC3PARAM
TYPE65534

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

salting NSEC3

[Casey Deccio]

Hello,

I'm trying to better understand NSEC3.  I have a signed zone for which
I periodically resign expiring RRs with expiring RRSIGs using
dnssec-signzone.  When I do so, I use a different salt each time,
which results in multiple salts being used in the zone.  According to
RFC 5155:
   This is harmless, since each RR stands
   alone (that is, it denies the set of owner names whose hashes, using
   the salt in the NSEC3 RR, fall between the two hashes in the NSEC3
   RR) -- it is only the server that needs a complete set of NSEC3 RRs
   with the same salt in order to be able to answer every possible
   query.

Also, according to RFC 5155:
   There MUST be at least one complete set of NSEC3 RRs for the zone
   using the same salt value.
and:
   If an NSEC3PARAM RR is present at the apex of a zone with a Flags
   field value of zero, then there MUST be an NSEC3 RR using the same
   hash algorithm, iterations, and salt parameters present at every
   hashed owner name in the zone.  That is, the zone MUST contain a
   complete set of NSEC3 RRs with the same hash algorithm, iterations,
   and salt parameters.

So from what I gather, each time a new salt (and therefore NSEC3PARAM)
is introduced to the mix, a new NSEC3 chain is generated, so given n
distinct owner names in the zone, there are n*(num NSEC3PARAM RRs)
NSEC3 RRs and covering RRSIGs.

I'm looking for a sanity check here.  Aside from the increase in zone
size, there shouldn't be any resolution/validation problems with this,
correct?  Is it more reasonable to use the same salt until the zone is
completely (i.e., all RRs) resigned?

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

Re: Server names for query

[Casey Deccio]

On Mon, Mar 23, 2009 at 3:20 PM, Kevin Darcy  wrote:
> For the *initial* NS query, I believe BIND will resolve those names down to
> a flat set of addresses, all of which have equal chance of being tried, so,
> yes, if a given NS name resolves to more addresses than other names, it is
> more likely to be tried on the initial NS query.
>
> But that's just the *initial* NS query. Once BIND, and/or virtually any
> other full-resolver implementation, builds up a history of how fast each
> nameserver responds (based on round-trip-time or RTT), it will start using
> nameservers which respond faster (although there is some "banding" that
> occurs, so that nameservers which respond more-or-less at the same speed get
> tried equally often). So if the point of your question is to try to control
> the distribution of query load to nameservers, be aware that this will be
> determined much more by the speed at which they respond, respectively, to
> clients, than to how the NS names are organized. Clients gravitate to faster
> servers. If the extra volume causes the fast servers to bog down and be
> slower, then clients gravitate away from them, and some sort of query-volume
> equilibrium is achieved between all of the nameservers which are published
> for the zone. In a sense, it is "auto-tuning" in this regard.
>

Thanks, Kevin.  My analysis is more based on collective queries (i.e.,
from clients in diverse geographical/network locations), rather than
from any particular client.  So the point of my question is
determining whether it would be expected that the *total* number of
queries from different clients for a given domain would be distributed
roughly proportional to the number of A records corresponding to each
NS target in the NS RR set for the domain.

The 'rndc dumpdb -cache' command seems pretty useful in looking at the
server stats on client server.  However, it organizes stats by name
(rather than by IP address), so it doesn't help clarify the issue in
the RFC.

Best regards,
Casey
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Server names for query

[Casey Deccio]

RFC 1035 [1] (page 44) describes the use of a list of server names (SLIST)
to query for a particular name.  It is unclear to me from the RFC as to
whether the server is selected by address or by name.  In other words, all
history (e.g., batting average and response time) being equal, if a name
resolves to two IP addresses, is it twice as likely to be used in resolution
for a name as that which resolves to only one--both according to the RFC,
and as implemented in BIND?  Example:

example.com. 3600 IN NS ns1.example.com.
example.com. 3600 IN NS ns2.example.com.
ns1.example.com. 3600 IN A 10.0.0.1
ns1.example.com. 3600 IN A 10.0.0.2
ns2.example.com. 3600 IN A 10.0.0.3

Best regards,
Casey

[1] http://tools.ietf.org/html/rfc1035
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users