Re: [External] Re: intermittent resolution
On 30.10.13 21:58, Samp, Daniel [USA] wrote: In the past when I've had issues with certain .gov sites (e.g. noaa.gov, nih.gov, ssa.gov) it was due to application based filtering (layer 4). For some reason the responses from these sites are more often than not fragmented and if you have something doing filtering based on ports it may not be delivering the follow-up fragments because they do not have the tcp headers. Do a tcpdump of your DNS traffic from noaa.gov and check to see if reponses are being fragmented and whether you are receiving all of the fragments. We had to set edns-udp-size to 512 as a workaround until we could identify the problematic piece of hardware. this is a server option, not a client option. did you have to set this on your recursive servers, because HW between them and your clients was problematic? If you did find the culprit, can you tell us who was it? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. There's a long-standing bug relating to the x86 architecture that allows you to install Windows. -- Matthew D. Fuller ___ 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: [External] Re: intermittent resolution
-Original Message- From: Matus UHLAR - fantomas Date: Thursday, October 31, 2013 7:49 AM To: "bind-users@lists.isc.org" Subject: Re: [External] Re: intermittent resolution >On 30.10.13 21:58, Samp, Daniel [USA] wrote: >>In the past when I've had issues with certain .gov sites (e.g. noaa.gov, >> nih.gov, ssa.gov) it was due to application based filtering (layer 4). >> For some reason the responses from these sites are more often than not >> fragmented and if you have something doing filtering based on ports it >>may >> not be delivering the follow-up fragments because they do not have the >>tcp >> headers. Do a tcpdump of your DNS traffic from noaa.gov and check to >>see >> if reponses are being fragmented and whether you are receiving all of >>the >> fragments. > >> We had to set edns-udp-size to 512 as a workaround until we >> could identify the problematic piece of hardware. > >this is a server option, not a client option. did you have to set this on >your recursive servers, because HW between them and your clients was >problematic? > >If you did find the culprit, can you tell us who was it? i would assume a firewall somewhere between the server and clients doing things like protocol inspection or "fixups" based on outdated BCPs. i've encountered that numerous times myself. one more reason the oarc reply size test is useful. https://www.dns-oarc.net/oarc/services/replysizetest/ http://www.cisco.com/web/about/security/intelligence/dnssec.html#11 ___ 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: intermittent resolution
Mark, It is a GM issue-) I appreciate any help but I have had numerous hosts @noaa.gov reported one to choose from would be ftp.cpc.ncep.noaa.gov thanks for any help con On Oct 30, 2013, at 5:24 PM, Mark Andrews wrote: > > IF YOU WANT HELP SPECIFY THE FAILING DOMAIN NAME. YES I AM SHOUTING > > This report is like saying you have a problem with a car manufacture by GM. > > Mark > > In message , Con Wieland writes: >> I recently upgraded to version: 9.8.6. I am having trouble resolving a .gov s >> ite. When I reload the name server it will resolve fine for a while then afte >> r an hour or two I will get a server fail. I can perform a dig +trace and res >> olve but dig will fail. If I do an rndc reload it will work for some period o >> f time again. I suspect negative caching but the site has a the ttl set to 6 >> 0 so I would expect it to resolve again but it doesn't until a reload is pref >> ormed, other sites seem to be effected but I don't know. This is a high visi >> bility site. The only configuration change has been to add RPZ which seems to >> be working fine. >> >> Other name servers seem to be unaffected. What am I missing? What else can I >> check? I can provide more details if it would be helpful. >> >> Con Wieland >> Office of Information Technology >> University of California at Irvine >> ___ >> 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: [External] Re: intermittent resolution
In message <20131031114900.gb10...@fantomas.sk>, Matus UHLAR - fantomas writes: > On 30.10.13 21:58, Samp, Daniel [USA] wrote: > >In the past when I've had issues with certain .gov sites (e.g. noaa.gov, > > nih.gov, ssa.gov) it was due to application based filtering (layer 4). > > For some reason the responses from these sites are more often than not > > fragmented and if you have something doing filtering based on ports it may > > not be delivering the follow-up fragments because they do not have the tcp > > headers. Do a tcpdump of your DNS traffic from noaa.gov and check to see > > if reponses are being fragmented and whether you are receiving all of the > > fragments. > > > We had to set edns-udp-size to 512 as a workaround until we > > could identify the problematic piece of hardware. > > this is a server option, not a client option. did you have to set this on > your recursive servers, because HW between them and your clients was > problematic? edns-udp-size is for telling the server what size to send to you. max-udp-size is for limiting response size sent to clients. > If you did find the culprit, can you tell us who was it? > > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > There's a long-standing bug relating to the x86 architecture that > allows you to install Windows. -- Matthew D. Fuller > ___ > 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
BIND and idnkit vs GNU libidn
BIND appears to be setup to compile against the idnkit supplied in contrib. It will not build against GNU's libidn. Or at least I have not been able to make it do so. Is there a way to use libidn instead of idnkit (besides modifying the code myself) that I am missing? Thank you -- Jack Tavares ___ 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: intermittent resolution
In message <8297a803-1cf6-40bb-92c9-6f647ca63...@uci.edu>, Con Wieland writes: > Mark, > > It is a GM issue-) I appreciate any help but I have had numerous hosts > @noaa.gov reported one to choose from would be ftp.cpc.ncep.noaa.gov > > thanks for any help > con >From this part of the world ftp.cpc.ncep.noaa.gov resolves fine and it validates as authentic data. You will however note from the dig +trace (add +dnssec to older versions of dig to get the DNSSEC records returned) that the final response is 2635 bytes which will not fit in a single Ethernet packet. This means the IP layer (v4 and v6) will be fragmenting the responses. If you have a firewall that is dropping fragmented packets this will mean that the nameserver will get timeouts rather than answers and will need to try fallback strategies to get the answers. Sometimes these take too long which results in SERVFAIL being returned to the client. There really is no need to block fragmented packets. Modern IP stacks cope. Really old IP stacks could consume lots of memory dealing with incomplete packets but that hasn't been a issue for decades. Mark ; <<>> DiG 9.10.0a1 <<>> +trace ftp.cpc.ncep.noaa.gov ;; global options: +cmd . 518400 IN NS l.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS f.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS a.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS m.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN RRSIG NS 8 0 518400 2013110700 2013103023 59085 . aCvNEdYy57xb1AobSiCzLakqRRMTm6/tRO0FAiO/s5slccgWhlplvow8 8PZo0jdHbU6gaKc3EbfzMvSN2sehN8YEVn1bqgzgbXtDn/UYtocQHjNr CYDMT0BAMgUKc5gUDl0eW7Pes78AEKddrh/aWZ4gV/c/PO1UCwclTCmW wkk= ;; Received 397 bytes from 127.0.0.1#53(127.0.0.1) in 2 ms gov.172800 IN NS a.gov-servers.net. gov.172800 IN NS b.gov-servers.net. gov.86400 IN DS 7698 8 2 6BC949E638442EAD0BDAF0935763C8D003760384FF15EBBD5CE86BB5 559561F0 gov.86400 IN DS 7698 8 1 6F109B46A80CEA9613DC86D5A3E065520505AAFE gov.86400 IN RRSIG DS 8 1 86400 2013110700 2013103023 59085 . UA03FJLWwJMvxSdTCrmaqQG42qm9v/WX5Q+pHU3F1B4IV4Eo3l0+C0NU ppGccTLhbEISzUHLLQJsl8nXOSt1C4nFAlcm/zLu5ZHG7yR96qCB7PqY dbjQXpYxiRE5Gcvw2Gb8/GtdZRI9lJ+GQ0R9/fZolMXukgGE5hZVHm9i jzk= ;; Received 400 bytes from 192.33.4.12#53(c.root-servers.net) in 163 ms noaa.gov. 86400 IN NS ns-e.noaa.gov. noaa.gov. 86400 IN NS ns-mw.noaa.gov. noaa.gov. 86400 IN NS ns-nw.noaa.gov. noaa.gov. 3600IN DS 31531 5 1 FEFD9EC572F204622204148665FD71C434BA84D5 noaa.gov. 3600IN DS 31531 5 2 CEC7B9358E2BCCA57CCD5097760CFAFA5EBCDE7EE99377CFA71E836C 126EE8B1 noaa.gov. 3600IN DS 36283 5 1 0173D13977FFDF12716E3A1225B1B0B639B8CB46 noaa.gov. 3600IN DS 36283 5 2 80C0FF77866D4FAEC4F696D87D2C7C9652A0ACC3549706FAE38651C7 CDBC5312 noaa.gov. 3600IN RRSIG DS 8 2 3600 20131107160020 20131031160020 46733 gov. AB4T1tm8ExzwiQP9TnbbzO+UdAt3ThgKNP7UKNc/foxzpxWnNP8zpcd2 SD3gl/n58mttNwGS4jVlI6/yoWWFE/c6aj8l4hS1rJa3PSoSmTTSL4wQ 8vMzZ5JG9pmisKDGaWI9pGbpd8SCTijsCL3R0QN2zu7Yx953wUmbJrFZ iQQ= ;; Received 572 bytes from 209.112.123.30#53(b.gov-servers.net) in 186 ms ftp.cpc.ncep.noaa.gov. 60 IN A 140.90.101.32 ftp.cpc.ncep.noaa.gov. 60 IN RRSIG A 5 5 60 20131107203052 20131031203052 42006 ncep.noaa.gov. YD+i1JMg/quwBmxq6in3xRn0nu8O6fbwyshvxLwKWeux5lh/FU74dAU/ ttqasLu4Rcu8kXxtzRZjG1HvAwjgnd8b12U59tz4B6m9fpfAvi5qR1Gd TIhfALeFu0u1dMcbEd0H/bKNxkmmkAD5zapf+iN21FGYHa++t1WIZkxu sK4B1JU08wBy1tfWq9MoMOfqNDTUS/19rOy++7PJNlboEkVhJ+gKuT+z ed4oOr0/393joWwm5saTmehOc/wDbEU+xcahhq1u2xHrProgu3tuR68X OzSPwE19goKG8It60j3jPtyiLwvh5alc7GoSrcLBm2OXTMm8QsHH629k XVl/cg== ncep.noaa.gov. 86400 IN NS ns-mw.noaa.gov. ncep.noaa.gov. 86400 IN NS ns-nw.noaa.gov. ncep.noaa.gov. 86400 IN NS ns-e.noaa.gov. ncep.noaa.gov. 86400 IN RRSIG NS 5 3 86400 20131107203052 20131031203052 42006 ncep.noaa.gov. poUREStH+jGSqFvEHjgzZbsj9pZfp
