query-source and recursive options
Hi guys, I noticed query-source takes effect even recursive is set false. My question is, if recursion is disabled, no outgoing queries should be generated. So why query-source still takes effect? Also, resovler is created per view when starting up named even recursive==false. Why? Do resolvers necessary when recursion is disables? Thanks ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Weird DNS behaviour resolution issues when more labels are present in a zone
Thanks Mark for responding. Whenever we have broken delegation as domain owners didn't follow proper RFC, the default behaviour of the query hits " _." which doesn’t exist.? And we get NXDOMAIN or SERVFAIL response. Is my understanding correct ? -- Thanks Prasanna On 14/12/20, 6:51 AM, "Mark Andrews" wrote: > On 12 Dec 2020, at 20:36, Prasanna Mathivanan (pmathiva) via bind-users wrote: > > Hi everyone, > > I have an issue in resolving a domain, from logs I see its timing out. > And from dig output we are getting SERV fail response. > The bind version we are using 9.14.10, same domain resolves in bind version 9.11 and lower. > > Example domain:- a.b.c.eample.com > When we took tcpdump and saw what’s happening when we do a dig, we see its querying the wrong domain“_.b.c.example.com” , and it’s not able to query the NS for this domain and we get timeout in logs. > Adding to that we get SERVFAIL response when doing dig. If you are getting a timeout then the server for _.b.c.example.com is broken or it is unreachable. “_” is a legal label in the DNS. If the server for b.c.example.com responds to b.c.example.com but does not respond to _.b.c.example.com then the server is broken or there is a broken firewall in front of it. > We don’t see this behaviour for bind version 9.11 or lower and works with +trace as well. > > If anyone can explain why this behaviour is happening, it will be very helpful in understanding the issue. > > After looking into the problem, it appears that bind 9.14 ships with Query Name Minimisation feature as defined by RFC 7816 enabled by default. > few have experienced this behaviour and solution was to disable QNAME minimization. > > How does QNAME Minimisation alter this behaviour? To quote from RFC 7816: > Instead of sending the full QNAME and the original QTYPE upstream, a resolver that implements QNAME minimisation and does not already have the answer in its cache sends a request to the name server authoritative for the closest known ancestor of the original QNAME. The request is done with: > • the QTYPE NS > • the QNAME that is the original QNAME, stripped to just one label more than the zone for which the server is authoritative > A resolver using QNAME Minimisation implicitly assumes that each label in the query name corresponds to a zone cut. The resolver queries a parent zone server, using an abbreviated query name that is truncated after the name of the immediate child label and uses a query type of NS. > > > Am adding the following links to justify this behaviour, but just wanted a suggestion if we are good with doing this. > https://datatracker.ietf.org/doc/rfc7816/?include_text=1 > https://blog.apnic.net/2019/08/12/dns-query-privacy/ > https://labs.ripe.net/Members/wouter_de_vries/make-dns-a-bit-more-private-with-qname-minimisation > https://github.com/iagox86/dnscat2/issues/144 > > Disabling QMIN does fix the issue, but I would like to understand why delegation breaks if there are more labels. > And why the query goes to underscore domain even though it doesn’t exist. Because people deploy non-RFC compliant nameservers. If you find one complain to the operator of it. _. is chosen so that the resulting NXDOMAINs are not being cached for . The initial QMIN implementation used NS queries but that caused problems when servers returned NXDOMAIN to NS queries but there were really records there. Querying for A / at also distorts QTYPE statistics for . Prepending “_” prevents that by using a QNAME that almost never exists. > -- > Thanks > Prasanna > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list > > ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. > > > 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 ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: query-source and recursive options
Nameservers generate their own requests. Nameservers have to translate names to addresses as part of the notify process. -- Mark Andrews > On 16 Dec 2020, at 19:18, Xinyu Wang wrote: > > > > > Hi guys, I noticed query-source takes effect even recursive is set false. > My question is, if recursion is disabled, no outgoing queries should be > generated. So why query-source still takes effect? > > Also, resovler is created per view when starting up named even > recursive==false. Why? Do resolvers necessary when recursion is disables? > > Thanks > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > 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 ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
How Zone Files Are Read
I ran into a situation yesterday which got me pondering something about bind. In this case, a single line in a zone file was bad. The devops automation had inserted a space in the hostname field of a PTR record. What was interesting was that - at startup - bind absolutely refused to load the zone file at all. I would have expected it to complain about the bad record and ignore it, but load the rest of the good records. Can someone please explain the rationale or logic for this? Not complaining, just trying to understand for future reference. TIA, Tim ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How Zone Files Are Read
Am 16.12.20 um 17:37 schrieb Tim Daneliuk: I ran into a situation yesterday which got me pondering something about bind. In this case, a single line in a zone file was bad. The devops automation had inserted a space in the hostname field of a PTR record. What was interesting was that - at startup - bind absolutely refused to load the zone file at all. I would have expected it to complain about the bad record and ignore it, but load the rest of the good records. Can someone please explain the rationale or logic for this? Not complaining, just trying to understand for future reference. it's better not load a invalid zone on a single nameserver at all as you are supposed to have at least two nameservers and the second one won't get the failure via master/slave replication if it has an error something is wrong if the last version had no error that version is good for the world *everything* still is good as long there is one slave - subtle errors can lead to completly unexpected behavior ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How Zone Files Are Read
This isn't, IMO, very useful as a response to the OP. To sum up the response; "It's better to never fail!" Yes, that seems pretty obvious. It *would* be better to never fail. Way, way better. But the big problem in life is; We're always failing! Dammit! So, learning how to gracefully fail, and understanding what happens and why, when something fails, is pretty important to achieve the outcome of; "Not failing quite so catastrophically." So, while I don't have helpful knowledge to impart to the OP, I think I can say that giving the advice of "don't fail" doesn't seem very helpful. RH> Am 16.12.20 um 17:37 schrieb Tim Daneliuk: >> I ran into a situation yesterday which got me pondering something about bind. >> In this case, a single line in a zone file was bad. The devops automation >> had inserted a space in the hostname field of a PTR record. >> What was interesting was that - at startup - bind absolutely refused >> to load the zone file at all. I would have expected it to complain >> about the bad record and ignore it, but load the rest of the >> good records. >> Can someone please explain the rationale or logic for this? Not complaining, >> just trying to understand for future reference. RH> it's better not load a invalid zone on a single nameserver at all as you RH> are supposed to have at least two nameservers and the second one won't RH> get the failure via master/slave replication RH> if it has an error something is wrong RH> if the last version had no error that version is good RH> for the world *everything* still is good as long there is one slave - RH> subtle errors can lead to completly unexpected behavior RH> ___ RH> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How Zone Files Are Read
Am 16.12.20 um 18:26 schrieb Gregory Sloop: This isn't, IMO, very useful as a response to the OP. let that decide the OP To sum up the response; "It's better to never fail!" Yes, that seems pretty obvious. It *would* be better to never fail. Way, way better. But the big problem in life is; We're always failing! Dammit! So, learning how to gracefully fail, and understanding what happens and why, when something fails, is pretty important to achieve the outcome of; "Not failing quite so catastrophically." loading a invalid zoen file is far away from "fail geraceful"! if a comozter don't understand the input fully it's not supposed to guess So, while I don't have helpful knowledge to impart to the OP, I think I can say that giving the advice of "don't fail" doesn't seem very helpful. where did i give the advice "don't fail"? please read my repsonse again! * the zone fails on the master * the zone is still available on the slaves * so the error isn't fatal * but you recognize your mistake what happens when the error is in the line of the MX record and named would say "well, it's only one line, we still have the zone but no longer an MX"? it would lead to a *fatal error* for the behavior of the whole zone, even if *all* or your nameservers go down it would be better because every delivering MTA would just queue the messages in case of a SERVFAIL without the MX the would go to the A record of the zone which is in most cases simply the wrong destination *RH> Am 16.12.20 um 17:37 schrieb Tim Daneliuk: I ran into a situation yesterday which got me pondering something about bind. In this case, a single line in a zone file was bad. The devops automation had inserted a space in the hostname field of a PTR record. What was interesting was that - at startup - bind absolutely refused to load the zone file at all. I would have expected it to complain about the bad record and ignore it, but load the rest of the good records. Can someone please explain the rationale or logic for this? Not complaining, just trying to understand for future reference. RH> it's better not load a invalid zone on a single nameserver at all as you RH> are supposed to have at least two nameservers and the second one won't RH> get the failure via master/slave replication RH> if it has an error something is wrong RH> if the last version had no error that version is good RH> for the world *everything* still is good as long there is one slave - RH> subtle errors can lead to completly unexpected behavior ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How Zone Files Are Read
On 12/16/20 11:36 AM, Reindl Harald wrote: > > > Am 16.12.20 um 18:26 schrieb Gregory Sloop: >> This isn't, IMO, very useful as a response to the OP. > > let that decide the OP > >> To sum up the response; "It's better to never fail!" >> >> Yes, that seems pretty obvious. It *would* be better to never fail. Way, way >> better. >> But the big problem in life is; We're always failing! Dammit! >> >> So, learning how to gracefully fail, and understanding what happens and why, >> when something fails, is pretty important to achieve the outcome of; "Not >> failing quite so catastrophically." > > loading a invalid zoen file is far away from "fail geraceful"! if a comozter > don't understand the input fully it's not supposed to guess > >> So, while I don't have helpful knowledge to impart to the OP, I think I can >> say that giving the advice of "don't fail" doesn't seem very helpful. > > where did i give the advice "don't fail"? > please read my repsonse again! > > * the zone fails on the master > * the zone is still available on the slaves > * so the error isn't fatal > * but you recognize your mistake > > what happens when the error is in the line of the MX record and named would > say "well, it's only one line, we still have the zone but no longer an MX"? > > it would lead to a *fatal error* for the behavior of the whole zone, even if > *all* or your nameservers go down it would be better because every delivering > MTA would just queue the messages in case of a SERVFAIL > > without the MX the would go to the A record of the zone which is in most > cases simply the wrong destination > I agree that in a master-slave topology, your argument makes sense. I this case, the server was a singleton responsible for a small virtual private network within a much larger one. So. when the server failed to start, the client had NO DNS for that subnet. -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How Zone Files Are Read
On 16-Dec-20 11:37, Tim Daneliuk wrote: > I ran into a situation yesterday which got me pondering something about bind. > > In this case, a single line in a zone file was bad. The devops automation > had inserted a space in the hostname field of a PTR record. > > What was interesting was that - at startup - bind absolutely refused > to load the zone file at all. I would have expected it to complain > about the bad record and ignore it, but load the rest of the > good records. > > Can someone please explain the rationale or logic for this? Not complaining, > just trying to understand for future reference. > > TIA, > Tim DNS is complicated. The scope of an error in a zonefile is hard to determine. To avoid this, your automation should use named-checkzone before releasing a zone file. This will perform all the checks that named will when it is loaded. Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. OpenPGP_signature Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How Zone Files Are Read
On 12/16/20 12:25 PM, Timothe Litt wrote: > On 16-Dec-20 11:37, Tim Daneliuk wrote: >> I ran into a situation yesterday which got me pondering something about bind. >> >> In this case, a single line in a zone file was bad. The devops automation >> had inserted a space in the hostname field of a PTR record. >> >> What was interesting was that - at startup - bind absolutely refused >> to load the zone file at all. I would have expected it to complain >> about the bad record and ignore it, but load the rest of the >> good records. >> >> Can someone please explain the rationale or logic for this? Not complaining, >> just trying to understand for future reference. >> >> TIA, >> Tim > > DNS is complicated. The scope of an error in a zonefile is hard to determine. > > To avoid this, your automation should use named-checkzone before releasing a > zone file. > > This will perform all the checks that named will when it is loaded. > Kind of what I thought. Whoever build the environment in question really didn't understand DNS very well and hacked together a kludge that I am still trying to get my head around. -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Weird DNS behaviour resolution issues when more labels are present in a zone
On Wed, Dec 16, 2020 at 3:48 AM Prasanna Mathivanan (pmathiva) via
bind-users wrote:
> Whenever we have broken delegation as domain owners didn't follow proper RFC,
> the default behaviour of the query hits " _." which
> doesn’t exist.? And we get NXDOMAIN or SERVFAIL response.
Going back to your original example, a.b.c.example.com, qname
minimisation first identifies that there is a delegation at .com for
example.com, and then asks the example.com namesevers for
_.c.example.com. Typically this _.c.example.com query would come
back with either an NXDOMAIN answer, which means that the queried
nameserver believes it is authoritative for all names within
c.example.com, or it comes back with a NOERROR answer that lists a
delegation in the authority section.
In the first case (NXDOMAIN), the resolver knows it can ask the same
servers about _.b.c.example.com and the cycle repeats. In the latter
case, the resolver is able to distinguish between whether there was a
delegation for c.example.com (and ask the new nameservers about
_.b.c.example.com) or a delegation that's actually at _.c.example.com
(highly unusual, in which case, ask the original example.com
nameservers about _.b.c.example.com).
Getting a SERVFAIL throws a wrench in all this. It's the
authoritative server basically saying, "I'm badly broken and can't
tell you how." Generally this means the resolver should ask the next
server in the authoritative list. If they're all giving SERVFAIL then
the resolver can either try to work around the brokenness (for
example, by querying the full name at its closest enclosing
delegation) or just give up on the SERVFAIL.
--
tale
PS: While thinking about this I realized a weird case, which is if
only a subset of the parent nameservers are authoritative for a
subdomain. That is, imagine example.com is served by the four servers
ns{1,2,34}.example.com, but c.example.com is delegated only to
ns{1,2}.example.com. If you ask ns1 or ns2 about _.c.example.com,
they'll give an authoritative answer and the fact that a delegation
exists wouldn't be identified (absent DNSSEC), but asking ns3 or ns4
would give the delegation to ns1 and ns2. I can't think of how this
might be a real problem for future queries though, outside of the
usual type of brokenness that can happen even with full name queries
(eg, a parent has a subdomain configured that it isn't actually
delegated to it).
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: How Zone Files Are Read
On 16-Dec-20 13:52, Tim Daneliuk wrote: > On 12/16/20 12:25 PM, Timothe Litt wrote: >> On 16-Dec-20 11:37, Tim Daneliuk wrote: >>> I ran into a situation yesterday which got me pondering something about >>> bind. >>> >>> In this case, a single line in a zone file was bad. The devops automation >>> had inserted a space in the hostname field of a PTR record. >>> >>> What was interesting was that - at startup - bind absolutely refused >>> to load the zone file at all. I would have expected it to complain >>> about the bad record and ignore it, but load the rest of the >>> good records. >>> >>> Can someone please explain the rationale or logic for this? Not >>> complaining, >>> just trying to understand for future reference. >>> >>> TIA, >>> Tim >> DNS is complicated. The scope of an error in a zonefile is hard to >> determine. >> >> To avoid this, your automation should use named-checkzone before releasing a >> zone file. >> >> This will perform all the checks that named will when it is loaded. >> > > Kind of what I thought. Whoever build the environment in question > really didn't understand DNS very well and hacked together a kludge > that I am still trying to get my head around. > For a simple example of why it's complicated - what if the typo you had was for a host that sends e-mail? You'll see intermittent delivery errors when remote hosts can't resolve the host's address; some require that a reverse lookup resolve to the host as an anti-spoofing measure. Others won't. You'll spend a long time diagnosing. named can't tell this case from a typo for a local printer's PTR - where it's unlikely that a reverse lookup failure will matter. Of course, this means it could go undetected for years - until it IS needed. Or the typo is in a NS record - which you probably won't detect until the other NS goes down... And, any errors are cached for their TTL by resolvers. The TTL may (hopefully for query rate reduction) be large. In your case, it would be the negative TTL (meaning that even adding the record later wouldn't have immediate effect). The bottom line is that named must assume that anything placed in a zone file is important, and that the external impact - either sin of omission or commission - might be large. Thus, while named can't detect all (or even most) errors, those that it does detect cause immediate failure to load. That prevents caching and propagation as well as getting human attention. When something's wrong, it's best to stop and fix it. Error recovery is a very good thing - but only when you can demonstrate that the cure is better than the disease. Skipping format errors in a zone file would not satisfy that constraint. Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. OpenPGP_signature Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How Zone Files Are Read
Am 16.12.20 um 19:18 schrieb Tim Daneliuk: On 12/16/20 11:36 AM, Reindl Harald wrote: where did i give the advice "don't fail"? please read my repsonse again! * the zone fails on the master * the zone is still available on the slaves * so the error isn't fatal * but you recognize your mistake what happens when the error is in the line of the MX record and named would say "well, it's only one line, we still have the zone but no longer an MX"? it would lead to a *fatal error* for the behavior of the whole zone, even if *all* or your nameservers go down it would be better because every delivering MTA would just queue the messages in case of a SERVFAIL without the MX the would go to the A record of the zone which is in most cases simply the wrong destination I agree that in a master-slave topology, your argument makes sense sorry, i can't think of any network with only one nameserver given that DNS is one of the most important services I this case, the server was a singleton responsible for a small virtual private network within a much larger one. So. when the server failed to start, the client had NO DNS for that subnet. don't get me wrong but that's how one learns the hard way build basic redundancy for services he cares and if one don't care it's no problem if they fail you have 3 options: 1: master/slave as recommended always 2: verify zones file before write them 3: fix software which generates broken zones normally you chose all 3 in the sense of "and" instead of "or" ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Weird DNS behaviour resolution issues when more labels are present in a zone
Hi Tale,
Thanks for explaining
We can close this query now.
Thanks team for helping me understand the issue.
--
Thanks
Prasanna
On 17/12/20, 1:13 AM, "tale" wrote:
On Wed, Dec 16, 2020 at 3:48 AM Prasanna Mathivanan (pmathiva) via
bind-users wrote:
> Whenever we have broken delegation as domain owners didn't follow proper
RFC, the default behaviour of the query hits " _." which
doesn’t exist.? And we get NXDOMAIN or SERVFAIL response.
Going back to your original example, a.b.c.example.com, qname
minimisation first identifies that there is a delegation at .com for
example.com, and then asks the example.com namesevers for
_.c.example.com. Typically this _.c.example.com query would come
back with either an NXDOMAIN answer, which means that the queried
nameserver believes it is authoritative for all names within
c.example.com, or it comes back with a NOERROR answer that lists a
delegation in the authority section.
In the first case (NXDOMAIN), the resolver knows it can ask the same
servers about _.b.c.example.com and the cycle repeats. In the latter
case, the resolver is able to distinguish between whether there was a
delegation for c.example.com (and ask the new nameservers about
_.b.c.example.com) or a delegation that's actually at _.c.example.com
(highly unusual, in which case, ask the original example.com
nameservers about _.b.c.example.com).
Getting a SERVFAIL throws a wrench in all this. It's the
authoritative server basically saying, "I'm badly broken and can't
tell you how." Generally this means the resolver should ask the next
server in the authoritative list. If they're all giving SERVFAIL then
the resolver can either try to work around the brokenness (for
example, by querying the full name at its closest enclosing
delegation) or just give up on the SERVFAIL.
--
tale
PS: While thinking about this I realized a weird case, which is if
only a subset of the parent nameservers are authoritative for a
subdomain. That is, imagine example.com is served by the four servers
ns{1,2,34}.example.com, but c.example.com is delegated only to
ns{1,2}.example.com. If you ask ns1 or ns2 about _.c.example.com,
they'll give an authoritative answer and the fact that a delegation
exists wouldn't be identified (absent DNSSEC), but asking ns3 or ns4
would give the delegation to ns1 and ns2. I can't think of how this
might be a real problem for future queries though, outside of the
usual type of brokenness that can happen even with full name queries
(eg, a parent has a subdomain configured that it isn't actually
delegated to it).
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: How Zone Files Are Read
> On 17 Dec 2020, at 06:44, Timothe Litt wrote: > > > On 16-Dec-20 13:52, Tim Daneliuk wrote: >> On 12/16/20 12:25 PM, Timothe Litt wrote: >> >>> On 16-Dec-20 11:37, Tim Daneliuk wrote: >>> I ran into a situation yesterday which got me pondering something about bind. In this case, a single line in a zone file was bad. The devops automation had inserted a space in the hostname field of a PTR record. What was interesting was that - at startup - bind absolutely refused to load the zone file at all. I would have expected it to complain about the bad record and ignore it, but load the rest of the good records. Can someone please explain the rationale or logic for this? Not complaining, just trying to understand for future reference. TIA, Tim >>> DNS is complicated. The scope of an error in a zonefile is hard to >>> determine. >>> >>> To avoid this, your automation should use named-checkzone before releasing >>> a zone file. >>> >>> This will perform all the checks that named will when it is loaded. >>> >>> >> >> Kind of what I thought. Whoever build the environment in question >> really didn't understand DNS very well and hacked together a kludge >> that I am still trying to get my head around. >> >> > For a simple example of why it's complicated - what if the typo you had was > for a host that sends e-mail? > > You'll see intermittent delivery errors when remote hosts can't resolve the > host's address; some require that a reverse lookup resolve to the host as an > anti-spoofing measure. Others won't. You'll spend a long time diagnosing. > named can't tell this case from a typo for a local printer's PTR - where it's > unlikely that a reverse lookup failure will matter. Of course, this means it > could go undetected for years - until it IS needed. > > Or the typo is in a NS record - which you probably won't detect until the > other NS goes down... > > And, any errors are cached for their TTL by resolvers. The TTL may > (hopefully for query rate reduction) be large. In your case, it would be the > negative TTL (meaning that even adding the record later wouldn't have > immediate effect). > The bottom line is that named must assume that anything placed in a zone file > is important, and that the external impact - either sin of omission or > commission - might be large. > > Thus, while named can't detect all (or even most) errors, those that it does > detect cause immediate failure to load. That prevents caching and > propagation as well as getting human attention. > When something's wrong, it's best to stop and fix it. Error recovery is a > very good thing - but only when you can demonstrate that the cure is better > than the disease. Skipping format errors in a zone file would not satisfy > that constraint. > Timothe Litt > ACM Distinguished Engineer > -- > This communication may not represent the ACM or my employer's views, > if any, on the matters discussed. And on top of all this there is STD 13 (RFC 1034, RFC 1035) which says in RFC 1035: "5.2. Use of master files to define zones When a master file is used to load a zone, the operation should be suppressed if any errors are encountered in the master file. The rationale for this is that a single error can have widespread consequences. For example, suppose that the RRs defining a delegation have syntax errors; then the server will return authoritative name errors for all names in the subzone (except in the case where the subzone is also present on the server). Several other validity checks that should be performed in addition to insuring that the file is syntactically correct: 1. All RRs in the file should have the same class. 2. Exactly one SOA RR should be present at the top of the zone. 3. If delegations are present and glue information is required, it should be present. 4. Information present outside of the authoritative nodes in the zone should be glue information, rather than the result of an origin or similar error." Those of use with long memories have seen all the errors scenarios reported here play out in real life because early versions of BIND did just drop bad lines and continue on as “best effort". We fixed this behaviour over 2 decades ago now with no regrets other than we didn’t fix it sooner. The above list of thing to check is not exhaustive. BIND checks much more these days. Mark -- 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 ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@list
