Re: Sites that points their A Record to localhost

[Bill Owens]

On Tue, Jan 14, 2014 at 07:55:44PM -0500, Kevin Darcy wrote:
> If the domain owner *really* feels that they have to publish *some*
> address record for a particular name, but there is no available
> service at that name, then the null or "unspecified" address (IPv4 =
> 0.0.0.0, IPv6 = ::0) is the appropriate value to put there.
> 
> Loopback is anti-social; an apparent attempt to make the client
> waste resources connecting to itself. In legal terms, one might call
> this an "attractive nuisance".

You're quite right; that's why I have MX records for decades-old dead hostnames 
pointing to loopback, because the only queries for those names are from 
spammers and I'd very much like them to waste their time. But that's about the 
only reason I can think of to use it. . .

Bill.
___
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: Disable DNSSEC

[Bill Owens]

On Tue, Jan 07, 2014 at 04:34:27PM +, Eric Davis wrote:
> Duh...silly mistake...I did a DIG on the NS record..Once  the DS record is 
> removed DNS queries should work fine right? Thanks Bill.

Once the DS record is removed from the .edu zone, queriers won't expect your 
zone to be signed any more. At that point, you can leave it signed or remove 
the signatures, and it won't make any difference. You just need to wait at 
least 24 hours from the time the record disappears from the .edu zone.

Bill.
___
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: Disable DNSSEC

[Bill Owens]

On Tue, Jan 07, 2014 at 04:24:31PM +, Eric Davis wrote:
> So I guess my DS record has the same TTL as my default TTL for my records?  
> My default is 8 hours, so if I wait 8 hours after I remove the DS from my 
> parent zone then I should be ok?  My parent zone is a TLD(.edu).

The DS record is in the parent zone (.edu) and it has a one-day TTL:

;; AUTHORITY SECTION:
rockefeller.edu.172800  IN  NS  r2d2.rockefeller.edu.
rockefeller.edu.172800  IN  NS  rockyd.rockefeller.edu.
rockefeller.edu.86400   IN  DS  40486 5 1 
954F779D591F011288CAD43D64D96EA543E0D3E5
rockefeller.edu.86400   IN  RRSIG   DS 8 2 86400 20140113054536 
20140106043536 20750 edu. 
0XmRgd7FPG56t7etP2dK0W9gvVVm5oJlaCXufHlWnLsPWwNcAGIEQBCp 
RxBicOFdPgmxvm1VV+IXq7W2qEKiFOchCgfqm9ugqQ7/DOR0DJW1edgI 
ZqUVLfMgp/VT1+6EXU+wGiR7D2rZs1xvyu82cMQCkBseiKVAJv2F35LK MSE=

Bill.
___
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

[Bill Owens]

On Wed, Jul 17, 2013 at 09:49:18AM -0700, Ray Van Dolson wrote:
> Hello;
> 
> Running BIND 9.8.2 in RHEL6 (at the latest vendor provided version --
> bind-9.8.2-0.17.rc1) and trying to troubleshoot an issue resolving
> ic.fbi.gov that seems to be DNSSEC related.
> 
> Am fairly certain of this because if I set dnssec-enable and
> dnssec-validation to no (have them at 'yes' normally), resolution
> succeeds.
> 
> If I run a dig @nameserver ic.fbi.gov from a client machine, dig just
> hangs for a bit then eventually times out.  dig @nameserver fbi.gov
> works fine

This is one of the weirder ones I've seen. . . there are TXT and MX records for 
ic.fbi.gov, both correctly signed:

;; ANSWER SECTION:
ic.fbi.gov. 261 IN  RRSIG   MX 7 3 600 20131014154120 20130716154120 32497 
fbi.gov. kuorwabpVJ5QJqPhInJXhAQZgCSbB/xT6A7lkvoqJck5EBzn62UANtMk 
mYVcNNXXJUWPZATKbldsCbluos8NJyE33vdRft/I7+YRCgUsJ/ZFSmdR 
OknrSTQbc8M4YzvclEKVRuDBu5P8wuufmWWqNtXl+vrUgTo97CE9EYQ7 CJw=
ic.fbi.gov. 261 IN  MX  10 mail.ic.fbi.gov.
ic.fbi.gov. 261 IN  RRSIG   TXT 7 3 600 20131014154120 20130716154120 32497 
fbi.gov. iWlwUHl1KrUopGu6ixdCoNyquco3UNaip8cFONOpHNo8p/KjEYmiDyhL 
z2DWslNwbUuvh/nConYy86clgPZB3Q9MaxuhMNbiZCpsRPds98Yh+Fbg 
4U3WDRy+ww8DFLpozZc+3gBLYtcnS9UDtZOmNEjxEzDf6Zw5eyUfggpX nxY=
ic.fbi.gov. 261 IN  TXT "v=spf1 a mx ptr:mail.leo.gov mx:mail.ic.fbi.gov 
ip4:153.31.119.132 a:mail.leo.gov include:mail.leo.gov mx:mail.leo.gov ?all"

There's also an NSEC3 record for ic.fbi.gov, asserting that there are only MX, 
TXT and RRSIG records for it:

7PLEGSLCCDFUBJ53UG8E19T9MH9HIP2B.fbi.gov. 370 IN NSEC3 1 0 10 BBAB 
7PPJ5IC2PQQ5HTFGU7I2908P3DRN5FUO MX TXT RRSIG

However, that NSEC3 record is not signed. If you ask for ic.fbi.gov with 
checking disabled but also request DNSSEC records, you'll get it. If you ask 
with checking enabled, you won't, because it can't be validated. This seems to 
be true for the whole fbi.gov zone, at least the records I checked. So any 
query to fbi.gov that returns a record will be okay, anything that doesn't will 
end up with a SERVFAIL.

Bill.
___
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 KSK

[Bill Owens]

On Fri, Apr 27, 2012 at 08:40:54AM -0400, wbr...@e1b.org wrote:
> We are authoritative for a few dozen small zones.  Is it possible to use 
> the same KSK for all of them?  I can see where if it gets compromised we 
> would need to resign all zones using the KSK at once.  How much effort 
> would I be saving sharing the KSK?
> 
> I'm sure there are plenty of other good reasons not to do this... 
> Enlighten me!

Don't know about reasons for or against, but Binero AB, a big provider in 
Sweden, signs thousands of their customers' zones with the same KSK and ZSK.

Bill.
___
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 Generating Zone Key hanging

[Bill Owens]

On Sun, Apr 22, 2012 at 01:11:55AM +0100, Damian Myerscough wrote:
>Hello,
>I was setting up BIND DNSSEC and when I issue the following command the
>process never finishes.
>dnssec-keygen -a RSASHA1 -b 1024 -n ZONE example.com
>I straced the process and noticed the following messages
>write(2, "Generating key pair.", 20Generating key pair.)= 20
>gettimeofday({1335044641, 756413}, NULL) = 0
>read(3, "s\2161\363\364<\1s1\343\311\212\1", 64) = 13
>read(3, 0x7fffcac9c960, 51) = -1 EAGAIN (Resource temporarily
>unavailable)
>select(4, [3], [], NULL, NULL)  = 1 (in [3])
>read(3, "p\32\254\352$\264:\22", 51)= 8
>read(3, 0x7fffcac9c960, 43) = -1 EAGAIN (Resource temporarily
>unavailable)
>select(4, [3], [], NULL, NULL)  = 1 (in [3])
>read(3, "\370\270\363IE\342X\343", 43)  = 8
>read(3, 0x7fffcac9c960, 35) = -1 EAGAIN (Resource temporarily
>unavailable)
>select(4, [3], [], NULL, NULL)  = 1 (in [3])
>My machine is a virtual host, does anyone have any ideas what resource is
>temporarily unavailable. 

