Re: Problem upgrading to 9.18 - important feature being removed

[Michael Sinatra]

On 2/26/24 13:41, Al Whaley wrote:
As far as I have been able to determine through some fairly extensive 
reading, a feature I depend on has fallen out of favor with the BIND 
developers, and is being removed.
DNSSEC in 9.18 has two automatic actions where the original code had 
just one, and the second cannot be disabled.

I am referring to the deprecated feature:

|auto-dnssec maintain;|

||Originally (under the above command) RR records for DNSSEC were 
maintained by bind, but the ZSK and KSK keys were maintained by me.  
This command is being discarded.  I understand that bind "sort of" 
supports this feature in 9.18 by allowing the DNSSEC policy statement to 
declare unlimited lifetime, but after careful reading of the 
documentation and reading a number of complaints, it turns out that bind 
may under various circumstances decide that it is appropriate not to use 
existing keys and decide that it knows best, and then it makes new 
ones.  This potential instability of course would be disastrous, and 
completely unnecessary.


I have never experienced this, in either BIND 9.16 or BIND 9.18 
(including the latter with KASP set to not rotate any keys).  Can you 
elaborate as to where in the documentation and/or what complaints you 
have seen where correctly configured KASPs in 9.18.24+ decide to roll 
keys?  I'd certainly like to know if that's the case, for reasons 
described below.


I am sure there are the usual people that will assure me I don't or 
shouldn't want to do what I am doing, but I am experienced and have good 
reasons.  Yes I know that I can have bind update the DS records, but for 
good reason I definitely do not want to do that.  I need some syntax 
that assures my use of existing KSK and ZSK keys and prevents bind from 
changing them.


Actually, I do exactly what you're doing in several circumstances.  I 
use the deprecated `dnssec-keymgr` on a few different systems, including 
a signing service that I run, in order to maintain keys.  (As is 
probably the case with you, there's already some tooling built around 
generating, rotating, backing up, etc. of keys that I have not yet 
integrated with the newer KASP regime.) I *do* plan to refactor these 
different services to use KASP, but I still need to do some more 
testing/QA/etc.  On my personal domains (including the ironically-named 
one I am sending this from), I have mostly switched to 100% KASP.  KSKs 
properly don't rotate, and ZSKs do only if I request.


I wonder if the bind developers are open to allowing a command in the 
new policy statement structure that blocks this 'feature' of 
automatically updating ZSK and KSK?  If there is such a thing already, I 
will be delighted to hear that I had missed seeing it.


I believe the following KASP will do what you want it to do:

dnssec-policy pkcs11 {
keys {
zsk lifetime unlimited algorithm 13;
ksk lifetime unlimited algorithm 13;
};
signatures-refresh P26D;
signatures-validity P30D;
signatures-validity-dnskey P30D;
};

This policy has been running for about 6 months and BIND has never seen 
fit to roll any keys, ZSK or KSK.  (You can safely ignore the sig 
validity/refresh stuff; I add that for other reasons.)



A lot of pain and suffering in this world comes from people being sure 
they have a 'better idea' and everybody needs to do whatever.  This 
feels a bit like that.  A command that gives choice and real certainty 
would be great.


That's certainly true in a lot of cases.  We hear stories all of the 
time (and sometimes experience them) about how well-intentioned software 
developers try to reduce code complexity and end up inadvertently 
generating work for users and admins.  Some of that's inevitable as we 
keep up with evolving software and best-practices.  (It also provides 
some level of job security :-D.)


But in this case, I think the BIND developers did a good job ensuring 
there was a way to create policies that integrate well with 
key-management regimes external to BIND.


michael
--
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: BIND 9.18 unable to successfully transfer zone from axfrdns primary

[Michael Sinatra]

Right, BIND 9.18 now enforces Section 2.2 of RFC 5936, specifically, this:
   "The AXFR server MUST copy the
   Question section from the corresponding AXFR query message into the
   first response message's Question section.  For subsequent messages,
   it MAY do the same or leave the Question section empty."

There are some older implementations out there that don't do this 
correctly.  I have a vendor supported IPAM implementation, where I have 
gone back to the vendor and quoted the above, and they have fixed the 
implementation.


michael

On 8/31/23 17:34, Ian Bobbitt wrote:
That gets me more information, and I think puts the problem onto 
axfrdns. Thanks.


xfer-in: info: zone example.net/IN: Transfer started.
xfer-in: debug 1: zone example.net/IN: forced reload, requesting AXFR of 
initial version from 198.51.100.1#53
xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: 
connected using 198.51.100.1#53
xfer-in: debug 3: transfer of 'example.net/IN' from 198.51.100.1#53: 
sent request data
xfer-in: debug 3: transfer of 'example.net/IN' from 198.51.100.1#53: 
missing question section
xfer-in: error: transfer of 'example.net/IN' from 198.51.100.1#53: 
failed while receiving responses: FORMERR

xfer-in: debug 1: zone example.net/IN: zone transfer finished: FORMERR
xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: 
Transfer status: FORMERR


Looks like this isn't going to be solvable on my side. 
https://gitlab.isc.org/isc-projects/bind9/-/blob/v9.18.17/lib/dns/xfrin.c?ref_type=tags#L1657-1663


Packet capture confirms that we are indeed not getting a response with 
the question section.


I'm running the same version of dig, on the same system. Interesting 
that dig isn't as strict about this.


-- Ian

On 8/31/23 7:58 PM, Mark Andrews wrote:
Set debug level 3 on the xfrin channel.  There are some debug level 
messages that really should be set to error level in lib/dns/xfrin.c 
on FORMERR.


Also make sure you are running dig from the same version as later 
versions are more strict in parsing responses from the wire.



On 1 Sep 2023, at 09:23, Ian Bobbitt  wrote:

I have a system running BIND 9.18.17 that needs to transfer a zone 
from djbdns/axfrdns. I receive FORMERRs, and haven't been able to get 
any log messages indicating the problem.


xfer-in: info: zone example.net/IN: Transfer started.
xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: 
connected using192.0.2.1 #53
xfer-in: error: transfer of 'example.net/IN' from 198.51.100.1#53: 
failed while receiving responses: FORMERR
xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: 
Transfer status: FORMERR
xfer-in: info: transfer of 'example.net/IN' from 198.51.100.1#53: 
Transfer completed: 0 messages, 0 records, 0 bytes, 0.008 secs (0 
bytes/sec) (serial 0)


This replaced a long obsolete system running 9.8.2 that was able to 
successfully transfer the zone. I can also successfully transfer the 
zone with `dig -t axfr ...` from the new system, which gives no 
errors. named-checkzone on the resulting data also gives no errors, 
and BIND is able to successfully load it as a primary.


How do I go about finding the cause of the FORMERR and resolve it?

-- Ian
--
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

--
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: Nice new logging feature

[Michael Sinatra]

On 12/16/21 06:42, Borja Marcos wrote:




On 16 Dec 2021, at 14:55, Reindl Harald  wrote:



Am 16.12.21 um 14:49 schrieb Borja Marcos:


bind-9.16.23-1.fc34.x86_64

16-Dec-2021 13:08:10.598 lame-servers: connection refused resolving 
'ns2.serverion.eu/A/IN': 94.228.210.122#53
16-Dec-2021 13:11:29.269 lame-servers: host unreachable resolving 
'250.84.141.45.in-addr.arpa/PTR/IN': 45.79.19.196#53
16-Dec-2021 13:11:31.804 lame-servers: host unreachable resolving 
'250.84.141.45.in-addr.arpa/PTR/IN': 96.126.123.244#53
16-Dec-2021 13:12:10.567 lame-servers: host unreachable resolving 
'166.84.141.45.in-addr.arpa/PTR/IN': 198.58.118.167#53
16-Dec-2021 13:12:13.903 lame-servers: host unreachable resolving 
'166.84.141.45.in-addr.arpa/PTR/IN': 45.33.18.44#53
16-Dec-2021 13:12:14.034 lame-servers: host unreachable resolving 
'166.84.141.45.in-addr.arpa/PTR/IN': 45.33.2.79#53
16-Dec-2021 13:12:15.773 lame-servers: host unreachable resolving 
'166.84.141.45.in-addr.arpa/PTR/IN': 45.33.23.183#53
16-Dec-2021 13:12:15.938 lame-servers: host unreachable resolving 
'166.84.141.45.in-addr.arpa/PTR/IN': 96.126.123.244#53

Not for me definitely, but I am not running Linux. This is a FreeBSD port of 
the ISC release.
Does that version include some back ported code from bind 9.17?


i doubt that Fedora does any functional patching, maybe some of the build flags 
while i'm not sure if the stuff shown at startup is really all


Hmm. Doesn’t look like that, I have compared the build options and it doesn’t 
explain it.


I can confirm the same logs are appearing in my 'lamers.log' file on a 
FreeBSD 12.2 system running BIND 9.16.22 (about to be upgraded).  Maybe 
your `logging {}` stanza is missing the appropriate incantation?


