[Pdns-users] PowerDNS Recursor: McAfee-related errors in your log files

2010-12-08 Thread bert hubert
Dear PowerDNS Recursor users,

If you have McAfee users among your client base, you may currently be seeing
errors like these in your log file:

pdns_recursor[4024]: DNS parser error: 
0.xx-x.xx.1xxx...xxx.x.xx.avqs.mcafee.com.,
 
Parsing record content: expected digits at position 9 in 
'\# 45 
093a800258'

These errors are harmless to your general Recursor operations, but the
McAfee program generating these queries will be reporting timeouts to your
end-users.

The root cause of this error is a protocol violation by the McAfee
nameserver software. We are attempting to contact McAfee so that they can
become aware of this error. In short, they are emitting answers in 'CLASS0'
instead of in 'CLASS IN'. 

This causes PowerDNS to log the scary errors reported above. Additionally,
it crashes many versions of 'dig'. 

We are attempting to contact McAfee. If you know anyone in a DNS position
there, please let me know.  In the meantime, if you want to get rid of this
error and you can recompile your PowerDNS Recursor, you can use:

Index: dnsparser.cc
===
--- dnsparser.cc(revision 1745)
+++ dnsparser.cc(working copy)
@@ -246,6 +246,8 @@
   dr.d_ttl=ah.d_ttl;
   dr.d_type=ah.d_type;
   dr.d_class=ah.d_class;
+  if(dr.d_class == 0)
+dr.d_class = 1;
   
   dr.d_label=label;
   dr.d_clen=ah.d_clen;

Kind regards,

Bert Hubert
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
http://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] PowerDNS Recursor: McAfee-related errors in your log files

2010-12-08 Thread bert hubert
McAfee responded within minutes, and they are on the case. Thanks for the
hint!

Bert

On Wed, Dec 08, 2010 at 09:05:24AM -0500, Curtis Maurand wrote:
 You might try posting a message to the nanog list.
 
 --Curtis
 
 On 12/8/2010 7:43 AM, bert hubert wrote:
 Dear PowerDNS Recursor users,
 
 If you have McAfee users among your client base, you may currently be seeing
 errors like these in your log file:
 
 pdns_recursor[4024]: DNS parser error:
 0.xx-x.xx.1xxx...xxx.x.xx.avqs.mcafee.com.,
 Parsing record content: expected digits at position 9 in
 '\# 45 
 093a800258'
 
 These errors are harmless to your general Recursor operations, but the
 McAfee program generating these queries will be reporting timeouts to your
 end-users.
 
 The root cause of this error is a protocol violation by the McAfee
 nameserver software. We are attempting to contact McAfee so that they can
 become aware of this error. In short, they are emitting answers in 'CLASS0'
 instead of in 'CLASS IN'.
 
 This causes PowerDNS to log the scary errors reported above. Additionally,
 it crashes many versions of 'dig'.
 
 We are attempting to contact McAfee. If you know anyone in a DNS position
 there, please let me know.  In the meantime, if you want to get rid of this
 error and you can recompile your PowerDNS Recursor, you can use:
 
 Index: dnsparser.cc
 ===
 --- dnsparser.cc(revision 1745)
 +++ dnsparser.cc(working copy)
 @@ -246,6 +246,8 @@
 dr.d_ttl=ah.d_ttl;
 dr.d_type=ah.d_type;
 dr.d_class=ah.d_class;
 +  if(dr.d_class == 0)
 +dr.d_class = 1;
 
 dr.d_label=label;
 dr.d_clen=ah.d_clen;
 
 Kind regards,
 
 Bert Hubert
 ___
 Pdns-users mailing list
 Pdns-users@mailman.powerdns.com
 http://mailman.powerdns.com/mailman/listinfo/pdns-users
 
 ___
 Pdns-users mailing list
 Pdns-users@mailman.powerdns.com
 http://mailman.powerdns.com/mailman/listinfo/pdns-users
 
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
http://mailman.powerdns.com/mailman/listinfo/pdns-users


[Pdns-users] forward-zones, SSHFP and non-FQDN

2010-12-08 Thread Willem
Hi there,

Happy longtime PDNS user here. I'm setting up SSHFP to be able to
utilize the openssh VerifyHostKeyDNS feature. My internal network uses
a local pdns_recursor resolver with this setting:

 forward-zones=internal=IP_OF_PDNS_AUTH_SERVER

So machines can find each other with serverX.internal. This works fine
for most apps, however not for openssh. When it looks up the SSHFP
record, it doesn't expand boxX to use the FQDN (.internal) as has been
specified in resolv.conf. Imho this is by design but this renders the
feature useless in my network (unless I stick to using FQDNs).

Apart from patching openssh, would it possible to tell powerdns
recursor to also forward non-FQDN queries to a specific source? Ie.
lookups for hosts without a dot?

Alternative solutions welcome :)

Cheers!
Willem
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
http://mailman.powerdns.com/mailman/listinfo/pdns-users


[Pdns-users] Additional records

2010-12-08 Thread Pete Stapley

When I query the SOA record for a domain from a bind server I receive this.

 set type=SOA
 yahoo.com
Server: ns.domain1.com
Address:1.2.3.4#53

Non-authoritative answer:
yahoo.com
origin = ns1.yahoo.com
mail addr = hostmaster.yahoo-inc.com
serial = 2010120812
refresh = 3600
retry = 300
expire = 1814400
minimum = 600

