Re: [External] nslookup issues

[Graham Clinch]

On 13/09/2022 21:09, Casey Deccio wrote:


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

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

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


I suspect nrpe-ng is closing stdin before launching nslookup.


With mac homebrew's build of bind 9.18.6 and a bit of shell redirection to 
close stdin, I get:

---
$ /opt/homebrew/bin/nslookup -version
nslookup 9.18.6

$ /opt/homebrew/bin/nslookup example.net 0<&-
[... usual output snipped ...]

Assertion failed: (fd > STDERR_FILENO), function uv__close, file core.c, line 
602.
Abort trap: 6

$ echo $?
134
---


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

---
$ /usr/bin/nslookup -version
nslookup 9.10.6

$ /usr/bin/nslookup example.net 0<&-
[... usual output snipped ...]

$ echo $?
0
---


(dig & delv are also affected in the same way)

The cmake group came across the same situation with libuv and open missing 
standard fds against /dev/null to compensate:
https://gitlab.kitware.com/cmake/cmake/-/merge_requests/3282


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

dlv.isc.org DNSSEC expired - potential impact to resolvers?

[Graham Clinch]

At 16:05:08, a toy BIND 9.10.3-P4 recursive nameserver began answering all 
queries with SERVFAIL, logging:

-=-
Mar 25 16:05:08 serni named[1525]:   validating dlv.isc.org/NSEC: verify failed 
due to bad signature (keyid=64263): RRSIG has expired
Mar 25 16:05:08 serni named[1525]:   validating dlv.isc.org/NSEC: no valid 
signature found
Mar 25 16:05:08 serni named[1525]:   validating dlv.isc.org/NSEC: verify failed 
due to bad signature (keyid=64263): RRSIG has expired
Mar 25 16:05:08 serni named[1525]:   validating dlv.isc.org/NSEC: no valid 
signature found
-=-


dnssec-lookaside had been set to 'auto'.

changing dnssec-lookaside to 'no' restored service (and has no impact on 
security because the DLV has been an empty zone for years!).



It looks like signatures in dlv.isc.org have stopped being refreshed - 

Here's the bottom of a 'dig +trace ns dlv.isc.org':

-=-

isc.org.86400   IN  NS  sfba.sns-pb.isc.org.
isc.org.86400   IN  NS  ns.isc.afilias-nst.info.
isc.org.86400   IN  NS  ord.sns-pb.isc.org.
isc.org.86400   IN  NS  ams.sns-pb.isc.org.
isc.org.86400   IN  DS  7250 13 2 
A30B3F78B6DDE9A4A9A2AD0C805518B4F49EC62E7D3F4531D33DE697 CDA01CB2
isc.org.86400   IN  RRSIG   DS 7 2 86400 20200415152856 
20200325142856 33209 org. 
YTPrAcPA4m3BUQnxMaAQizsosbldafWIcNfedHclACGsEgyQwQWlO57Y 
ApSDd/sKEI2+PAntcXf4eeuGqA+pz1AnH4IpoqWfFOeZcI4qKKz1yfX/ 
+VXQ6gKoJklqwLomXsi8IpwKFM9IzP3iWHIufG7luy8ZccgwIwX/07Z6 /Ro=
;; Received 482 bytes from 2001:500:e::1#53(a0.org.afilias-nst.info) in 100 ms

dlv.isc.org.300 IN  NS  ns1.isc.ultradns.net.
dlv.isc.org.300 IN  NS  dlv.sfba.sns-pb.isc.org.
dlv.isc.org.300 IN  NS  ns.isc.afilias-nst.info.
dlv.isc.org.300 IN  NS  dlv.ord.sns-pb.isc.org.
dlv.isc.org.300 IN  NS  ns2.isc.ultradns.net.
dlv.isc.org.300 IN  NS  dlv.ams.sns-pb.isc.org.
dlv.isc.org.300 IN  RRSIG   NS 5 3 300 20200325160456 
20200224153150 64263 dlv.isc.org. 
H1H0F1xGgvH/nqFu3pI66eTn7PkAInRKb8CgKn0fEHzHJYecRqqQ9G2s 
v0gC6nYjPq+SP8LEzCQdZTelt2unG7xnVIQJBuCwpu2tV0OJdko2/Eqq 
dwi+Wn/kWNIZa48Scr5rHLYJ16ABrqLTMxeXBwVs7U3k/0T0auzQm71C h7k=
;; Received 1124 bytes from 199.254.63.254#53(ns.isc.afilias-nst.info) in 144 ms
-=-


Note the signature expiration of '20200325160456'.

Is this related to the shutdown of sns-pb?

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

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

dnssec-policy & views

[Graham Clinch]

How does the new-in-9.16 dnssec-policy interact with views - in 
particular for key generation/rollover?


For example, we have a zone defined in multiple views with different 
contents (and thus not suitable for in-view), being signed by the same 
set of keys (currently maintained by dnssec-keymgr) - this allows us to 
publish only a single set of DS records for that zone.


If a zone 'example.net' is defined in view 'a', and a zone 'example.net' 
is defined in view 'b', but both views share a single key-directory, is 
it 'safe' to configure dnssec-policy in both views?


Graham
___
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: about source code

[Graham Clinch]

> In Socket.c, there are many "manager->nevents" 
> for an example, manager->nevents = ISC_SOCKET_MAXEVENTS; 
>  
> but the manager is defined in "isc_socketmgr_t *manager "

Where the nevents member is involved, I see manager being of type
isc__socketmgr_t - note the additional underscore (in 9.10 at least).

Graham
___
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: From AWS route 53 to Bind9

[Graham Clinch]

> [...]

But I'm getting errors in bind9.


What do the errors say?  Perhaps the text will point either you or us to 
the cause.


Graham
___
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: Querying locally on a nameserver - odd behavior

[Graham Clinch]

I have a DNS server (which is both forwarder and authoritative NS) and I see 
this odd behavior locally on the host:

dig @localhost   # returns immediately with right response

