Re: [dns-operations] DNS Issue
* John Kristoff wrote: And why auditors do not like tcp53 open to public? They may have an outdated, naive view of what should be open and what shouldn't be? Show them the above and ask them why. I'd be curious what the response is. We have never seen TCP/53 in public beside strange examples or attack. TCP/53 ise superseded by EDNS0 TCP/53 is only needed for AXFR, allow TCP/53 only to(!) your primary NS DNS works over UDP There are more such answers. But the most prominent answer is: We marked it red, because it's a security risk. Close it! ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Issue
We've seen large companies' sysadmins being adamant that their firewall setup was correct and that we didn't know DNS .. .. even though every single article and test result proved otherwise .. Never underestimate stupidity and ignorance :) Mr Michele Neylon Blacknight Solutions ♞ Hosting Domains ICANN Accredited Registrar http://www.blacknight.co http://blog.blacknight.com/ Intl. +353 (0) 59 9183072 US: 213-233-1612 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Facebook: http://fb.me/blacknight Twitter: http://twitter.com/mneylon --- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Issue
* Joe Abley: The assumption is that firewall means device that keeps state. This could be a firewall, or a NAT, or an in-line DPI device, or something similar. We're not talking about stateless packet filters. I think you still can't serve UDP over IPv6 without per-client sate, keeping both full RFC conformance and interoperability with the existing client population. Pre-fragmentation to 1280 or so bytes isn't enough, you also have to generate atomic fragments. But the latter cannot be processed by some clients, so you cannot send out atomic fragments unconditionally (even if there were a socket option to do that). Many large servers do not even pre-fragment to 1280 bytes, so they rely on path MTU information in the destination cache for communication with clients on sub-1500-MTU links. I wonder when this statefullness of IPv6 UDP traffic will cause practical problems, probably as soon as the traffic levels exceeds what can be comfortably kept in the server cache. Enough ranting today. I suspect this issue will only get addressed when enough operators experience it first-hand, like the EDNS0 fallback issue. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Issue
On May 1, 2013, at 9:40 PM, Florian Weimer wrote: I wonder when this statefullness of IPv6 UDP traffic will cause practical problems, One rather suspects that there are many more implications to moving fragmentation to the endpoint nodes which have yet to be fully understood (for example, the negative effects of ICMPv6 overblocking on PMTU-D). --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Issue
-Original Message- From: Michele Neylon :: Blacknight mich...@blacknight.com Date: Wednesday, May 1, 2013 8:21 AM To: Lutz Donnerhacke l...@iks-jena.de Cc: dns-operati...@mail.dns-oarc.net dns-operati...@mail.dns-oarc.net Subject: Re: [dns-operations] DNS Issue We've seen large companies' sysadmins being adamant that their firewall setup was correct and that we didn't know DNS .. .. even though every single article and test result proved otherwise .. Never underestimate stupidity and ignorance :) Hanlon's razor... One of my favorites. :-) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Issue
Florian Weimer f...@deneb.enyo.de wrote: I think you still can't serve UDP over IPv6 without per-client sate, keeping both full RFC conformance and interoperability with the existing client population. Pre-fragmentation to 1280 or so bytes isn't enough, you also have to generate atomic fragments. Or don't fragment and restrict the EDNS buffer size to 1280. I'm somewhat amazed that DNS-over-fragmented-UDP works as well as it does. See also https://www.usenix.org/conference/lisa12/dnssec-what-every-sysadmin-should-be-doing-keep-things-working Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Issue
* Tony Finch: Florian Weimer f...@deneb.enyo.de wrote: I think you still can't serve UDP over IPv6 without per-client sate, keeping both full RFC conformance and interoperability with the existing client population. Pre-fragmentation to 1280 or so bytes isn't enough, you also have to generate atomic fragments. Or don't fragment and restrict the EDNS buffer size to 1280. Unfortunately, that's still not compliant. Those responses can trigger ICMP Packet Too Big messages, and then you're supposed to generate atomic fragments (that is, send a single-packet unfragmented response with a Fragmentation header). It's one of those things in the IPv6 specification which should go, but 6man *loves* them, unfortunately. (By the way, if you've got a system which generates atomic fragments, you should set a lower EDNS buffer size than 1280.) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Issue
Tony Finch wrote: ... don't fragment and restrict the EDNS buffer size to 1280. I'm somewhat amazed that DNS-over-fragmented-UDP works as well as it does. See also https://www.usenix.org/conference/lisa12/dnssec-what-every-sysadmin-should-be-doing-keep-things-working and: http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Issue
In message alpine.lsu.2.00.1305011825160.19...@hermes-2.csi.cam.ac.uk, Tony F inch writes: Florian Weimer f...@deneb.enyo.de wrote: I think you still can't serve UDP over IPv6 without per-client sate, keeping both full RFC conformance and interoperability with the existing client population. Pre-fragmentation to 1280 or so bytes isn't enough, you also have to generate atomic fragments. Or don't fragment and restrict the EDNS buffer size to 1280. I'm somewhat amazed that DNS-over-fragmented-UDP works as well as it does. See also https://www.usenix.org/conference/lisa12/dnssec-what-every-sysadmin-should-be -doing-keep-things-working Which just moves the PMTUD problem to TCP which I can assure you is also a problem. Some of the ORG servers are configured like this and guess what it does not work well. Named now sets IPV6_USE_MIN_MTU to 1 on TCP sockets to avoid this as well. In theory this should impact on the MSS negotiation and the MTU for the connection has been reduced to 1280. Apple and FreeBSD (at least get this wrong). Bug reports have been filed with both vendors as well as a kernel patch for FreeBSD. In practice it results in fragmented TCP packets being sent but at least you avoid PMTUD one way. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Issue
On Apr 26, 2013, at 8:24, Cihan SUBASI (GARANTI TEKNOLOJI) wrote: Hi, Also can someone explain why tcp53 should be allowed on the firewalls if dns is behind a firewall? In addition to other already posted reasons, TCP isn't susceptible to reflection attacks. (FWIW.) And why auditors do not like tcp53 open to public? Can't read their minds, but, well, the auditor has at least been misinformed on how DNS works. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Issue
On Apr 26, 2013, at 12:27 AM, Warren Kumari wrote: I think that in many cases it is not that the named version doesn't support randomization, but rather that they / their firewall group believes that DNS should only be allowed on port 53 (and UDP, natch). The actual problem being that the DNS servers oughtn't to be behind a firewall in the first place. ; --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Issue
From: Dobbins, Roland rdobb...@arbor.net The actual problem being that the DNS servers oughtn't to be behind a firewall in the first place. Can you elaborate on your statement? I can guess what the reaction around here would be if I suggested it. 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. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Issue
On 2013-04-26, at 08:11, wbr...@e1b.org wrote: From: Dobbins, Roland rdobb...@arbor.net The actual problem being that the DNS servers oughtn't to be behind a firewall in the first place. Can you elaborate on your statement? I can guess what the reaction around here would be if I suggested it. This list needs a FAQ. The following is the usual way this conversation pans out. The assumption is that firewall means device that keeps state. This could be a firewall, or a NAT, or an in-line DPI device, or something similar. We're not talking about stateless packet filters. A DNS server can process 100,000 qps on only mildly modern iron. With typical query patterns, that means something approaching a capacity of 100,000 flows per second. Your steady state query load may be much lower, but DNS servers have a habit of attracting flash crowds. The number of stateful firewalls that can happily handle occasional flows of up to 100,000 flows per second two/from individual devices are few. Yours probably isn't one of them. Joe ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Issue
Hi, Also can someone explain why tcp53 should be allowed on the firewalls if dns is behind a firewall? And why auditors do not like tcp53 open to public? -Original Message- From: dns-operations-boun...@lists.dns-oarc.net [mailto:dns-operations-boun...@lists.dns-oarc.net] On Behalf Of wbr...@e1b.org Sent: Friday, April 26, 2013 3:11 PM To: Dobbins, Roland Cc: dns-operations@lists.dns-oarc.net List; dns-operations-boun...@lists.dns-oarc.net Subject: Re: [dns-operations] DNS Issue From: Dobbins, Roland rdobb...@arbor.net The actual problem being that the DNS servers oughtn't to be behind a firewall in the first place. Can you elaborate on your statement? I can guess what the reaction around here would be if I suggested it. 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. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs This message and attachments are confidential and intended solely for the individual(s) stated in this message. If you received this message although you are not the addressee, you are responsible to keep the message confidential. The sender has no responsibility for the accuracy or correctness of the information in the message and its attachments. Our company shall have no liability for any changes or late receiving, loss of integrity and confidentiality, viruses and any damages caused in anyway to your computer system. Bu mesaj ve ekleri, mesajda gonderildigi belirtilen kisi/kisilere ozeldir ve gizlidir. Bu mesajin muhatabi olmamaniza ragmen tarafiniza ulasmis olmasi halinde mesaj iceriginin gizliligi ve bu gizlilik yukumlulugune uyulmasi zorunlulugu tarafiniz icin de soz konusudur. Mesaj ve eklerinde yer alan bilgilerin dogrulugu ve guncelligi konusunda gonderenin ya da sirketimizin herhangi bir sorumlulugu bulunmamaktadir. Sirketimiz mesajin ve bilgilerinin size degisiklige ugrayarak veya gec ulasmasindan, butunlugunun ve gizliliginin korunamamasindan, virus icermesinden ve bilgisayar sisteminize verebilecegi herhangi bir zarardan sorumlu tutulamaz. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Issue
Joe Abley (jabley) writes: The number of stateful firewalls that can happily handle occasional flows of up to 100,000 flows per second two/from individual devices are few. Yours probably isn't one of them. Corollary: whatever device you'll be putting in front of the DNS servers to protect them probably won't be dealing so well with whatever conectivity you'll have a couple of years down the road. In general, vendors of attack mitigation equipment rarely advise you about what you'll need in the future, only what they can sell you now. Phil ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Issue
On Apr 26, 2013, at 7:24 PM, Cihan SUBASI (GARANTI TEKNOLOJI) wrote: Also can someone explain why tcp53 should be allowed on the firewalls if dns is behind a firewall? Truncate mode. And why auditors do not like tcp53 open to public? 'Security' misinformation spread by firewall vendors since the late 1990s. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Issue
On Apr 26, 2013, at 7:23 PM, Joe Abley wrote: The number of stateful firewalls that can happily handle occasional flows of up to 100,000 flows per second two/from individual devices are few. Yours probably isn't one of them. I've seen 3mb/sec of spoofed SYN-flood take down a stateful firewall rated at 20gb/sec - DDoS, deliberate or inadvertent, means that no stateful firewall which could practically be constructed now or in the foreseeable future could handle this. What's more, it's unnecessary - since every incoming connection is unsolicited, there's no state to inspect in the first place. Operators should use stateless ACLs in hardware-based routers/layer-3 switches to instantiate network access policies (I know you know all this, just posting it for the sake of completeness). --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Issue
On Apr 26, 2013, at 7:29 PM, Phil Regnauld wrote: In general, vendors of attack mitigation equipment rarely advise you about what you'll need in the future, only what they can sell you now. +1. The architecture should be designed for horizontal scalability from the outset. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Issue
On Apr 26, 2013, at 4:32 AM, Dobbins, Roland rdobb...@arbor.net wrote: On Apr 26, 2013, at 12:27 AM, Warren Kumari wrote: I think that in many cases it is not that the named version doesn't support randomization, but rather that they / their firewall group believes that DNS should only be allowed on port 53 (and UDP, natch). The actual problem being that the DNS servers oughtn't to be behind a firewall in the first place. Oh, yeah, *fully* agree -- I meant to mention this in my response (actually I was just going to cut-n-paste from an earlier rant on the subject) but forgot. I'd probably s/firewall/firewall, load-balancer or anything else that keeps state/ -- I know you already mentioned statefull things further down in the thread, but for some reason many folk don't think of load-balancers as keeping state[0]... W [0]: Yes, yes, I know that you can configure LBs in a non-stateful / DSR mode (been there, done that, got the t-shirt), but many folk plug an LB in front of their DNS servers in some NAT / stageful manner and then get sad when it falls over… ; --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Consider orang-utans. In all the worlds graced by their presence, it is suspected that they can talk but choose not to do so in case humans put them to work, possibly in the television industry. In fact they can talk. It's just that they talk in Orang-utan. Humans are only capable of listening in Bewilderment. -- Terry Practhett ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Issue
On Fri, 26 Apr 2013 12:24:01 + Cihan SUBASI (GARANTI TEKNOLOJI) cih...@garanti.com.tr wrote: Also can someone explain why tcp53 should be allowed on the firewalls if dns is behind a firewall? DNS over TCP is not just for zone transfers. Many legitimate queries and answers, will be carried over TCP. Usually this will occur in one of two scenarios: 1. An answer does not fit into single, negotiated, through EDNS0 or not, UDP message. 2. An operator is forcing DNS to switch-over to TCP to mitigate spoofed source address queries, usually in response to some sort of packet flooding attack. Some in-line gear has done this in the past, but more recently it is being put directly into implementations. See http://redbarn.org/dns/ratelimits for details. IETF RFC 5966 updates 1035 and 1123 to specify that DNS over TCP must be supported in implementations. See that document and this generic sounding talk almost a decade ago for some additional discussion about why disallowing TCP can be harmful: DNS Anomalies and Their Impact on DNS Cache Servers http://www.nanog.org/meetings/nanog32/abstracts.php?pt=NTY4Jm5hbm9nMzI=nm=nanog32 Note, rarely in my experience does a query start with TCP outside of troubleshooting scenarios, but it is not infeasible and it is not hard to imagine it being done. And why auditors do not like tcp53 open to public? They may have an outdated, naive view of what should be open and what shouldn't be? Show them the above and ask them why. I'd be curious what the response is. John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Issue
From: Jared Mauch ja...@puck.nether.net Because someone told them the wrong thing and they don't know any difference. Just because they're an auditor doesn't mean they are clued. Simple thing would be to show them a dns query that requires tcp, such as: Would you show anything to a doctor prescribing bloodletting to cure what ails you or would you quietly leave? (except for lab work) Someone who let a financial auditor with equivalent ignorance about the fundamentals of bookkeeping near the company's books (not to mention hiring) would fear being fired or indicted as an accessory. If your boss or boss' boss' boss etc. hired an equivalent to audit the company books, you'd infer the worst and start looking for a new job while the banks are still cashing your paychecks. The same should apply to network security quacks. Bogus security audits or auditors might not signal as much about your paychecks as bogus financial audits, but they do signal coming security disasters that probably won't help your career. Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Issue
Good timing... On Fri, 26 Apr 2013, Cihan SUBASI (GARANTI TEKNOLOJI) wrote: Also can someone explain why tcp53 should be allowed on the firewalls if dns is behind a firewall? And why auditors do not like tcp53 open to public? See, that's another of the arguments why DNS should *not* be behind the firewall: topology issues. If your (recursive/caching) DNS server was outside the firewall, with appropriate access controls, then port 53 through the firewall needs only to be open with respect to the servers which you control. That's not to say that you wouldn't/shouldn't have appropriate traffic monitoring/etc. in place between the server and the rest of the internet. Agree/disagree, but there it is... -- Fred Morris ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
[dns-operations] DNS Issue
Dears I wonder if someone can guide me in the direction for troubleshooting my DNS issues. I work in the regional ISP, we have to DNS servers where it works fine for most of the Domain names but it cannot resolve some others, like dyn.com. When I try to do dig + trace , below is the output, the txt in red shows that for that specific domain the DNS server cannot resolve it, please guide me to the proper procedure for troubleshooting such problem. dig dyn.com +trace ; DiG 9.3.4-P1 dyn.com +trace ;; global options: printcmd . 518394 IN NS j.root-servers.net. . 518394 IN NS k.root-servers.net. . 518394 IN NS l.root-servers.net. . 518394 IN NS m.root-servers.net. . 518394 IN NS a.root-servers.net. . 518394 IN NS b.root-servers.net. . 518394 IN NS c.root-servers.net. . 518394 IN NS d.root-servers.net. . 518394 IN NS e.root-servers.net. . 518394 IN NS f.root-servers.net. . 518394 IN NS g.root-servers.net. . 518394 IN NS h.root-servers.net. . 518394 IN NS i.root-servers.net. ;; Received 512 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms com.172800 IN NS h.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 l.gtld-servers.net. com.172800 IN NS d.gtld-servers.net. com.172800 IN NS i.gtld-servers.net. com.172800 IN NS m.gtld-servers.net. com.172800 IN NS f.gtld-servers.net. com.172800 IN NS k.gtld-servers.net. com.172800 IN NS b.gtld-servers.net. com.172800 IN NS a.gtld-servers.net. ;; Received 497 bytes from 192.58.128.30#53(j.root-servers.net) in 112 ms dyn.com.172800 IN NS ns1.p01.dynect.net. dyn.com.172800 IN NS ns3.p01.dynect.net. dyn.com.172800 IN NS ns2.p01.dynect.net. dyn.com.172800 IN NS ns4.p01.dynect.net. ;; Received 175 bytes from 192.54.112.30#53(h.gtld-servers.net) in 167 ms dig: couldn't get address for 'ns1.p01.dynect.net': failure Thank you Best Regards Samir Abid Ali Core Network Manager Gorannet ISP Mobile:07703-587-625 Office:053 5111 000 ext. 1032 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Issue
On 2013-04-24, Samir Abidali samir.abid...@gorannet.net sent: I wonder if someone can guide me in the direction for troubleshooting my DNS issues. I work in the regional ISP, we have to DNS servers where it works fine for most of the Domain names but it cannot resolve some others, like dyn.com. When I try to do dig + trace , below is the output, the txt in red shows that for that specific domain the DNS server cannot resolve it, please guide me to the proper procedure for troubleshooting such problem. Are you doing query source port randomization? https://www.dns-oarc.net/oarc/services/porttest -- Chip Marshall c...@2bithacker.net http://2bithacker.net/ pgprO_I77NsYe.pgp Description: PGP signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Issue
On 2013/04/24, at 09:06, Samir Abidali wrote: I wonder if someone can guide me in the direction for troubleshooting my DNS issues. I work in the regional ISP, we have to DNS servers where it works fine for most of the Domain names but it cannot resolve some others, like dyn.com. I wasn't able to reproduce this myself.. it all looks good from here. dig: couldn't get address for 'ns1.p01.dynect.net': failure What happens if you run a 'dig +trace ns1.p01.dynect.net'? Since that name server name isn't a subdomain of dyn.com I think dig is (correctly) ignoring the additional section in the response from h.gtld-servers.net, and has gone to your stub resolver to get the address for ns1.p01.dynect.net. If that is failing for some reason it would explain the error you're seeing. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Issue
On Wed, 24 Apr 2013, Chip Marshall wrote: Are you doing query source port randomization? https://www.dns-oarc.net/oarc/services/porttest I have been hearing more reports of people in the last two weeks that DNS queries originating from port 53 are getting blocked. slashdot.org was one of those domains that started failing when your recursing name server is configured to use a query port of 53. I'm not sure if this is related to some cloud provider, or a firewall/router vendor. Paul ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Issue
Paul Wouters wrote: I have been hearing more reports of people in the last two weeks that DNS queries originating from port 53 are getting blocked. slashdot.org was one of those domains that started failing when your recursing name server is configured to use a query port of 53. We've seen several DDOS attacks directed towards our nameservers that used source port 53. Likewise, we have temporarily blocked queries that used source port 53 to buy us time while enacting better DDOS mitigations. With the prevalence of source port randomization, it wouldn't surprise me if some people started permanently blocking source port 53. I'm not saying I agree with that practice, but I can definitely imagine it happening. -- Jason ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