Mine are fairly plain:
[...]
  channel lamers {
file "/var/log/named/lamers.log" versions 9;
print-time yes;
  };
[...]
  category lame-servers { lamers; };
[...]

michael
___
Please 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: BIND 'max-cache-size' Value on FreeBSD-13.0

[Michael Sinatra]

On 9/2/21 2:59 PM, Mark Tinka wrote:



On 9/2/21 23:51, Michael Sinatra wrote:



I have noticed this also and have opened a (similar but different) 
issue, but it's a bit weird how it manifests itself.


On your freebsd installation, make sure that all of your interfaces 
are configured and that bind can listen on them.  (They don't 
necessarily need to be up; they just need to be configured.)


Also, 'listen-on[-v6] any;' is more likely to prevent this kind of 
memory leaking than having it listen on explicit addresses.  But the 
way I can (more) reliably reproduce it is to have a 'listen-on' 
statement that references a non-existent interface/address.


I think this is a libuv problem, but I have been really short on time 
to troubleshoot.  But in the meantime, I would check on your 
'listen-on' statements and make sure there aren't any stray addresses 
in there.


What we have on all of our name servers is the below:

// If named is being used only as a local resolver, this is a safe default.
// For named to be accessible to the network, comment this option, specify
// the proper IP address, or delete this option.
//  listen-on   { 127.0.0.1; };

// If you have IPv6 enabled on this system, uncomment this option for
// use as a local resolver.  To give access to the network, specify
// an IPv6 address, or the keyword "any".
     listen-on-v6    { ::1; };


It *feels* like the above ^^ could be the culprit.  'listen-on any' 
ought to listen on the loopback interface in addition to all other 
configured ethernets and loopbacks.  OTOH, the libuv-based versions of 
BIND (e.g. >=9.16.x) appear to get kind of weird/confused with certain 
types of listen-on statements.



     listen-on-v6    { any; };

We are running dual-stack on all name servers, and both IPv4 and IPv6 
reachability is confirmed solid.


On IPv4, we are listening on just the main interface. On IPv6, we are 
listening on both the localhost and the main interface. Not sure if this 
matters.


For local resolution on each name server, it refers to localhost for 
both IPv4 and IPv6 in '/etc/resolv.conf'. Given our configuration, it's 
using ::1 for local resolution, whenever that may be required, since 
127.0.0.1 has nothing listening on it. Thanks.


'listen-on any;' is the default for v4, so you should actually be 
listening on 127.0.0.1 in addition to everything else (since all of your 
listen-on's for v4 appear to be commented out).  You *should* be able to 
remove 'listen-on-v6{ ::1; };' and just leave the 'listen-on-v6{ 
any; };' in place.  Doing a 'sockstat | grep named' on FreeBSD should 
confirm this once you restart named (pretty sure you already knew that, 
but I thought I'd mention it for completeness).


michael

___
Please 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: BIND 'max-cache-size' Value on FreeBSD-13.0

[Michael Sinatra]

On 9/2/21 2:35 PM, Mark Tinka wrote:

Not sure if this issue offers some clue:

https://gitlab.isc.org/isc-projects/bind9/-/issues/2575

I see its maintainer just closed it 11hrs ago...


I have noticed this also and have opened a (similar but different) 
issue, but it's a bit weird how it manifests itself.


On your freebsd installation, make sure that all of your interfaces are 
configured and that bind can listen on them.  (They don't necessarily 
need to be up; they just need to be configured.)


Also, 'listen-on[-v6] any;' is more likely to prevent this kind of 
memory leaking than having it listen on explicit addresses.  But the way 
I can (more) reliably reproduce it is to have a 'listen-on' statement 
that references a non-existent interface/address.


I think this is a libuv problem, but I have been really short on time to 
troubleshoot.  But in the meantime, I would check on your 'listen-on' 
statements and make sure there aren't any stray addresses in there.


michael
___
Please 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

Does BIND support "conservative" (RFC 6781, sec 4.1.4) algorithm rollovers?

[Michael Sinatra]

Hi,

I have, in the past, used the "conservative" approach to performing 
algorithm rollovers for various domains.  For many domains, this is 
probably overkill, but I'd prefer to have the option of doing it, 
especially for those mission-critical domains where you really don't 
want to rely simply on the hope that nobody who needs to reach you (or 
your org/company) is using a resolver that is still following the 
strictest interpretation of RFC 4035, section 2.2.


In the past, I have handled this completely manually, signing the zone 
using dnssec-signzone to sign the zone with keys of both algs before 
(again manually) including the the new alg keys in the DNSKEY RRSET. 
But for zones which I am inline-signing as a provider for someone else, 
I would like to use a more automated method.  It doesn't appear that 
BIND currently supports this, either with dnssec-keymgr and 
'inline-signing' or with KASP.


I did try the trick of setting the key metadata manually ('publish' in 
the future and 'activate' in the past), but BIND 'inline-signing' would 
not sign the zone prior with the key prior to its publication, despite 
my timing metadata settings.


So I am assuming that only the "liberal" approach is supported.  One 
thing I thought of was trying a "moderate" approach, where the various 
TTLs are manipulated so that the zone RRSIGs expire quickly before the 
new alg is added and then flipping it so that the DNSKEY RRSET expires 
quickly and the zone/RRSIG TTLs stay in cache longer.  But that is still 
a fairly tricky approach and I am not sure it would work...


michael
___
Please 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: BIND-9.16.1 memory leak?

[Michael Sinatra]

On 2020-04-17 06:45, sth...@nethelp.no wrote:
> We have what appears to be a significant memory leak in BIND-9.16.1.
> 
> Environment:
>  FreeBSD 12.1-STABLE.
>  BIND-9.16.1 installed from packages.
>  Also uses libuv-1.35.0 installed from packages.
>  Authoritative only.
>  Around 800 zones of varying sizes. DNSSEC in use.

Additional datum, as I am seeing the same thing:

- FreeBSD 12.1-RELEASE-p3
- BIND-9.16.1 compiled from ports/poudriere via a local package build
server (no options changed, though, so it likely could have been
installed from the FreeBSD package repo).
- Authoritative only
- `rndc status` reports 1058 zones (69 automatic)
- Host is a VM with 16GiB allocated and 4 CPU cores
- named running for approx 2.5 weeks (wall-clock)

Current BIND status (from `top`):

  PID USERNAMETHR PRI NICE   SIZERES STATEC   TIMEWCPU
COMMAND
 1707 bind 14  520  5312M  5260M sigwai   2  34.4H   5.79% named

A recursive-only server, running the same versions of all software, on
an identically-provisioned VM, running for the same amount of wall-clock
time (approximately 2.5 weeks) looks like this:

  PID USERNAMETHR PRI NICE   SIZERES STATEC   TIMEWCPU
COMMAND
 1485 bind 14  520   927M   890M sigwai   3  89.6H  32.86% named

The recursive memory footprint looks normal.

Contrast that with a separate server:

- FreeBSD 11.3-RELEASE-p7
- BIND 9.14.11 compiled from ports/poudriere via a local package build
server (no options changed, though, so it likely could have been
installed from the FreeBSD package repo).
- Authoritative only + recursive only running in a separate jail
- Same configuration as above, only a bit busier
- Host is standalone with 96GiB RAM and 8 cores

In the `top` output below, both the jailed named processes are shown.
The busier one is the authoritative-only:

  PID USERNAME  THR PRI NICE   SIZERES STATE   C   TIMEWCPU
COMMAND
  896 bind   18  520   956M   927M sigwai  0  99.2H  30.03%
named
 1584 bind   18  520  1171M  1080M sigwai  2 166.2H  13.47%
named

It definitely looks like a memory leak in 9.16.1 when configured as
authoritative-only.  The leak seems slow enough as to be manageable, but
the footprint does appear to growing monotonically (and is still
growing--by another 4M as I wrote this email).

michael
___
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

redundant bump-in-the-wire signers using BIND

[Michael Sinatra]

To close the loop a bit on this...

On 05/22/18 03:22, Tony Finch wrote:
> Michael Sinatra  wrote:
>>
>> My only concern is that serial numbers might get out of sync between the
>> two signers at some point.
> 
> You can avoid this problem with `serial-update-method unixtime`.
> 
> HOWEVER! I think you are going to have problems with inconsistent IXFRs
> depending on which signer the public authoritative servers talk to. You
> can work around this by only using AXFR, by turning off `provide-ixfr` and
> `request-ixfr`.

Thanks, Tony, that's a great point, and it ultimately led me to the work
done on by the yeti-dns project.  One of their experiments was a
multi-signer, multi-ZSK setup.[1]  That's a bit different from what I am
doing, as I am actually synching the private keys.  However, since I am
also signing with ECDSA, and the major crypto libraries don't yet
support deterministic ECDSA, I am going to have differing sigs no matter
how synchronized they are.

In testing this setup over the past several weeks, it appears that BIND
operates in the same way as NSD, in that, if it tries an ixfr and can't
cleanly diff the updated zone into the old one, it falls back to axfr.
Here's an example log:

18-Jun-2018 14:25:42.698 transfer of '6tap.net/IN' from
cleverly:obfuscated:ipv6:server-address#53: connected using
cleverly:obfuscated:ipv6:client-address#41964
18-Jun-2018 14:25:42.724 transfer of '6tap.net/IN' from
cleverly:obfuscated:ipv6:server-address#53: failed while receiving
responses: not exact
18-Jun-2018 14:25:42.724 transfer of '6tap.net/IN' from
cleverly:obfuscated:ipv6:server-address#53: Transfer status: IXFR failed
18-Jun-2018 14:25:42.724 transfer of '6tap.net/IN' from
cleverly:obfuscated:ipv6:server-address#53: Transfer completed: 0
messages, 11 records, 0 bytes, 0.025 secs (0 bytes/sec)
18-Jun-2018 14:25:43.203 transfer of '6tap.net/IN' from
cleverly:obfuscated:ipv6:server-address#53: connected using
cleverly:obfuscated:ipv6:client-address#41965
18-Jun-2018 14:25:43.229 transfer of '6tap.net/IN' from
cleverly:obfuscated:ipv6:server-address#53: Transfer status: success
18-Jun-2018 14:25:43.229 transfer of '6tap.net/IN' from
cleverly:obfuscated:ipv6:server-address#53: Transfer completed: 1
messages, 61 records, 5366 bytes, 0.025 secs (214640 bytes/sec)


The fallback to AXFR is not an issue for the zones I am currently
signing because they are not that big and don't change very often (there
are no dynamic DHCP names in these zones, for example).  So it does seem
like this will work, but I am doing some more testing (and have run into
another issue, which will be in a different thread).  Thanks, though for
the heads up.

