Re: BIND benchmark tool

[Petr Bena]

That's what I needed - thanks :)

On 27/09/2021 12:50, Marc wrote:

dnsperf -f inet -t 10 -s 192.168.10.235 -d files.tst -l 30

   Queries sent: 451753
   Queries completed:451753 (100.00%)
   Queries lost: 0 (0.00%)

   Response codes:   NOERROR 451753 (100.00%)
   Average packet size:  request 30, response 121
   Run time (s): 30.032850
   Queries per second:   15041.962385

   Average Latency (s):  0.006456 (min 0.000714, max 0.148530)
   Latency StdDev (s):   0.007529


Is there any open source tool that benchmarks the DNS server? Sends
pre-defined amount of queries, in parallel to specified DNS servers and
calculates the results, with average response time, error count, time
out count etc. Something like FIO for IO devices, but for DNS?


___
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

BIND benchmark tool

[Petr Bena]

Hello,

Is there any open source tool that benchmarks the DNS server? Sends 
pre-defined amount of queries, in parallel to specified DNS servers and 
calculates the results, with average response time, error count, time 
out count etc. Something like FIO for IO devices, but for DNS?


___
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: BIND 9.16.17-snapshot - testers needed - recursive performance

[Petr Bena]

Hello,

It works just fine to me, so I guess it's a problem on your end? Try 
using wget instead of firefox, or different browser.


On 25/05/2021 16:44, Erich Eckner wrote:

On Tue, 25 May 2021, Ondřej Surý wrote:

> Hi,

Hi Ondrej,


> we merged a change that substantially reduces a contention between 
threads
> and improves the recursive performance in 9.16 branch quite 
significantly.


> After the change, the 9.16 branch performance will surpass 9.11 
performance
> in both scenarios - authoritative (already the case, from the very 
beginning)

> and recursive (since a version to be released in June).

> Although, we are quite confident that the new code is correct, we 
would appreciate
> if people running different work loads than ours to test the 
snapshot tarball available

> from here:

> https://users.isc.org/~ondrej/bind-9.16.17-pre.tar.xz

I tried to pull the tarball from this url, but only got some gitlab 
page (which firefox refused to show, but insisted to download). Is 
this my error or did you accidentally push the wrong content?



> We would like to hear both success (it’s ok here in the mailing 
list) and failure stories

> (please create GitLab issues).

> Thanks,
> Ondrej

regards,
Erich


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

Re: Interest in a webinar on any of these DNS mgmt tools?

[Petr Bena]

Hello Victoria,

I'd like to also make you aware of a tool I made, although I am not sure 
if it fits into this category, because it (on purpose) doesn't directly 
edit the zone files - it performs all changes to zone files via 
nsupdate. But it adds a graphical user interface + API. That makes it 
very flexible and non-invasive, you can add it to existing BIND setup, 
with no need to change anything. It's very simple in design (basically 
just a PHP wrapper around dig and nsupdate), but we use it for 
management of very old and very large DNS infrastructure and people in 
our corporation are quite happy with it. The main benefit of this tool 
is really that you can integrate it with pretty much any BIND9 setup 
that supports dynamic updates.


+ It seems to work (at least in read-only mode) for non-BIND DNS servers 
as well, we have some Microsoft DNS zones as well.


https://github.com/benapetr/dnsphpadmin

On 03/06/2020 20:15, Victoria Risk wrote:
There are a number of open source tools for managing BIND zonefiles. 
The three below (at least) seem currently maintained and popular.  Is 
there interest in a presentation on any of these? If there seems to be 
interest, I would be willing to try to recruit someone who is either a 
member of the core team developing the tool, or perhaps an 
operator/user of the tool (if those are different) to give a webinar.


VinylDNS - created and used by Comcast. 
https://github.com/VinylDNS/vinyldns