/dev/random - VMs, with no keyboard or mouse, don't accumulate enough entropy 
to keep /dev/random full. Installing haveged would probably help; or consider 
generating keys on a machine with a decent amount of entropy and securely 
moving them to your VM.

Bill.
___
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:

[Bill Owens]

On Tue, Mar 13, 2012 at 01:42:00PM +, hugo hugoo wrote:
> 
> Thanks for the feedback.
> Is this a glue record? I do not have any IP defined in the NS record.

No, a glue record is an address record (A or ) for an NS record in the 
parent zone, to avoid the problem of having the child zone needed to resolve 
the nameservers that would serve the child zone. For example, if your child 
zone is 'titi.toto.be' and the nameservers are 'ns.titi.toto.be' and 
'ns1.titi.toto.be', glue records in the parent are needed in order to allow a 
querier to follow the delegation.

> What is the flow of a request to a subzone?

Walking down the names from right to left, starting at the root, then 'be', 
then 'toto.be', and 'titi.toto.be' The easiest way to visualize it is to do a 
query with 'dig +trace'.

> Is the content of the zone checked before checking the subzone?

I'm not sure what you mean by 'checked'; it isn't verified in any way, but in 
the normal progression there would be a query for 'titi.toto.be' at the 
authoritative server for 'toto.be', which would return NS records; one of those 
nameservers would then be queried for records in 'titi.toto.be'.

Bill.
___
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 records

[Bill Owens]

On Tue, Mar 13, 2012 at 08:26:02AM -0500, Daniel McDonald wrote:
> 
> On 3/13/12 8:20 AM, "hugo hugoo"  wrote:
> 
> > ==> do I have to create in zone "toto.be" the following NS record:
> >  
> >  titi.toto.be.   TTL   IN   NSns1.xxx.be
> >  
> >  
> > I have found cases where this situation is present and other when it is not
> > present...and both cases seems to work.
> > What is the difference?
> 
> The glue records aren't necessary when both the zone and subzone are on the
> same server, although it is good to have them for completeness.  When the
> zones are on different servers you need the glue records.

That's true, and it also becomes a problem when you want to sign the zones with
DNSSEC; if there's no NS record in the parent, there can't be a chain of trust
from the parent to the child. Assuming that you'll someday want to sign
toto.be, you should put the parent NS records in place now. 

Bill.
___
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: fermat primes and dnssec-keygen bug?

[Bill Owens]

On Wed, Mar 07, 2012 at 03:35:25PM +, Spain, Dr. Jeffry A. wrote:
> Please post any additional evidence you may have that would further the 
> discussion. Thanks. Jeff.

There's quite a bit about choosing e in this presentation:
http://www.esiea-recherche.eu/Slides09/slides_iAWACS09_Erra-Grenier_How-to-compute-RSA-keys.pdf

However, I don't understand the math, so I can't say whether any of the advice 
is reasonable :(

Bill.
___
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: fermat primes and dnssec-keygen bug?

[Bill Owens]

On Wed, Mar 07, 2012 at 02:43:01PM +, Chris Thompson wrote:
> You can see the BE (2^30+3) ones in the DNSKEYs for dlv.isc.org as
> well as in a number of our own zones (which says either that the keys
> are oldish or that the versions of OpenSSL used are not as up to date
> as they probably ought to be).

Incidentally, I surveyed a number of domains for exponent choices a couple of 
weeks ago, just for fun. These have 2^30+3:

bolagsverket.se
isc.org
sba.gov
skatteverket.se
verksamt.se

And these have 2^32+1:

america.gov
applicationmanager.gov
berkeley.edu
bredbandskollen.se
com.de
com.my
edu.my
epages.com
eu.com
fbi.gov
fueleconomy.gov
gov.my
iis.se
lsu.edu
mimiaukce.cz
mimishop.cz
net.my
nic.cz
opm.gov
ornl.gov
stockholm.se
uk.com
usajobs.gov
us.com
usconsulate.gov
usembassy.gov
uspto.gov
webtrh.cz

Reading Michael Sinatra's account of how he set up berkeley.edu was what led me 
to look at the zkt tool, which hardcodes the -e flag.

As Miek discovered, the hard way, .us also uses 2^32+1; my list didn't include 
TLDs so there may be others. I'll do another run over lunch today. . .

Bill.
___
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: fermat primes and dnssec-keygen bug?

[Bill Owens]

On Wed, Mar 07, 2012 at 02:43:01PM +, Chris Thompson wrote:
> Oh, damn. I have to retract. Or indeed, grovel. It all depends on which
> version of OpenSSL it is linked with, not on the code in dnssec-keygen
> itself. Older versions do indeed generate 2^30+3, but newer ones 2^32+1.
> 
> You can see the BE (2^30+3) ones in the DNSKEYs for dlv.isc.org as
> well as in a number of our own zones (which says either that the keys
> are oldish or that the versions of OpenSSL used are not as up to date
> as they probably ought to be).

Caveat - I am no kind of a programmer; I frequently get into trouble trying to 
read other peoples' code. However, I made an extremely naive patch to 
opensslrsa_link.c:

[littledebian:bind-9.9.0/lib/dns] owens% diff -c opensslrsa_link.c.orig 
opensslrsa_link.c
*** opensslrsa_link.c.orig  2012-03-07 09:48:48.0 -0500
--- opensslrsa_link.c   2012-03-07 09:50:46.0 -0500
***
*** 752,760 
BN_set_bit(e, 0);
BN_set_bit(e, 16);
} else {
!   /* F5 0x10001 */
BN_set_bit(e, 0);
!   BN_set_bit(e, 32);
}
  
if (callback == NULL) {
--- 752,761 
BN_set_bit(e, 0);
BN_set_bit(e, 16);
} else {
!   /* 2^30+3 0x4003 */
BN_set_bit(e, 0);
!   BN_set_bit(e, 1);
!   BN_set_bit(e, 30);
}
  