michael

[1] See
https://raw.githubusercontent.com/BII-Lab/Yeti-Project/master/doc/Report-MZSK.md
and https://tools.ietf.org/html/draft-song-yeti-testbed-experience-06
(section 4.2.1) for more info.  To be on the safe side, it may make
sense to just configure AXFR all of the time, but BIND seems to be doing
a good job of falling back to AXFR when it detects an inconsistency.


___
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

redundant bump-in-the-wire signers using BIND

[Michael Sinatra]

Hi all:

First, let me explain the trade-off I am trying to manage (as succinctly
as possible):

My current setup has an DNS/IPAM system that backs up to a redundant one
in a different location, a bump-in-the-wire hardware signing appliance
(different from the IPAM), and a bunch of authoritative slaves running
BIND in an anycast cloud.

+-+ +---+
|  IPAM   | --> | HW Signer | --> (Slaves)
+-+ +---+

The HW signer also backs up to a redundant one elsewhere.  Failover for
both can either be manual or a complex combination of heartbeats and
synchronization that yields an active-standby arrangement.  I choose
manual here because our needs don't require immediate, seamless
failover, and I don't want the complexity.

Now, I'd like to replace the HW signers with VMs running BIND.  HSM is
not a requirement for me.  I can run dnssec-keymgr to generate keys on
one of the BIND VMs and then rsync the keys to the other (again,
geographically redundant).  The configurations are similarly synched
between the two.

I am trying to go for reasonable, practical security for the secret
keys, but I also want them backed up to one other location.  So having 2
geographically redundant VMs that can be locked down so that they only
talke to the IPAM and the slaves seems reasonable.  Putting secret keys
on all of the slaves, and having them do inline signing seems a bit more
reckless.  (There are other reasons I'd like to maintain the
bump-in-the-wire method, but I won't go into them now.)

My initial thought is that, as long as I can keep the keys and config in
sync between the two signing VMs, I can keep both VMs running bind *and*
can treat them both as stealth masters and have all of the slaves
configured to use both VMs as masters.  This obviates the need for
manual failover of the *signers*.

This seems to work in practice with a legacy zone that I am using for
testing.  The two signers sometimes sign at slightly different times, so
the signatures are different, but they both produce valid signatures.

My only concern is that serial numbers might get out of sync between the
two signers at some point.  If signer 1 is down for an extended period
of time, signer 2 may go through a few re-sign cycles and have a
consistently higher serial number in the case of a zone that isn't
modified much.

I can see two possible solutions: 1. manually "jiggle the handle" on the
IPAM by bumping the serial number to be greater than that of the larger
signer's SOA serial.  (The IPAM uses date/time serial format, so this
should be easy.) 2. use 'rndc signing -serial' to set the serial number,
possibly in concert with a monitoring script that checks to see if the
serial is out of sync.

Has anyone implemented anything like this?  Any other gotchas I should
be thinking about?  BIND does a good job of doing the right thing with
serial numbers, but I have yet to see (via google-foo or even bing-foo)
any evidence of anyone trying to do an active-active redundant
configuration with BIND inline-signing.

thanks!
michael
___
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: Unable to slave root zones

[Michael Sinatra]

On 04/07/17 09:21, Tony Finch wrote:

Mark Knight  wrote:


I've just noticed (after the slave zones expired), that the root name servers
have been refusing my zone transfer requests since the end of March.


This is because Cloudflare are now helping isc.org to host
f.root-servers.net, and the Cloudflare instances don't allow zone
transfers.

https://lists.dns-oarc.net/pipermail/dns-operations/2017-March/016150.html

I have switched to transferring the root zone from k.root-servers.net.


ICANN has "sanctioned" servers for doing root zone transfers that are 
separate from the root DNS servers.  See:


http://www.dns.icann.org/services/axfr/

It's probably better to use the servers listed there (although they do 
appear to be US-centric), to avoid having to deal with changes akin to 
f-root.



michael
___
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: MAcOS X 10.9 upgrade removes BIND

[Michael Sinatra]

On 10/25/13 1:33 PM, Carsten Strotmann wrote:
 Hello Eduardo,
 
 thanks for confirming that MacOS X removed BIND.
 
 Our new BIND installers for MacOS X 10.9 are now available at 
 http://support.menandmice.com/download/bind/macosx/10.9-Mavericks/
 
 I've build BIND 9.9.4 (with and without RRL) and BIND 9.8.6. If anyone
 need 9.6-ESV let me know.
 
 Please report any issues with this installers to me.

Thanks to Carsten and Men and Mice for doing this.

I usually maintain the latest BIND on my Mac using MacPorts.  It looks
like you can still do that on Mavericks, but there some work
(http://www.ghostwheel.com/merlin/Personal/notes/2013/10/05/macports-on-mavericks/)
you have to do--MacPorts doesn't currently support Mavericks out of the
box.  The good news is that it looks like you can still download a
supported version of xcode for Mavericks.

michael


___
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

[Michael Sinatra]

It appears to me that the NSEC3 record that is denying the existence of
the DS record for ic.fbi.gov does not have a corresponding RRSIG.
That's based on a fairly cursory glance.

This seems to be the case for all of the NSEC3 records in fbi.gov.

Something's messed up in fbi.gov.

michael

PS: Note below that the SOA record has an RRSIG but the NSEC3 record
doesn't.  Querying for any non-existing record (including for
properly-delegated domains without DS records) in fbi.gov will cause a
validation failure.

schuylkill:~ ms$ dig +cdflag +dnssec ds ic.fbi.gov

;  DiG 9.9.3-P1  +cdflag +dnssec ds ic.fbi.gov
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 23239
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;ic.fbi.gov.IN  DS

;; AUTHORITY SECTION:
fbi.gov.600 IN  SOA ns1.fbi.gov. dns-admin.fbi.gov. 
2013071601 7200
3600 2592000 43200
fbi.gov.600 IN  RRSIG   SOA 7 2 600 20131014154120 
20130716154120 32497
fbi.gov. mjg99/NUrrtRn51Ju90FeYyIlF0IITjP/qqk4yWjVsLSDVZIr3uQ9sAn
3e/WrxWeSMteGUMixVDzCBbky5M6/hpO26v2AyKh4IV3I/gIBsy0daS6
MeOMgwhF6EK2HcFoSU24i2Np3GTY05UjpTxlcz1vvoJmBvUOgFbOBJ6d eJM=
7PLEGSLCCDFUBJ53UG8E19T9MH9HIP2B.fbi.gov. 600 IN NSEC3 1 0 10 BBAB
7PPJ5IC2PQQ5HTFGU7I2908P3DRN5FUO MX TXT RRSIG