dig @ # returns sometimes, timesout most of 
the time

> [...]

during this behavior, I saw lots of UDP packet loss on the host:

netstat -s | egrep -A4 "Udp:"
...
..


I tried similar local queries when traffic reduced (and when UDP pkt loss was 
zero) and both local queries succeeded.


Which version of Bind are you running?  This sounds like an issue I've 
seen with prefetch in 9.10 before 9.10.4.


https://kb.isc.org/article/AA-01315/0/prefetch-performance-in-BIND-9.10.html

Graham
___
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: forwarders (IPv6)

[Graham Clinch]

I added below line to my named.conf to include IPv6 addresses to the
forwarders list. However I am getting this error *“Sep 13 10:33:06
servername named[24778]: [ID 873579 daemon.error] /etc/named.conf:158:
expected IP address near '2001:1890:1C04:3000:0CB7:4432'”*


That's because it's not a valid representation of an IPv6 address (it 
has only 6 hextets where you would expect to see 8, or a double-colon to 
mark compressed zeros):


2001:db8:a4:ea5c:0:0:53:a1 = 2001:db8:a4:ea5c::53:a1

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

stub resolver (lwresd?)

[Graham Clinch]

I'm trying to settle on a (Linux) caching stub resolver configuration 
and looking at lwresd, but it's not working as I expect for validation.


Given an lwresd.conf of:

-=-
options {
  forwarders { 192.168.125.1; };
  forward only;
  dnssec-enable yes;
  dnssec-validation auto;
};
lwres {};
-=-

Clients (via libnss-lwres) can unexpectedly resolve 
www.dnssec-failed.org.  The forwarder (192.168.125.1) is a validating 
bind instance, but lwresd is sending queries with the CD flag set, 
though it then doesn't follow up by doing any validation locally.  I can 
force lwresd to not set the CD flag with an additional:


-=-
server 192.168.125.1 {
  edns no;
};
-=-

and then the SERVFAIL for dnssec-failed.org from the bind instance does 
propagate down to the client, but this all feels a bit guess-worky.


I'd really appreciate any input from people who have deployed lwresd or 
a different stub resolver.  From scraping around the web, I detect that 
lwresd isn't widely used.  Should I just use 'full' named everywhere? 
systemd-resolved makes too many assumptions to be in with much of a 
chance, and nscd holds unhappy memories.


Graham
___
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: whether squid application of the machine and the client will get different Name Resolution ( A records)at cdn ( balance or random ) environment .

[Graham Clinch]

Hi John,

> whether we can force BIND to realize same Name Resolution ( A records) ,
> i search named.conf detail and *found the command ***rrset-order fixed )
> *will be suitable *, but fixed will be support by BIND 8 ,
> 
> and i use BIND 9 now , if possible , please give me some advisement

