encountering "too many records" loading authoritative zone even when AXFR report shows nothing exceeding max-records-per-type

I'm encountering the max-records-per-type limit when loading an authoritative zone, so named won't load the zone. But an audit of the zone (count the records returned by AXFR) finds no records exceeeding the limit. Is anyone else encountering this? -- Details: I'm using Infloblox NIOS, a com

Re: bind-9.11.0-P1 "db.c", line 771: error: syntax error before or at: )

On Fri Nov 4 05:43:44 UTC 2016 Dennis Clarke dclarke at blastwave.org wrote: >During a compile in the same way as I have always done I was surprised >to see : > >. >. >. >/opt/developerstudio12.5/bin/cc -mt >-I/usr/local/build/bind-9.11.0-P1_SunOS5.10_sparcv9.001 -I../../../.. >-I/usr/local/bui

BIND 9.11.2 acting as a forwarder: authority section populated differently than BIND 9.9.11 ?

I'm preparing to upgrade from BIND 9.9.11 to 9.11.2. I notice a difference in how named populates the authority section in some responses, and am trying to understand if it's OK. My server is a caching-only server, and provides recursive service. For some zones, my server is configured to forwa

Re: BIND slave server ignoring responses to all UDP-based SOA queries (zone refresh) for hours at a time

(for all the SOA queries all the zones it pulled from various unrelated masters) for hours at a time every 1-3 days (until picking another port), exposing my latent configuration problem. Irwin Tillman OIT Networking & Monitoring Systems, Princeton University __

BIND slave server ignoring responses to all UDP-based SOA queries (zone refresh) for hours at a time

and are so large, that using AXFR caused my server to lag well behind the zones' other servers. -- I'll mention (without knowing whether it is relevant) that: * my server receives lots of NOTIFY messages it refuses because they come from non-masters * because some of the zones my server

RFC 6303 vs. BIND: NS ... has no address records (A or AAAA)

RFC 6303 says that a recursive nameserver should locally serve a number of DNS zones. Section 3 provides this generic empty zone for this purpose, in master file format: @ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800 @ 10800 IN NS @ The RFC notes: "The NS RR is needed as some UPDAT

Re: avoid-v4-udp-ports ineffective? (BIND 9.8.1-P1)

I wrote: > I don't understand why named would try to use these ports in the first > place as they appear in avoid-v4-udp-ports. Mark Andrews replied: The "::" in the log message is the IPv6 equivalent of 0.0.0.0 in IPv4. You machine *is* dual stacked even if it only has IPv6 on loo

avoid-v4-udp-ports ineffective? (BIND 9.8.1-P1)

It appears that named is trying to use ports I've mentioned in avoid-v4-udp-ports. Platform: BIND 9.8.1-P1 on Solaris 10 / SPARC On some of the ports which BIND might otherwise choose to use, I have other daemons running and/or the OS treats the ports as privileged. To keep named from trying t