Re: Rejected queries for mx???.emailfiltering.com
Once upon a time, Phil Mayers p.may...@imperial.ac.uk said: On the subject of rejected queries - although this isn't a bind question per-se, I'm curious if anyone else here sees a lot of these: client 178.123.92.141#23861: view main: query (cache) 'mx242.emailfiltering.com/A/IN' denied We get *loads* of them to our authoritative resolvers. I am assuming they are attempts at cache poisoning given the (ahem) dubious geographical origin of the queries (no offense intended to anyone living in those parts of the world) but I can't see any corresponding inbound forged DNS packets in our netflow. Do you have domains listing mx242.emailfiltering.com as an MX? I have seen some broken resolvers that will do an MX lookup and then turn around and do A lookups for the MX hosts at the same DNS server. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursion on auth-only server
Once upon a time, Matus UHLAR - fantomas uh...@fantomas.sk said: I don't care if they do recursion themselves, but if anyone asks this server with RD flag set, the answer will be venemous. You should realize that anybody trying to debug possible DNS issues might issue queries directly to your server with tools like dig, which requests recursion by default. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Trying to understand DNSSEC and BIND versions better
Since I read that the root is supposed to be signed by the end of the year, I am just trying to understand DNSSEC support and the various versions of BIND a little better here, so please don't throw too many rocks if I ask something stupid... I run the nameservers for an ISP. For the recursive servers, what are the hazzards in enabling DNSSEC (once the root is signed, so no DLV necessary I guess)? I know the things that generally break with regular DNS, but I don't know that with DNSSEC (I know there have been DLV troubles but that's it). Currently, my servers run BIND 9.3.4-10.P1 (as patched by Red Hat in RHEL; we typically stick with their security patched version, since that's what we pay them for). What does that mean with .ORG for example, where NSEC3 is used? Would we just not see NXDOMAIN responses as validated (and what happens to unvalidated responses)? I've put in a request to Red Hat to update to a version that supports NSEC3 but I don't know what their response will be yet. For our authoritative servers, we'll need to set up a system to sign the zones. Is it expected that ISPs will sign every zone they serve, or just the domains we consider important? What kind of problems might be expected here? In both cases, what kind of CPU and/or RAM overhead will large-scale use of DNSSEC add? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