On 7/17/13 10:05 AM, Sten Carlsen wrote:
 From here i see a fast response using the local server:
 ~
 $ dig ic.fbi.gov
 
 ;  DiG 9.7.6-P1  ic.fbi.gov
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: _/*NOERROR*/_, id: 2421
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;ic.fbi.gov.INA
 
 ;; AUTHORITY SECTION:
 fbi.gov.600INSOAns1.fbi.gov. dns-admin.fbi.gov.
 2013071601 7200 3600 2592000 43200
 
 ;; Query time: 158 msec
 ~
 No error, but no address.
 
 Using Google I get a servfail:
 ~
 $ dig ic.fbi.gov @8.8.8.8
 
 ;  DiG 9.7.6-P1  ic.fbi.gov @8.8.8.8
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: *_/SERVFAIL/_*, id: 11426
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;ic.fbi.gov.INA
 
 ;; Query time: 102 msec
 ;; SERVER: 8.8.8.8#53(8.8.8.8)
 ;; WHEN: Wed Jul 17 18:54:41 2013
 ;; MSG SIZE  rcvd: 28
 ~
 SERVFAIL, so something is unclear.
 
 
 On 17/07/13 18:49, 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

 On my BIND server, I see the following in a packet capture:

   0.00 1.1.1.1 - 156.154.64.48 DNS Standard query A ic.fbi.gov
   0.026504 156.154.64.48 - 1.1.1.1 DNS Standard query response
   0.026927 1.1.1.1 - 156.154.69.48 DNS Standard query DS 
 7PLEGSLCCDFUBJ53UG8E19T9MH9HIP2B.fbi.gov
   0.042998 156.154.69.48 - 1.1.1.1 DNS Standard query response, No such name
   0.043485 1.1.1.1 - 156.154.67.48 DNS Standard query DS 
 97S2G907NEFOJ79P721E4FEQ9LR3IT1S.fbi.gov
   0.048186 156.154.67.48 - 1.1.1.1 DNS Standard query response, No such name
   0.048595 1.1.1.1 - 156.154.67.48 DNS Standard query DS 
 6VTIGSHGMAR334K0PFDJ5ODURDL6CUFP.fbi.gov
   0.053765 156.154.67.48 - 1.1.1.1 DNS Standard query response, No such name
  30.043683 1.1.1.1 - 156.154.65.48 DNS Standard query DS 
 GON9PTIAV4KLS7E9NMHD9LG02RQD6K3I.fbi.gov
  30.061169 156.154.65.48 - 1.1.1.1 DNS Standard query response, No such name

 So it seems like the issue is related to the DS records queried not
 existing, but I've checked a few DNSSEC validation tools out there by
 plugging ic.fbi.gov in and things appear to check out.  This could be
 firewall related on my side (we have Checkpoint firewalls), but other
 DNSSEC queries appear to be working OK.

 A dig @8.8.8.8 +dnssec ic.fbi.gov works OK as well also making me think
 the issue is somehow on my side

 Am reading up on additional troubleshooting steps for DNSSEC, but still
 wrapping my head around concepts.

 Anyone have any tips as to where to start digging next based on what
 I'm seeing above?

 Thanks,
 Ray
 ___
 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
 
 -- 
 Best regards
 
 Sten Carlsen
 
 No improvements come from shouting:
 
MALE BOVINE MANURE!!! 
 
 
 
 

Re: Troubleshooting DNSSEC issue w/ ic.fbi.gov

[Michael Sinatra]

On 7/17/13 2:38 PM, Mark Andrews wrote:
 
 In message 1673423961.50595218.1374096753729.javamail.r...@k-state.edu, 
 Lawr
 ence K. Chen, P.Eng. writes:


 - Original Message -
 On Wed, Jul 17, 2013 at 01:58:25PM -0400, Bill Owens wrote:
 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.


 Thanks for the replies, all.  Am trying to find a hostmaster contact
 at
 fbi.gov to make them aware.

 In the meantime, I'll convince Sendmail to not try to look up this
 domain during sender verification. :)

 Ray
 ___


 Try contacting dotgov.gov

 regist...@dotgov.gov or 877-734-4688 or 703-948-0723

 They'll have phone numbers for the people they need to contact for fbi.gov to
  get things fixed.
  
 Which would not be required if .gov had a properly functioning whois.
 Could all US residents on this list contact your Congress Critters
 and complain about this stupidity.

The SOA RNAME should work:

fbi.gov.600INSOAns1.fbi.gov. dns-admin.fbi.gov.
2013071601 7200 3600 2592000 43200

fbi.gov's MX is resolvable down to an IP address, so mail should get
through, depending on your MTA.

michael


___
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: ISC Bind in Active Directory

[Michael Sinatra]

On 10/18/12 11:03 AM, Aaron Thompson wrote:
 Hi All,
 
 I'm hopping to get some feedback from people who use ISC Bind and DHCPD
 in Active Directory environments.
 
 Currently we use Bind/DHCPD for dynamic DNS and DHCP.  It's been a
 pretty stable service, redundant and we are polling statistics with
 Cacti.  There is concern by Management of using a somewhat non standard
 approach for Active Directory SRV records being handled by ISC services
 and not AD.

Microsoft may tell management that it's non-standard, but it's not.
What you're describing is very common, especially among EDUs.

Management's attitude appears to be based on two myths:

1. You must use AD integrated DNS for your AD installation.
2. You must use DDNS for your AD installation (at least for the relevant
SRV records).

Neither of these are true, and plenty of places have gotten by for at
least a decade with *static* SRV records in a BIND server.

A few years ago, Gartner did a paper where they discussed new features
that Microsoft claims require AD-integrated DNS.  Gartner's conclusion
was that this is basically not true and that if the current BIND-AD
integration is working for you, then you should stick with it.

[snip]

 Overall it's been a very stable design for the last 5+ years.

It sounds like something that's not broken and shouldn't be fixed.
Again, this is the experience at other EDUs.

 If you have any relevant feed back I would appreciate it.  I'm looking
 for information on experience with Active Directory integration with ISC
 or if anyone has had problems/stability issues with AD doing DNS/DHCP or
 AD working with ISC.
 
 Thanks in advance.
 
 Here's a brief survey http://www.surveymonkey.com/s/2VYNKWR for
 Schools that have ISC running in an AD environment.
 
 http://www.surveymonkey.com/s/2VYNKWR

Done, on behalf of the other Berkeley. :)

michael

___
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: Moving from type forward to type static-stub

[Michael Sinatra]

On 9/20/12 5:49 PM, Oscar Ricardo Silva wrote:

 If I'm correct, it will send non-recursive queries to the listed servers
 and will honor delegations. I've tested this configuration in our lab
 and it all appears to be working.

Yup, static stub will do exactly that.

 With our configuration, are there any downsides to changing from forward
 zones to static-stub?  Any gotchas I should know about?

I am pretty sure that the recursive server will still cache the entries
it receives from the static-stub server.  If your goal is for
instantaneous updates on your recursives when your authoritatives get
update, I don't think it will work as well as just slaving the zones.

If the goal is for the recursives to see an internal view of the zones,
then static-stub will work great.

 At this time we
 don't have dnssec validation turned on.  We tried it and had too many
 problems with misconfigured domains not resolving properly so backed out.

It's time to back in again (front in?).  Now that Comcast is validating,
any mistakes that people make will get fixed right quick.  1.7 million
people doing validation is good incentive to get things right and fix
them quickly.  At UC Berkeley, validation has been turned on for four
years now and only a handful of domains have required special handling.

All of the emphasis on signing for DNSSEC is great, but DNSSEC can't
really work without validation.

michael
___
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: OpenSSL problem: bind98-base FreeBSD port

[Michael Sinatra]

On 07/08/12 09:54, Matthew Pounsett wrote:

08-Jul-2012 16:45:00.352 initializing DST: openssl failure
08-Jul-2012 16:45:00.352 exiting (due to fatal error)


In particular the logs above suggest that named is unable to find the 
necessary openssl libraries.  In the case where openssl 1.x.x is 
compiled with shared libraries enabled, named can't see the openssl 
engines (necessary for GOST crypto support) in its chrooted environment.


What makes me doubt what I just said is that this has been an issue for 
more than a year now, so I am not sure why you have escaped it for so 
long.  I assume you had openssl 1.0.x installed before you upgraded 
it--or was it an earlier version?


At any rate, if you run make config in /usr/ports/security/openssl, it 
gives you the option of compiling the libraries statically.  I have 
successfully done this in the past and it has worked.  However, anything 
else that is currently depending on the openssl shared library from 
ports (as opposed to the bundled system) will need to be recompiled 
before it will work, as will bind 9.8.


Doug Barton may have some better ideas as to how best to make it all work.

michael

___
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: VMware Bind

[Michael Sinatra]

On Tue, 5 Jun 2012, Manson, John wrote:


Will bind run on VMware?


Yes.  I have a few machines running BIND 9.9.x on FreeBSD as a guest os on 
vmware.


michael
___
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: zone transfer with DIG: SOA duplicate

[Michael Sinatra]

On 03/19/12 10:33, hugo hugoo wrote:

Dear all,

I have this strange behaviour when I do a zone transfer with the
following commande:

dig @name_server zone_name AXFR


