Truncated DNS message over UDP
Hello everyone, before sending this email I tried do some seaches on this topic, but no luck so far...so before bothering bind-workers here's my question I was wondering if a configuration option exists in order to force bind server to send a "minimal (from size and number of returned record point of view)" response in case the trucated bit is set in the header. Let me explain better... 1) Client asks for "www.mydomain.com" type ANY to my server (RD bit is set) 2) Server gets the response (does not matter if from cache or not) but the answer is bigger than 512 bytes (or the server has udp-max-size 512 parameter in configuration) 3) Server send answer with TC bit = 1, but instead of giving partial response header is like this QDCOUNT = 1, ANCOUNT = 0, NSCOUTN = 0, ADDITIONAL=0 (if there is no EDSN0 in query) and just sent back the question section. 4) Client (if needed) re-do the query using TCP (some clients does not use records contained in packets with TC bit set in the header) If I'm not wrong RFCs does not state that partial answer must be returned to the client, so probably there is no issue in getting rid of them (with a configuration option :) ) Is there any parameter that could let me achieve this result? Kind regards. Seba ___ 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
prevent DNS attack
Hello, DNS is very easy to be attacked. My named service got 1G or more traffic of attack some time. How can we take some steps to prevent them? Thanks -- Email/Jabber/Gtalk: pa...@riseup.net Free DNS Hosting with www.DNSbed.com ___ 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: Understanding cause of DNS format error (FORMERR)
In article , Barry Margolin wrote: > In article , > Sam Wilson wrote: > > > For a NXDOMAIN response, or NOERROR with an empty answer section, the > > server should provide the SOA record in the authority section. That SOA > > is the apex of the zone which doesn't contain the answer record you > > asked for, if you see what I mean. The server is proving that it has > > authority to tell you that the information doesn't exist. > > More important, the SOA record contains the TTL that should be used for > the negative cache entry. More important for the operation of the DNS, but I'd think less important from the point of view of manual debugging, like we're doing here. > > The fact that looking for nonexistent data for > > vlasext.partners.extranet.microsoft.com returns the > > partners.extranet.microsoft.com SOA record shows that the vlasext > > subdomain has not been delegated. The servers should therefore be able > > to offer an authoritative answer for data that does exist for > > vlasext.etc... but they don't. > > This type of inconsistency often suggests a DNS-based load balancer is > involved. I wondered that but it's not consistent with earlier results in the thread which suggested Windows DNS server for at least one of them. An old version of fpdns (someone might like to try a newer one) concurs: $ for i in 0 1 2 3 ; do fpdns dns1$i.one.microsoft.com ; done fingerprint (dns10.one.microsoft.com, 131.107.125.65): Microsoft \ Windows 2003 fingerprint (dns11.one.microsoft.com, 94.245.124.49): Microsoft \ Windows 2003 fingerprint (dns12.one.microsoft.com, 207.46.55.10): Microsoft \ Windows 2003 fingerprint (dns13.one.microsoft.com, 65.55.31.17): Microsoft \ Windows 2003 $ fpdns -v fpdns.pl version 0.9.1 Sam -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ 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: Truncated DNS message over UDP
Hello, Several RFC's on DNS do state that name servers (not only Bind) should avoid, if possible, to send messages that would require the TC bit set in the reply. Replies can be stay shorter if some sections (authority/additional) are not included in the reply. I know for sure that DNSSEC related RFC's explicitly state to leave authority/additional section empty if filling them would lead to the answer becoming too big and requiring the TC bit to be set. --> it is not a configuration setting, it's RFC defined. Kind regards, Marc Lampo Security Officer EURid (for .eu) -Original Message- From: Sebastiano Di Paola [mailto:sebastiano.dipa...@gmail.com] Sent: 27 June 2012 10:43 AM To: bind-users@lists.isc.org Subject: Truncated DNS message over UDP Hello everyone, before sending this email I tried do some seaches on this topic, but no luck so far...so before bothering bind-workers here's my question I was wondering if a configuration option exists in order to force bind server to send a "minimal (from size and number of returned record point of view)" response in case the trucated bit is set in the header. Let me explain better... 1) Client asks for "www.mydomain.com" type ANY to my server (RD bit is set) 2) Server gets the response (does not matter if from cache or not) but the answer is bigger than 512 bytes (or the server has udp-max-size 512 parameter in configuration) 3) Server send answer with TC bit = 1, but instead of giving partial response header is like this QDCOUNT = 1, ANCOUNT = 0, NSCOUTN = 0, ADDITIONAL=0 (if there is no EDSN0 in query) and just sent back the question section. 4) Client (if needed) re-do the query using TCP (some clients does not use records contained in packets with TC bit set in the header) If I'm not wrong RFCs does not state that partial answer must be returned to the client, so probably there is no issue in getting rid of them (with a configuration option :) ) Is there any parameter that could let me achieve this result? Kind regards. Seba ___ 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: prevent DNS attack
pa...@riseup.net wrote on 06/27/2012 05:20:32 AM: > DNS is very easy to be attacked. Yes it is > My named service got 1G or more traffic of attack some time. > How can we take some steps to prevent them? http://www.google.com/search?q=prevent+DNS+atttack 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
Re: prevent DNS attack
pangj wrote: > > DNS is very easy to be attacked. > My named service got 1G or more traffic of attack some time. > How can we take some steps to prevent them? Incoming or outgoing? A number of people have been having this problem recently. You might want to join the dns-operations list: https://lists.dns-oarc.net/mailman/listinfo/dns-operations/ There has been much discussion of DDoS attacks this month and you can read the messages in the list archives. There is also a patch for BIND which can help: http://www.redbarn.org/dns/ratelimits Tony. -- f.anthony.n.finchhttp://dotat.at/ Humber, Thames, Dover: Southwest backing southeast 4 or 5. Slight or moderate. Occasional rain, fog patches. Moderate, occasionally very poor. ___ 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: Truncated DNS message over UDP
Hi, Mark you are right saing "When it's possible..." But I want to address the the situation when the DNS server is made to limit response on 512 Bytes (i.e. for bind server parameter udp-max-size 512) and the answer is bigger. (Imagine I have a big TXT record for example) As bind up to version 9.9.1-P1 gives partial answer in this case (filling the reply packet up to 512 Bytes and setting TC bit) is there any configuration to obtain a response packet with omitted "answer" and "authorities" and, unless additional record is specified by query packet i.e. setting edsn0, "additional" parts ? The behaviour I observed is not what you said is stated in DNSSEC (but I'm not just talking about DNSSEC) related RFCs, even if I would like it had been like that. Regards, Sebastiano On Wed, Jun 27, 2012 at 2:10 PM, Marc Lampo wrote: > Hello, > > Several RFC's on DNS do state that name servers (not only Bind) should > avoid, > if possible, to send messages that would require the TC bit set in the > reply. > Replies can be stay shorter if some sections (authority/additional) are > not > included in the reply. > I know for sure that DNSSEC related RFC's explicitly state to leave > authority/additional section empty if filling them would lead to the > answer becoming too big and requiring the TC bit to be set. > --> it is not a configuration setting, it's RFC defined. > > > Kind regards, > > Marc Lampo > Security Officer > EURid (for .eu) > > > -Original Message- > From: Sebastiano Di Paola [mailto:sebastiano.dipa...@gmail.com] > Sent: 27 June 2012 10:43 AM > To: bind-users@lists.isc.org > Subject: Truncated DNS message over UDP > > Hello everyone, > before sending this email I tried do some seaches on this topic, but no > luck so far...so before bothering bind-workers here's my question > > I was wondering if a configuration option exists in order to force bind > server to send a "minimal (from size and number of returned record point > of view)" response in case the trucated bit is set in the header. > > Let me explain better... > 1) Client asks for "www.mydomain.com" type ANY to my server (RD bit is > set) > 2) Server gets the response (does not matter if from cache or not) but the > answer is bigger than 512 bytes (or the server has udp-max-size > 512 parameter in configuration) > 3) Server send answer with TC bit = 1, but instead of giving partial > response header is like this QDCOUNT = 1, ANCOUNT = 0, NSCOUTN = 0, > ADDITIONAL=0 (if there is no EDSN0 in query) and just sent back the > question section. > 4) Client (if needed) re-do the query using TCP (some clients does not use > records contained in packets with TC bit set in the header) > > If I'm not wrong RFCs does not state that partial answer must be returned > to the client, so probably there is no issue in getting rid of them (with > a configuration option :) ) > > Is there any parameter that could let me achieve this result? > Kind regards. > Seba > ___ 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: Reverse zones best practices
On 26/06/12 17:25, nex6 wrote: * Phil Mayers [2012-06-26 16:54:55 +0100]: I am not going to be editing files by hand, we actually have a tool. I am more concerned about best practices, and how to fix the mess. eg, say we have about 500 vlans (/24s) and say only 350 have reverse zones. from what I understand its best to just create the missing zones and fix the tools so new networks always get reverse zones created. becuase I dont think i can just create a larger /16 or /8. becuase they will overlap and create a bigger mess. Do what works for you. If you would rather create the full range of x.y.10.in-addr.arpa from your tools, that's fine. I'm not sure the "best practice" you are asking about exists in that form. One final point though - you *should* have an enclosing 10.in-addr.arpa zone or "fill the holes", so that you don't leak reverse lookups to the DNS root servers. You might even find that, unless you disable it, your nameserver creates the empty zone for you. ___ 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: Truncated DNS message over UDP
On Wed, 27 Jun 2012, Sebastiano Di Paola wrote: Hello everyone, before sending this email I tried do some seaches on this topic, but no luck so far...so before bothering bind-workers here's my question I was wondering if a configuration option exists in order to force bind server to send a "minimal (from size and number of returned record point of view)" response in case the trucated bit is set in the header. See if "minimal-responses yes" does what you want. If I'm recalling correctly, it applies to all responses, not just those which would be truncated. It can cause more subsequent queries, to get the information which would have been in the first response, but they'll probably all be UDP which might be better than fallback to TCP. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ 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: Reverse zones best practices
* Phil Mayers [2012-06-27 14:29:38 +0100]: > On 26/06/12 17:25, nex6 wrote: > >* Phil Mayers [2012-06-26 16:54:55 +0100]: > > > > > >I am not going to be editing files by hand, we actually have a tool. I am > >more > >concerned about best practices, and how to fix the mess. > > > >eg, say we have about 500 vlans (/24s) and say only 350 have reverse zones. > >from what I understand its best to just create the missing zones and fix the > >tools > >so new networks always get reverse zones created. > > > >becuase I dont think i can just create a larger /16 or /8. becuase they will > >overlap and create a bigger mess. > > Do what works for you. If you would rather create the full range of > x.y.10.in-addr.arpa from your tools, that's fine. > > I'm not sure the "best practice" you are asking about exists in that form. > > One final point though - you *should* have an enclosing > 10.in-addr.arpa zone or "fill the holes", so that you don't leak > reverse lookups to the DNS root servers. You might even find that, > unless you disable it, your nameserver creates the empty zone for > you. so, you *should* have a larger 10.x.x.x zone? *and* smaller 10.x.x.0/24 zones? so i am assuming the workflow would be in this case, records go in the smaller zones, and the larger zone is the catchall to prevent leakage? ___ 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: Reverse zones best practices
On 27/06/12 15:30, nex6 wrote: so, you *should* have a larger 10.x.x.x zone? *and* smaller 10.x.x.0/24 zones? so i am assuming the workflow would be in this case, records go in the smaller zones, and the larger zone is the catchall to prevent leakage? It is good practice, and polite, to prevent leakage of reverse DNS queries for the private IP ranges. You can accomplish this two ways: 1. Have a "zone" statement for every /24 inside 10/8 e.g. 0.0.10.in-addr-arpa 1.0.10.in-addr.arpa ... 255.255.in-addr.arpa You could use empty/dummy zones (maybe even the same zone file) for zones which don't have actual contents defined. 2. Have a "10.in-addr.arpa" zone *and* the smaller zones. If you do this, you might want to take the time to insert the proper delegations inside the 10.in-addr.arpa zone to the smaller zones, even if they're on the same servers. It might work without that, but there might be circumstances where it won't - I'm not sure. ___ 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
Using Zone Files as Data Base
For years, we have used the A records in a zone as a data base of assigned IP addresses and host names. We have always done a zone transfer from a slave each time we were about to assign new IP addresses and this has worked well, but it occurred to me that it would also work if one could run a dynamic slave DNS which always wrote changes to files as they occurred rather than to journals which is the usual case and which is normally desirable. Now, we do a zone transfer from the slave, look for all the A records, and then that tells us which IP addresses are likely to be free in a network. In the new system, we would have a dynamic zone that was always current so no need to do a zone transfer. Additions and deletions would just be there a fraction of a second later and the file would always be current. Thanks for any useful ideas. Martin McCormick ___ 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
Want to see NXDOMAIN responses
What logging level and channel do I need to configure to see every NXDOMAIN response generated by the server and the address of the client which sent the corresponding request? Thanks, Ken Traynham KEN TRAYNHAM ITS EPA II - COTS CSC (Contractor) 79 TW Alexander Drive, Building 4201, Research Triangle Park, NC 27709 North American Public Sector | p: 919.767.7059 | f: 919.484.7703 | traynham@epa.gov | www.csc.com ___ 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: Reverse zones best practices
I would set up 10.in-addr.arpa which is slaved on all internal nameservers and delegate the /24's as required. 10.in-addr.arpa won't change much and will be cheaper in the long run than using a stub zone. In message <4feb2a8a.4050...@imperial.ac.uk>, Phil Mayers writes: > On 27/06/12 15:30, nex6 wrote: > > > so, you *should* have a larger 10.x.x.x zone? *and* smaller > > 10.x.x.0/24 zones? so i am assuming the workflow would be in this > > case, records go in the smaller zones, and the larger zone is the > > catchall to prevent leakage? > > It is good practice, and polite, to prevent leakage of reverse DNS > queries for the private IP ranges. > > You can accomplish this two ways: > > 1. Have a "zone" statement for every /24 inside 10/8 e.g. > > 0.0.10.in-addr-arpa > 1.0.10.in-addr.arpa > ... > 255.255.in-addr.arpa > > You could use empty/dummy zones (maybe even the same zone file) for > zones which don't have actual contents defined. > > > 2. Have a "10.in-addr.arpa" zone *and* the smaller zones. If you do > this, you might want to take the time to insert the proper delegations > inside the 10.in-addr.arpa zone to the smaller zones, even if they're on > the same servers. It might work without that, but there might be > circumstances where it won't - I'm not sure. It won't work is 10.in-addr.arpa is signed and you have validating clients that know the trust anchor for it. > ___ > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: Want to see NXDOMAIN responses
In message , Ken Traynham writes: > > What logging level and channel do I need to configure to see every > NXDOMAIN response generated by the server and the address of the client > which sent the corresponding request? There isn't a logging level which will give you this. I would use a packet level tool like tcpdump / snoop to get this. > Thanks, > Ken Traynham > > KEN TRAYNHAM > ITS EPA II - COTS > CSC (Contractor) > > 79 TW Alexander Drive, Building 4201, Research Triangle Park, NC 27709 > North American Public Sector | p: 919.767.7059 | f: 919.484.7703 | > traynham@epa.gov | www.csc.com -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: prevent DNS attack
There is also a patch for BIND which can help: http://www.redbarn.org/dns/ratelimits Thank you. The traffic is incoming, and the incoming IPs are fake, how will the patch work to stop them? -- Email/Jabber/Gtalk: pa...@riseup.net Free DNS Hosting with www.DNSbed.com ___ 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: prevent DNS attack
define "fake" -- if you mean rfc1918, you can block the ranges at ingress, or with iptables or similar to avoid letting it hit bind at all. -Original Message- From: pangj Date: Wednesday, June 27, 2012 6:36 PM To: Tony Finch Cc: "bind-users@lists.isc.org" Subject: Re: prevent DNS attack > >> There is also a patch for BIND which can help: >> >> http://www.redbarn.org/dns/ratelimits > >Thank you. >The traffic is incoming, and the incoming IPs are fake, how will the >patch work to stop them? > >-- >Email/Jabber/Gtalk: pa...@riseup.net >Free DNS Hosting with www.DNSbed.com > > >___ >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: prevent DNS attack
define "fake" -- if you mean rfc1918, you can block the ranges at ingress, or with iptables or similar to avoid letting it hit bind at all. Yes I mean source-spoofed DDoS attack and I am reading this document: http://en.wikipedia.org/wiki/Ingress_filtering Is there a sample iptables script for that? -- Email/Jabber/Gtalk: pa...@riseup.net Free DNS Hosting with www.DNSbed.com ___ 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