Authoritative answers can be found from:
yahoo.com   nameserver = ns5.yahoo.com.
yahoo.com   nameserver = ns8.yahoo.com.
yahoo.com   nameserver = ns2.yahoo.com.
yahoo.com   nameserver = ns1.yahoo.com.
yahoo.com   nameserver = ns6.yahoo.com.
yahoo.com   nameserver = ns4.yahoo.com.
yahoo.com   nameserver = ns3.yahoo.com.
ns1.yahoo.com   internet address = 68.180.131.16
ns2.yahoo.com   internet address = 68.142.255.16
ns3.yahoo.com   internet address = 121.101.152.99
ns4.yahoo.com   internet address = 68.142.196.63
ns5.yahoo.com   internet address = 119.160.247.124
ns6.yahoo.com   internet address = 202.43.223.170
ns8.yahoo.com   internet address = 202.165.104.22

When I query a powerdns server I receive this.

 yahoo.com
Server: ns.domain2.com
Address:2.3.4.5#53

Non-authoritative answer:
yahoo.com
origin = ns1.yahoo.com
mail addr = hostmaster.yahoo-inc.com
serial = 2010120812
refresh = 3600
retry = 300
expire = 1814400
minimum = 600

Authoritative answers can be found from:

Is there a way to configure powerdns to return the extra records? I 
think I may be missing something. Thanks!

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
http://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] zone2sql with bind

2010-12-08 Thread Erik Ljungstrom
Are you possibly using a slightly older version? This  was fixed in 
http://wiki.powerdns.com/trac/changeset/1234 - released in 2.9.22.

Cheers,
Erik

From: pdns-users-boun...@mailman.powerdns.com 
[pdns-users-boun...@mailman.powerdns.com] on behalf of Ian Mordey 
[ian.mor...@griffin.com]
Sent: 08 December 2010 15:35
To: pdns-users@mailman.powerdns.com
Subject: [Pdns-users] zone2sql with bind

Hi there
I’m trying to use zone2sql to migrate DNS from a bind box to a new PowerDNS 
box. I have a problem where the bind zone file contains a . in the $ORIGIN. For 
example:

$ORIGIN .

Zone2sql writes the insert as:
Insert into domains (name,type) values (‘example.com’,’NATIVE’);
Insert into records (domain_id,name,type,content,ttl,prio) select id 
,’example.com’ ,  ‘NS’ , ‘ns0.example.com’, 345600, 0 from domains where name = 
‘example.com.’)

This breaks the insert of the record as no domain exists with the name = 
‘example.com.’ only ‘example.com’

Any ideas why? Or any workaround?

Thanks
Ian
This message is intended solely for the use of the individual or organisation 
to whom it is addressed. It may contain privileged or confidential information. 
If you have received this message in error, please notify the originator 
immediately. If you are not the intended recipient, you should not use, copy, 
alter, or disclose the contents of this message. All information or opinions 
expressed in this message and/or any attachments are those of the author and 
are not necessarily those of DediPower Managed Hosting Ltd or its affiliates.

DediPower Managed Hosting Ltd is registered in England and Wales No. 3625971 
Registered Office: Cadogan House, Rose Kiln Lane, Reading, Berkshire, RG2 0HP
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
http://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Additional records

2010-12-08 Thread Kenneth Marshall
On Wed, Dec 08, 2010 at 04:30:35PM -0700, Pete Stapley wrote:
 When I query the SOA record for a domain from a bind server I receive this.

  set type=SOA
  yahoo.com
 Server: ns.domain1.com
 Address:1.2.3.4#53

 Non-authoritative answer:
 yahoo.com
 origin = ns1.yahoo.com
 mail addr = hostmaster.yahoo-inc.com
 serial = 2010120812
 refresh = 3600
 retry = 300
 expire = 1814400
 minimum = 600

 Authoritative answers can be found from:
 yahoo.com   nameserver = ns5.yahoo.com.
 yahoo.com   nameserver = ns8.yahoo.com.
 yahoo.com   nameserver = ns2.yahoo.com.
 yahoo.com   nameserver = ns1.yahoo.com.
 yahoo.com   nameserver = ns6.yahoo.com.
 yahoo.com   nameserver = ns4.yahoo.com.
 yahoo.com   nameserver = ns3.yahoo.com.
 ns1.yahoo.com   internet address = 68.180.131.16
 ns2.yahoo.com   internet address = 68.142.255.16
 ns3.yahoo.com   internet address = 121.101.152.99
 ns4.yahoo.com   internet address = 68.142.196.63
 ns5.yahoo.com   internet address = 119.160.247.124
 ns6.yahoo.com   internet address = 202.43.223.170
 ns8.yahoo.com   internet address = 202.165.104.22

 When I query a powerdns server I receive this.

  yahoo.com
 Server: ns.domain2.com
 Address:2.3.4.5#53

 Non-authoritative answer:
 yahoo.com
 origin = ns1.yahoo.com
 mail addr = hostmaster.yahoo-inc.com
 serial = 2010120812
 refresh = 3600
 retry = 300
 expire = 1814400
 minimum = 600

 Authoritative answers can be found from:

 Is there a way to configure powerdns to return the extra records? I think I 
 may be missing something. Thanks!


That does not really make much sense with regards to SOA records. If you look
up NS records you will see that it returns the needed additional information.
If you can show a performance problem resulting from that missing extra
information, it might be worth adding them in. Currently, that extra information
is not returned. I actually logged a bug for this issue with regards to MX
records, I think. In that case, the performance with PDNS was dramatically
slower than AD DNS which returned some additional information in the MX query.
PDNS now returns that information and its performance is great. I think if
you have an actual problem caused by that missing additional information,
you will have the best chance of having it included in a future release.

Cheers,
Ken
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
http://mailman.powerdns.com/mailman/listinfo/pdns-users