In message <4bc4603e-5123-4479-a399-5cac997ed...@uci.edu>, Con Wieland writes:
> I added edns-udp-size 512; which solved the issue but after more reading it s
> eems like a better option would be to disable EDNS for the specific hosts sin
> ce we have had no luck working with them. Looking at the ARM I thought I coul
> d add a server statement for each of the sites name servers but I apparently
> have a syntax error. It also seems that the edns-udp-size option can be put i
> n on a per server basis but
>
> server 140.90.33.237/0 { edns no };
If you want to disable edns for a specific host then you would use
server 140.90.33.237 { edns no };
That said 140.90.33.237 understands EDNS. The ONLY machines that
you should want to set "edns no" to are those that FAIL TO RESPOND
to EDNS queries. 140.90.33.237 responds to EDNS queries. You
just don't let those responses through.
Your problem is that *you*, as in *your* institution, have installed
equipment that is configured to deliberately break IPv4 connectivity.
That has consequences.
There is a myth that you need to stop IP fragments, that IPv4
fragments are harmful. This is much like the myth that you need
to block icmp packets as they are harmful. Neither is the case.
Back before the turn of the century there were some machines with
broken IP stacks that needed to be shielded from these packets UNTIL
THE IP STACKS WERE FIXED. What were supposed to be TEMPORARY
measures have morfed into PERMANENT measures that need to be applied
regardless of the consequences.
Additionally there are firewalls that think all DNS UDP packets are
smaller than 512 bytes. This hasn't been the case for 15 years
now. There was never a need to check this in firewalls. Nameservers
were quite capable of checking DNS responses themselves.
Mark
> This does not work. I have added this at the root config and in the options s
> ection to no avail.
>
> Con Wieland
> Office of Information Technology
> University of California at Irvine
>
> On Nov 2, 2013, at 7:10 AM, Con Wieland <cwiel...@uci.edu> wrote:
>
> > Hello,
> >
> > This solved our issue, how did you diagnose the issue? what did you find? w
> hat was the ultimate solution? What would the downside be to leaving the end
> s-udp-size setting set to 512
> >
> > thanks for any help
> > con
> >
> > On Oct 30, 2013, at 2:58 PM, "Samp, Daniel [USA]" <samp_dan...@bah.com> wro
> te:
> >
> >> In the past when I've had issues with certain .gov sites (e.g. noaa.gov, n
> ih.gov, ssa.gov) it was due to application based filtering (layer 4). For so
> me reason the responses from these sites are more often than not fragmented a
> nd if you have something doing filtering based on ports it may not be deliver
> ing the follow-up fragments because they do not have the tcp headers. Do a t
> cpdump of your DNS traffic from noaa.gov and check to see if reponses are bei
> ng 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 problema
> tic piece of hardware.
> >>
> >> Since the only thing you changed was BIND versions, this may have nothing
> to do with your issue, but I thought I'd throw it out there.
> >>
> >> -Dan
> >>
> >> ________________________________________
> >> From: bind-users-bounces+samp_daniel=bah....@lists.isc.org [bind-users-bou
> nces+samp_daniel=bah....@lists.isc.org] on behalf of Con Wieland [cwieland@uc
> i.edu]
> >> Sent: Wednesday, October 30, 2013 5:28 PM
> >> To: BIND List
> >> Subject: [External] Re: intermittent resolution
> >>
> >> The site I am having issues with are a half a dozen sites at noaa.gov. No
> I have not tried 9.9.4 when I upgraded 9.8.6 was listed as the current stable
> version so I went with that.
> >>
> >> con
> >>
> >> On Oct 30, 2013, at 11:48 AM, Alan Clegg <a...@clegg.com> wrote:
> >>
> >>>
> >>> On Oct 30, 2013, at 10:03 AM, Con Wieland <cwiel...@uci.edu> wrote:
> >>>
> >>>> I recently upgraded to version: 9.8.6. I am having trouble resolving a .
> gov site. When I reload the name server it will resolve fine for a while then
> after an hour or two I will get a server fail. I can perform a dig +trace an
> d resolve but dig will fail. If I do an rndc reload it will work for some per
> iod of time again. I suspect negative caching but the site has a the ttl set
> to 60 so I would expect it to resolve again but it doesn't until a reload is
> preformed, other sites seem to be effected but I don't know. This is a high
> visibility site. The only configuration change has been to add RPZ which see
> ms to be working fine.
> >>>>
> >>>> Other name servers seem to be unaffected. What am I missing? What else c
> an I check? I can provide more details if it would be helpful.
> >>>
> >>> Can you tell us _what_ .gov site? Do you see the same problem with 9.9.
> 4?
> >>>
> >>> AlanC
> >>> --
> >>> Alan Clegg | +1-919-355-8851 | a...@clegg.com
> >>>
> >>
> >> _______________________________________________
> >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscr
> ibe 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 unsubscri
> be 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
--
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