if (callback == NULL) {

. . . recompiled, and tried the new dnssec-keygen:

[littledebian:~] owens% /home/owens/src/bind-9.9.0/bin/dnssec/dnssec-keygen -e 
example.net
Generating key pair...++ .++ 
Kexample.net.+005+19281
[littledebian:~] owens% cat Kexample.net.+005+19281.key
; This is a zone-signing key, keyid 19281, for example.net.
; Created: 20120307145213 (Wed Mar  7 09:52:13 2012)
; Publish: 20120307145213 (Wed Mar  7 09:52:13 2012)
; Activate: 20120307145213 (Wed Mar  7 09:52:13 2012)
example.net. IN DNSKEY 256 3 5 
BEO+k2eTlU4PS0U16bt6AVTZLqoaYKJKHXZYG+0yWZiiADqTd61W 
yuBHqrVgPJMLMKEGJRQpNJJRuVrOw3VZTC255gt+L5XLVzrmQwR2jG+0 
QFPx+Dqriq9lqmhvxtUXDMTwrCMyhv5fdDjPJ1KxknimH0htOivrHBEE EIV/6gwPkQ==

As you pointed out, BEO is 2^30+3

[littledebian:~] owens% echo 'BEO+' | base64 -d | xxd -l 12 -b
000: 0100 0100   0011 1010  .@

This certainly looks (to my inexpert eyes) like an explicit choice on the part 
of the BIND authors. 

Bill.
___
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: fermat primes and dnssec-keygen bug?

[Bill Owens]

On Wed, Mar 07, 2012 at 12:13:35PM +, Chris Thompson wrote:
> This is wrong (although I have seen the same thing stated in a number
> of other places). When the default public exponent was changed from
> 3 to 2^16+1 (change 2088) the one selected by -e was changed from
> 2^16+1 to 2^30+3 ... *not* 2^32+1. And so it remains today.

...

> And you will find that the ones generated by "dnssec-keygen -e" start
> BE...

Umm, no:

[littledebian:~/dns] owens% dnssec-keygen -e example.com
Generating key pair++ 
.++ 
Kexample.com.+005+43304
[littledebian:~/dns] owens% cat Kexample.com.+005+43304.key
; This is a zone-signing key, keyid 43304, for example.com.
; Created: 20120307140855 (Wed Mar  7 09:08:55 2012)
; Publish: 20120307140855 (Wed Mar  7 09:08:55 2012)
; Activate: 20120307140855 (Wed Mar  7 09:08:55 2012)
example.com. IN DNSKEY 256 3 5 
BQEBw3A8Wji6BjyanbOXUtIH1UcroHZKh06qRKXASbxHAQHJogaw 
6m2wYX77KvtzVSto/nbHXM/53Vbu/Ar8CAXC/+r/R5BOHw73qA12LqXr 
7utMeLmBPjq4RUqluurlVTHt5/FD85tr0yr8mu7h39gVmMY0bnRpgx6p aj2zjpv3O3U=

The code definitely uses 2^32+1:

[littledebian:bind-9.9.0/lib/dns] owens% grep -A 3 -B 5 F5 opensslrsa_link.c
if (exp == 0) {
/* RSA_F4 0x10001 */
BN_set_bit(e, 0);
BN_set_bit(e, 16);
} else {
/* F5 0x10001 */
BN_set_bit(e, 0);
BN_set_bit(e, 32);
}

Note - I have no opinion on whether this is good, bad, or merely ugly since I 
don't write crypto code and don't understand enough about RSA to be able to 
form an opinion. But that's what BIND does, as of the current version.

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

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

Re: BIND 9.9.0 is now available

[Bill Owens]

On Fri, Mar 02, 2012 at 11:13:06AM +0100, Matus UHLAR - fantomas wrote:
> On 29.02.12 17:53, Michael McNally wrote:
> >  NXDOMAIN redirection is now possible. This enables a resolver
> >  to respond to a client with locally-configured information
> >  when a query would otherwise have gotten an answer of "no
> >  such domain". This allows a recursive nameserver to provide
> >  alternate suggestions for misspelled domain names.  Note that
> >  names that are in DNSSEC-signed domains are exempted from
> >  this when validation is in use. [RT #23146]
> 
> just by signing? so I can spare all our domains from being misused by 
> such shit just by signing them?

That's one half of it; the queries also need to request DNSSEC (EDNS DO=1). One 
or the other, by itself, isn't enough. This applies to both NXDOMAIN rewriting 
and RPZ, as of 9.9.0 (the RPZ behavior changed during the 9.9.0 development 
process).

Bill.
___
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: rndc flush /recursive ?

[Bill Owens]

On Mon, Feb 27, 2012 at 02:32:31PM +0100, Stephane Bortzmeyer wrote:
> With Unbound, there are two commands to clear the cache, one which
> deletes only the records with the exact name and one which is
> recursive (deletes everything under the name).
> 
> With BIND, I find only the first one, "rndc flushname". Any command
> that I missed to delete recursively?

It's in the new 9.9.0 rndc:

  flush Flushes all of the server's caches.
  flush [view]  Flushes the server's cache for a view.
  flushname name [view]
Flush the given name from the server's cache(s)
  flushtree name [view]
Flush all names under the given name from the server's cache(s)

Bill.
___
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: Adding DS record to parent

[Bill Owens]

On Fri, Feb 24, 2012 at 10:31:24AM -0500, wbr...@e1b.org wrote:
> Does anyone know how to register a DS record for domains registered 
> through Network Solutions?  I submitted a query through their website and 
> got this response below.  I find the copyright on the canned response an 
> amusing touch.
> 
> I called the number shown, and fought my way though a tangle of prompts to 
> talk to a human in their DNS group.  I could tell DNSSEC was a foreign 
> concept to her and asked to speak with someone familiar with DNSSEC.  She 
> assured me she could help.  Turns out she was wrong.
> 
> http://www.google.com/#q=site%3Anetworksolutions.com "ds record" returns 
> no meaning hits.  Going to GoDaddy's website, I was able to find the 
> directions in a couple minutes.

I haven't heard of NS supporting DNSSEC, and there haven't been any good 
resources to find a registrar who *does*, but this popped up recently:

http://www.icann.org/en/topics/dnssec/deploy-en.htm

. . . and NS isn't on that list. FWIW, DynDNS does a fine job (that's who we've 
chosen), GoDaddy works okay too (though I think there are many other reasons to 
avoid using them) and I've heard good things about GKG. 

Bill.
___
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: dig -- only RRSIG present.

[Bill Owens]

On Sun, Feb 12, 2012 at 10:22:22AM -0800, Michael Sinatra wrote:
> On 02/12/12 09:40, dE . wrote:
> >I'm trying to see DNSSEC response of various sites; my DNS server is
> >8.8.8.8 (google's public DNS service)
 . . .
> >As we can see, the DNSKEY and DS RR is missing which's mandatory for
> >this to be of any use. So where is it?
> 
> Well, the DS RR resides in the parent, not in the zone you're querying. 
>  You need to ask for it explicitly.  Although DNSKEY records are in the 
> actual zone you're querying, you still need to ask for them explicitly. 
>  They're there; you just need to ask for them.

As Tony Finch pointed out to me a few days ago, the Google public servers don't 
understand that fact about DS records, and don't know to ask for them in the 
parent. But here's something interesting - as of my testing just now, they *do* 
respond with DS records:

[littledebian:~/dns] owens% dig isc.org @8.8.8.8 ds +dnssec

; <<>> DiG 9.9.0rc2 <<>> isc.org @8.8.8.8 ds +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48488
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;isc.org.   IN  DS

;; ANSWER SECTION:
isc.org.73847   IN  DS  12892 5 1 
982113D08B4C6A1D9F6AEE1E2237AEF69F3F9759
isc.org.73847   IN  DS  12892 5 2 
F1E184C0E1D615D20EB3C223ACED3B03C773DD952D5F0EB5C777586D E18DA6B5
isc.org.73847   IN  RRSIG   DS 7 2 86400 20120301160425 
20120209150425 55440 org. 
AaHh8ATWNZqZAfqKxoFS2GyScv46ME2s2sS6lG/AzWzDn6r7R1aXRPIT 
2zfDhLfP6yyQSREh8BSd4K98OKfWW2ZSDPxHx3soJotG+N9RFqs33HYR 
2rfJNsKDelnLQZvql93HkhblDALFycKHxKZDocNF/DgANJZbhV0qh1c9 5Cs=

;; Query time: 63 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Feb 12 19:19:43 2012
;; MSG SIZE  rcvd: 283

They're not setting AD so they aren't validating, and in fact they'll return 
records with broken signatures, like so:

[littledebian:~/dns] owens% dig pastdate-a.test.dnssec-tools.org @8.8.8.8

; <<>> DiG 9.9.0rc2 <<>> pastdate-a.test.dnssec-tools.org @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30272
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;pastdate-a.test.dnssec-tools.org. IN   A

;; ANSWER SECTION:
pastdate-a.test.dnssec-tools.org. 86400 IN A75.119.216.33

;; Query time: 154 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Feb 12 19:23:11 2012
;; MSG SIZE  rcvd: 77

Still, I think it's a good sign. . .

Bill.
___
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

[Bill Owens]

On Fri, Feb 03, 2012 at 10:04:19AM -0500, Lear, Karen (Evolver) wrote:
> Who would be responsible for opening a trouble report to GoDaddy?  I don't 
> understand exactly what the problem is here.

It looks, from the outside, as though the Oppedahl Patent Law Firm LLC uses 
GoDaddy for DNS registration, DNS server hosting, and web server hosting. 
They're also DNSSEC-signing their domain (for which they should be praised ;)

The GoDaddy DNS servers are distributed around the network in various 
colocation sites, and reachable by IP anycast, which means that a number of 
different hosts will answer queries as if they were 'dns1.oppedahl.com', they 
are all reachable over the same IP address, and normal IP routing takes your 
DNS queries to the closest one. When I query for oppedahl.com, I use servers in 
Chicago and they work fine. When you're trying to query for oppedahl.com, 
you're likely using the same Washington, DC area server that Florian was using, 
and it is broken; it doesn't respond to queries that use EDNS0, and therefore 
can't handle DNSSEC. 

Since Oppedahl is the GoDaddy customer, they should open a support case. It 
should be especially important for them to have the USPTO be able to reach 
their website, email, etc. so I'd think they would want to follow up on this 
quite vigorously. . .

Incidentally their phone numbers are 970-468-8600 and 303-252-8800, since you 
can't get them off the website any more ;)

Bill.
___
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

[Bill Owens]

On Fri, Feb 03, 2012 at 02:12:43PM +, Florian Weimer wrote:
> * Bill Owens:
> 
> > On Fri, Feb 03, 2012 at 01:55:12PM +, Florian Weimer wrote:
> >> These nameservers:
> >> 
> >> dns2.oppedahl.com.  172800  IN  A   208.109.255.50
> >> dns1.oppedahl.com.  172800  IN  A   216.69.185.50
> >> 
> >> return SERVFAIL for EDNS0 queries.  COM contains a signed delegation.
> >> This configuration is not supported.  It seems that BIND produces
> >> a failure even if DNSSEC validation is not enabled for the view.
> >
> > How odd. . . it doesn't look that way from here:
> >
> > [littledebian:~] owens% dig oppedahl.com soa +norec +edns=0 @216.69.185.50
> 
> The exact same command line results in SERVFAIL for me.
> 
> Various protocol-specific traceroutes suggests that I'm hitting the
> Godaddy servers hosted close to Level3 in Washington DC.

Aha, the dreaded anycast. I didn't think to look for that since they were using 
oppedahl.com names for the servers. And indeed, my tcptraceroutes go to Chicago 
from one test machine, an unidentified location from the other. Sadly, they 
don't appear to do the hostname.bind or id.server trick (or I'm requesting it 
incorrectly).

I suppose this needs to turn into a trouble report to GoDaddy, though I wonder 
how hard it will be to find someone who would understand it. . .

Bill.
___
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

[Bill Owens]

On Fri, Feb 03, 2012 at 01:55:12PM +, Florian Weimer wrote:
> These nameservers:
> 
> dns2.oppedahl.com.  172800  IN  A   208.109.255.50
> dns1.oppedahl.com.  172800  IN  A   216.69.185.50
> 
> return SERVFAIL for EDNS0 queries.  COM contains a signed delegation.
> This configuration is not supported.  It seems that BIND produces
> a failure even if DNSSEC validation is not enabled for the view.

How odd. . . it doesn't look that way from here:

[littledebian:~] owens% dig oppedahl.com soa +norec +edns=0 @216.69.185.50

; <<>> DiG 9.9.0rc2 <<>> oppedahl.com soa +norec +edns=0 @216.69.185.50
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59472
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;oppedahl.com.  IN  SOA

;; ANSWER SECTION:
oppedahl.com.   3600IN  SOA dns1.oppedahl.com. 
dns.jomax.net. 201708 28800 7200 604800 3600

;; AUTHORITY SECTION:
oppedahl.com.   3600IN  NS  dns1.oppedahl.com.
oppedahl.com.   3600IN  NS  dns2.oppedahl.com.

;; ADDITIONAL SECTION:
dns1.oppedahl.com.  3600IN  A   216.69.185.50
dns2.oppedahl.com.  3600IN  A   208.109.255.50

;; Query time: 100 msec
;; SERVER: 216.69.185.50#53(216.69.185.50)
;; WHEN: Fri Feb  3 09:06:24 2012
;; MSG SIZE  rcvd: 172

; <<>> DiG 9.9.0rc2 <<>> oppedahl.com @216.69.185.50 dnskey +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32030
;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;oppedahl.com.  IN  DNSKEY

;; ANSWER SECTION:
oppedahl.com.   3600IN  DNSKEY  257 3 5 
AwEAAZ5XEDidVFrH3eT2nH/W/sbaZFpG6U2oer0H8XJnFwJU83O8DcyH 
nHDgGtyB/tWH1zcv1CtwVrSRSxtD8lLZfuJFe3cWUP4126URj3rEmeyc 
U1WNmQVXqykApqCFcGglWnIjflOIoZtkSFJc4TPQjeCF2DuHSXouFY3h 
rvEZqxMudrtW4a226szsa2KyDWk0R671Gq3emfmwPC77DIwRNkMX/GIP 
PDZwz5mKXz7awKLOQyEpOcahTlGNWCEGw9w1JxmqbatJh84imuiI2lfY 
lVsrqI3jHvW2qPz7+sQ9203BMcpp61k/2L1TyMV7bqKDZHnZER6M9Kvo adBsWMUCsZ0=
oppedahl.com.   3600IN  DNSKEY  257 3 5 
AwEAAdnoykMtls1LXIjSR64JB/gdOfkcdzqakUU2I/YClfwSGcIRY8dM 
9IvMg69dFwN1kOVwd21gOZxMlRC8FxK3Weygu2EWDVLMJMYppH6jhPtO 
JOFB6lc8sum63C2mCmy9gbgZmYulSbZbnT608K8g2VCVzksBBJ0rjdaQ 
Stl17Djyu5aZ7HlNK98iYvkGILPQZnO/2kcIFnpcExHTncW7PvaKMmWr 
2PPoKcbv7NV2Pv98GKpcCoST221wGTeYhCay5h55x0fHG51H1DpXURPo 
XhVx+W7dHFCUM0iIfJciKXqAeQRa/VhQ+3RCW0wuJexYxqaf0RcGjhyu +Ma4GRxd390=
oppedahl.com.   3600IN  DNSKEY  256 3 5 
AwEAAd3FBGqcuvfY9a4csyC0trx9iXIzAZFc4klLr1IF+bhjtUFG9Es/ 
cD19GeWa/HF65Fzlykgqe+mVYAQ5yled/rLgMOg14jKIWA3dX2aMGMpJ 
Buddzr/Nvb+AnHk7muwjx9rjUxy1miWKls+AovoWOydgeESJogDDPRdT 9AxS34I9
oppedahl.com.   3600IN  DNSKEY  256 3 5 
AwEAAaIoPlTY6ilGGOMc7zqyuOzRYkpaNMdjrnqmmxJZUsCe3O3oXjA4 
gzDq9VsiL67JUKvV6DP/QzJaiGDuqhO7X2GIQsW9iBT9ME98C3xkeDEe 
FCrJVJJcyRrC2XimcaSE4ri/wXqegif4hq24tvZB2mtFROAfSUzjEJkq /DqDk8jN
oppedahl.com.   3600IN  RRSIG   DNSKEY 5 2 3600 20120212140129 
20120128140129 14779 oppedahl.com. 
UJl1TpJfuutGzHyZfsW5QwD++namGTDTr9wlqd+OpSYHJD/CCi1n2FLQ 
6VgrytswOdIe8lhmU3jF4BqLSkikR7yGNGD/ABHd3nIkIbsuadA9Vp+k 
csYsjihrsUEGG+ZwArteyqSnfby76c5fHjH3THH56wF6vhEETl0bTsgr 
+5LKogEGMzHbD2oWyrxe/eJH2lthp5FDCoh9z8rDXqdbjxOvsdp7qRSF 
WTHy/CVTX1OtuAKhu8qEDooD6jjEOqv16eKNNAD02cwUNjKb7a07kaPj 
jcBqPrUaPeKI/0NBuW/XuEWKalvX3p+OmUhzFEQDm6WT7RHUF1OqX9jI CtDzZw==

;; Query time: 100 msec
;; SERVER: 216.69.185.50#53(216.69.185.50)
;; WHEN: Fri Feb  3 09:06:46 2012
;; MSG SIZE  rcvd: 1201


Bill.
___
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

[Bill Owens]

On Fri, Feb 03, 2012 at 08:37:04AM -0500, Lear, Karen (Evolver) wrote:
> Beginning sometime within the past few days, uspto.gov domain cannot resolve 
> oppedahl.com domain, but can resolve it from almost everywhere else.  Some 
> free websites (http://centralops.net/co/) cannot resolve it as well.  I want 
> to verify that uspto.gov doesn't need to correct anything on our end.  When 
> doing a dig, I can't get an IP address for their nameservers.
> 
> By the way, they have published DNSSEC keys out there not in use.  Last year, 
> I had a few clients that couldn't connect to uspto.gov domain when I had 
> published keys out there that I had not removed.  Once I removed them, the 
> problem was resolved.  Do you think this could be the same case for 
> oppedahl.com?  I appreciate any help.  Thx.

>From here it appears that oppedahl.com is signed correctly, with the small 
>quirk that they have two DS records pointing to two KSKs, both valid, but only 
>one of which has signed the DNSKEY RRSET. It's possible they are partway 
>through a KSK rollover, though their serial number makes it look like the zone 
>hasn't changed since last November. I wouldn't think that BIND 9.7.4 would 
>have any issues with that. It might be worth looking at your logs, assuming 
>you log DNSSEC errors (and if you don't, it's a good idea to start ;)

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

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

Re: BIND trying to use IPv6 for recursion

[Bill Owens]

On Fri, Jan 13, 2012 at 11:20:39AM -0600, Ian Pilcher wrote:
> I am a relative newbie to running BIND in "production".  I have recently
> set up BIND 9.7 (on CentOS 6.2) as the nameserver for my home network.
> I am using Google's public DNS servers (8.8.8.8 and 8.8.4.4 as my
> forwarders).
> 
> My ISP does not support IPv6, and none of the network interfaces on the
> server has an IPv6 address (including the loopback interface).  Despite
> this, BIND appears to be trying to use IPv6 to communicate with other
> nameservers.  My log is filling with messages like:

I'm not familiar with CentOS, but I would be surprised to hear that any modern 
Linux distro didn't have IPv6 enabled by default; you should see at least 
link-local addresses on your active interfaces (address family inet6, beginning 
with fe80::) I'm only pointing that out because if you're *not* seeing those, 
it is possible that the tool you're using to look for IPv6 isn't working 
correctly.

If you're actually ahead of that point and really saying that none of your 
interfaces have *global* IPv6 interfaces, then the only other thing I could 
suggest is looking to make sure you don't have a tunnel interface for 6to4; I 
don't think that would be enabled by default, though. 

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

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

Re: Bind 9.9.0b2 inline signing...

[Bill Owens]

On Mon, Nov 28, 2011 at 01:03:15PM -0500, wbr...@e1b.org wrote:
> Todd wrote on 11/24/2011 11:29:14 AM:
> 
> > I don't understand why Windows doesn't include dig by default, even 
> > now.  Free software hate?
> 
> And grep and logrotate!  At least the GnuWin32 project has a good version 
> of grep.

There are others who sympathize with you:

https://twitter.com/dns_borat/status/139996381661237248

;)