OctoDNS - maintained by Github. Manages zonefiles across multiple DNS 
providers. (https://github.com/github/octodns)


DNS Control - maintained by Stack Exchange. Manages zonefiles across 
multiple DNS providers (https://stackexchange.github.io/dnscontrol/)


Reply on this Doodle poll - https://doodle.com/poll/i8vf3tmi6p5ity6q 
or email me directly if you have other suggestions/requests.



Thanks,

Vicky

Victoria Risk
Product Manager
Internet Systems Consortium
vi...@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
___
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

nsupdate: using "wildcard" TTL when removing specific record

[Petr Bena]

Hello,

Is there any way to tell nsupdate to delete specific record with ANY TTL 
value? For example I have following record:


record.domain.org 3500 A 1.2.3.4

I want to delete exactly that record (A with IP 1.2.3.4), except I don't 
know what the TTL is, normally, if I knew the TTL, I would do


update delete record.domain.org 3500 A 1.2.3.4

But I would like to do something like

update delete record.domain.org * A 1.2.3.4

Is there any way to accomplish this, or do I always have to retrieve the 
record somehow, figure out the TTL and then continue?


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: Nsupdate and TTL

[Petr Bena]

Hello,

From my experience you don't need to delete whole set, I was actually 
doing this quite recently and discovered and interesting behavior of 
BIND server - last record you add will override the TTL value for a set.


So if you add another NS record to a zone, all existing NS records will 
have TTL overriden with the last one you add.


On 23/04/2020 01:06, Mark Andrews wrote:



On 23 Apr 2020, at 07:20, Evan Hunt  wrote:

On Wed, Apr 22, 2020 at 03:04:38PM -0600, @lbutlr via bind-users wrote:

# nsupdate -k /path/to/key

zone example.com
ttl 3600
send
^d

No errors, but no change in the TTL.

"ttl 3600" just means "from now on assume I mean ttl 3600 in all the
records I send". You didn't actually send an update, so nothing changed..

As far as I can recall, the only way to change a TTL in nsupdate is to
delete the whole RRset and then add it back in the same transaction:


zone example.com
ttl 3600
update del example.com in a
update add example.com in a 192.0.2.1
update add example.com in a 192.0.2.2
update add example.com in a 192.0.2.3
send

Also don’t forget to add a prerequisite section to ensure you are removing
the records you think you are.

zone example.com
ttl 3600
prereq yxrrset example.com in a 192.0.2.1
prereq yxrrset example.com in a 192.0.2.2
prereq yxrrset example.com in a 192.0.2.3
update del example.com in a
update add example.com in a 192.0.2.1
update add example.com in a 192.0.2.2
update add example.com in a 192.0.2.3
send

Also note you can’t do it this way for the NS RRset at top of zone.  You need to
delete the NS RRs individually and then add them back without deleting all the
NS at any point in the process as the NS RRset is required to always exist.

Note: named only keeps a single TTL for a RRset so it will update the TTL on all
the records when you add a new one with a different TTL but this is not part of
the UPDATE RFC.


___
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

Chaining NOTIFY and slave servers - is it supported?

[Petr Bena]

Hello,

In our massive corporate setup with hundreds BIND servers all around 
planet, we have some "funny" configurations (please don't ask why :)), 
that seem to be actually working just fine, but I would like to 
understand if this is actually supported setup, or they just work by 
accident or due to some kind of a bug.


We have some DNS servers which have some network limitations (mostly 
firewalls) that allow communication only in certain directions, imagine 
this setup with 3 DNS servers:


* A: is a master for zone test.org, can talk to B only

* B: is a slave for zone test.org, can talk to A and C

* C: is a slave for zone test.org, can talk only to B

What we do is, that:

* A is a real master, but can't reach C, so it allows zone transfer to B 
and also sends NOTIFY to B.


* B is a slave to A, but master to C, it has also-notify for C, despite 
it's not really a master.


* C is a slave to B

So when someone changes zone on A via nsupdate, NOTIFY and subsequent 
IXFR goes like this: A -> B -> C instead of:


A -> B

   -> C

Which would be the case in more "correct setup".

What confuses me however, is that I just found this in BIND 
documentation at: https://www.zytrax.com/books/dns/ch7/xfer.html#also-notify


"The *also-notify* statement is relevant only with master zones..."

If also-notify works only with master zones, then why this works? Is it 
even supposed to work? Is this a supported configuration at all?



Thanks for clearing this up

___
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: Machine friendly alternative to nsupdate

[Petr Bena]

Hello,

The problem with this approach is that it's not atomic. I can run a 
query to check if record exists before it's created, but there are two 
problems:


* It adds an overhead (one more call of dig to lookup current situation)

* It's not reliable - because it's not atomic

So I was hoping this can be achieved with the nsupdate, I guess the 
prereq statement is what I need to work with, but as I said - parsing 
the current output of nsupdate, especially that header from debug or 
answer section, is just not very easy, and I wouldn't be surprised if 
the format of output changed in future versions (that would break my 
parser), so that's why I am looking for a some alternative to nsupdate, 
that can achieve the same, but more machine friendly, like a "proper DNS 
library" you talk about, is there any such a thing?


On 01/04/2020 14:35, Tony Finch wrote:

Petr Bena  wrote:
I think your approach of using standard protocols (DNS queries and
updages) to edit zones is very good!


Is there any alternative to nsupdate, something that can work with XML
or JSON payloads or provide output in such machine parseable format?

I've done a lot with wrapping dig and nsupdate, and it works quite well,
but I find that when I start getting into parsing swamps (anything more
complicated than one line per record, or caring about response codes)
it's better to use a proper DNS library, which should include support for
UPDATE requests as well as queries.


For example, typical problem I am facing right now - is that nsupdate
silently ignores things that IMHO shouldn't be ignored - for example
when someone try to add a record that already exists, or try to add an A
record over CNAME, nsupdate silently ignores this,

This error behaviour is mostly specified by the UPDATE protocol (RFC
2136). It's worth reading the RFC becasue (as you have found) some of the
behaviour is a bit surprising. For instance, adding a record that already
exists is not an error because multiple copies of the same record
traditionally get silently de-duplicated in the DNS. (I can't explain the
lack of error in the CNAME case...)

You might find that a more complicated update strategy gives you better
error detection, using UPDATE's prerequisite feature. Something roughly
like,

   * Query the current state of the name you want to edit. In most cases
 you care about the type being edited and whether or not there's a
 CNAME involved. You may already have this information for display in
 your user interface!

   * In your update request, assert in the prerequisite section that the
 state of the zone matches what you expect, to detect problems with
 concurrent updates;

   * In the update section, you'll have to explicitly delete existing
 records and add new ones if a CNAME is involved. If you have all the
 records of all the types at a name in hand, a simple strategy
 might be to delete everything at the name and add all the records that
 you think should be there.

In nsdiff (https://dotat.at/prog/nsdiff/) I'm doing whole-zone updates
which makes things slightly simpler. I know I have all the records at a
name so I can handle CNAMEs fairly straightforwardly, and I can just use
the SOA serial number (a SOA record in the prerequisite section) to detect
concurrent updates. But it gets slow and eats memory with big zones!

Tony.

___
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

Machine friendly alternative to nsupdate

[Petr Bena]

Hello,

Some preamble: Some time ago I created an open source DNS admin web GUI 
*1 that is basically a wrapper around dig and nsupdate that allows 
people with "less CLI knowledge" to easily manipulate DNS records. The 
main reason for this was that in our corporation we have about 400 
internal DNS zones hosted on over 100 different BIND master servers, in 
more than 10 countries around the planet and this tool allowed us to 
unify the management as it allowed integration with different master 
servers, allow granular role based access for individual zones 
(integrated with LDAP groups), including some web API for our automation 
tools etc.


Now to the actual problem: as I said, this tool is just a wrapper around 
nsupdate and dig, I like it that way because it's non-invasive, unlike 
other similar DNS admin panels, it doesn't require ANY changes on DNS 
server configuration and it integrates well with other solutions already 
in place. The problem I have however, is, that nsupdate was created as a 
tool for humans, rather than machines and parsing its output and even 
giving it input is very hard. Plus some things don't even seem to be 
possible in it.


Is there any alternative to nsupdate, something that can work with XML 
or JSON payloads or provide output in such machine parseable format? For 
example, typical problem I am facing right now - is that nsupdate 
silently ignores things that IMHO shouldn't be ignored - for example 
when someone try to add a record that already exists, or try to add an A 
record over CNAME, nsupdate silently ignores this, even in debug output 
I can't see any difference, in first send the record is created, 
resulting in NOERROR, in second identical send, update is ignored 
resulting in NOERROR, so I have no way to tell users of my app that 
record was not in fact created or changed (because it already exists). 
For example:


Here is operation where I first add a CNAME record and then try to add 
same A record (imagine two different users were doing this so user B was 
unaware that CNAME already exists) you can see in both cases nsupdate 
respond with same answer, despite record is created only in first case. 
And on top of that this answer is not easy to machine parse.


> debug
> update add petrbena.test.zone. 600 CNAME this.is.test.
> send
Sending update to 10.15.12.17#53
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 48433
;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1
;; ZONE SECTION:
;test.zone.            IN    SOA

;; UPDATE SECTION:
petrbena.test.zone.    600    IN    CNAME    this.is.test.

;; TSIG PSEUDOSECTION:
server. 0    ANY    TSIG    hmac-md5.sig-alg.reg.int. 1585729680 300 16 
xx== 48433 NOERROR 0



Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 48433
;; flags: qr ra; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; ZONE SECTION:
;test.zone.            IN    SOA

;; TSIG PSEUDOSECTION:
server. 0    ANY    TSIG    hmac-md5.sig-alg.reg.int. 1585729680 300 16 
xx== 48433 NOERROR 0


> update add petrbena.test.zone. 600 A 0.0.0.0
> send
Sending update to 10.15.12.17#53
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 30709
;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1
;; ZONE SECTION:
;test.zone.            IN    SOA

;; UPDATE SECTION:
petrbena.test.zone.    600    IN    A    0.0.0.0

;; TSIG PSEUDOSECTION:

server. 0    ANY    TSIG    hmac-md5.sig-alg.reg.int. 1585729721 300 16 
xx== 30709 NOERROR 0



Is there any alternative to nsupdate that can do this? Or some newer 
version of nsupdate that can acomplish this?


Thanks


*1 https://github.com/benapetr/dnsphpadmin

___
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: Weird behaviour in wildcard CNAME - is this feature or bug? Can it be changed?

[Petr Bena]

Oh, that explains it, I didn't know there is such a thing as "empty 
domain", thanks!


On 11/02/2020 16:33, Matus UHLAR - fantomas wrote:

On 11.02.20 15:58, Petr Bena wrote:

for example test.prod.app.pcp.cn.prod

step 2) search the available zones - the zone in question here is 
pcp.cn.prod which is found


step 3) no matching name is found but *.prod.app exists inside of 
pcp.cn.prod which is returned


However, with payis.test.prod.app.pcp.cn.prod

step 2) search the available zones - the zone in question here is 
pcp.cn.prod which is found


step 3) no matching name is found, *.prod.app exists inside of 
pcp.cn.prod but NXDOMAIN is returned instead?