== I received 2 SOA records (duplicates).

One SOA record is at the end of the received information.


Is this normal?


Yes.

In recent versions of dig, you can use the following option, as 
documented in the man page:


   +[no]onesoa
   Print only one (starting) SOA record when performing an 
AXFR. The

   default is to print both the starting and ending SOA records.


michael
___
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: Name Resolution issue with one domain

[Michael Sinatra]

On 03/19/12 13:28, babu dheen wrote:

Dear Support,
I am trying to resolve www.dubaiairport.com
http://www.dubaiairport.com from my GW BIND server as below. But not
getting any output
$ dig A www.dubaiairport.com http://www.dubaiairport.com
;  DiG 9.3.4-P1  A www.dubaiairport.com
http://www.dubaiairport.com
;; global options: printcmd
;; connection timed out; no servers could be reached
Whereas, when i try through dubaiairport.com NS, i am getting the
response as below. What could be the problem. Any idea?
$ dig @213.42.52.79 A www.dubaiairport.com http://www.dubaiairport.com
;  DiG 9.3.4-P1  @213.42.52.79 A www.dubaiairport.com
http://www.dubaiairport.com
; (1 server found)
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 48514
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.dubaiairport.com. IN A
;; ANSWER SECTION:
www.dubaiairport.com http://www.dubaiairport.com. 7200 IN A 213.42.55.169
;; Query time: 127 msec
;; SERVER: 213.42.52.79#53(213.42.52.79)
;; WHEN: Mon Mar 19 23:25:35 2012
;; MSG SIZE rcvd: 54


When you see this sort of situation, a good guess is that there is an 
authority mismatch and some/all of the authoritative NS records listed 
in the child zone are not responding.  In this case, there is an 
authority mismatch:


dig +trace ns dubaiairport.com

[skip root response]

dubaiairport.com.   172800  IN  NS  dcaowa01.dubaiairport.com.
dubaiairport.com.   172800  IN  NS  svr-b003.dubaiairport.com.
[RRSIG deleted]
;; Received 608 bytes from 192.12.94.30#53(192.12.94.30) in 724 ms

dubaiairport.com.   7200IN  NS  secdns.dubaiairport.com.
dubaiairport.com.   7200IN  NS  auhans2.ecompany.ae.
dubaiairport.com.   7200IN  NS  dxbans2.ecompany.ae.
dubaiairport.com.   7200IN  NS  dxbans1.ecompany.ae.
dubaiairport.com.   7200IN  NS  dcaowa01.dubaiairport.com.
dubaiairport.com.   7200IN  NS  auhans1.ecompany.ae.
dubaiairport.com.   7200IN  NS  svr-b003.dubaiairport.com.
;; Received 323 bytes from 213.42.52.79#53(213.42.52.79) in 279 ms

One of the above DNS servers, secdns.dubaiairport.com, isn't responding 
for me.  Sometimes that's enough to cause intermittent timeouts for dig.


dig +nssearch dubaiairport.com
SOA dcaowa01.dca.com. administrator.dubaiairport.com. 2005061961 900 600 
86400 7200 from server 213.42.52.79 in 278 ms.
SOA dcaowa01.dca.com. administrator.dubaiairport.com. 2005061961 900 600 
86400 7200 from server 195.229.237.52 in 278 ms.
SOA dcaowa01.dca.com. administrator.dubaiairport.com. 2005061961 900 600 
86400 7200 from server 194.170.1.99 in 282 ms.
SOA dcaowa01.dca.com. administrator.dubaiairport.com. 2005061961 900 600 
86400 7200 from server 213.42.52.75 in 288 ms.
SOA dcaowa01.dca.com. administrator.dubaiairport.com. 2005061961 900 600 
86400 7200 from server 194.170.1.6 in 289 ms.
SOA dcaowa01.dca.com. administrator.dubaiairport.com. 2005061961 900 600 
86400 7200 from server 194.170.1.7 in 293 ms.
;; connection timed out; no servers could be reached [referring to 
secdns.dubaiairport.com]


michael



___
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 ed.gov

[Michael Sinatra]

Please be aware that RFC 2671, which specifies EDNS0, allows for buffer 
sizes to reach 64k, not just 4k.  Most implementations default to 4k, 
but the buffer size can easily be set higher.  Moreover, the EDNS0 
buffer size merely specifies the size where the UDP response becomes 
truncated and must fall over to TCP.  If you limit UDP responses and 
also block TCP, you may also someday block legitimate traffic.  At this 
point it's extremely unlikely, but at one time DNS responses in the 
range of 1k-2k seemed extremely unlikely...


michael

On 01/19/12 12:34, Faehl, Chris wrote:

Josh - are you using Cisco firewalls? We've seen problems resolving other
.gov sites due to EDNS/DNSSEC requests being truncated by dns inspect
size set to 512 bytes (out-of-box conf). Changing to 4k yielded good
results and fixed those problems without other operational impact.

Chris Faehl
Director, Cloud Architecture
RightNow Technologies

On 1/19/12 12:39 PM, Baird, Joshjba...@follett.com  wrote:


Ugly fix, but it does work.  I already had that in place as a band-aid
anyways.

Josh

-Original Message-
From: wbr...@e1b.org [mailto:wbr...@e1b.org]
Sent: Thursday, January 19, 2012 2:36 PM
To: Baird, Josh
Cc: bind-users@lists.isc.org
Subject: Re: Problem with ed.gov

Josh wrote on 01/19/2012 02:06:05 PM:


My resolvers seem to be having problems resolving ed.gov hosts.

Others

have reported similar problems, but I am having trouble figuring out
where the problem lies.  Some other resolvers seem to be resolving
ed.gov correctly.  I am able to query their authoritative servers
directly from the same network where my resolvers are located.  But,

my

resolvers are not able to recurse to them.


[snip]

Is anyone else having problems?  Can you spot anything that could be
preventing my/our resolvers to successfully query this?



Years ago, we had problems with ed.gov.  We added the following to our
config on 2009-08-11 to forward to their name servers:

zone ed.gov {
type forward;
forwarders { 148.9.101.50; 148.9.101.52; 160.109.63.185;
160.109.63.186;
  };
};

Ugly fix? You bet!  But the problems went away...

IIRC, we did network sniffs at the perimeter and a bunch of other
troubleshooting to no avail.



Confidentiality Notice:
This electronic message and any attachments may contain confidential or
privileged information, and is intended only for the individual or
entity
identified above as the addressee. If you are not the addressee (or the
employee or agent responsible to deliver it to the addressee), or if
this
message has been addressed to you in error, you are hereby notified that

you may not copy, forward, disclose or use any part of this message or
any
attachments. Please notify the sender immediately by return e-mail or
telephone and delete this message from your system.
___
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


___
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

[Michael Sinatra]

On 10/01/11 04:54, Bill Owens wrote:

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 ;)


I am pretty sure that it doesn't, at least not in 9.8.1.  There's no 
place to specify the location of the dsset or keyset files in 
named.conf, and that's what the signer process needs to insert the DS 
records.  When I put dsset files in the parent zone's directory with the 
key files and did 'rndc sign', the DS records still didn't get 
automagically put in.


There are ways of getting the DS records into the zone(s).  Here are 
some steps that I took on some test zones:


0. First, I made sure there were proper delegation NS records in the 
parent zone(s)!


1. Ensure that there are no pending dynamic updates and run 'rndc freeze'.

2. Create a central directory to hold the keyset and dsset files.  I 
used /var/named/etc/namedb/master/signed-zonefiles/keysets on a FreeBSD 
system with named running in a chroot environment.


3. Assuming keys have already been generated, run the following command 
in the *child* zones first, substituting sub1.gost.radiofreebeer.net for 
your child zone and substituting 'zone.db.signed' for the signed version 
of the zone that named is configured to read on startup:


/usr/sbin/dnssec-signzone -C -g -p -d 
/var/named/etc/namedb/master/signed-zonefiles/keysets -o 
sub1.gost.radiofreebeer.net. -e +518400 -N unixtime zone.db.signed 
K*.private


This will produce zone.db.signed.signed.

