Thank you very much John.

That is what I'd expected to hear, but wanted confirmation before trying to 
test.

Not sure it wasn't a cached lookup failure, but I don't know at this point. 
That is a thing, right? I remember discussions but don't know at what level or 
in which cache that is held, can the client store a false negative because of a 
lookup failure?

Not sure why we weren't resolving correctly but at this point it's too late for 
a postmortem, will just have to wait for it to recur.

-----Original Message-----
From: bind-users <bind-users-boun...@lists.isc.org> On Behalf Of John W. Blue
Sent: Monday, October 15, 2018 1:56 PM
To: bind-users@lists.isc.org
Subject: RE: Question about forwarder zones

ATTENTION: This email came from an external source. Do not open attachments or 
click on links from unknown senders or unexpected emails.


Based upon everything that I am reading it is name specific.  To wit:

".. forwarding rules apply to queries for all domain names that end in the 
domain name of the zone."

So it would follow that "example.com" would not get queries for 
"reallycool.example.com" if zone forwarding is configured correctly.  You can 
walk this out by creating a test zone and pointing at a server that you can run 
tcpdump on.

As you change the name of the zone (lvl1.example.com vs lvl2.lvl1.example.com) 
the previous queries for lvl1 that worked should stop and tcpdump should 
reflect that.

But honestly, seems like a postmortem should be done to find out why BIND had 
to be restarted unless you already know.

Good hunting!

John

-----Original Message-----
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
Cuttler, Brian R (HEALTH)
Sent: Monday, October 15, 2018 10:27 AM
To: bind-users@lists.isc.org
Subject: Question about forwarder zones


We had an issue with forward zones not resolving this morning, resolved by 
restarting DNS but prompted me to ask a question I'd been wondering about.

We have multiple zones that we forward to DNS servers we do NOT manage.

The domain names take the form

Example.org
Bar.example.org
Foo.bar.example.org
Snafu.foo.bar.example.org

Despite the fact that these are all example.org and managed by our sister 
organization the servers they forward to are often different from one another.
That is bar.example.com might forward queries to a.a.a.a and a.b.b.a but 
foo.bar.example.com might forward to c.d.a.a and d.e.b.a.

What I'm trying to say is that the parent server for a forwarded zone is not 
necessarily, and is seldom the authoritative zone for a child zone.

So it got me wondering, when I want to resolve host.snafu.foo.bar.example.org, 
where does the chain of resolution start?

I'm hoping that it is the most _specific_ domain name, rather than the least or 
random, or first find in the physical zone file.

To me most specific makes the most sense, but I haven't run across that written 
anyplace in my searches and I'd like to know if I should reorder my zones or 
should employ some other mechanism to help assure I'm hitting the 
best-forwarders/most productive forwarder zone selection I can.

Thank you,
Brian


Brian Cuttler
Network and System Administrator, ITG - Information Technology Group Wadsworth 
Center, NYS Department of Health Biggs Lab, Empire State Plaza, Albany, NY 12201
(518) 486-1697 | brian.cutt...@health.ny.gov


_______________________________________________
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
_______________________________________________
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
_______________________________________________
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

Reply via email to