BTW i’ve had no problems with Bind 9.8 and DNSSEC. I’m running Ubuntu 14.04 so 
its a little more up to date in the repo’s than CentOS is.

Try the following config:

dnssec-enable yes;
dnssec-validation yes;
//dnssec-lookaside auto;

DNSSEC Lookaside these days is just not needed. As you can see they are mostly 
about failing to validate via dlv.isc.org which from my experience just isn’t 
right to rely on a third party to validate. We have enough TLD’s signed that we 
shouldn’t need to do this any more.

For example this is what a correct validation of a zone should look like (with 
dig +trace). Also this is very useful in verifying it in a ‘pretty gui’ way - 
http://dnssec-debugger.verisignlabs.com/ 
<http://dnssec-debugger.verisignlabs.com/>

frizianz@vocus-dc:~$ dig +trace +dnssec frizianz.com

; <<>> DiG 9.9.5-3ubuntu0.2-Ubuntu <<>> +trace +dnssec frizianz.com
;; global options: +cmd
.                       6610    IN      NS      g.root-servers.net.
.                       6610    IN      NS      i.root-servers.net.
.                       6610    IN      NS      k.root-servers.net.
.                       6610    IN      NS      d.root-servers.net.
.                       6610    IN      NS      l.root-servers.net.
.                       6610    IN      NS      j.root-servers.net.
.                       6610    IN      NS      f.root-servers.net.
.                       6610    IN      NS      h.root-servers.net.
.                       6610    IN      NS      b.root-servers.net.
.                       6610    IN      NS      m.root-servers.net.
.                       6610    IN      NS      e.root-servers.net.
.                       6610    IN      NS      a.root-servers.net.
.                       6610    IN      NS      c.root-servers.net.
.                       6610    IN      RRSIG   NS 8 0 518400 20150618170000 
20150608160000 48613 . G3PQwokv63uJxh4O852r6xXN9Z3ThngwHwwYEAn/zdi4r0eZufhoyBJE 
BePtCKzq8edJAw1896AIggvFl7A9r8+3G13F/z0bFOAnibqn+J793BPb 
jM2hn/6Anr4i5gcQO0H2WymVcTEqSCe1FJiocbOyfoJZVJw07SdzleTL 6ws=
;; Received 397 bytes from 8.8.8.8#53(8.8.8.8) in 1397 ms

com.                    172800  IN      NS      m.gtld-servers.net.
com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      d.gtld-servers.net.
com.                    172800  IN      NS      k.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
com.                    86400   IN      DS      30909 8 2 
E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com.                    86400   IN      RRSIG   DS 8 1 86400 20150618170000 
20150608160000 48613 . f93gln5Ep+ZgQ2O+q9CKOWePw4xZLpRuEcY7Jh7CnDHcrwtA2ol9Brap 
AbwH+hwisGpJkuaLUUEprLws1mEF1RERZNwNA0kCriOP+Jy9g+xrLdb2 
xPACPwKm4ZAVWy48DyJXIvGiZlCJBxVPiNGTRd/TYMUTR5NTPd7fTmOI BR4=
;; Received 736 bytes from 193.0.14.129#53(k.root-servers.net) in 1701 ms

frizianz.com.           172800  IN      NS      ns1.iama.geek.nz.
frizianz.com.           172800  IN      NS      ns2.iama.geek.nz.
frizianz.com.           172800  IN      NS      ns3.iama.geek.nz.
frizianz.com.           86400   IN      DS      56031 7 2 
CA0BB1B1DB8433D89325D593C855E9CBE09B1AFA901486012EB3C46A 988C4D50
frizianz.com.           86400   IN      DS      56031 7 1 
3267E25132F3EA4E3FCEE84A7A6F3441E99FEFD4
frizianz.com.           86400   IN      RRSIG   DS 8 2 86400 20150612043952 
20150605032952 33878 com. 
ZGgr0ey+AVX6tDfZ+Bjys+3B0fLiW6Xw/BIwd4MWPSY1d5bYkAdnhHzZ 
eIuy96vLi+zbdnpC+5OuxC0ath5iVTtvNly2bzxHq9r6gqPowcPGTDYJ 
KdkQiAvCuuLS+mmNqXI5eQ5y2PH8iwAwYMrax5IOh7uc0opS1bQ4cL+M GRY=
;; Received 354 bytes from 192.42.93.30#53(g.gtld-servers.net) in 1977 ms