I think that if I had to use a Windows workstation my first installs would be 
the ISC binary kit and wireshark, since AFAIK Windows doesn't come with a 
packet capture program either. . .

Bill.
___
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: Port number in A record in zone file

[Bill Owens]

On Thu, Nov 17, 2011 at 03:41:54PM +0100, Aleksander Kurczyk wrote:
> > Why would you run a dns server on a non standard port? There's no way
> > for clients to query via non standard ports.
> 
> I would like to make a experimental configuration simulating a few BIND 
> servers on one PC (PowerMac G4 400 Mhz :) ), without virtual machines.

So would I, but the only way I know of to do this is through some form of VM. 
I've seen a very nice setup using KVM and that's what I'm playing with so far, 
though it's a spare time effort and I haven't made a lot of progress. . .

Bill.
___
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: All Bind servers crashed

[Bill Owens]

On Wed, Nov 16, 2011 at 07:59:10AM -0600, b...@namor.ca wrote:
> On Wed, 16 Nov 2011, Bill Owens wrote:
> >This behavior makes me bet that the trigger is a name in an incoming 
> >email message, being resolved by an anti-spam filter. 
> 
> We had the same thing happen, across multiple, geographically-diverse 
> servers overnight, around the exact same time as the OP.  That seems a 
> little odd to be an email, as it would have to cover a myriad of 
> destinations all at once.
> 
> While that's possible, I'm just finding it lacking as the sole reason for 
> the conclusion.