Checking section 6.2.16.14 of the BIND 9.10 Administrators Reference
Manual (https://www.isc.org/downloads/bind/doc/):

-=-
In this release of BIND 9, the rrset-order statement does not support
”fixed” ordering by default. Fixed ordering can be enabled at compile
time by specifying ”–enable-fixed-rrset” on the ”configure” command line.
-=-

However, my reading of fixed ordering ('the order they are defined in
the zone file') implies it can only work on an authoritative server that
has a full copy of the zone.  A server that is iterating will receive
records in the order that the authoritative sorts them, and I don't see
how the iterating server can reorder them against the zone file.

sortlist (section 6.2.16.13 of 9.10) might be more appropriate, but it's
scaled more towards continent-sized address blocks rather than
reordering all answers lexicographically.

Graham
___
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: PCS, Corosync, Pacemaker, and Bind

[Graham Clinch]

> Please confirm that if a DNS query is sent to the virtual address, the reply
> will be sourced from the virtual address. The reason for restricting BIND to
> a single address was mostly for firewall and administrative simplicity, but
> that's not a big deal as long as the same address is used both directions.

Yes, the correct source address is used (the source of a response is the
destination of the inbound query).  However, onward queries that bind
makes on behalf of a client (eg if recursing) will use whatever address
(or presumably query-source/query-source-v6).  The default query source
always seems to be the primary address of an interface, as far as I've seen.

> The documentation for keepalived isn't very good, but as near as I can tell
> it does not support bringing up an application like BIND along with a VRRP
> address. Maybe I'm wrong? The cluster.org package works great except for the
> lack of an interface, so I've posted over there also to see if it's possible
> to build a virtual interface for the IP, but I doubt it.

Our recursive servers run keepalived to juggle the two service addresses
that we advertise, and we don't set query-source, listen-on or
notify-source.  I don't see any benefit in moving the query/notify
source addresses between hosts, especially since it makes it hard to
test/monitor a host that isn't in service at the moment.

Keepalived calls 'rndc scan' to nudge the already-running named when
addresses appear/disappear, but I think this might be a historical thing
now that bind can watch the routing socket.

Graham



> 
> -Original Message-
> From: Tony Finch [mailto:d...@dotat.at] 
> Sent: Tuesday, March 15, 2016 5:40 PM
> To: Mike Bernhardt
> Cc: bind-users@lists.isc.org
> Subject: Re: PCS, Corosync, Pacemaker, and Bind
> 
> Mike Bernhardt  wrote:
>>
>> I'm setting up a new CentOS 7 DNS server cluster to replace our very 
>> old CentOS 4 cluster. The old one uses heartbeat which is no longer 
>> supported, so I'm now using pcs, corosync, and pacemaker.
> 
> I suggest having a look at keepalived: it's significantly simpler.
> 
>> I want BIND to listen on, query from, etc on a particular IP address, 
>> which is virtualized. The options currently used are:
>> query-source address
>> listen-on
>> notify-source
>>
>> listen-on isn't a big deal, but the source address options are.
> 
> Why do you care about the query source address?
> 
> I don't set any of those options and just let BIND pick whatever source
> address it wants; it might choose the server admin address or the advertised
> service address, and that doesn't matter because everything else is
> configured to accommodate this.
> 
> Tony.
> --
> f.anthony.n.finch    http://dotat.at/ Shannon, Rockall:
> Southeast 4 or 5, increasing 6 at times in Shannon. Moderate or rough. Fair.
> Mainly good.
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 

___
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

DNAME in forward zones - issues with Microsoft Edge browser

[Graham Clinch]

Hi Folks,

We use a DNAME record on lancaster.ac.uk and are seeing cases where
Microsoft's new Edge web browser is unable to display pages from web
servers reached via a DNAME in certain circumstances[1].

If you have deployed a DNAME record in a forward zone and would be
willing to help us explore the problems, please contact me off-list.

Many thanks,

Graham

Infrastructure Systems Developer,
Lancaster University, UK

[1] The circumstances appear to be a bag of confusion - on the Windows
client, the gateway & DNS resolver addresses need to be the same
(standard home-router setup), the network needs to be marked as 'Private
Network' ('Find devices and content' turned on - probably a standard
home setup?), and it only breaks for Edge (IE is fine).
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: How to make bind/named to listen for requests on both IPV4 and IPV6

[Graham Clinch]

> I see that named is not listening on IPV6
> [...]
> 
> What changes would be required to make Bind Listen on both IPV4 and IPV6?

Perhaps the named process has been started with the -4 argument? ('Use
IPv4 only even if the host machine is capable of IPv6')

Graham
___
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: RFC 1918/3330/5735

[Graham Clinch]

On 17/07/2015 20:41, Leandro wrote:

Hello guys.
I was writting the reverse zone definitions you recommended some weeks ago.
What I understood is that RFC 1918/3330/5735 defines the reserved ips
for internal or experimental use. They can not be routed outside a
private network.
It means that my dns cache server should not send those queries to root
servers.


Assuming you're running a reasonably recent version of bind (i.e. one 
that's still in support - 9.9 or 9.10), take a look at the 
empty-zones-enable flag to have the server automatically generate all 
the appropriate zones:


https://kb.isc.org/article/AA-00800/0

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

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

Re: bind 9.10 fallback to tcp

[Graham Clinch]

Hi Carl,


I have a client with 9.10.2-P1-RedHat-9.10.2-2.P1.fc22 on Fedora 22, on
a machine with a pppoe link with an mtu of 1492. The routers seem to be
properly fragmenting udp - it can receive large packets such as

dig www.byington.org +dnssec +bufsiz=4000 +notcp @205.147.40.34

which says:

;; MSG SIZE  rcvd: 3790

However, a tcpdump for tcp port 53 shows a lot of traffic. In
particular,

rndc flushtree novell.com
dig www.novell.com @localhost

shows some tcp traffic to the .com servers. How does one isolate the
query or server that is causing that fallback to tcp?


We saw a similar jump in TCP traffic with 'cold' (not much in the cache) 
resolvers after switching from 9.9 to 9.10.  The cause seems to be a 
change to the way edns sizes are advertised to unknown servers.  The 
gory details are in the ARM for the 'edns-udp-size' option, but here's a 
simplified version:


In 9.9, edns-udp-size is advertised initially, and only after problems 
is it reduced to 512 bytes.
In 9.10, edns-udp-size sets the *maximum* size that could be advertised, 
but the first query uses 512 and then it grows up as successes occur.


The 'Address database dump' section of a cache dump (rndc dumpdb -cache) 
has 'udpsize' notes along with edns success rates:


; [edns success/4096 timeout/1432 timeout/1232 timeout/512 timeout]
; [plain success/timeout]
;	148.88.65.105 [srtt 1489] [flags 6000] [edns 50/0/0/0/0] [plain 
0/0] [udpsize 1757] [ttl 173]


though I'm not clear what udpsize is really reflecting here since it has 
many different values (not just 512, 1232, 1432  4096, as I would 
expect from the ARM).


We see a freshly restarted (validating) 9.10 resolver need to make many 
TCP connections before returning its first answer, but things settle 
after it's got comfortable using larger edns sizes with the root  tld 
servers.


Graham
___
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: subdomain with domain

[Graham Clinch]

 zone _msdcs.domain {
 [..]
  file data/db.192.168.1.2.slave;
 };
 zone domain {
 [..]
  file data/db.192.168.1.2.slave;
 };

Both zones are being backed by the same file, so one will be overwriting
the other.  This may not be the cause of the half-working situation, but
it won't be helping.  Do the bind logs (not sure where Fedora puts them
though - /var/log/messages?) contain any errors?

Unless domain is really '192.168.1.2', I would suggest naming your
file after the zone that it is going to contain - e.g.

file data/db._msdcs.domain;
and
file  data/db.domain;

Graham
___
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 update

[Graham Clinch]

 I  configure bind to serve example.com domain with
 
 1.   dnssec-enable yes;
 2.   auto-dnssec maintain;
 3.   inline-signing yes;
 4.   allow-update{localhost;};
 
 Bind can fully automatic  dnssec signing on example.com but If I want to
 modify a record in example.com zone in the  zone's file directly without
 using nsupdate for dynamic zone.
 
 How can I force bind to read from  the modified zone's file and sign it
 immediately like manual signing in an older version.

The same as without any dnssec at all - edit the zonefile (including
increasing the serial number), and call 'rndc reload example.com'.  The
signed version of the zone will be updated as required - existing
signatures that are still valid won't be replaced (unless they expire
soon, etc, etc)

However, the 'allow-update' stanza makes me wonder whether you're mixing
dynamic updates with manual zonefile changes - I'm not sure whether
inline-signing can support a mixture of dynamic and manual
modifications.  If you do need to support this mixed style, Tony Finch
has a script that will generate nsupdate-style change commands from the
difference between two manual zonefiles:

http://dotat.at/prog/nsdiff/

If you used this, you wouldn't enable inline-signing at all, since all
changes would be dynamic.

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

'error (chase DS servers)' for static-stub zones

[Graham Clinch]

Hi Folks,