frizianz.com.           3600    IN      A       107.170.218.200
frizianz.com.           3600    IN      RRSIG   A 7 2 3600 20150624155804 
20150525153843 9239 frizianz.com. 
bB7z7IJrrXptgvVHcWLAu7j8UEKp0Sr96bSkVS5I2jGMpwjFiA1AewvP 
WW8ojZ8i2FaH+DE9n57Bm+V0Q4FEPjubh87D5zKRBa4AnrjwrWxjomGs 
1qVyc4yQFdNdhnO1U1iXND2FkxYqLTxaA+/TFRClSt6lF54Dky2GrLs9 
1kftqSO7b+YnyTSmat9lAeWtrMCxqOuV15tI9lzICl4nPaQBY1B0hpwA 
LLJGrTFXXXAUnzqYLqhYcdAYUbDPD3EwA2/njtZqOYtSQvRNap7Lmdi5 
jxZb81dGoN5NJ4xYikaV0lAF2R227Icm5DfhlYJoDd78yiHZzqjuB4t2 tQI3gg==
frizianz.com.           3600    IN      NS      ns3.iama.geek.nz.
frizianz.com.           3600    IN      NS      ns1.iama.geek.nz.
frizianz.com.           3600    IN      NS      ns2.iama.geek.nz.
frizianz.com.           3600    IN      RRSIG   NS 7 2 3600 20150624155804 
20150525153843 9239 frizianz.com. 
kB27OIP9VGQxEeAlSZJHR2hfI+2yxsZusN3PsshD1Mp5QPwdR81i+sR1 
8FE8oTFCCxOkuE5FqH2rP5nYbcSAqHTA54DobNNdm2sHyyWfimYSuCFZ 
sjiioa62mA7Mv/S3vaYJylH+HlMFXXzAEnmMEF693YrJb4gjIUI3jWYv 
EFfuE6IFGz44WrIhpFubpkp/1gr5abKHGlT6Hdjm++nMxwiN0B23gE36 
X+uY1xndbFPSL4VJyhBG/yboNl4VYT4/vd5Aka9o/hH+CcCNVBK3JXGW 
vstrkHajNV6PmHew6cj2uL9c7OE27YzcrZWJuFyOTDaaDqWKNK1J+N0O xNYEWA==
;; Received 1999 bytes from 111.69.52.230#53(ns2.iama.geek.nz) in 40 ms

frizianz@vocus-dc:~$

Cheers,

Fraser