Looks like I'll lose the bet - a NYSERNet member campus admin tells me that his 
campus servers were affected, but he runs individual copies of BIND on his mail 
servers specifically to handle the load anti-spam queries and they had no 
problems.

Bill.
___
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: All Bind servers crashed

[Bill Owens]

On Wed, Nov 16, 2011 at 09:57:18AM +0100, Stephane Bortzmeyer wrote:
> On Wed, Nov 16, 2011 at 09:47:48AM +0100,
>  Magnus Schmidt  wrote 
>  a message of 49 lines which said:
> 
> > Nov 16 05:30:41 xxx named[1326]: critical: query.c:1781: INSIST(!
> > dns_rdataset_isassociated(sigrdataset)) failed, back trace

This behavior makes me bet that the trigger is a name in an incoming email 
message, being resolved by an anti-spam filter. That appeared to trigger a 
site-wide resolver crash back in May, when the oversigned .gov zone was 
mentioned on a list (this particular list, I think). That suggests looking in 
the inbound mail spool to see what might have been received at the time of the 
crash might be productive.

Regardless of how the query was started, if this theory of propagation is 
correct I'd suggest that posting the triggering name unobscured in an email 
message would be A Bad Thing, even if one is emailing it to ISC as they've 
suggested. Perhaps *especially* in that case, unless they've taken care to have 
one production recursor running Unbound ;)