because defining domain funding-gw.payis.prod.app.pcp.cn.prod defined 
empty
domain payis.prod.app.pcp.cn.prod, and since it exists (although 
empty), the
*.prod.app.pcp.cn.prod does not apply to payis.prod.app.pcp.cn.prod 
nor to

any subdomain under it.


___
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: Weird behaviour in wildcard CNAME - is this feature or bug? Can it be changed?

[Petr Bena]

Hello,

I fail to see that:

for example test.prod.app.pcp.cn.prod

step 2) search the available zones - the zone in question here is 
pcp.cn.prod which is found


step 3) no matching name is found but *.prod.app exists inside of 
pcp.cn.prod which is returned


However, with payis.test.prod.app.pcp.cn.prod

step 2) search the available zones - the zone in question here is 
pcp.cn.prod which is found


step 3) no matching name is found, *.prod.app exists inside of 
pcp.cn.prod but NXDOMAIN is returned instead?


Why?

How this algorith is broken if something under or above the requested 
record is existing?



On 11/02/2020 15:06, Mark Andrews wrote:

Yes, this is standard behaviour.  It falls out of this section of RFC 1034
which is part of STD 13 (DNS).  Work the algorithm by hand with the records
you said existed in the zone.

4.3.2. Algorithm


The actual algorithm used by the name server will depend on the local OS
and data structures used to store RRs.  The following algorithm assumes
that the RRs are organized in several tree structures, one for each
zone, and another for the cache:

1. Set or clear the value of recursion available in the response
   depending on whether the name server is willing to provide
   recursive service.  If recursive service is available and
   requested via the RD bit in the query, go to step 5,
   otherwise step 2.

2. Search the available zones for the zone which is the nearest
   ancestor to QNAME.  If such a zone is found, go to step 3,
   otherwise step 4.

3. Start matching down, label by label, in the zone.  The
   matching process can terminate several ways:

  a. If the whole of QNAME is matched, we have found the
 node.

 If the data at the node is a CNAME, and QTYPE doesn't
 match CNAME, copy the CNAME RR into the answer section
 of the response, change QNAME to the canonical name in
 the CNAME RR, and go back to step 1.

 Otherwise, copy all RRs which match QTYPE into the
 answer section and go to step 6.

  b. If a match would take us out of the authoritative data,
 we have a referral.  This happens when we encounter a
 node with NS RRs marking cuts along the bottom of a
 zone.

 Copy the NS RRs for the subzone into the authority
 section of the reply.  Put whatever addresses are
 available into the additional section, using glue RRs
 if the addresses are not available from authoritative
 data or the cache.  Go to step 4.

  c. If at some label, a match is impossible (i.e., the
 corresponding label does not exist), look to see if a
 the "*" label exists.

 If the "*" label does not exist, check whether the name
 we are looking for is the original QNAME in the query
 or a name we have followed due to a CNAME.  If the name
 is original, set an authoritative name error in the
 response and exit.  Otherwise just exit.

 If the "*" label does exist, match RRs at that node
 against QTYPE.  If any match, copy them into the answer
 section, but set the owner of the RR to be QNAME, and
 not the node with the "*" label.  Go to step 6.