> On 9 Jun 2015, at 10:11 am, steve <[email protected]> wrote:
> 
> It's a CentOS 6 install, so bind 9.8.2, currently using OpenDNS forwarders, 
> and a backup google one ( this has varied a *lot* ). I have changed to ( from 
> commented out )
> 
>     dnssec-enable no;
>     dnssec-validation no;
>     #dnssec-enable yes;
>     #dnssec-validation yes;
>     #dnssec-lookaside auto;
> 
> I have hundreds of pages of logs like
> 
> Jun  7 03:36:54 localhost named[27394]: error (no valid RRSIG) resolving 
> 'v0cdn.net/DS/IN': 208.67.220.220#53
> Jun  7 03:36:54 localhost named[27394]:   validating @0x7f805c025e40: 
> dlv.isc.org SOA: got insecure response; parent indicates it should be secure
> Jun  7 03:36:55 localhost named[27394]:   validating @0x7f80644fc9f0: 
> dlv.isc.org SOA: got insecure response; parent indicates it should be secure
> 
> 
> Through the wonders of sed and awk, here's the worst ones ( count - > 100 - 
> first ) from the last 2 days:
> 
>     103 nz.dlv.isc.org
>     104 facebook.com.dlv.isc.org
>     104 www.google.com.dlv.isc.org <http://www.google.com.dlv.isc.org/>
>     105 google.co.nz.dlv.isc.org
>     105 openweathermap.org.dlv.isc.org
>     107 wunderground.com.dlv.isc.org
>     115 akamai.net
>     122 amazon.com
>     124 google.co.nz
>     126 skype.com
>     127 googleapis.com
>     129 accuweather.com
>     129 plexapp.com
>     133 <none>
>     134 yourpbx.com
>     135 crashlytics.com
>     142 google.com.dlv.isc.org
>     143 amazonaws.com.dlv.isc.org
>     145 net.dlv.isc.org
>     147 apptimize.com
>     148 akadns.net.dlv.isc.org
>     158 a-msedge.net
>     163 com.dlv.isc.org
>     177 msn.com
>     189 mixpanel.com
>     190 yahoo.com
>     202 aprs.net
>     204 akamaiedge.net
>     232 facebook.com
>     254 openweathermap.org
>     280 wunderground.com
>     324 amazonaws.com
>     347 google.com
> 
> 
> Cheers,
> 
> 
> Steve
> 
> 
> 
> 
> 
> 
> On 09/06/15 11:59, Fraser McGlinn wrote:
>> In my experience I haven’t had any issues having DNSSEC Validation on. Minus 
>> the odd bogus signed zone (both publicly and privately). Back when I was 
>> working with Craig we enabled it on the TotalTeam ISP DNS servers without 
>> any impact. Also i’ve been running validation on my internal recursive DNS 
>> servers running Bind 9.9 for a long time.
>> 
>> Without further information inclination would be that it ‘might' be a broken 
>> DNSSEC implementation on the DNS server. Any further info on what domains 
>> are not validating correctly or what DNS server and version you are running?
>> 
>> Fraser
>> 
>>> On 9 Jun 2015, at 7:18 am, steve <[email protected] 
>>> <mailto:[email protected]>> wrote:
>>> 
>>> There's a few notes below, but I think that removing DNSSEC requirements 
>>> from the DNS server might have sorted it.
>>> 
>>> Does that make sense? It was causing a metric shedload of error messages.
>>> 
>>> 
>>> Steve
>>> 
>>> On 08/06/15 09:09, C. Falconer wrote:
>>>> steve wrote on 06/06/15 17:00:
>>>>> Am nearing wits end... been away on hols for a month and my network 
>>>>> performance has plummeted.
>>>>> 
>>>>> The best way of describing the problem is that you need to refresh a web 
>>>>> page before you get any content. In addition, bulk loading across a VPN ( 
>>>>> eg scp ) fails regularly.
>>>>> 
>>>>> Basic design of network: 'firewall' server runs fail2ban and links 
>>>>> upstream ADSL to local wireless and wired subnets. It also provides DNS ( 
>>>>> caching server ), DHCP, OpenVPN etc services.
>>>>> 
>>>>> I initially thought it was a DNS problem, and have migrated from the 
>>>>> local ( Voda ) DNS servers to OpenDNS, having briefly tried Googles 
>>>>> resolvers on the way. No improvement.
>>>>> 
>>>>> Any thoughts on what I can try to identify the real problem? My thought 
>>>>> is that the GCSB are involved somewhere along the line, but as a SysAdm I 
>>>>> am paid to be paranoid!
>>>> 
>>>> 
>>>> OK - honestly I have no idea.... but I agree with Fraser in that "random 
>>>> weird stuff" does often have root causes in DNS or MTU.  But you've 
>>>> appeared to rule them out.
>>>> 
>>>> 
>>>> So, cut the problem up.
>>>> 1) Does the link test as slow when from the firewall box, as opposed to a 
>>>> client machine?
>>>>         If no then its a local network thing - isolate between wired and 
>>>> wireless clients
>>>>         If yes, then its an internet link.
>>> OK, I'm testing this as we speak as I don't have a GUI and want to test 
>>> like for like. Download speeds are not a problem generally, I usually 
>>> manage to crank over 1MB/s from anywhere not wirelessly connected.
>>> 
>>> Interestingly, if I try to start up firefox via ssh -X to the 'firewall', 
>>> it starts a new session up on the local workstation if ff is running on 
>>> that, and vv.
>>>> 
>>>> 2) How's the neighbour's speeds?  Do they have Chorus ADSL?
>>> No idea really. We generally get good service over here, probably due to 
>>> the odd MP living locally (:
>>>> 
>>>> 3) Have you got any other ADSL routers to swap out?  Its not unknown for 
>>>> the hardware to just start dying from rubbish on the wire, specially if 
>>>> its not completely urban.
>>> The venerable 12 year old speedtouch doesn't seem to make any appreciable 
>>> difference.
>>>> 
>>>> 4) Have you spoken with your ISP about getting line tests done?  They can 
>>>> do a 2 or 24 hour line test and monitor the stats from your DSL link, 
>>>> which should give some indication of the DSL's performance.  You can 
>>>> continue to use it like normal for the test period too.
>>> Like I say, the line seems to be fine, once the traffic is flowing.
>>>> 
>>>> 5) From memory you're in Diamond Harbour, so pretty SOOL for anything like 
>>>> fibre.  Would you have line of sight to Marleys hill?  Probably not.   
>>>> Would you entertain the thought of a wireless link across the water?   Do 
>>>> you know anyone in Lyttelton with fibre and LOS to your place ?
>>> Yes, I'm over the water,unfortunately round the corner too. I'm not too 
>>> sure what wireless propagates like over water... last time I read up, the 
>>> bounces caused problems. However, with these 3 aerialed thingies, that 
>>> shouldn't be a problem nowadays???
>>>> 
>>>> 6) If you want to investigate further, do a        tcpdump -i any -nn -w 
>>>> poorlink.pcap -vv -s 1500
>>>> on your firewall, while testing from the internal host.   Do something to 
>>>> exhibit the problem, and then email me the pcap off list.
>>>> 
>>>> 7) Finally, apply all windows updates, upgrade flash, java and acrobat 
>>>> reader, do a antivirus scan and a malware scan, and restart your computer.
>>> Wash your mouth out (:
>>>> 
>>>> --
>>>> CF
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Linux-users mailing list
>>>> [email protected] 
>>>> <mailto:[email protected]>
>>>> http://lists.canterbury.ac.nz/mailman/listinfo/linux-users 
>>>> <http://lists.canterbury.ac.nz/mailman/listinfo/linux-users>
>>> 
>>> --
>>> Steve Holdoway BSc(Hons) MIITP
>>> http://www.greengecko.co.nz <http://www.greengecko.co.nz/>
>>> Linkedin: http://www.linkedin.com/in/steveholdoway 
>>> <http://www.linkedin.com/in/steveholdoway>
>>> Skype: sholdowa
>>> _______________________________________________
>>> Linux-users mailing list
>>> [email protected] 
>>> <mailto:[email protected]>
>>> http://lists.canterbury.ac.nz/mailman/listinfo/linux-users 
>>> <http://lists.canterbury.ac.nz/mailman/listinfo/linux-users>
>> 
>> 
>> 
>> _______________________________________________
>> Linux-users mailing list
>> [email protected] 
>> <mailto:[email protected]>
>> http://lists.canterbury.ac.nz/mailman/listinfo/linux-users 
>> <http://lists.canterbury.ac.nz/mailman/listinfo/linux-users>
> 
> --
> Steve Holdoway BSc(Hons) MIITP
> http://www.greengecko.co.nz <http://www.greengecko.co.nz/>
> Linkedin: http://www.linkedin.com/in/steveholdoway 
> <http://www.linkedin.com/in/steveholdoway>
> Skype: sholdowa
> _______________________________________________
> Linux-users mailing list
> [email protected]
> http://lists.canterbury.ac.nz/mailman/listinfo/linux-users

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
Linux-users mailing list
[email protected]
http://lists.canterbury.ac.nz/mailman/listinfo/linux-users

Reply via email to