Re: intermittent SERVFAIL for high visible domains such as *.google.com
On Wed, 2018-01-17 at 10:45 -0500, Brian J. Murrell wrote: > I have a BIND (9.9.4)[1] server that runs well most of the time, but > periodically it will start returning SERVFAIL for very high-level > domains such as *.google.com, *.gstatic.com, *.github.com, etc. It > seems to happen most frequently with Google domains, but I wonder if > that is just a reflection on the percentage of queries I have for > those > here. The culprit here is the DDNS processing. Once I moved the DDNS processing (that is coming from the DHCP server) off onto a separate server the problem server stopped having SERVFAIL for names that it should just not happen for, like www.google.com. So, now I just have to chase down why DDNS is causing this. This BIND server is from the FreeIPA project so it's an LDAP-backed BIND so perhaps (probably?) that has something to do with it. I will take it up with the FreeIPA folks since it's their build of BIND that is causing the problems. Much much thanks for the help and patience here while I got to the root cause. Cheers, b. signature.asc Description: This is a digitally signed message part ___ 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 DNS conditional forwardning
you just showed how parent zone (2.0.192.in-addr.arpa) must be
configured for it.
On 18.01.18 12:58, Grant Taylor via bind-users wrote:
No, I did not. The following zone is the authoritative zone, as seen
by the world.
; Mach Global zone file
$ORIGIN 2.0.192.in-addr.arpa.
@INSOAprisoner.iana.org. hostmaster.root-servers.org.
(2002040800 30m 15m 1w 1w)
1INPTRhost1.example.net.
2INPTRhost2.example.net.
; …
42INPTRhost42.example.net.
; …
Note that nothing has been done in the authoritative zone.
The following is the zone that would go on the local server that
would override the globally authoritative zone.
; Mach local zone file
$ORIGIN 2.0.192.in-addr.arpa.
@INSOAmyLocalServer.myLocalDomain.myTld.
myEmail.myPublicDomain.myTld. (2002040800 30m 15m 1w 1w)
1INPTRclient1.myLocalDomain.myTld.
2INPTRclient2.myLocalDomain.myTld.
; …
42INNSblackhole-1.iana.org.
42INNSblackhole-2.iana.org.
; …
96INPTRserver3.myLocalDomain.myTld.
97INPTRoldServer3.myLocalDomain.myTld.
; …
This local copy is where the changes are made to override what the
globally authoritative zone serves. (Like I think the OP was
indicating s/he was doing.)
The NS records for 42 in the local zone ""delegate back to the parent
servers.
so, in fact you want the whole zone locally, override anything you like, but
forward some records to other servers?
DNS does not work that way.
in BIND this is not done by configuring zone data, but by configuring named
to forward zones.
zone "42.2.0.192.in-addr.arpa" {
type static-stub;
server-names {
blackhole-1.iana.org;
blackhole-2.iana.org;
};
};
what you describe is how dj bernstein proposed reverse delegation.
I was not aware of that. I'll have to look into his proposed solution.
I'm not sure this will help you. What you want is apparently asking for
troubles.
However it's much better to define subzone and redirect records via
CNAMEs to it. it's easier to define one subzone with a few NS
records pointing to it and replace each PTR with CNAME than replace
each PTR with multiple NSes.
I'm going to have to disagree with you. I have used both RFC 2317
Classless IN-ADDR.ARPA (type) delegation and the delegation that I'm
suggesting multiple times. Every time I've used Classless
IN-ADDR.ARPA (type) delegation has resulted in heartache or worse.
I don't remember having any troubles with classless delegation.
unless someone misconfigured it, of course. but misconfigured DNS is a
problem of different kind.
I've even personally experienced cases where Spam RBLs failed
miserably with RFC 2317 Classless IN-ADDR.ARPA and ended up black
listing things inappropriately. I have had zero problems with the
type of delegation that I'm advocating.
what do dns blacklist have in common with classless delegation?
classless delegation means you are delegating subzone to other server.
Which blacklist ever tried to delegate subzone to other blacklist?
Combining the fact that 2317 Classless IN-ADDR.ARPA (type) delegation
requires support in the authoritative / parent zone with the problems
that I've seen and the fact that I've not seen any problems with my
alternate, I'll continue using my alternate.
As a bonus, it's entirely possible to do cross delegation using my
method without any problems. I can have two clients using /25, each
cross delegating the others part, and things work out quite well.
this may "work" when you have your own reverze zone and agree with other
owners on sharing. But from the internet, and from the DNS point of view,
you are creating problematic mess.
--
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.
A day without sunshine is like, night.
___
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 DNS conditional forwardning
On 01/25/2018 07:29 AM, Matus UHLAR - fantomas wrote:
so, in fact you want the whole zone locally, override anything you like,
but forward some records to other servers?
Yes.
DNS does not work that way.
I have successfully used this technique many times, including for
resolvers in the wild and local.
I've specifically used this a number of times for IN-ADDR.ARPA
delegation with great success. - No problems have been reported by
anybody and all tests that I've repeatedly run over the years from
multiple locations have always worked without any problems.
So, I do believe that it does in fact work. It may not be proper and
pure, but it does function exactly as I need it to.
in BIND this is not done by configuring zone data, but by configuring
named to forward zones.
That would require configuring multiple zones. Why would I want to do
that when my method works flawlessly (with every test that I and others
have thrown at it) and uses a single zone.
zone "42.2.0.192.in-addr.arpa" {
type static-stub;
server-names {
blackhole-1.iana.org;
blackhole-2.iana.org;
};
};
Thank you for an example of proper syntax.
I'm not sure this will help you. What you want is apparently asking
for troubles.
I've not had any troubles with this technique in 10+ years.
I don't remember having any troubles with classless delegation.
unless someone misconfigured it, of course. but misconfigured DNS is a
problem of different kind.
what do dns blacklist have in common with classless delegation?
classless delegation means you are delegating subzone to other server.
Which blacklist ever tried to delegate subzone to other blacklist?
I've had problems with multiple things not properly following the CNAME
chain in RFC 2317 Classless IN-ADDR.ARPA Delegation. Years ago I had a
notable and popular RBL completely fail at following RFC 2317 Classless
IN-ADDR.ARPA Delegation and black list multiple servers that were
perfectly configured. (Read: RBL script parsing bug.) Ultimately email
servers were erroneously black listed indirectly because of RFC 2317
Classless IN-ADDR.ARPA Delegation.
Around the same time I learned about the delegation method that I now
use. All of my tests showed that the delegation worked the way that I
wanted and no side effects or problems.
I also collaborated with the RBL operator (that's how I found out that
it was a bug) and he admitted that his script(s) did not process RFC
2317 Classless IN-ADDR.ARPA Delegation. (I believe that he updated his
scripts after I reported the problem to him.) We also discussed the
method that I'm using and he confirmed that his scripts would not have
had any problem with it.
So, in light of the problems I experienced while correctly using RFC
2317 Classless IN-ADDR.ARPA Delegation and issues helping others get it
set up, combined with the simplicity of simple cross delegation, I
decided to favor delegation in lieu of RFC 2317.
this may "work" when you have your own reverze zone and agree with other
owners on sharing. But from the internet, and from the DNS point of view,
you are creating problematic mess.
I've had this deployed for in-addr.arpa delegation for a number of
different prefixes over the last 10 years and it has worked quite well.
--
Grant. . . .
unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
___
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
