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
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
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?
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?
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: 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?
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?
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
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