What does 'lame-servers: error (chase DS servers) resolving [...]'
really mean, and is it really an error?

It seems to be: pause the current resolution whilst I start another
round to fetch a (DS) record from the parent zone, but once that
completes, everything works out.

In particular, I see this for the first resolution within a static-stub
zone.

I suppose that the usual process of resolution would involve iterating
down and so any DS record(s) would come in from the parent whilst
discovering the delegation NS records, but with static-stub there's no
need to know the delegation NS records.

In short, is it expected behaviour to see a 'chase DS servers' error
occasionally (once every DS-record TTL?) for static-stubbed zones?

Graham
___
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: 'error (chase DS servers)' for static-stub zones

[Graham Clinch]

On 04/02/2015 13:04, Tony Finch wrote:
 Graham Clinch g.cli...@lancaster.ac.uk wrote:

 What does 'lame-servers: error (chase DS servers) resolving [...]'
 really mean, and is it really an error?
[snip]
 In particular, I see this for the first resolution within a static-stub
 zone.
 
 I am not getting this error in my logs. I have a number of static-stub
 zones; the interesting ones wrt DS chasing are cam.ac.uk (signed) and
 private.cam.ac.uk (unsigned).

Are these static-stub zones configured with 'server-names'?  Ours are
'server-addresses', and I imagine that the additional resolution caused
by server-names might improve the chance of finding the DS record
already cached.

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

also-notify with multiple occurrences of same IP address

[Graham Clinch]

Hi List,

Using BIND 9.9, I am trying to notify two different slave views on the
same host using TSIG keys as the differentiator:

also-notify { 127.0.0.1 key slave1; 127.0.0.1 key slave2; };

It appears that only the first (slave1) receives a notify.


If I change the second address to a different IP address on the same host:

also-notify { 127.0.0.1 key slave1; 127.0.0.2 key slave2; };

Then both views receive the notification.


I think this is down to an optimisation in lib/dns/zone.c which checks
whether a notification is already queued to the same 'dst' address,
ignoring whether the key differs (roughly line 9990?).

Is this the 'correct' behaviour?  It wasn't what I was expecting, but I
can see how we got here.

I guess this doesn't affect people with fewer than three views.  Has
anybody on-list got a clever(er?) trick?  I suppose that 9.10 with
in-view might make the problem go away.

Graham
___
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: also-notify with multiple occurrences of same IP address

[Graham Clinch]

On 19/01/2015 19:10, Evan Hunt wrote:
 On Mon, Jan 19, 2015 at 05:56:52PM +, Graham Clinch wrote:
 I think this is down to an optimisation in lib/dns/zone.c which checks
 whether a notification is already queued to the same 'dst' address,
 ignoring whether the key differs (roughly line 9990?).

 Is this the 'correct' behaviour?  It wasn't what I was expecting, but I
 can see how we got here.
 
 I haven't confirmed the behavior yet, but I agree that this sounds like
 a bug.
 
 Would you mind opening a ticket at bind9-b...@isc.org?