Bill (who is downloading Unbound right now)
___
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 forward zones

[Bill Owens]

On Wed, Nov 02, 2011 at 10:02:45AM -0400, wbr...@e1b.org wrote:
> But it does provide some alternatives:
> 
> .intranet
> .internal
> .private
> .corp
> .home
> .lan
> 
> But can we guarantee that they won't be approved as new public TLDs per 
> the new rules adopted this summer where anything can be a TLD?

Oops, I didn't read that far in the draft ;) Interesting question, and it 
forced me to download and crack open the 352-page ICANN guidebook for new 
gTLDs. Page 2-8 says:

Top-Level Reserved Names List

AFRINIC
ALAC
APNIC
ARIN
ASO
CCNSO
EXAMPLE*
GAC
GNSO
GTLD-SERVERS
IAB
IANA
IANA-SERVERS
ICANN
IESG
IETF
INTERNIC
INVALID
IRTF
ISTF
LACNIC
LOCAL
LOCALHOST
NIC
NRO
RFC-EDITOR
RIPE
ROOT-SERVERS
RSSAC
SSAC
TEST*
TLD
WHOIS
WWW
*Note that in addition to the above strings, ICANN will reserve translations of 
the terms “test” and “example” in multiple languages. The remainder of the  
strings are reserved only in the form included above.

I suppose any of those could be used. I like .invalid, personally ;)

Bill.
___
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 forward zones

[Bill Owens]

On Wed, Nov 02, 2011 at 08:45:31AM -0400, wbr...@e1b.org wrote:
> Lyle wrote on 11/01/2011 04:19:18 PM:
> 
> > Again, this has a disadvantage if they ever decide to make .internal a 
> > real internet domain name and some people frown upon this practice.  Be 
> > sure you know what can go wrong.
> 
> Is there an IETF/ICANN reserved TLD for internal use?  I've seen plenty of 
> .loc and .local, but I haven't seen an RFC reserving it.  

I happened to be looking for some other details on mDNS yesterday and noticed 
that the current draft version of the spec reserves .local:

http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-14
   This document specifies that the DNS top-level domain ".local." is a
   special domain with special semantics, namely that any fully-
   qualified name ending in ".local." is link-local, and names within
   this domain are meaningful only on the link where they originate.

At the same time it also specifies that .local can only be used with mDNS, so 
it isn't really suitable for this use. . .

Bill.

___
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: zone before delegation?

[Bill Owens]

On Fri, Oct 28, 2011 at 05:39:05PM +, Laws, Peter C. wrote:
> OK, so simply putting the NS records in the parent zone is sufficient to make 
> it a separate zone.  No need to put stuff in named.conf unless I want to or 
> until I actually delegate to a different set of nameservers.

Actually, the opposite - sorry if I was unclear. Maybe an example will help. . .

If we start with this config:

zone "example.com" {
type master;
file "/usr/local/etc/bind/example.com.zone";
};

# example.com.zone
$TTL 86400
@   IN  SOA ns.example.com  hostmaster.example.com (
2011102900 86400 14400 864000 86400 )
IN  NS  ns.example.com.
;
www IN  A   192.0.2.1

We can add a subdomain of example.com simply by creating the zone file and 
adding an entry in named.conf, *without* placing anything in the example.com 
zone itself:

zone "test.example.com" {
type master;
file "/usr/local/etc/bind/test.example.com.zome";
};


# test.example.com.zone
$TTL 86400
@   IN  SOA ns.example.com  hostmaster.example.com (
2011102900 86400 14400 864000 86400 )
IN  NS  ns.example.com.
;
testserver  IN  A   198.51.100.20

There is no connection between example.com and test.example.com, since the 
records for test are in a separate zone and there's no delegation point (no NS 
records for 'test.example.com'). However, any queries for test.example.com have 
to work through example.com first, and the same server knows about both zones. 
When someone asks for 'testserver.test.example.com' at ns.example.com, it will 
provide an authoritative answer for the A record and include an NS record in 
the additional section. Everything will work just fine; that's true even if 
there are additional authoritative servers, as long as all of the servers for 
example.com are also authoritative for test.example.com.

That said, here's the right way to do it; after creating the subdomain zone 
file and adding the entry in named.conf, go back to the parent:

# example.com.zone
$TTL 86400
@   IN  SOA ns.example.com  hostmaster.example.com (
2011102901 86400 14400 864000 86400 )
IN  NS  ns.example.com.
;
www IN  A   192.0.2.1
;
testIN  NS  ns.example.com.

Now everything's consistent and complete. That configuration will always work, 
regardless of the location of the authoritative nameserver(s) for 
test.example.com. It will also work when you sign test.example.com and add DS 
records in example.com to secure it.

> My thought was to create the new zones as zones on the parent server as a 
> prelude to actually delegating them, in a  sense, delegating the zone to 
> myself.  That will let me clean stuff up and get it ready for the coming 
> move.  

That's fine, but still create the NS records. You can keep them at a low TTL 
until your transition, if you want to speed up the process when you do make the 
change.

> Yes, DNSSEC is, IMHO, much like IPv6 - no one wants to mess with it but a lot 
> of people claim it's inevitable.  *Hopefully* both will end up like maglevs 
> and monorails - "technology of the future: always has been, always will be".  
> :-)

Actually I think they're very different. Both will require some effort and some 
pain; IPv6 more of both and for less obvious return (though it truly does have 
some significant advantages). DNSSEC - once it is sufficiently deployed - will 
make some very cool things possible, well beyond the basic, but very important 
addition of end-to-end DNS integrity. Have a look at the freshly minted RFC 
6394 for one early example. . .

Bill.
___
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: zone before delegation?

[Bill Owens]

On Fri, Oct 28, 2011 at 04:48:10PM +, Laws, Peter C. wrote:
> It seems like there are two ways I could delegate a zone.
> 
> I could, in the zone file for the parent, simply list the name of the zone
> and a number of NS records to which the zone has been delegated.
> 
> Or, I could create a zone statement within named.conf that points to a file
> that contains an SOA and a number of NS records to which the zone has been
> delegated.
> 
> Which is better and which should I prefer?

If I'm reading this correctly, both ;) I take it the same servers are 
authoritative for both parent and child, right? You can get away with just 
creating the new zone in named.conf and not delegating it properly in the 
parent, due to a quirk in BIND behavior; it always answers from its authority 
and the chain of resolution will always pass through the server (because it's 
authoritative for the parent). But when* you configure DNSSEC, the lack of NS 
records in the parent zone will break your configuration. So installing them 
now will save you that grief later. 

I don't think that the order is particularly important, since queries can't be 
answered until the zone is created and configured in named.conf, though I 
suppose that creating the zone first is slightly more correct.

Bill.

(* note that I didn't say if you install DNSSEC, since I believe it will be 
inevitable ;)
___
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

[Bill Owens]

On Tue, Oct 04, 2011 at 06:31:03PM +, Raymond Drew Walker wrote:
> I have been unable to determine the correct method to add a DS record by
> hand. The ultimate goal would be the automation of this process.