NOTE that this assumes that each zone has its own directory with its 
keys in that directory (and no other zone's keys).


4. Then run the same command on any parent of any signed zone, *after* 
you have run the command on the signed child zone.


5. For every *parent* zone, you will need to 'mv zone.db.signed.signed 
zone.db.signed' so that the version with the DS records will go into 
production.  This is only necessary with parent zones, but it can also 
be done on the child zones just to keep things clean.


6. 'rndc thaw'

You can also use a signing tool like zkt, which will basically generate 
all of the keys and do the DSification of parent zones automatically.


There are other features of tools like zkt and opendnssec that 
auto-dnssec can't (yet) do, such as key rollovers.  auto-dnssec will do 
rollovers, once the keys with proper activation and inactivation dates 
have been created.  But something else needs to generate the keys, set 
the metadata according to a policy defined by the administrator, and 
remove stale keys so that auto-dnssec can do its work.  As far as I can 
tell, there isn't yet an auto-dnssec-savvy tool that can handle these 
tasks so it needs to be custom-scripted.



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's right--this needs to be fixed right away.

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

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

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

[Michael Sinatra]

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

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


A quick glance shows two problems:

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


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


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

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


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


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


michael

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


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

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

Re: Clients get DNS timeouts because ipv6 means more queries for each lookup

[Michael Sinatra]

Users are experiencing this problem now in the field, and more users

will
be experiencing it as BIND is upgraded in more and more places. Every 
single user relying on a Fedora 15 DNS server, for example, is going to 
see occasional unnecessary DNS timeouts when trying to resolve host 

names.

It seems clear to me that a generally available, generally applicable 
fix 
to BIND is needed to avoid this issue and perhaps similar issues like 

it.

What is the fix you want?  Negative caching of FORMERR responses?  That 
won't work in the wikipedia case, since the (incorrect) SOA minimum is 
only 10 minutes, and your cron job runs every 15 minutes.


There are millions of broken domains out there.  Asking BIND to install 
kludges to pave over them is probably not the best way to go.


michael

PS. BTW, it would be incorrect to state that queries for non-existent  
records for a domain name for which other records exist (e.g. CNAME or A) 
should get an NXDOMAIN response.  They absolutely should not.  They should 
get an empty answer with a NOERROR RCODE.  NXDOMAIN means that there are 
no dns records whatsoever that have the domain name en.wikipedia.org, 
which is certainly not the case.


___
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

[Michael Sinatra]

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?


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.


michael
___
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

[Michael Sinatra]

On 06/18/11 10:26, David Miller wrote:


All domains, at every level, have to configure their records such that
the tree can be walked from root to their domain.

Follow the .s.

For: this.long.chain.example.com.

com. must be delegated by .
example.com. must be delegated by com.
chain.example.com. must be delegated by example.com.
long.chain.example.com. must be delegated by chain.example.com.
this.long.chain.example.com. must be delegated by long.chain.example.com.

The wikipedia article on DNS is quite good:
http://en.wikipedia.org/wiki/Domain_Name_System

In the particular case of the OP - example.net. has name servers under
example.com.

To make lookups for records under example.net., resolvers walk the tree
from . to net. and get NS records - ns1.example.com. and
ns2.example.com.

You can't insert glue records into net. for name servers that exist
under com., so now resolvers walk the tree from . to com. to get the
name servers for example.com. which in the OP's case are - GoDaddy name
servers.


In theory, you can insert glue records anywhere above the zone in 
question.  See RFC 2181, section 5.4.1.


As an example, glue for the servers adns1.berkeley.edu and 
adns2.berkeley.edu exist in the root zone.



If there are no glue records in com. for ns1.example.com. and
ns2.example.com., then resolvers will just ask the authoritative name
servers for example.com. (which in the OP's case are - GoDaddy name
servers) for the A/ records for ns1.example.com. and
ns2.example.com. If the GoDaddy name servers provide A/ records for
ns1.example.com. and ns2.example.com., then resolution works and
everyone is happy.

Glue is only required if that is the only way to traverse the tree to
get to the IP addresses for the name servers for a domain.


A registrar can't know this a priori, and more importantly, can't know 
that it will always be the case with a particular domain and/or NS RRs. 
 Registrars therefore have to require registered DNS servers when a 
registrant wants a new domain.



Can someone point to an RFC or BCP that says that *all* name servers *must* 
have glue present in their parent?


I doubt such an RFC exists.  RFC 1912, section 2.3 does a nice job of 
summing up where glue is necessary and where it isn't, but that doesn't 
take into account NS records that are in zones that are completely 
outside the administration of the registrar and/or registrant.


michael
___
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

[Michael Sinatra]

On 06/18/11 15:23, Chris Thompson wrote:

On Jun 18 2011, Michael Sinatra wrote:


In theory, you can insert glue records anywhere above the zone in
question. See RFC 2181, section 5.4.1.

As an example, glue for the servers adns1.berkeley.edu and
adns2.berkeley.edu exist in the root zone.


For fj, hk, and xn--j6w193g. These are examples of what some
of the BIND documentation calls sibling glue.


You forgot au :)

And I now recall that the subject of sibling glue has been discussed on 
this list a couple years ago.



Of course, at the root zone level, *all* NS records need either
required glue or sibling glue, because every single one of them
is somewhere under the root zone. At least, until the aliens contact
us and we get the Internet spliced into the Galactinet ..

Also, the required glue + sibling glue desideratum is not always
enough. Consider

foo.com. NS ns1.bar.net.
foo.com. NS ns2.bar.net.

and

bar.net. NS ns1.foo.com.
bar.net. NS ns2.foo.com.

Neither seems to to need glue in either com or net, but without
either the domains cannot be resolved. This was a significant issue
when VeriSign changed the way the *.gltd-servers.net responded last
year.


That's a good example (dare I say the canonical one?).  I was thinking 
of even simpler cases, such as where you are at least a layer below SLD. 
 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.


Because registrars (and even registries) can't always control the 
immediate parent of the NS, they require registration of the nameserver 
to allow for glue to be placed at higher levels.


michael
___
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 thehartford.com domain

[Michael Sinatra]

On Wed, 15 Jun 2011, M. Meadows wrote:


Question : our check of whois indicates that ns1.thehartford.com and 
ns2.thehartford.com are
the authoritative nameservers for thehartford.com. A dig with a +trace for
eftc.thehartford.com seems to indicate that they are indeed the auth 
nameservers. It?s
interesting, though, that an http://www.kloth.net/services/nslookup.php lookup 
for
thehartford.com query for NS records shows a non-authoritative answer of
hfdns3.thehartford.com, hfdns4.thehartford.com, simns3.thehartford.com, 
simns3.thehartford.com
and simns4.thehartford.com. We?re unsure what?s going on with that.


Instead of doing 'dig +trace eftc.thehartford.com', do 'dig +trace ns 
thehartford.com', and you'll see the problem.


This is a classic authority mismatch, as others have pointed out.

michael

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

Re: querylog format

[Michael Sinatra]

On 6/6/11 8:09 PM, Jeff Peng wrote:

Hello,

The querylog of BIND in my hosts is like:

client 58.240.56.18#16768: query: s18.mhxx.game.yy.com IN A -EDC

For the last part, I know the '-' means non-recursion，'E' means EDNS.
But what are the 'D' and 'C' flags?


D = DO (DNSSEC Okay), client is requesting DNSSEC records and AD bit set 
if server is doing validation and can validate the zone


C = CD (Checking Disabled), client does not want the server to do 
validation on the response, but to return it regardless.


Although setting both flags sounds contradictory, it makes some sense 
where a validating forwarding resolver wants to do its own validation 
and enforce its own policy for dealing with valid/insecure/bogus zones.


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

Re: [dns-operations] Bind 9.8.0 intermittent problem with non-recursive responses

[Michael Sinatra]

This will be in BIND 9.8.1 final.  BIND 9.8.1b1 is already cut
and will need this to be applied.


I just noticed that the patch for query.c has been added as an extra patch 
to the FreeBSD port for 9.8.0-P2, so if you build the bind98 port from the 
latest FreeBSD ports collection, you'll get the bugfix now.  (Thanks, 
dougb)


michael

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

Re: BIND Security Advisory May 2011: Large RRSIG RRsets and Negative Caching can crash named

[Michael Sinatra]

On Fri, 27 May 2011, Frank Kloeker wrote:


Hello,

I would want to say thank you very much for the wonderful work of the
ISC team and the quick solution of the problem and a very
professional appearance.


I have come to expect such performance from everyone at ISC, but yesterday 
the exceeded even those high expectations.  Hats off to a great job by a 
talented group of people who takes their role in the Internet very 
seriously.


michael

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

Re: Bug in bind 9.7.3?

[Michael Sinatra]

On Thu, 26 May 2011, Frank Kloeker wrote:


Hi,

I using bind 9.7.3 as resolver in a slightly larger server farm with
some mail servers that use domain key validation.
If a try

# host -t TXT _adsp._domainkey.federalreserve.gov

bind dies with

May 26 19:59:02 resolv04 named[8237]: buffer.c:285: REQUIRE(b-used + 1
= b-length) failed
May 26 19:59:02 resolv04 named[8237]: exiting (due to assertion failure)

This is reproducible and should only affected in 9.7.3. Can this be
possible?


Yes, UC Berkeley had 7 of 8 anycast servers die in the same way, and I do 
recall seeing exactly that query earlier in the stream.  I think you're on 
to something, and I am looking into it further.


michael

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

Re: question about multiple queries in a single dns packet

[Michael Sinatra]

On 12/29/10 14:06, Alan Clegg wrote:

On 12/29/2010 2:17 PM, Federico Barbieri wrote:

Not sure if this is the right place to ask but I've been trying to dig
around and found nothing...

reading the dns specification it would seems possible to send multiple
request in a single packet.


I'm not sure what the actual reference is, but don't do that.

Nobody supports it (what would the answer section contain?  what does
the RCODE actually mean?)...


I believe it's in the EDNS1 specification that Paul did a while back, 
after EDNS0.  I don't think it ever got advanced to RFC:


http://tools.ietf.org/html/draft-ietf-dnsext-edns1-03

See especially section 4.

The answer to your question on RCODE:


4.2. RCODE and AA apply to all RRs in the answer section having the

   QNAME that is shared by all questions in the question section.  AA
   applies to all matching answers, and will not be set unless the exact
   original request was processed by an authoritative server and the
   response forwarded in its entirety.

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

Re: about nsupdate

[Michael Sinatra]

On 12/19/10 23:47, Jorg W Young wrote:

Hello,

We primarily update the DNS records by nsupdate from a web interface.
Under this case, if I modified the zone file directly by hand, will
nsupdate overwrite the modification?


If you attempt to update a dynamic zone by hand, without first 
freezing the zone or shutting down named, you will likely corrupt the 
zone.  You need to use 'rndc freeze zone' and then do the update by 
hand (don't forget to bump the serial number!), and then do 'rndc thaw 
zone' (assuming you're using a recent version of BIND).  While the 
zone is frozen, updates made dynamically (e.g. via your web interface) 
will be discarded.  For these reasons, it's often good to think about 
whether the hand-editing is really necessary and what impact it has on 
your overall process.


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

Re: DNS Redundancy

[Michael Sinatra]

On 10/21/10 08:26, Gordon A. Lang wrote:


It is actually counter-productive to have two resolvers configured
with this architecture, but to circumvent human nature, we publish two.

There is absolutely no functional difference between the two, and
there is no redundancy value for the second one -- they are both
hosted on each and every one of the any-cast servers. The only
reason for the the second resolver is to deter people from making
up their own second resolver -- people expect two resolvers, and
if you give them only one, they will go ahead and put something in
as the second resolver -- even if you tell them not to. This is a
very important aspect of having the architecture succeed in our
environment.


I mentioned this in another thread (perhaps on another list!), but there 
are reasons you might want to have two separate redundant anycast clouds 
and configure two servers in client stub resolvers.


Background: We have been doing anycast within our OSPF IGP since 1999 
for DNS.  Initially, we announced all resolver addresses from one set of 
anycast servers, and each server advertised all configured addresses (we 
had 4 back then for historical reasons).  On very rare occasions, we 
would have a weird error where a system would be unable to fork new 
processes (such as the cron script to verify health of the server) or 
the kernel would get into a weird bogged-down state where named would 
effectively stop working but the system wouldn't get taken out of 
routing. (That one turned out to be a kernel bug.) Clients within the 
anycast catchment of such a server would be stuck talking over and over 
to the same broken server.  We now have two separate sets of anycast 
servers so that the resolvers can still fail to a different set of 
servers as a last resort.  Having the stub resolver's own failover 
mechanism in place provides an extra layer of protection, provided you 
have separate anycast clouds.  This is now considered a best practice.


See slide 38 of Woody's presentation here:

http://www.pch.net/resources/papers/ipv4-anycast/ipv4-anycast.pdf

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

Re: repository for zone files

[Michael Sinatra]

On 09/23/10 12:53, Stewart Dean wrote:

On AIX, I'm used to /etc/dns.  CentOS seems to place in /var/named.  Is
there any blessed, bestofallpossibleworlds place for the zone files. I'm
moving our DNS from from AIX to CentOS/Fedora. I'm inclined to create
the /etc/dns dir but maybe it'd be better to put it in
/var/named.Comments, brickbats?


I have always found it to be a good idea to do what the OS wants.  Many 
OSes now are set up to run bind in a chroot jail (a good thing), but 
this requires a specific directory structure.  If your OS has already 
set that up (and if the startup scripts work with that structure), then 
it's best to keep them that way.  Probably the ideal thing to do is use 
the OS defaults and then symlink your previous directory structure to 
the OS defaults as necessary to maintain compatibility with your 
in-house scripts and processes.


michael

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

Re: USADOTGOV.NET Root Problems?

[Michael Sinatra]

On Sat, 24 Jul 2010, Warren Kumari wrote:



On Jul 23, 2010, at 2:37 PM, Danny Mayer wrote:


On 7/22/2010 11:08 PM, Merton Campbell Crockett wrote:

Thanks for the confirmation that the problem was related to DNSSEC.

I didn't see your message until I got home from work; however, I did
find the root of the problem late this afternoon.  At each of our
Internet egress and ingress points, we have Cisco ASA devices sitting in
front of a pair of redundant firewalls.  Each ASA is configured with the
default DNS inspect policy that doesn't accept fragmented UDP packets.


Why would any inspection policy not allow fragmented UDP packets?
There's nothing wrong with that.



Because it's hard The issue is that then you need to buffer fragments 
until you get a full packet -- which leaves you open to attacks that send a bunch of 
fragments but leave one of them out.

Vendors like to avoid reassembling fragments by default, because it makes their 
performance numbers better


That's true, but it doesn't quite explain why the DNS Inspection Policy, 
turned on by default on the PIX/FWSM/ASA, continued to have a default 
maximum DNS message size of 512 bytes more than a decade after EDNS0 
became a standards-track RFC.


In this case, Cisco's defaults are brain-dead.  Whether that had an impact 
here or the issue was due to mere fragmentation isn't clear, but those 
default values have had an impact on DNSSEC deployment.


michael

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

Re: USADOTGOV.NET Root Problems?

[Michael Sinatra]

On 07/23/10 05:37, Danny Mayer wrote:

On 7/22/2010 11:08 PM, Merton Campbell Crockett wrote:

Thanks for the confirmation that the problem was related to DNSSEC.

I didn't see your message until I got home from work; however, I did
find the root of the problem late this afternoon.  At each of our
Internet egress and ingress points, we have Cisco ASA devices sitting in
front of a pair of redundant firewalls.  Each ASA is configured with the
default DNS inspect policy that doesn't accept fragmented UDP packets.


Why would any inspection policy not allow fragmented UDP packets?
There's nothing wrong with that.


Because the default DNS inspection policy for most Cisco 
ASAs/FWSMs/PIXes is brain-dead.  It is on by default and, in older 
versions, only allows DNS messages up to 512 bytes in length.  In some 
later versions it allows something larger (1024 or 1500?), but basically 
makes no exceptions for EDNS0 and UDP fragments.


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

Re: Automated DNSSEC (command line)

[Michael Sinatra]

On 05/28/10 14:18, Michelle Konzack 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?


Check out zkt (http://www.hznet.de/dns/zkt/).

There are a few more involved tools out there, but zkt sounds like what 
you want.



I can not believe, that you are signing each zone by hand!  :-D


*I'm* not. :)  (I use a combination of zkt and the BIND tools in an 
automated script.)



Can an expert please check  'dig ANY tamay-dogan.net'  whether  this  is
right?


Looks good to me.  The sigs seem to be within their validity interval, 
but there doesn't appear a DLV record in dlv.isc.org, so I can't 
validate.  (Actually, I *could* snarf the ksk from the ANY query and 
manually configure it as a trust anchor, but I am lazy.  Moreover, that 
won't tell us if something goes wrong if/when you publish a trust-anchor 
DLV record or DS record, when NET becomes signed.)



Also I am not realy sure whether I need  dnssec-validation yes  in  my
options.


For authoritative service, you don't need it.  Only if you're running a 
validating nameserver do you need it, and it's 'yes' by default in 
recent versions of BIND.  You still need to configure a trust anchor (or 
anchors) if you want to do validation.


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

Re: Resolving .gov w/dnssec

[Michael Sinatra]

On 04/22/10 18:48, Timothe Litt wrote:

I get a connection timed out; no servers could be reached after the
Truncated, retrying in TCP mode even with +bufsiz=512


I get a correct response when I use +bufsiz=512.  After Truncated, 
retrying in TCP mode I get a response, but apparently you don't.



I am not blocking tcp/53. In fact, telnet dns1.uspto.gov 53 will happily
establish a connection :-) I'm on a fiber (Verizon FiOS business)
circuit - given that others are seeing this over a wide geography, seems
like the investigation needs to start closer to the .gov servers...


Certainly for the UDP fragmentation issue that's true.  Everyone seems 
to be having that problem.  But you seem to be the only one having the 
problem where you can't receive TCP even if you set a low bufsize.  I 
can fallback to TCP just fine as long as I set a low bufsize.



If you're into numerology, 1736 is 1500 + 236 -- with a 20 byte header
on the 236, you get 256 for the fragement - which is mildly curious.
Folks on DSL should remember that their magic number is less than 1500
bytes (1492 is common, as is 1453).