4. Start matching down in the cache.  If QNAME is found in the
   cache, copy all RRs attached to it that match QTYPE into the
   answer section.  If there was no delegation from
   authoritative data, look for the best one from the cache, and
   put it in the authority section.  Go to step 6.

5. Using the local resolver or a copy of its algorithm (see
   resolver section of this memo) to answer the query.  Store
   the results, including any intermediate CNAMEs, in the answer
   section of the response.

6. Using local data only, attempt to add other RRs which may be
   useful to the additional section of the query.  Exit.




On 12 Feb 2020, at 00:45, Petr Bena  wrote:

But, is this behaviour consistent with other DNS software (microsoft DNS etc.), 
or is this specific only to BIND9?

Is there any standard / documentation that explain how or why is this 
happening? Because it just doesn't make any sense to me.

On 11/02/2020 14:39, Tony Finch wrote:

Petr Bena  wrote:

Why is this? Is that normal or a bug?

It's because wildcards in the DNS are crazy and totally abnormal, but
sadly ossified tradition means it cannot be considered a bug. (It's also
intimately tied up with the subtle semantics of NXDOMAIN, and rigidly
enforced by DNSSEC.) It's annoying because it makes wildcards a lot less
useful than one might hope.

https://tools.ietf.org/html/rfc4592 - The Role of Wildcards in the Domain Name 
System.
https://tools.ietf.org/html/rfc8020 - NXDOMAIN: Th

Re: Weird behaviour in wildcard CNAME - is this feature or bug? Can it be changed?

[Petr Bena]

But, is this behaviour consistent with other DNS software (microsoft DNS 
etc.), or is this specific only to BIND9?


Is there any standard / documentation that explain how or why is this 
happening? Because it just doesn't make any sense to me.


On 11/02/2020 14:39, Tony Finch wrote:

Petr Bena  wrote:

Why is this? Is that normal or a bug?

It's because wildcards in the DNS are crazy and totally abnormal, but
sadly ossified tradition means it cannot be considered a bug. (It's also
intimately tied up with the subtle semantics of NXDOMAIN, and rigidly
enforced by DNSSEC.) It's annoying because it makes wildcards a lot less
useful than one might hope.

https://tools.ietf.org/html/rfc4592 - The Role of Wildcards in the Domain Name 
System.
https://tools.ietf.org/html/rfc8020 - NXDOMAIN: There Really Is Nothing 
Underneath.

Tony.

___
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

Weird behaviour in wildcard CNAME - is this feature or bug? Can it be changed?

[Petr Bena]

Hello,

I observed very weird behaviour that I can reproduce on both these BIND9 
versions:


BIND 9.11.4-P2-RedHat-9.11.4-9.P2.el7 (Extended Support Version) 
 (slave)


BIND 9.8.2rc1-RedHat-9.8.2-0.68.rc1.el6_10.1 (master)

Someone has created a wildcard CNAME:

*.prod.app.pcp.cn.prod.     300     IN     CNAME 
gs-vip.prod-wq-01.k8s.pcp.cn.prod.


Which was working just fine, everything behind this wildcard was working 
as a CNAME:


# dig test.prod.app.pcp.cn.prod +short
gs-vip.prod-wq-01.k8s.pcp.cn.prod.

But moment when someone has created another record (CNAME as well) behind it

funding-gw.payis.prod.app.pcp.cn.prod.     30     IN     CNAME 
gs-vip.prod-wq-01.k8s.pcp.cn.prod.


Records that are anywhere in the path of this new record stopped 
working, for example


payis.prod.app.pcp.cn.prod        would NOT work

test.payis.prod.app.pcp.cn.prod would NOT work

test.prod.app.pcp.cn.prod  would work


Why is this? Is that normal or a bug?


___
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