Generate the DS record with dnssec-dsfromkey, cut and paste it into the zone 
file, then re-sign the zone (or add it with nsupdate, or however you put 
records into the nau.edu zone).
 
> Am I also missing somewhere in the RFC where NS records of children zones
> need be populated in the parent? Is this something that has changed with
> the addition of DNSSEC?

AFAIK that's always been the case; RFC1034 references it:
"As the last installation step, the delegation NS RRs and glue RRs necessary to 
make the delegation effective should be added to the parent zone."

Bill.
___
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

[Bill Owens]

On Fri, Sep 30, 2011 at 10:26:34PM +, Raymond Drew Walker wrote:
> In our initial implementation of DNSSEC, we chose to try out the "auto"
> functionalities in version 9.8.0 P4 ie. using "auto-dnssec maintain" in
> all master zones.
> 
> When going live, we found that though all zones that we are acting as
> master for would populate their own DS records, but there would be no
> population of a child zone's DS record in the corresponding parent master
> zone file. 

The ARM for 9.8.1 has this to say about dnssec-signzone:

"Any keyset files corresponding to secure subzones should be present. The zone 
signer will generate NSEC, NSEC3 and RRSIG records for the zone, as well as DS 
for the child zones if '-g' is specified. If '-g' is not specified, then DS 
RRsets for the secure child zones need to be added manually."

I take that to mean that if I have a pair of zones served by the same master, 
dnssec-signzone will figure out the relationship and install DS records in the 
parent zone. However, that assumes two things - that both zones are on the same 
master (as seems to be the case for you), and that there are NS records in the 
parent to provide a delegation point (which doesn't seem to be true for nau.edu 
and extended.nau.edu, at least). 

I couldn't tell whether this also applies to auto-dnssec; either the ARM 
doesn't say or I missed it ;) 

> We have since backed out DNSSEC until we can get a resolution of the issue.

Incidentally, you haven't - you're still serving a signed zone for nau.edu and 
extended.nau.edu, which causes the problems noted in the other responses to 
your original note. I think you could fix it very quickly though, by adding the 
NS records to the nau.edu zone. 

Bill.
___
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

[Bill Owens]

On Fri, Sep 30, 2011 at 08:48:56PM -0400, Jeff Reasoner wrote:
> Hmm, I see an A record using the same query:

Interesting. . . my validating resolver (also 9.8.1) will only give me an A if 
I ask with +cd. And if I follow that query with another, without the +cd, I get 
SERVFAIL; then re-querying with +cd gives NXDOMAIN. Do you have validation 
enabled as well?

Bill.
___
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

[Bill Owens]

On Fri, Sep 30, 2011 at 10:26:34PM +, Raymond Drew Walker wrote:
> In our initial implementation of DNSSEC, we chose to try out the "auto"
> functionalities in version 9.8.0 P4 ie. using "auto-dnssec maintain" in
> all master zones.
> 
> When going live, we found that though all zones that we are acting as
> master for would populate their own DS records, but there would be no
> population of a child zone's DS record in the corresponding parent master
> zone file. 
> 
> This means upon go-live, any DNSSEC validation of our children zones
> (X.nau.edu, Y.X.nau.edu etc.) would fail, though our root master zone
> (nau.edu) would validate fine.
> 
> We have since backed out DNSSEC until we can get a resolution of the issue.
> 
> After much research, I'm not sure why this is happening... Any suggestions
> or ideas?