Thanks Evan - I've logged '[ISC-Bugs #38369] also-notify sends a maximum
of one notification per dst address, even if multiple keys are specified'.

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

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

Re: How to alias a domain

[Graham Clinch]

On 16/01/2015 15:36, John wrote:
 DNAME will not work with DNSSEC.
 DNAME only work with the sub-tree, while DNSSEC is at the domain level.
 
 taking the example: 
 klam.biz   IN DNAME klam.com
 
 DNSSEC will try to find keys for klam.biz NOT klam.com, which results in
 DNSSEC failure.

DNAME and DNSSEC certainly do work together - take a look at
http://dnsviz.net/d/www.lancaster.ac.uk/dnssec/

The klam.biz zone would need to be signed (I suppose you could use the
same key material as for klam.com, but I am not sure what benefit that
would bring) and biz to provide DS records, but there's nothing special
there from a DNSSEC point of view.

74.116.186.178 (one of two nameservers for klam.biz) is currently
returning SERVFAIL to my queries regarding klam.biz, which may be
obscuring the real problem.

Graham
___
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: AW: Disable DNSSEC Validation for selected Domains

[Graham Clinch]

On 14/01/2015 09:34, stefan.las...@t-systems.com wrote:

 Our customer uses a fictional Toplevel Domain[...]

Can you flip the problem on its head, by signing the fictional TLD and
deploying managed-keys (or trusted-keys) on the validating resolvers?

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

NSEC3 wildcard validation failures [was: Wrong NSEC3 for wildcard cname]

[Graham Clinch]

Hi Folks,

I think we can wrap this up thanks to assistance from the reporting site - 
they're running BIND 9.8.1-P1 (stock package in Ubuntu 12.04 LTS).

This means they don't have the following fix, which appeared in 9.8.2b1.

3175.   [bug]   Fix how DNSSEC positive wildcard responses from a
NSEC3 signed zone are validated.  Stop sending a
unnecessary NSEC3 record when generating such
responses. [RT #26200]

I can recreate the problem with a validating resolver running 9.8.1-P1 (Ubuntu 
12.04), and the problem is not present using 9.8.2rc1 (stock package in CentOS 
6), so I'm fairly sure it's this bug.  (For posterity, validation fails with 
validating @0x7f4b44014fe0: foo.cnametest.lancs.ac.uk A: noqname proof not 
found, whilst validating @0x7f2b3c0008b0: foo.cnametest.lancs.ac.uk A: 
closest encloser from wildcard signature 'cnametest.lancs.ac.uk' is *not* 
logged)

The stock Ubuntu configuration is to enable validation (this is good), 
unfortunately 12.04 LTS is supposedly being (security?) supported into 2017, so 
it could be quite a while before sites (even the ones who perform package 
updates regularly) advance into a situation of being able to resolve our 
wildcard entries.  The most recent Ubuntu LTS (14.04) is not affected.  I have 
logged an Ubuntu bug[1] to request this fix is 'back ported' into 12.04.

To give a sizing hint on the probabilistic risk of being affected, lancs.ac.uk 
(an affected zone) has ~50,000 unique owner names, whilst palatine.ac.uk 
(unaffected), has ~10.  We signed lancs.ac.uk in early/mid September, and this 
is the first real report of DNSSEC-related issues I've seen.

 delv +vtrace continues to report NSEC3 at super-domain only for
 foo.cnametest2.palatine.ac.uk http://foo.cnametest2.palatine.ac.uk
 records, and not for
 foo.cnametest2.lancs.ac.uk http://foo.cnametest2.lancs.ac.uk.  Is
 this a similar
 miscalculating-the-owner-name as for DNSViz?
 
 
 Don't know, but I would guess that this is simply recognizing the fact
 that in addition to covering the non-existent name, the NSEC3 record
 also happens to correspond to palatine.ac.uk http://palatine.ac.uk.

delv reports the validation as succeeding, so after further reflection I 
believe this additional message is merely a helpful (?to whom?) diagnostic.  
Unfortunately there's no obvious (to me, at least) distinction between 'debug', 
'interesting' and 'this is where it's gone wrong' log levels in delv +vtrace's 
output (but I'm not really complaining that much).

Graham

[1] https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1395216
___
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

Wrong NSEC3 for wildcard cname

[Graham Clinch]

Hello list (and this time it's not the DHCP list...),

Using bind 9.9.5 with inline-signing, I have a test wildcard cname
record in two zones:

*.cnametest.lancs.ac.uk CNAME www.lancs.ac.uk
*.cnametest.palatine.ac.uk CNAME www.palatine.ac.uk

dnsviz is showing the error
NSEC3 proving non-existence of foo.cnametest.lancs.ac.uk./CNAME:
QNAME_NOT_COVERED
for the lancs.ac.uk version (but the palatine.ac.uk version is fine).

According to delv, both are fully validated, but the palatine output has
one extra line:

;; validating foo.cnametest.palatine.ac.uk/A: NSEC3 at super-domain
cnametest.palatine.ac.uk



I can see a discrepancy in the NSEC3 records in the Authority section:

For palatine.ac.uk:

AEP7P2GGD4GEBNRMSBP4I97SU0MKR5R9.palatine.ac.uk. 3600 IN NSEC3 1 0 10
BB1150B39E44B92F E92VAEN6BQ1T2N54AA2RSA1V49RM394S

(AEP... is the hash of cnametest.palatine.ac.uk)


For lancs.ac.uk:

RA9FSQ8NSK36A6568UHF8L26UFV2B1PG.lancs.ac.uk. 3600 IN NSEC3 1 0 10
9B6EFFBA177399A0 RA9V2QS7NE6Q5VLKU2EF4QONHP5CGIJR A RRSIG

(RA9... isn't the hash of cnametest.lancs.ac.uk, and it's claiming there
are A and RRSIG records!?).

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

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

Thanks,

Graham

-- 
Graham Clinch
Systems Programmer,
Lancaster University
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Wrong NSEC3 for wildcard cname

[Graham Clinch]

Hi Casey  List folks,
 My apologies - this was actually a bug in DNSViz.  The NSEC3 computation
 was being performed on the wrong name (the wrong origin was being
 applied).  It should be fixed now, as shown in:
 
 http://dnsviz.net/d/foo.cnametest.lancs.ac.uk/VGzlkA/dnssec/
 http://dnsviz.net/d/foo.cnametest.palatine.ac.uk/VGzrqg/dnssec/

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

The cnametest records were an attempt at simplifying a real issue that's
been reported to us.

An unsimplified version is cnametest2.lancs.ac.uk (here the RR is
*.cnametest2 CNAME cnametest2, with an A RR for cnametest2), which (now)
passes DNSViz, but not Verisign's DNSSEC debugger
(http://dnssec-debugger.verisignlabs.com/foo.cnametest2.lancs.ac.uk).

I'm more confident that this is a bug in Verisign's debugger, as the
error is 'No DS records found for cnametest2.lancs.ac.uk in the
cnametest2.lancs.ac zone' (where's the .uk gone, and why the interest in
a DS where there's no zone cut?).  Do any Verisign DNSSEC debugger
maintainers lurk on bind-users?  (The 'Contact Us' link on the page
looks very corporate and not very useful)

delv +vtrace continues to report NSEC3 at super-domain only for
foo.cnametest2.palatine.ac.uk records, and not for
foo.cnametest2.lancs.ac.uk.  Is this a similar
miscalculating-the-owner-name as for DNSViz?  I'll try to dig (haha!)
into the delv source tomorrow.  Tested with delv 9.10.0  9.10.1.

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

I'm attempting to discover more about the validating resolver, but since
I have no access to it and the reporter is just a user of that resolver,
odds are not stacked in our favour.

 *snipping the bits where I obviously need to read about
 NSEC3 again*

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

Regards,

Graham

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

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

dnssec-coverage - ignore coverage gaps in the distant past

[Graham Clinch]

Hi folks,

Summary: Is there a trick to running dnssec-coverage so that it will not 
report failure if there are coverage gaps in the 'distant' past?


Detail:

I've performed a key rollover, and dnssec-coverage reports:

===
PHASE 1--Loading keys to check for internal timing problems
PHASE 2--Scanning future key events for coverage failures
Checking scheduled KSK events for zone palatine.ac.uk, algorithm 
RSASHA256...

  Thu Apr 24 08:56:09 UTC 2014:
Publish: palatine.ac.uk/008/04681 (KSK)
Activate: palatine.ac.uk/008/04681 (KSK)
  Thu May 01 15:02:35 UTC 2014:
Publish: palatine.ac.uk/008/37960 (KSK)
  Sat May 31 15:02:35 UTC 2014:
Activate: palatine.ac.uk/008/37960 (KSK)
Inactive: palatine.ac.uk/008/04681 (KSK)
  Sun Jun 29 15:02:35 UTC 2014:
Delete: palatine.ac.uk/008/04681 (KSK)
No errors found

Checking scheduled ZSK events for zone palatine.ac.uk, algorithm 
RSASHA256...

  Thu Apr 24 08:56:38 UTC 2014:
Publish: palatine.ac.uk/008/27594 (ZSK)
Activate: palatine.ac.uk/008/27594 (ZSK)
  Wed May 07 11:36:59 UTC 2014:
Publish: palatine.ac.uk/008/30231 (ZSK)
  Thu May 08 11:36:59 UTC 2014:
Inactive: palatine.ac.uk/008/27594 (ZSK)
Activate: palatine.ac.uk/008/30231 (ZSK)
  Thu Jun 05 11:36:59 UTC 2014:
Delete: palatine.ac.uk/008/27594 (ZSK)
No errors found
===

As the ZSK palatine.ac.uk/008/27594 has been deleted from the zone, I'd 
like to simplify the key directory by removing the now unused key 
material.  When I do so, named continues happily (the zone is 
inline-signed), and there are no warnings when it rescans the key directory.


However, dnssec-coverage now complains:

===
PHASE 1--Loading keys to check for internal timing problems
PHASE 2--Scanning future key events for coverage failures
Checking scheduled KSK events for zone palatine.ac.uk, algorithm 
RSASHA256...

  Thu Apr 24 08:56:09 UTC 2014:
Publish: palatine.ac.uk/008/04681 (KSK)
Activate: palatine.ac.uk/008/04681 (KSK)
  Thu May 01 15:02:35 UTC 2014:
Publish: palatine.ac.uk/008/37960 (KSK)
  Sat May 31 15:02:35 UTC 2014:
Activate: palatine.ac.uk/008/37960 (KSK)
Inactive: palatine.ac.uk/008/04681 (KSK)
  Sun Jun 29 15:02:35 UTC 2014:
Delete: palatine.ac.uk/008/04681 (KSK)
No errors found

Checking scheduled ZSK events for zone palatine.ac.uk, algorithm 
RSASHA256...

  Wed May 07 11:36:59 UTC 2014:
Publish: palatine.ac.uk/008/30231 (ZSK)
ERROR: No ZSK's are active after this event
===

If dnssec-coverage continued processing and got to May the 8th, it 
(should) find that the key became active.


Is there a trick to ask dnssec-coverage to ignore gaps in the distant ( 
TTL?) past, or do I need to keep all of the keys ever used on the zone 
in the key directory, if I wish to use dnssec-coverage?


Graham

--
Graham Clinch
Systems Programmer,
Lancaster University
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: How can I increase the TTL for the cached entries in my local dns serveder?

[Graham Clinch]

On 28/03/2014 06:09, Hongyi Zhao wrote:

In addtition, I also want to have long TTL so that I can obtain a short
inquiry respond time.


Bind 9.10 might help in this regard - by refreshing cached records 
before they expire, rather than by faking their expiry time.  From the 
change log:



3703.   [func]  To improve recursive resolver performance, cache
records which are still being requested by clients
can now be automatically refreshed from the
authoritative server before they expire, reducing
or eliminating the time window in which no answer
is available in the cache. See the prefetch option
for more details. [RT #35041]


Note that 9.10 is still in beta (http://www.isc.org/downloads/).

Small nit for ISC - the download page suggests there is an ARM for 9.10, 
linking to http://www.isc.org/downloads/bind/doc/bind-9-10/ - but that 
page contains the ARM for 9.9 (and thus, no details on prefetch).  The 
download for 9.10b2 does contain an ARM with details on prefetch.


Graham

--
Graham Clinch
Systems Programmer,
Lancaster University
___
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: changing NSEC3 salt

[Graham Clinch]

Hi,

Sorry to hijack this older thread, but..


rndc signing -nsec3param ...

I would expect the old NSEC3 chain and old NSEC3PARAM record to be
removed, once the new chain is in place.

(Similarly, the new NSEC3PARAM record will not appear in the zone until
the new NSEC3 chain has been completely generated).


This isn't quite what I see with inline-signing on 9.9.5:

If I switch from NSEC to NSEC3, my zone continues to have an NSEC chain 
until the moment it has an NSEC3 chain.


If I replace an existing NSEC3 chain with a new salt, I seem to lose a 
load of RRSIGs, and there are no NSEC or NSEC3 records until the 
operation completes!!  For example, the are no signatures on the 
DNSKEYs, which feels like a disaster.


Am I doing something wrong?  I hope so!

Graham

--
Graham Clinch
Systems Programmer,
Lancaster University
___
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: Converting an inline-signed zone to unsigned

[Graham Clinch]

Thanks - I have now tried that (set the deletion date to now with
dnssec-settime), and it does work. You end up with a [zone-file].signed
which is not actually signed being served, but being maintained from
[zone-file] in an incremental way.

I suppose this is indeed the way to go with the flow of inline signing.
You don't even have to have any keys for the zone in the key directory
initially. It's the transition between having inline-signing yes and
inline-signing no in the zone definition that seems to expose rough
edge cases.


Is [zone-file].signed really being maintained?  When I took an unsigned 
zone and enabled inline-signing without generating any keys, the zone 
content became 'frozen in time' until keys were generated (at least with 
versions

'9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu3' 
'9.9.5-2-Ubuntu').

In short, these messages are logged:

info: zone test1.local/IN (unsigned): loaded serial 2014030615
info: zone test1.local/IN (signed): serial 2014030615 (unsigned 2014030615)
error: zone test1.local/IN (signed): could not get zone keys for secure 
dynamic update

error: zone test1.local/IN (signed): receive_secure_serial: not found

But despite showing unsigned and signed zone both with serial 
2014030615, the 'signed' one actually still has 2014030610 - the serial 
at the point of enabling inline-signing.



I still have to investigate the problem that Graham Clinch reported,
and see whether that might be a show-stopper for the application of
inline signing that I have in mind.

More generally: it's a pity that there isn't any real documentation
of inline signing in the ARM, just the examples in ISC's KB articles.
Some clearer explanation of which options inline-signing yes is
(in)compatible with would be helpful. For example, it obviously turns
on some sort of moral equivalent of ixfr-from-differences yes on
the unsigned version of the zone, but would turning inline signing
on (or off) work better if this were specified explicitly? And the
examples have auto-dnssec maintain, but would auto-dnssec allow
work?


An 'rndc sync -clear test1.local' clears both zonefile.jnl and 
zonefile.signed.jnl.  It doesn't seem to modify the zonefile (because 
it's only recording past differences as a side effect of inline-signing 
enabling ixfr-from-differences??), but it does mean that the signed zone 
doesn't have IXFR data anymore, which probably leads me back to just 
blowing away zonefile.jnl (or hoping that named doesn't stop/isn't 
stopped - although I'm obviously hoping that anyway...).


Graham
___
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: Converting an inline-signed zone to unsigned

[Graham Clinch]

Hi Chris  co,


Using 9.9.5, I get messages exactly like that
when updating the unsigned zone file while there are no keys.


Thanks for the confirmation - I've logged bind9 bug #35502 
inline-signed zone, with no keys, does not synchronise changes made in 
master file.


Back on topic - I didn't investigate very thoroughly, but simply 
removing 'inline-signing yes' seemed to do ok for me (without marking 
the keys as deleted, or setting 'dnssec-secure-to-insecure').


Graham


___
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: Regarding zone trf from master to slave

[Graham Clinch]

Hi,

 We want to have log of what entries has been changed in the master
 (which is causing this zone transfer) at the time of zone transfer.

Two options come to mind:

1) Log the output of 'dig -t ixfr=2014030501 example.org' occasionally,
updating the serial to query for changes since the last run.  If the
master doesn't provide IXFR, you could enable 'ixfr-from-differences' on
a slave and then query the slave.

2) If your slave has access to a zone journal (because the master
supports IXFRs or you have 'ixfr-from-differences' enabled), log the
output of 'named-journalprint example.org.jnl'

Graham

___
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

Updating inline-signed masterfile whilst named is stopped causes 'journal rollforward failed'

[Graham Clinch]

I'm trialling inline-signing with our provisioning system which 
generates master files (rather than performing dynamic updates).


The configuration directives in use are:

inline-signing yes;
key-directory /etc/bind/dnssec_keys/test1.local;
auto-dnssec maintain;

There is 1 KSK and 1 ZSK, and an NSEC3 chain (configured via rndc 
signing -nsec3param ...), and the initial signing process has completed.


If I modify the original zonefile and reload the zone, a zonefile.jnl is 
created/updated, correctly identifying the modification I made in the 
original.  My changes are also applied across to zonefile.signed(.jnl) 
with the additional RRSIG bits.  This is all working ok.  If I restart 
named, everything is fine.


If I stop named, modify the original zonefile, and restart named, the 
zone refuses to load:


general: error: zone test1.local/IN (unsigned): journal rollforward 
failed: journal out of sync with zone

general: error: zone test1.local/IN (unsigned): not loaded due to errors.

If I stop named, modify the original zonefile, *remove the 
zonefile.jnl*, and restart named, the zone loads ok:


04-Mar-2014 13:05:41.816 general: info: zone test1.local/IN (unsigned): 
loaded serial 2014030415
04-Mar-2014 13:05:42.646 general: info: zone test1.local/IN (signed): 
loaded serial 2014083141 (DNSSEC signed)


And the modifications I made are correctly reflected in 
zonefile.signed(.jnl), so the zonefile.jnl doesn't appear to be used.


And so, to my actual question: Is it safe for the provisioning system to 
remove zonefile.jnl when it writes a new zonefile?


If zonefile.jnl doesn't serve any purpose (for non-dynamic, 
inline-signed zones - I can't see one), could named not create it at all 
(something for bugs@?)


This feels similar but not identical to Chris Thompson's mail from the 
19th of February.  I wonder whether there was also a playground.test.jnl?


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

Insecurity proof failed resolving newsletter.postbank.de - but why?

[Graham Clinch]

Hi List,

I'm seeing a dnssec validation error that I can't pin down, for the 
domain: newsletter.postbank.de.


Neither of http://dnsviz.net/ and 
http://dnssec-debugger.verisignlabs.com/ report finding a problem, but 
two (ubuntu packaged) versions of bind report a failure validating the 
delegation as intentionally insecure.


I've tried versions:

BIND 9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu1.1 
(Extended Support Version) id:d8a6fe8b built with '--prefix=/usr' 
'--mandir=/usr/share/man' '--infodir=/usr/share/info' 
'--sysconfdir=/etc/bind' '--localstatedir=/var' '--enable-threads' 
'--enable-largefile' '--with-libtool' '--enable-shared' 
'--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' 
'--with-gnu-ld' '--with-geoip=/usr' '--with-atf=no' '--enable-ipv6' 
'--enable-filter-' 'CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2'

using OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
using libxml2 version: 2.9.1

and

BIND 9.8.1-P1 built with '--prefix=/usr' '--mandir=/usr/share/man' 
'--infodir=/usr/share/info' '--sysconfdir=/etc/bind' 
'--localstatedir=/var' '--enable-threads' '--enable-largefile' 
'--with-libtool' '--enable-shared' '--enable-static' 
'--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' 
'--with-geoip=/usr' '--enable-ipv6' 'CFLAGS=-fno-strict-aliasing 
-DDIG_SIGCHASE -O2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro' 
'CPPFLAGS=-D_FORTIFY_SOURCE=2'

using OpenSSL version: OpenSSL 1.0.1 14 Mar 2012
using libxml2 version: 2.7.8


Running with -g 2 (on v9.9.3), I see:

==

20-Jan-2014 11:58:43.779 createfetch: newsletter.postbank.de SOA
20-Jan-2014 11:58:43.780 createfetch: . NS
20-Jan-2014 11:58:43.817 decrement_reference: delete from rbt: 
0x7ff58b51f010 .
20-Jan-2014 11:58:43.817 decrement_reference: delete from rbt: 
0x7ff58b520010 a.root-servers.net
20-Jan-2014 11:58:43.817 decrement_reference: delete from rbt: 
0x7ff58b520010 b.root-servers.net
20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 
0x7ff58b520010 c.root-servers.net
20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 
0x7ff58b520010 d.root-servers.net
20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 
0x7ff58b520010 e.root-servers.net
20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 
0x7ff58b520010 f.root-servers.net
20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 
0x7ff58b520010 g.root-servers.net
20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 
0x7ff58b520010 h.root-servers.net
20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 
0x7ff58b520010 i.root-servers.net
20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 
0x7ff58b520010 j.root-servers.net
20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 
0x7ff58b520010 k.root-servers.net
20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 
0x7ff58b520010 l.root-servers.net
20-Jan-2014 11:58:43.818 decrement_reference: delete from rbt: 
0x7ff58b520010 m.root-servers.net

20-Jan-2014 11:58:43.819 createfetch: . DNSKEY
20-Jan-2014 11:58:43.881 createfetch: ns1.ecircle.de A
20-Jan-2014 11:58:43.882 createfetch: ns1.ecircle.de 
20-Jan-2014 11:58:43.882 createfetch: ns2.ecircle.de A
20-Jan-2014 11:58:43.882 createfetch: ns2.ecircle.de 
20-Jan-2014 11:58:43.905 createfetch: ns3.ecircle.com A
20-Jan-2014 11:58:43.905 createfetch: ns3.ecircle.com 
20-Jan-2014 11:58:43.938 decrement_reference: delete from rbt: 
0x7ff58b52c010 ns3.ecircle.com
20-Jan-2014 11:58:43.939 decrement_reference: delete from rbt: 
0x7ff58b52c010 ns3.ecircle.com
20-Jan-2014 11:58:43.943 decrement_reference: delete from rbt: 
0x7ff58b52c010 ns3.ecircle.com
20-Jan-2014 11:58:43.974 decrement_reference: delete from rbt: 
0x7ff58b52c010 ns3.ecircle.com

20-Jan-2014 11:58:43.974 createfetch: de DS
20-Jan-2014 11:58:44.120 createfetch: postbank.de DS
20-Jan-2014 11:58:44.244 createfetch: de DNSKEY
20-Jan-2014 11:58:44.270 createfetch: newsletter.postbank.de DS
20-Jan-2014 11:58:44.307 createfetch: postbank.de DNSKEY
20-Jan-2014 11:58:44.341 error (insecurity proof failed) resolving 
'newsletter.postbank.de/SOA/IN': 2a01:4f8:140:3482::3#53
20-Jan-2014 11:58:44.373 validating @0x7ff57c017bf0: 
newsletter.postbank.de SOA: got insecure response; parent indicates it 
should be secure
20-Jan-2014 11:58:44.373 error (insecurity proof failed) resolving 
'newsletter.postbank.de/SOA/IN': 195.140.184.21#53
20-Jan-2014 11:58:44.409 validating @0x7ff57c007f00: 
newsletter.postbank.de SOA: got insecure response; parent indicates it 
should be secure
20-Jan-2014 11:58:44.409 error (insecurity proof failed) resolving 
'newsletter.postbank.de/SOA/IN': 46.4.73.157#53
20-Jan-2014 11:58:44.410 client ::1#55009 (newsletter.postbank.de): 
query failed (SERVFAIL) for newsletter.postbank.de/IN/SOA at query.c:7406
20-Jan-2014 11:58:44.410 fetch completed at resolver.c:3044 for 
newsletter.postbank.de/SOA in 0.629817: failure/insecurity proof failed 

Re: Insecurity proof failed resolving newsletter.postbank.de - but why?

[Graham Clinch]

Hi List ( Chris  Tony),


What *does* matter is that the NSEC3 proves that there are no NS
records as well (as no DS ones) for newsletter.postbank.de (despite
the fact that the NS records are included in the referral). Note the
absence of opt-out in the NSEC3.


Thanks for the replies - and noticing the missing 'NS'!

From my rather brain-busting afternoon reading, I believe this 
situation is covered by section 4.4 of RFC 6840, which requires a 
validator to ensure the NS type bit is set for an insecure delegation's 
NSEC(3) (or that it's covered by opt-out, but as Chris pointed out, that 
doesn't seem to be the case here).


I've left feedback for the dnsviz maintainer in the hopes that this case 
can be picked up in future.


Graham

--
Graham Clinch
Systems Programmer,
Lancaster University
___
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: Looking for a pointer on getting reverse mapping with DDNS to work with DHCPD Named.

[Graham Clinch]

Hi Jim,

 I'm getting either of the following errors:
 dhcpd: unable to add reverse map from 51.20.10.172.in-addr.arpa. to
 proccilapxp.dhcp.coloradostudios.com
 http://proccilapxp.dhcp.coloradostudios.com: bad DNS key
 dhcpd: unable to add reverse map from 51.20.10.172.in-addr.arpa. to
 proccilapxp.dhcp.coloradostudios.com
 http://proccilapxp.dhcp.coloradostudios.com: timed out

it's actually the line above those :)

 Mar 26 07:56:59 dns04 dhcpd: db.172.10.20.: host unknown.

which is caused by the zone statements in dhcpd.conf:

 zone 20.10.172.in-addr.arpa. {
primary db.172.10.20.;
key DHCP_UPDATER;
#file internal/db.172.10.20;
 }

'primary' should be the address of the DNS server to send the update
message to (not the filename of the zone - dhcpd asks the nameserver to
make the updates on its behalf, it doesn't alter the zone file itself).

so you probably want:

zone 20.10.172.in-addr.arpa. {
   primary 127.0.0.1;
   key DHCP_UPDATER;
   #file internal/db.172.10.20;
}

(and similar a change for the forward zone).

Graham

-- 
Graham Clinch
Systems Programmer,
Information Systems Services,
Lancaster University



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

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