Re: Unable to completely transfer root zone
On Mon, Feb 10, 2020 at 02:32:55PM -0500, Warren Kumari wrote a message of 70 lines which said: > Also, can you try: > dig +tcp . axfr @192.0.32.132 > dig +tcp . axfr @192.0.47.132 > dig +tcp . axfr @b.root-servers.net > > (no, I'm not really sure why trying with the first 2 IPs instead of > hostname Because you know that IPv6 and IPv4 may exhibit different issues. ___ 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: Unable to completely transfer root zone
Warren Kumari wrote: > von Dein, Thomas wrote: > > > > Does anyone have an idea, what's wrong here and how I could possibly fix > > this? > > This sounds very much like a path MTU issue -- it starts the transfer, > gets part of the way and then a big packet doesn't make it through... I wondered about that, but a pMTU problem usually turns up right at the start of bulk data transmission, and on the receiver side I would expect to get approximately nothing rather than approximately 180 KB. There are different zone transfer implementations in `named` and `dig` so it's conceivable that they do something different enough to provoke a RST. But I can't think of anything plausible that might cause a RST... could it be IXFR vs AXFR? the logs didn't mention the flavour of transfer. Ah, but they did say: transfer of './IN' from 192.0.47.132#53: resetting which can happen when an IXFR fails and `named` tries to fall back to AXFR. (The relative priorities of the log messages in this area could be improved, because the LOG_DEBUG(3) "got %s, retrying with AXFR" is much more informative than the LOG_INFO "resetting"...) So maybe try setting `request-ixfr no;` and see if that improves matters. (IXFR does not provide many advantages for the root zone because most of the update traffic is bulk re-signing of the zone for which IXFR is very inefficient.) Tony. -- f.anthony.n.finchhttp://dotat.at/ Viking, North Utsire, South Utsire: Westerly veering northwesterly 6 to gale 8, occasionally severe gale 9 at first except in North Utsire. Very rough or high. Wintry showers, thundery for a time. Moderate, occasionally poor. ___ 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?
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
Re: Weird behaviour in wildcard CNAME - is this feature or bug? Can it be changed?
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. -- f.anthony.n.finchhttp://dotat.at/ Sole: West 6 to gale 8, decreasing 5 for a time, then backing southwest later. High or very high. Showers. Moderate, occasionally poor. ___ 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
AW: Unable to completely transfer root zone
Hi, > So maybe try setting `request-ixfr no;` and see if that improves matters. Nope, didn't change anything. Also, I was wrong when I stated that dig works, it does not. It transfers only a part of the zone as well. However, in the meantime we found, that some component drops packets. I implemented my own "root nameserver" and lots of packets sent out from it are not arriving here. So, not bind9's fault. Thanks a lot for your help anyway people! best, Tom ___ 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?
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
Re: Weird behaviour in wildcard CNAME - is this feature or bug? Can it be changed?
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: 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 -- 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 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?
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: There Really Is Nothing Underneath. Tony.
Re: Unable to completely transfer root zone
On Tue, Feb 11, 2020 at 3:12 AM Stephane Bortzmeyer wrote: > > On Mon, Feb 10, 2020 at 02:32:55PM -0500, > Warren Kumari wrote > a message of 70 lines which said: > > > Also, can you try: > > dig +tcp . axfr @192.0.32.132 > > dig +tcp . axfr @192.0.47.132 > > dig +tcp . axfr @b.root-servers.net > > > > (no, I'm not really sure why trying with the first 2 IPs instead of > > hostname > > Because you know that IPv6 and IPv4 may exhibit different issues. Hey, yeah, that's it! Thank you for explaining my thought processes to me -- for an encore, can you explain why I keep losing my keys? :-) Thanks Stephane, W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ 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?
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. -- 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. WinError #98652: Operation completed successfully. ___ 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?
The wildcard doesn’t cover empty non terminals. The only nonstandard implementation that did this was djbdns and the behavior was considered to be incompatible with rest of the DNS implementations. Ondrej -- Ondřej Surý — ISC > On 11 Feb 2020, at 15:59, Petr Bena wrote: > > 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
Re: Weird behaviour in wildcard CNAME - is this feature or bug? Can it be changed?
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
OT: Reminder: DNSSEC series starts in 1 day
First, I love it that ISC does these informative sessions. However, why send out iCal/Calendar instructions AND then send me emails 1 day and 1 hour before each session? I don't want to cancel my registration, but I do want to cancel the constant email reminders. Help! -Jim P. Forwarded Message From: Vicky Risk Reply-To: no-re...@zoom.us To: Jim Popovitch Subject: Reminder: DNSSEC series starts in 1 day Date: Tue, 11 Feb 2020 18:14:12 + Hi Jim Popovitch, This is a reminder that "DNSSEC series" will begin in 1 day on: Date Time: Feb 12, 2020 10:00 AM Pacific Time (US and Canada) Join from a PC, Mac, iPad, iPhone or Android device: Click Here to Join Note: This link should not be shared with others; it is unique to you. Add to Calendar Add to Google Calendar Add to Yahoo Calendar You can cancel your registration at any time. ___ 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: OT: Reminder: DNSSEC series starts in 1 day
Sorry, I hadn’t done a series of webinars before and hadn’t realized the constant reminders are the default setting. I just turned them off. Thank you for letting us know these are annoying. Vicky > On Feb 11, 2020, at 10:32 AM, Jim Popovitch via bind-users > wrote: > > First, I love it that ISC does these informative sessions. > > However, why send out iCal/Calendar instructions AND then send me emails > 1 day and 1 hour before each session? > > I don't want to cancel my registration, but I do want to cancel the > constant email reminders. Help! > > -Jim P. > > Forwarded Message > From: Vicky Risk > Reply-To: no-re...@zoom.us > To: Jim Popovitch > Subject: Reminder: DNSSEC series starts in 1 day > Date: Tue, 11 Feb 2020 18:14:12 + > > > > Hi Jim Popovitch, > > This is a reminder that "DNSSEC series" will begin in 1 day on: > Date Time: Feb 12, 2020 10:00 AM Pacific Time (US and Canada) > > Join from a PC, Mac, iPad, iPhone or Android device: > Click Here to Join > Note: This link should not be shared with others; it is unique to you. > Add to Calendar Add to Google Calendar Add to Yahoo Calendar > > > > You can cancel your registration at any time. > > > > > ___ > 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 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 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?
Perhaps a real example would help. Here is an example of a captive portal root domain. Everything goes to .25 . A 141.211.7.25 *. A 141.211.7.25 But I need everything except one host, dns1.itd.umich.edu, so I need wildcards at every level: . A 141.211.7.25 *. A 141.211.7.25 edu.A 141.211.7.25 *.edu. A 141.211.7.25 umich.edu. A 141.211.7.25 *.umich.edu.A 141.211.7.25 itd.umich.edu. A 141.211.7.25 *.itd.umich.edu.A 141.211.7.25 dns1.itd.umich.edu. A 192.12.80.214 -- Bob Harold On Tue, Feb 11, 2020 at 11:16 AM Petr Bena wrote: > 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 > ___ 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