I think there's something else going on here. If you have DNSKEY records in the 
child but no DS in the parent, everything should still be okay - there's no 
chain of trust, but there's also no assertion from the parent that there 
*should be* a chain of trust (that's what the DS record does).

However, in this case I believe your problem is the lack of NS records in 
nau.edu for extended.nau.edu. It's difficult to know for sure, but it appears 
that the only signature for the NS RRSET is using the ZSK for extended.nau.edu, 
not the ZSK for nau.edu. 

In the olden days you could get away with that since the same servers are 
authoritative for both zones, and they'd answer correctly. In the new world of 
DNSSEC, if you ask for extended.nau.edu, you get this:

paperboy {owens}% dig +dnssec extended.nau.edu a

; <<>> DiG 9.9.0a2 <<>> +dnssec extended.nau.edu a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60942
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;extended.nau.edu.  IN  A

;; AUTHORITY SECTION:
ewb.nau.edu.10199   IN  RRSIG   NSEC 5 3 86400 20111019222812 
20110919220129 7485 nau.edu. 
SfCIx42kzjbTV5sDH/OwIKGRRxfJaM8EgaX74/RbD+BJjJhP7o28dR1U 
VHRuO6arK8FXF0vCIZ5lpqaWFRkaCwEftrjX3ktdWUNfhRlD9qqHF+cV 
00icFXkasql9f8Yk9XgTeZ63CkH/8H9acjTuVlunqZDL1CVtaKTJfKKq uMs=
ewb.nau.edu.10199   IN  NSECfacdevnet.nau.edu. CNAME RRSIG 
NSEC
nau.edu.10199   IN  SOA ns3.nau.edu. 
DNS-Contact.nau.edu. 4779 1800 900 604800 86400
nau.edu.10199   IN  RRSIG   SOA 5 2 86400 20111030191258 
20110930181258 7485 nau.edu. 
xoY5c8d+UnJfXA0ZZDv2Zz5tht4ZspTOeGvEGcQr+XIOMH39krpWR6T9 
fUy5O/XnURz5nDGWR4QIKQMgAu+qfyGzA9Yzb5S5CkAWd4IDjKmznrXI 
G3beth9Dcr/fJxusMxGuhZWZftQBrHBn14Wqx8YKOOIwQZx/PSm8XONA tHc=
nau.edu.10199   IN  RRSIG   NSEC 5 2 86400 20111020001752 
20110919233312 7485 nau.edu. 
GizWBgmH1B7n0TuBjRgUEiu0XOCvrncyKR1iSSWJIrWKn4aZ9djBazdP 
/JEWGY73IIZ4j/i3yO6MSw1gJRe0ane3lZjpHFnFdaPPEcYHVWy3h7Zk 
UccnBd0ggkkLrHoG/CbRoVrF+90CDJymeAnYcWDycKQW84cNibj/tXxb CRk=
nau.edu.10199   IN  NSEC_tcp.nau.edu. A NS SOA MX TXT 
RRSIG NSEC DNSKEY TYPE65534

No records, so no delegation, so nowhere to go to get the A record (which is 
actually configured).

As for BIND automatically populating DS records, I don't even know whether 
that's a feature. Is it in the docs? I don't remember seeing it, but it's a big 
manual and I might have missed that reference. . .

Bill.
___
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: NXDOMAIN redirection in BIND 9.9

[Bill Owens]

On Thu, Sep 29, 2011 at 04:52:10PM -0500, Michael Graff wrote:
> I'm happy you read it, and hope to see you at the forum/customer webinar next 
> week!  I'll be speaking, and will bring my fireproof undies.

I'm already signed up, but no worries about flaming - at least not from me ;)

> We came to the conclusion that no matter how much we wanted it to not be 
> true, people find a way to do NXDOMAIN if they want to.  The issue is not 
> ours to push, it's between the ISP and the customer ultimately, and people 
> will do it -- and more intrusively -- than BIND 9.9 will.

Good point - if it's implemented in BIND 9.9, then perhaps it can be more sane 
than if done by someone else. Might I propose a pair of changes to the behavior 
that would improve its sanity level dramatically, from my perspective? Right 
now, the ARM describes 'redirect' thusly:

"If the client has requested DNSSEC records (DO=1) and the NXDOMAIN response is 
signed then no substitution will occur."

That's a fairly obvious choice, since it isn't possible to fake an answer if 
both sides of the transaction are actively doing DNSSEC. Philosophically, 
though, I think it's more correct to decree that if *either* side is doing 
DNSSEC, no substitution should occur. That is, if the query comes in with DO=1, 
no substitution because the client is trying to use DNSSEC, and if the response 
is signed, so substitution because the server is doing likewise.

That means I can opt out of NXDOMAIN substitution either by running a local 
client (forwarder, stub or application) that sets DO=1, and on the other side 
can opt out by signing my zone. We hope that someday everyone will do those 
things anyway, at which point redirect stops working anyway. . .

Bill.
___
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

NXDOMAIN redirection in BIND 9.9

[Bill Owens]

I've obviously been asleep and not following along with the announcements of 
new features in BIND 9.9 until today. . . both Evan's blog post 
 and 
the announcement of next week's webinar include NXDOMAIN redirection as the 
first new feature. I'm really surprised by that - is this something that BIND 
users were clamoring for? Or is it a situation where other servers were 
providing this feature, and BIND needed it to maintain parity?

Obviously those of us who find this idea disturbing don't need to enable it, 
and DNSSEC provides an effective defense against those who would enable it* but 
it still leaves me curious. 

*except that perhaps those who enable this feature will use it as an excuse to 
avoid enabling validation, which would be a very bad result, IMO. . .

Bill.
___
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: couldn't add command channel 127.0.0.1#54 error

[Bill Owens]

On Wed, Sep 07, 2011 at 10:39:30AM -0600, Norman Fournier wrote:
> Hello,
> 
> I was running BIND successfully on OS X 10.4 Tiger. That webserver crashed 
> and I replaced it with a new cpu and installed OS X 10.5 Leopard and have 
> encountered a number of errors in my configuration. This is the latest error 
> from the old config files. Any suggestions or pointers as to what might be 
> using this address or how I could find out would be appreciated.

Sounds like you have something already running. Try "sudo lsof -i | grep 
domain" to see whether anything is running on port 53. If there are any 
results, the second column is the process number, and you can do "ps wwx 
" to see what it is.

Bill.
___
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: Clients get DNS timeouts because ipv6 means more queries for each lookup

[Bill Owens]

On Mon, Jul 11, 2011 at 04:06:42PM -0400, Bill Owens wrote:
> On Mon, Jul 11, 2011 at 02:11:57PM -0400, Jonathan Kamens wrote:
> > The number of DNS queries required for each address lookup requested by 
> > a client has gone up considerably because of IPV6. The problem is being 
> > exacerbated by the fact that many DNS servers on the net don't yet 
> > support IPV6 queries. The result is that address lookups are frequently 
> > taking so long that the client gives up before getting the result.
> 
> I've seen the same thing, and poked around enough to see that the Wikipedia 
> name servers are returning the wrong authority info for these and other 
> queries (it isn't just  - try TXT, SRV, etc.) Some digging through the 
> archives finds this:
> 
> https://lists.isc.org/pipermail/bind-users/2011-March/083109.html
>  in which the first sentence says it all: "The nameservers for wikipedia.org 
> are broken."
> 
> And this followup:
> https://lists.isc.org/pipermail/bind-users/2011-March/083113.html
>  "It's PowerDNS 2.9.22 that is breaking this, and it will be fixed by 
>  PowerDNS 3.0 once that's released, and we get around to deploying it."
> 
> Looks like PowerDNS was in RC2 as of April 19, not released yet. . .

Updating that - according to Bert Hubert (via Twitter): 
"Friday the 22nd is... PowerDNS Authoritiative Server 3.0 release day!"

Bill.
___
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: AAAA type query invalidates A records in name server cache

[Bill Owens]

On Tue, Jul 19, 2011 at 04:58:53PM +0200, mailsecurity wrote:
> All,
> 
> anyone experiencing the same behavior?

I hope so, because that's the correct behavior. Dell's nameserver is broken:

http://tools.ietf.org/html/rfc4074
Common Misbehavior Against DNS Queries for IPv6 Addresses - May 2005
4.2.  Return "Name Error"

   This type of server returns a response with RCODE 3 ("Name Error") to
   a query for an  RR, indicating that it does not have any RRs of
   any type for the queried name.

   With this response, the stub resolver may immediately give up and
   never fall back.  Even if the resolver retries with a query for an A
   RR, the negative response for the name has been cached in the caching
   server, and the caching server will simply return the negative
   response.  As a result, the stub resolver considers this to be a
   fatal error in name resolution.

fpdns says that Dell's servers are BIND, wonder if that's accurate, and if so, 
how ancient a release, to have this bug?

Bill.
___
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: Clients get DNS timeouts because ipv6 means more queries for each lookup

[Bill Owens]

On Mon, Jul 11, 2011 at 04:25:59PM -0400, Jonathan Kamens wrote:
> On 7/11/2011 4:06 PM, Bill Owens wrote:
> >https://lists.isc.org/pipermail/bind-users/2011-March/083109.html
> >  in which the first sentence says it all: "The nameservers for 
> >  wikipedia.org are broken."
> It's not just wikipedia.org that's broken, obviously. I see this error 
> in my logs for 19 domains since July 3:

I have FORMERR entries in my logs for 79 names since June 19, a total of 5185 
error messages. 2247 of those are for wikipedia-related names. Spot-checking 
shows that the others appear to be unrelated issues; mostly bizarre-looking 
misconfigurations. 

> Even if PowerDNS is the only source of this issue, and even if the new 
> version of PowerDNS is released tomorrow, I'm sure there will still be 
> sites running the old version a year from now. So just relying on a 
> PowerDNS release to fix this problem seems unwise.

A fix to the PowerDNS problem won't remove all the FORMERR messages, but a 
fixed version running the wikipedia-related domains would repair your original 
problem, and that seems like a reasonable thing to expect. More reasonable than 
asking BIND to ignore incorrect responses, IMO. . .

Bill.
___
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: Clients get DNS timeouts because ipv6 means more queries for each lookup

[Bill Owens]

On Mon, Jul 11, 2011 at 02:11:57PM -0400, Jonathan Kamens wrote:
> The number of DNS queries required for each address lookup requested by 
> a client has gone up considerably because of IPV6. The problem is being 
> exacerbated by the fact that many DNS servers on the net don't yet 
> support IPV6 queries. The result is that address lookups are frequently 
> taking so long that the client gives up before getting the result.

I've seen the same thing, and poked around enough to see that the Wikipedia 
name servers are returning the wrong authority info for these and other queries 
(it isn't just  - try TXT, SRV, etc.) Some digging through the archives 
finds this:

https://lists.isc.org/pipermail/bind-users/2011-March/083109.html
 in which the first sentence says it all: "The nameservers for wikipedia.org 
are broken."

And this followup:
https://lists.isc.org/pipermail/bind-users/2011-March/083113.html
 "It's PowerDNS 2.9.22 that is breaking this, and it will be fixed by 
 PowerDNS 3.0 once that's released, and we get around to deploying it."

Looks like PowerDNS was in RC2 as of April 19, not released yet. . .

Bill.
___
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