...which makes me think that there is a PMTUD issue in your situation. 
You can establish a TCP connection, but perhaps you receive a larger 
packet than you can actually receive and you can't signal that you can't 
receive such a packet because someone is blocking ICMP on the path 
between you and uspto.gov.  Only a packet trace will even begin to yield 
some clues there.


*If* that's true, that, combined with the UDP fragment blockage just 
makes me think: My, how we've gunked up the Internet.


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

Re: Resolving .gov w/dnssec

[Michael Sinatra]

On 4/22/10 8:55 AM, Timothe Litt wrote:

So, others are also seeing this, and it's not unique to bind or my corner of
the internet.  Thanks.

It seems to have been going on for weeks, so it isn't going to fix itself.

Who do I report this to so that it gets resolved?


I have had good luck reporting this issues to the contact in the SOA:

;; ANSWER SECTION:
uspto.gov.  7200IN  SOA dns1.uspto.gov. nmb.uspto.gov. 
2010042002 10800

and I also cc Donna Samblanet who is the whois contact for GOV.  (Try 
'whois -h whois.iana.org =GOV' at your favorite unix prompt for her 
contact info.)



FWIW, I tried +vc - from here, it doesn't help.  Also, one sometimes gets
SERVFAIL - and once in a while, it actually resolves!


That may explain why it's broken for you and not for me.  My BIND 
servers (a mix of 9.7.0-P1 and 9.6.1-P3) all resolve uspto.gov 
correctly, with the AD bit set.  That's because they lower the EDNS0 
buffer if they don't get a response right away, thereby triggering a 
fallback to tcp.  Are you blocking (or is your network blocking) tcp/53 
somewhere?



As for the make work project and less stability comment -- it seems
likely to me that if DNS packets are being mishandled, others are too --
just not as visibly.  So DNSSEC may well be an over-due network diagnostic;
fixing these sorts of problems could equally well reduce retries, delays and
other mishandled fragments for other protocols. I'm not ready to blame the
indicator for the underlying problem.  At least until we get to a
DNSSEC-unique root cause.


You're correct that this isn't a DNSSEC problem.  It's arguably not even 
a DNS problem, since UDP fragments are used by other protocols.


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

Re: Understanding 'format error Messages

[Michael Sinatra]

b19...@anl.gov wrote:

I am trying to understand format error messages like this one from
BIND 9.7.0-P1:

 Apr 15 15:36:02 dnsserver.it.anl.gov named[8662]:
   [ID 873579 daemon.notice] DNS format error
   from 209.234.234.42#53 resolving markets.nytimes.wallst.com/
   for client 164.54.214.14#13132: invalid response


I haven't looked at the code too closely (maybe someone from ISC can 
chime in), but I am also interested in understanding the range of 
possible errors that this message indicates.


In this particular case, the authoritative nameserver is giving out an 
obviously bogus NS record for wallst.com:


manasquan# dig wallst.com @209.234.224.42 any

;  DiG 9.7.0-P1  wallst.com @209.234.224.42 any
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 17612
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;wallst.com.IN  ANY

;; ANSWER SECTION:
wallst.com. 500 IN  SOA 
lb-www-p1-bb2-01.mgmt.local. hostmaster.lb-www-p1-bb2-01.mgmt.local. 390 
10800 3600 604800 60

wallst.com. 500 IN  NS  lb-www-p1-bb2-01.mgmt.local.

Not sure if that's causing the format error, but it is obviously broken 
(and all too common still).


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

Re: OpenDNS today announced it has adopted DNSCurve to secure DNS

[Michael Sinatra]

On 3/7/10 10:46 AM, Danny Mayer wrote:


Autokey is not a cryptographic signature protocol. It *is* a
authentication protocol for the server only and there are a number of
exchanges that need to be done to complete the authentication of the
server. You cannot compare this with DNSSEC and nothing in NTP is encrypted.


Correct, the comparison was only to point out that Autokey, like DNSSEC, 
doesn't encrypt payload because it doesn't need to.


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

Re: OpenDNS today announced it has adopted DNSCurve to secure DNS

[Michael Sinatra]

On 02/24/10 01:25, Jonathan de Boyne Pollard wrote:



DNScurve advocates, on the other hand, point out that DNS isn't
encrypted. Well, neither is the phone book. So what?


So the protocol is vulnerable to both local and remote forgery attacks,
just like other unencrypted protocols
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/proxy-server-back-ends.html.
For any that don't understand this point, there's a simple thought to
prod them in the right direction: Do you remember why SSH and SSL were
invented?


Do you understand the difference between encryption and authentication? 
 SSH and SSL do both because they protect the payload, which may be 
sensitive, AND they want to verify that the server you're talking to is 
really the one you want.  DNS only needs authentication.  DNSSEC 
prevents forgery without encrypting the payload.



Do you remember, say, the forgery problems with TELNET and
HTTP?


The bigger problems with TELNET and HTTP were that they could be sniffed 
on the wire to get confidential information like passwords.  Forgery was 
conveniently solved by cryptography along the way, but confidentiality 
was in issue with these protocols, unlike with DNS.



The /very same problems exist/ for unencrypted UDP/IP protocols
such as DNS and NTP. And the solution is the same, too.


Yes, cryptographic signatures, not full encryption.  Just like NTP with 
Autokey.


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

Re: OpenDNS today announced it has adopted DNSCurve to secure DNS

[Michael Sinatra]

On 02/23/10 18:31, Joe Baptista wrote:

Now that OpenDNS the largest provider of public DNS supports DNSCurve

http://twitter.com/joebaptista/status/9555178362

Would it be possible to include DNScurve support in bind?

thanks
joe baptista


I'd love to see BIND adopt DNScurve...when it becomes an RFC.  Until 
then, I'd prefer that BIND stick to the existing body of RFCs.  If 
DNScurve is important enough for the whole Internet to use, then it's 
important enough to drag it through the whole IETF process, political as 
it may or may not be.


Personally, I think DNScurve misses the mark.  My concern, as someone 
who operates both authoritative and recursive servers, is that the data 
on the authority side be authentic end-to-end.  With DNSSEC, I can 
validate that that's true.


DNScurve advocates, on the other hand, point out that DNS isn't 
encrypted.  Well, neither is the phone book.  So what?  I regard DNS as 
a public database, and it's more important to me that it be 
authentic--from the source--than obscurified.


While I think the OpenDNS people (especially David U., their founder) 
have a huge amount of clue, I think they're barking up the wrong tree here.


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

Re: OpenDNS today announced it has adopted DNSCurve to secure DNS

[Michael Sinatra]

On 02/23/10 19:54, Joe Baptista wrote:

It would be nice to see it as an RFC. I agree with that. But from what I
know it will be a pretty cold day in hell before it becomes an RFC. I
humbly suggest Dr. Bernstein who is behind DNScurve thinks the IETF is
full of wackos. So it is unlikely he will ever be bothered to dance the
IETF RFC jig.

I do disagree with you that bind should only implement what is in the
RFC. Lets not forget the IETF has had 15 years to secure the DNS. The
result is the DNSSEC abortion. It has failed. This announcement today is
a stiff well deserved kick in the balls to the DNSSEC crowd.

We can not rely on the IETF for security. Commerce and simple common
sense communications are screaming for security solutions today.
DNSCurve is perfect and it works out of the box.

Folks. OpenDNS has set the DNS standard. We can start securing the DNS
with every new dnscurve upgrade to bind. Imagine how much money is being
spent on the DNSSEC make work project - time and energy wasted.

DNScurve installs - configures and runs. No need for a make work project.

agreed?


As someone who both signs his production zones and does DNSSEC 
validation, I can assure you that DNSSEC works.  But you've done as good 
job as I can imagine in making the case for DNScurve.


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

Re: DNSSEC DSSET KEYSET

[Michael Sinatra]

On 01/28/10 07:57, prock...@yahoo.com wrote:

That was very helpful. Thanks.

One last query.  For signed domains registered with and using ISC.ORG trust 
anchor, is there a sanity check similar to what you displayed below?


If you mean ISC DLV registry, that service continually does sanity 
checks on domains that are registered with it.  If you register your 
domain with ISC DLV, it will notify you if your zone keys are 
inconsistent or broken.


Be aware, though, if you register with DLV, there are resolvers that 
will try to validate your domain.  Ideally, you should make sure that 
you are good to go before registering it.  That includes re-signing your 
zone(s) periodically to prevent the signatures from expiring.


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

Re: Added new master zone, copy .hosts does not replicate properly

[Michael Sinatra]

On 1/21/10 3:40 PM, Ryan S wrote:


So my setup has been working great modifying existing zones adding
and removing records.  But when I add a new zone, it apparently does
not work.  So I think I am missing an important file that lists all
the zones BIND uses?   What BIND file am I needing to copy to
properly replicate MASTER-A to MASTER-B?  I hope this is something
very simple ..


named.conf, perhaps?
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users