Re: Bind to Bind DNS Lookup - Returns wildcard value for defined A record
Ok, I fixed the problem.
I changed the zonefile templates for dynamic DNS used at dynamix.run to the
following:
$TTL60
@ IN SOA ns.{domainname}. ad...@dynamix.run (
{serial} ;
30 ; Refresh
20; Retry
1209600 ; Expire
30 ) ; Minimum
{domainname}. IN NS ns.{domainname}.
ns.{domainname}.IN A{serverip}
ns.{domainname}.IN A{serveripBackup}
Rather than:
$TTL60
@ IN SOA ns.{domainname}. ad...@dynamix.run (
{serial} ;
30 ; Refresh
20; Retry
1209600 ; Expire
30 ) ; Minimum
{domainname}. IN NS ns.{domainname}.
ns.{domainname}.IN A{dnsip}
{dnsip} would get updated with the user's dynamic IP address. Thus, if you
were to query specific.wildcard-test.dynx.me, it would send the traffic to
their IP address to resolve, which is not correct, since the record is
defined on the main server, not theirs.
This makes it so queries for that subdomain resolve to that same specific
server, rather than the IP address provided by the end user since it is
acting as the main DNS server, in this case.
But, it still makes no sense to me how google's DNS (and others) was able
to resolve everything just fine... google's dns must not be asking
ns.{domainname}. for the records?
How crazy. I still don't fully understand why this happens, but I could
clearly see tcpdump asking 23.29.117.19 for the A record for
specific.wildcard-test.dynx.me which it has no information about since
there is no zonefile on 23.29.117.19 for wildcard-test.dynx.me...
--
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 to Bind DNS Lookup - Returns wildcard value for defined A record
I turned logging on, but I'm still not seeing anything that can help me pinpoint why the query is failing? Audit log: 18-Jul-2023 19:45:14.938 client @0x7f26e6def368 23.29.117.19#44526 (*. wildcard-test.dynx.me): query: *.wildcard-test.dynx.me IN A -E(0)DCV (23.29.117.19) 18-Jul-2023 19:45:22.142 client @0x7f26e6dee568 73.95.58.29#42969 (*. wildcard-test.dynx.me): query: *.wildcard-test.dynx.me IN A +E(0)K (23.29.117.19) 18-Jul-2023 19:45:22.142 fetch: *.wildcard-test.dynx.me/A 18-Jul-2023 19:45:22.142 client @0x7f26e6def368 23.29.117.19#47048 (*. wildcard-test.dynx.me): query: *.wildcard-test.dynx.me IN A -E(0)DCV (23.29.117.19) 18-Jul-2023 19:45:23.678 client @0x7f26e6dee568 73.95.58.29#57458 (*. wildcard-test.dynx.me): query: *.wildcard-test.dynx.me IN A +E(0)K (23.29.117.19) 18-Jul-2023 19:45:23.678 fetch: *.wildcard-test.dynx.me/A 18-Jul-2023 19:45:23.678 client @0x7f26e6def368 23.29.117.19#42309 (*. wildcard-test.dynx.me): query: *.wildcard-test.dynx.me IN A -E(0)DCV (23.29.117.19) 18-Jul-2023 19:45:33.762 client @0x7f26e6dee568 73.95.58.29#59621 (*. wildcard-test.dynx.me): query: *.wildcard-test.dynx.me IN A +E(0)K (23.29.117.19) 18-Jul-2023 19:45:33.762 fetch: *.wildcard-test.dynx.me/A 18-Jul-2023 19:45:33.762 client @0x7f26e6def368 23.29.117.19#33868 (*. wildcard-test.dynx.me): query: *.wildcard-test.dynx.me IN A -E(0)DCV (23.29.117.19) 18-Jul-2023 19:45:58.579 client @0x7f26e6dee568 73.95.58.29#54464 ( wildcard-test.dynx.me): query: wildcard-test.dynx.me IN A +E(0)K (23.29.117.19) 18-Jul-2023 19:45:58.579 fetch: wildcard-test.dynx.me/A 18-Jul-2023 19:45:58.579 client @0x7f26e6def368 23.29.117.19#37135 ( wildcard-test.dynx.me): query: wildcard-test.dynx.me IN A -E(0)DCV (23.29.117.19) 18-Jul-2023 19:45:58.579 fetch: ns.wildcard-test.dynx.me/ 18-Jul-2023 19:46:03.727 client @0x7f26e6dee568 73.95.58.29#54348 ( wildcard-test.dynx.me): query: wildcard-test.dynx.me IN A +E(0)K (23.29.117.19) 18-Jul-2023 19:46:03.727 fetch: wildcard-test.dynx.me/A 18-Jul-2023 19:46:03.727 client @0x7f26e6def368 23.29.117.19#51242 ( wildcard-test.dynx.me): query: wildcard-test.dynx.me IN A -E(0)DCV (23.29.117.19) 18-Jul-2023 19:46:14.143 client @0x7f26e6dee568 73.95.58.29#43180 ( specific.wildcard-test.dynx.me): query: specific.wildcard-test.dynx.me IN A +E(0)K (23.29.117.19) 18-Jul-2023 19:46:14.143 fetch: specific.wildcard-test.dynx.me/A 18-Jul-2023 19:46:14.143 fetch: _.wildcard-test.dynx.me/A 18-Jul-2023 19:46:14.183 client @0x7f26e6def368 23.29.117.19#59351 ( specific.wildcard-test.dynx.me): query: specific.wildcard-test.dynx.me IN A -E(0)DCV (23.29.117.19) Query log: client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#58627 ( wildcard-test.dynx.me): query failed (failure) for wildcard-test.dynx.me/IN/ at query.c:7824 client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#58635 ( specific.wildcard-test.dynx.me): query failed (failure) for specific.wildcard-test.dynx.me/IN/A at query.c:7824 client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#58636 ( specific.wildcard-test.dynx.me): query failed (failure) for specific.wildcard-test.dynx.me/IN/ at query.c:7824 client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#58644 ( specific.wildcard-test.dynx.me): query failed (failure) for specific.wildcard-test.dynx.me/IN/A at query.c:7824 client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#58645 ( specific.wildcard-test.dynx.me): query failed (failure) for specific.wildcard-test.dynx.me/IN/ at query.c:7824 client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#58653 ( specific.wildcard-test.dynx.me): query failed (failure) for specific.wildcard-test.dynx.me/IN/A at query.c:7824 client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#58654 ( specific.wildcard-test.dynx.me): query failed (failure) for specific.wildcard-test.dynx.me/IN/ at query.c:7824 client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#58662 ( specific.wildcard-test.dynx.me): query failed (SERVFAIL) for specific.wildcard-test.dynx.me/IN/A at query.c:7094 client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#58663 ( specific.wildcard-test.dynx.me): query failed (SERVFAIL) for specific.wildcard-test.dynx.me/IN/ at query.c:7094 client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#58672 ( wildcard-test.dynx.me): query failed (failure) for wildcard-test.dynx.me/IN/ at query.c:7824 client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#58681 ( wildcard-test.dynx.me): query failed (failure) for wildcard-test.dynx.me/IN/ at query.c:7824 client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#58690 ( wildcard-test.dynx.me): query failed (failure) for wildcard-test.dynx.me/IN/ at query.c:7824 client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#58699 ( wildcard-test.dynx.me): query failed (SERVFAIL) for wildcard-test.dynx.me/IN/ at query.c:7094 client @0x7f26e6ded768 2601:283:c200:4bb6:f099:a105:64ed:87f7#
Re: Bind to Bind DNS Lookup - Returns wildcard value for defined A record
The output from "named-checkconf -px" is over a million lines long, but here you go: http://23.29.117.19/bindconf.zip My resolver servers are setup for ad-blocking, hence why there are so many defined zones. Here is a quick tcpdump sample where I do not see anything too helpful: http://23.29.117.19/bind_tcpdump.zip -- 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 to Bind DNS Lookup - Returns wildcard value for defined A record
This time from the correct email alias! On Mon, 17 Jul 2023 at 22:58, Greg Choules wrote: > Hi. > Some observations: > - Please don't use nslookup. Please use dig, it is much more versatile and > gives much more information with which to try and interpret what might be > going on. > - If you're going to specify a destination server please use its IP > address, not its domain name (dnsr.dinofly.com). The reason for this is > that if you use a domain, first that domain needs to be resolved to an IP > address by the OS, which may or may not work, or may not give the result > you were expecting. > - I did a dig for "specific.wildcard-test.dynx.me" against my own BIND > server and it resolved to 1.1.1.1. So the issue is with your resolver. This > is not new, just confirming that this must be the problem end, not the auth > end. > - Please paste *the entire* config of your resolver, not just bits > that you think might be important. "named-checkconf -px" will produce that. > - Please run tcpdump on your resolver for port 53, captured to disc, then > download and analyse it in Wireshark. Only by seeing what your server does > after it receives your dig will you understand how it is attempting to find > an answer, which should shed some light on why you get the response you do. > That is, if you DO get the same answer using dig (@IP) rather than nslookup > (at domain). > > Cheers, Greg > > On Mon, 17 Jul 2023 at 20:36, OwN-3m-All wrote: > >> Spam assassin is blocking my message, so here are all the details (my >> latest response message): >> >> https://pastebin.com/raw/jSm6aGfC >> -- >> 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 >> > -- 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 to Bind DNS Lookup - Returns wildcard value for defined A record
Spam assassin is blocking my message, so here are all the details (my latest response message): https://pastebin.com/raw/jSm6aGfC -- 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 to Bind DNS Lookup - Returns wildcard value for defined A record
Also:- make the record self-contained, don’t make us go elsewhere, especially not to a place where data could disappear at the whim of the owner (as seen recently)- and finally, describe what you see, don’t speculate what it might be; by describing you are less likely to miss an important detailOndřej--Ondřej Surý — ISC (He/Him)My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.On 16. 7. 2023, at 10:25, Greg Choules via bind-users wrote:Real data please:- example queries (genuine, not invented for illustration)- real domains- real IP addresses- packet captures- both BIND server configs- zone file contents- startup logsThere are so many things it *could* be, the more information the better.Cheers, GregOn Sun, 16 Jul 2023 at 09:09, OwN-3m-All <own3m...@gmail.com> wrote:I've got a bind recursion DNS server setup that is returning the wrong value for an outside domain that I also maintain and host on another server running a bind DNS server. Yet Google's DNS and other major DNS providers respond with the correct IP address A record when querying. I can't figure out why my recursion enabled instance is not returning the correct IP address for a specific host. Rather, it returns the wildcard value from the zonefile rather than the specifically specified A record entry created for that host. It appears bind to bind is returning the wildcard value for a specifically defined host in the zonefile from the server it's hosted on.Is this a recent bug in bind? More information about my setup and issue can be found here:https://serverfault.com/questions/1136914/bind-recursion-dns-server-returning-wildcard-address-for-host-despite-exact-entrFrom what I found online, if there's a specific host A record entry defined, it should always return that IP. Wildcard is only for those not defined. Yet, when I remove the wildcard from the zonefile, my bind recursion instance returns the correct value, but not when the wildcard entry is there. But Google and other major DNS providers return the non-wildcard value as expected.Any help is appreciated. -- 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 -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users-- 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 to Bind DNS Lookup - Returns wildcard value for defined A record
Real data please: - example queries (genuine, not invented for illustration) - real domains - real IP addresses - packet captures - both BIND server configs - zone file contents - startup logs There are so many things it *could* be, the more information the better. Cheers, Greg On Sun, 16 Jul 2023 at 09:09, OwN-3m-All wrote: > I've got a bind recursion DNS server setup that is returning the wrong > value for an outside domain that I also maintain and host on another server > running a bind DNS server. Yet Google's DNS and other major DNS providers > respond with the correct IP address A record when querying. I can't figure > out why my recursion enabled instance is not returning the correct IP > address for a specific host. Rather, it returns the wildcard value from > the zonefile rather than the specifically specified A record entry created > for that host. > > It appears bind to bind is returning the wildcard value for a specifically > defined host in the zonefile from the server it's hosted on. > > Is this a recent bug in bind? More information about my setup and issue > can be found here: > > > https://serverfault.com/questions/1136914/bind-recursion-dns-server-returning-wildcard-address-for-host-despite-exact-entr > > From what I found online, if there's a specific host A record entry > defined, it should always return that IP. Wildcard is only for those not > defined. Yet, when I remove the wildcard from the zonefile, my bind > recursion instance returns the correct value, but not when the wildcard > entry is there. But Google and other major DNS providers return the > non-wildcard value as expected. > > Any help is appreciated. > -- > 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 > -- 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 to Bind DNS Lookup - Returns wildcard value for defined A record
On 16.07.23 02:08, OwN-3m-All wrote: I've got a bind recursion DNS server setup that is returning the wrong value for an outside domain that I also maintain and host on another server running a bind DNS server. Yet Google's DNS and other major DNS providers respond with the correct IP address A record when querying. I can't figure out why my recursion enabled instance is not returning the correct IP address for a specific host. Rather, it returns the wildcard value from the zonefile rather than the specifically specified A record entry created for that host. It appears bind to bind is returning the wildcard value for a specifically defined host in the zonefile from the server it's hosted on. Is this a recent bug in bind? More information about my setup and issue can be found here: https://serverfault.com/questions/1136914/bind-recursion-dns-server-returning-wildcard-address-for-host-despite-exact-entr From what I found online, if there's a specific host A record entry defined, it should always return that IP. Wildcard is only for those not defined. Yet, when I remove the wildcard from the zonefile, my bind recursion instance returns the correct value, but not when the wildcard entry is there. But Google and other major DNS providers return the non-wildcard value as expected. Please provide concrete example, I can't query fun.test.test.me. nor test.test.me. -- 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. Spam = (S)tupid (P)eople's (A)dvertising (M)ethod -- 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 to Bind DNS Lookup - Returns wildcard value for defined A record
I've got a bind recursion DNS server setup that is returning the wrong value for an outside domain that I also maintain and host on another server running a bind DNS server. Yet Google's DNS and other major DNS providers respond with the correct IP address A record when querying. I can't figure out why my recursion enabled instance is not returning the correct IP address for a specific host. Rather, it returns the wildcard value from the zonefile rather than the specifically specified A record entry created for that host. It appears bind to bind is returning the wildcard value for a specifically defined host in the zonefile from the server it's hosted on. Is this a recent bug in bind? More information about my setup and issue can be found here: https://serverfault.com/questions/1136914/bind-recursion-dns-server-returning-wildcard-address-for-host-despite-exact-entr >From what I found online, if there's a specific host A record entry defined, it should always return that IP. Wildcard is only for those not defined. Yet, when I remove the wildcard from the zonefile, my bind recursion instance returns the correct value, but not when the wildcard entry is there. But Google and other major DNS providers return the non-wildcard value as expected. Any help is appreciated. -- 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: RPZ wildcard domain passthru not effective in BIND 9.11.21
> RPZ wildcard domain whitelist (passthru) doesn't seem to work as it should > be. > > I have noticed that the last workable version is BIND 9.11.6-P1. I have > tested the same configurations with versions 9.11.8, 9.11.19 and 9.11.21, > and all produce the same issue. > > Has anyone experienced a similar issue here? or have I > mis-configured something? Looks like a match for GL #1619: https://gitlab.isc.org/isc-projects/bind9/-/issues/1619 This will fixed in BIND 9.11.22, which is due in a few weeks. If you urgently need a patch against BIND 9.11.21, try this one: https://gitlab.isc.org/isc-projects/bind9/-/commit/33ae88f08dabea846aee3be3af8a515fd9774ee1.diff Sorry about the trouble! -- Best regards, Michał Kępień ___ 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
RPZ wildcard domain passthru not effective in BIND 9.11.21
Hi all,
BIND version: 9.11.21
OS: RHEL 7
Compile options: ./configure --prefix=/usr --localstatedir=/var
--sysconfdir=/etc --with-openssl --enable-largefile --disable-ipv6
--enable-threads --enable-filter-
I have configured 4 RPZ zones (2 are from upstream feeds, and the other 2
are local overrides blacklist/whitelist).
The response-policy and RPZ zones configurations are as follows
response-policy {
zone "rpz.local.whitelist" policy passthru;
zone "rpz.local.blacklist" policy cname
sinkhole-local.domain.com;
zone "rpz.whitelist"policy passthru;
zone "rpz.blacklist" policy cname sinkhole-feed.domain.com;
};
zone "rpz.local.whitelist"{
type master;
file "zones/master/rpz.local.whitelist.db";
allow-query { localhost; };
};
zone "rpz.local.blacklist" {
type master;
file "zones/master/rpz.local.blacklist.db";
allow-query { localhost; };
};
zone "rpz.whitelist"{
type master;
file "zones/master/rpz.whitelist.db";
allow-query { localhost; };
};
zone "rpz.blacklist" {
type master;
file "zones/master/rpz.blacklist.db";
allow-query { localhost; };
};
Contents of zones that are relevant to the issue
# grep "*\.live\.com" rpz.*
rpz.blacklist.db:onedrive.live.com.rpz.blacklist. 3600 IN A 127.66.66.66
rpz.blacklist.db:*.live.com.rpz.blacklist. 3600 IN A 127.66.66.66
rpz.whitelist.db:*.live.com.rpz.whitelist. 3600 IN CNAME rpz.passthru.
# dig @dnsserver onedrive.live.com
;; QUESTION SECTION:
;onedrive.live.com. IN A
;; ANSWER SECTION:
onedrive.live.com. 5 IN CNAME sinkhole-feed.domain.com.
sinkhole-feed.domain.com. 900 IN A 127.66.66.66
I would expect the rpz.whitelist would allow *.live.com (passthru).
However, if I add the FQDN, not wildcard domain, in the rpz.local.whitelist
zone to override the external feeds, the FQDN resolution works
# grep "*\.live\.com" rpz.*
rpz.blacklist.db:onedrive.live.com.rpz.blacklist. 3600 IN A 127.66.66.66
rpz.blacklist.db:*.live.com.rpz.blacklist. 3600 IN A 127.66.66.66
rpz.local.whitelist.int.db:onedrive.live.com.rpz.local.whitelist. IN CNAME
rpz-passthru.
rpz.whitelist.db:*.live.com.rpz.whitelist. 3600 IN CNAME rpz.passthru.
# dig @dnsserver onedrive.live.com
;; QUESTION SECTION:
;onedrive.live.com. IN A
;; ANSWER SECTION:
onedrive.live.com. 60 IN CNAME odc-web-geo.onedrive.akadns.net.
odc-web-geo.onedrive.akadns.net. 36 IN CNAME odc-web-brs.onedrive.akadns.net
.
odc-web-brs.onedrive.akadns.net. 36 IN CNAME
odwebpl.trafficmanager.net.l-0004.dc-msedge.net.l-0004.l-msedge.net.
odwebpl.trafficmanager.net.l-0004.dc-msedge.net.l-0004.l-msedge.net. 240 IN
CNAME l-0004.l-msedge.net.
l-0004.l-msedge.net. 240 IN A 13.107.42.13
RPZ wildcard domain whitelist (passthru) doesn't seem to work as it should
be.
I have noticed that the last workable version is BIND 9.11.6-P1. I have
tested the same configurations with versions 9.11.8, 9.11.19 and 9.11.21,
and all produce the same issue.
Has anyone experienced a similar issue here? or have I
mis-configured something?
Thanks
myOcella
___
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: using "wildcard" TTL when removing specific record
TTL is ignored on delete if it present. It is set to 0 when sending. 2.5.4 - Delete An RR From An RRset RRs to be deleted are added to the Update Section. The NAME, TYPE, RDLENGTH and RDATA must match the RR being deleted. TTL must be specified as zero (0) and will otherwise be ignored by the primary master. CLASS must be specified as NONE to distinguish this from an RR addition. If no such RRs exist, then this Update RR will be silently ignored by the primary master. > On 1 Jun 2020, at 18:45, Petr Bena wrote: > > 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 -- 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
nsupdate: using "wildcard" TTL when removing specific record
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: update-policy wildcard grant
> On 2 Apr 2020, at 11:59, Jim Popovitch via bind-users
> wrote:
>
> On Thu, 2020-04-02 at 09:27 +1100, Mark Andrews wrote:
>>> On 2 Apr 2020, at 06:53, Jim Popovitch via bind-users <
>>> bind-users@lists.isc.org> wrote:
>>>
>>> Hello!
>>>
>>> I started on #bind, moved on to the ARM, and now I am here.
>>>
>>> Here is what I want:
>>>
>>> update-policy {grant webserver-tsig-key wildcard _acme-challenge.*
>>> TXT;};
>>>
>>> This is what I get:
>>>
>>> ~$ named-checkconf
>>> /etc/bind/named.conf:73: '_acme-challenge.*' is not a wildcard
>>>
>>> What am I doing wrong?
>>
>> Presumably the webserver is locked done enough that you can just let
>> the TSIG update TXT anywhere.
>
> Do you mean like kb.isc.org ? :-)
>
> Honestly, no webserver, worth it's salt in 2020, is ever locked down
> well enough, imho.
The tool updating the acme challenges and certificates can definitely
be locked down enough.
You could use SIG(0) rather than TSIG to authenticate the updates and store KEY
records in the DNS for each site. That is much easier to manage than TSIG’s for
each site and doesn’t require updating named.conf once it is setup with TSIG
only
being used to add the KEY records as each site is establised.
grant * self . TXT;
>> If you really need to apply tighter rules then use ‘external’ and
>> implement the check outside of named.
>
> Thanks for that, it looks exactly like what I need/want.
>
> -Jim P.
>
>
> ___
> 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: update-policy wildcard grant
On Thu, 2020-04-02 at 09:27 +1100, Mark Andrews wrote:
> > On 2 Apr 2020, at 06:53, Jim Popovitch via bind-users <
> > bind-users@lists.isc.org> wrote:
> >
> > Hello!
> >
> > I started on #bind, moved on to the ARM, and now I am here.
> >
> > Here is what I want:
> >
> > update-policy {grant webserver-tsig-key wildcard _acme-challenge.*
> > TXT;};
> >
> > This is what I get:
> >
> > ~$ named-checkconf
> > /etc/bind/named.conf:73: '_acme-challenge.*' is not a wildcard
> >
> > What am I doing wrong?
>
> Presumably the webserver is locked done enough that you can just let
> the TSIG update TXT anywhere.
Do you mean like kb.isc.org ? :-)
Honestly, no webserver, worth it's salt in 2020, is ever locked down
well enough, imho.
> If you really need to apply tighter rules then use ‘external’ and
> implement the check outside of named.
Thanks for that, it looks exactly like what I need/want.
-Jim P.
___
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: update-policy wildcard grant
> On 2 Apr 2020, at 06:53, Jim Popovitch via bind-users
> wrote:
>
> Hello!
>
> I started on #bind, moved on to the ARM, and now I am here.
>
> Here is what I want:
>
> update-policy {grant webserver-tsig-key wildcard _acme-challenge.* TXT;};
>
> This is what I get:
>
> ~$ named-checkconf
> /etc/bind/named.conf:73: '_acme-challenge.*' is not a wildcard
>
> What am I doing wrong?
Presumably the webserver is locked done enough that you can just let the TSIG
update TXT anywhere.
If you really need to apply tighter rules then use ‘external’ and implement the
check outside of named.
This is documented in the BIND 9 Administrators Reference Manual.
external
This rule allows named to defer the decision of whether to allow a given update
to an external daemon.
The method of communicating with the daemon is specified in the identity field,
the format of which is "local:path", where path is the location of a
UNIX-domain socket. (Currently, "local" is the only supported mechanism.)
Requests to the external daemon are sent over the UNIX-domain socket as
datagrams with the following format:
Protocol version number (4 bytes, network byte order, currently 1)
Request length (4 bytes, network byte order)
Signer (null-terminated string)
Name (null-terminated string)
TCP source address (null-terminated string)
Rdata type (null-terminated string)
Key (null-terminated string)
TKEY token length (4 bytes, network byte order )
TKEY token (remainder of packet)
The daemon replies with a four-byte value in network byte order, containing
either 0 or 1; 0 indicates that the specified update is not permitted, and 1
indicates that it is.
Mark
> tia!
>
> -Jim P.
>
>
> ___
> 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: update-policy wildcard grant
Jim Popovitch via bind-users wrote:
>
>update-policy {grant webserver-tsig-key wildcard _acme-challenge.* TXT;};
Sadly in the DNS a wildcard * can only occur as the leftmost label in a name.
RFC 4592 has more than you ever wanted to know about DNS wildcards. It's
not pretty.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
The Minch: Northwesterly 6 to gale 8, occasionally severe gale 9 at first in
north, decreasing 4 to 6 later. Slight or moderate, occasionally rough in
north. Squally wintry showers. Good, 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
update-policy wildcard grant
Hello!
I started on #bind, moved on to the ARM, and now I am here.
Here is what I want:
update-policy {grant webserver-tsig-key wildcard _acme-challenge.* TXT;};
This is what I get:
~$ named-checkconf
/etc/bind/named.conf:73: '_acme-challenge.*' is not a wildcard
What am I doing wrong?
tia!
-Jim P.
___
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
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 >> sectio
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
Limit Wildcard Entry with RPZ?
Hello,
a department would like to use the application Sandstorm. This application
needs a wildcard DNS entry. But with this every hostname would get an IP
address, even such an entry as "we-dont-like-to-work-here". It seems to be
possible to set a prefix to the random hostname created by Sandstorm (like
"sandstorm-*").
And now to my questions:
- Would it be possible to limit the possible hostnames to something like
"sandstorm-[a-z0-9]{32}.department.tu-darmstadt.de" with a RPZ rule?
- Would DNSSEC still be possible?
Even so I read a lot about RPZ in this mailinglist I never used it myself so
far. But I will start my investigation now.
Thank you, Tore
--
Tore Stelzner
Technische Universität Darmstadt, Kommunikationssysteme
Hochschulrechenzentrum, Hochschulstr. 1, 64289 Darmstadt
Tel. +49 6151 16-71037, Fax +49 6151 16-71188, http://www.hrz.tu-darmstadt.de
___
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: Wildcard prefix
Matus You are correct, I am coffee deprived. That direction was for an internal testing only/development goal. On Thu, Apr 12, 2018 at 12:18 PM, Matus UHLAR - fantomas wrote: > > On 12.04.18 12:14, Andrew Latham wrote: >> >> As long as your zone file is correct you can use *. (Note: Asterisk and >> Dot) to match all entries. I would put this below any other required >> entries. >> Example: >> """ >> $ORIGIN mydomain.com. >> *. IN A 192.168.12.12 >> """ > > > this should complain about out of zone data. > why do you say there's a dot needed? > > > -- > 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. > I feel like I'm diagonally parked in a parallel universe. ___ > > 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 -- - Andrew "lathama" Latham - ___ 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: Wildcard prefix
On 12.04.18 12:14, Andrew Latham wrote: As long as your zone file is correct you can use *. (Note: Asterisk and Dot) to match all entries. I would put this below any other required entries. Example: """ $ORIGIN mydomain.com. *. IN A 192.168.12.12 """ this should complain about out of zone data. why do you say there's a dot needed? -- 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. I feel like I'm diagonally parked in a parallel universe. ___ 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: Wildcard prefix
Andrew As long as your zone file is correct you can use *. (Note: Asterisk and Dot) to match all entries. I would put this below any other required entries. Example: """ $ORIGIN mydomain.com. *. IN A 192.168.12.12 """ On Thu, Apr 12, 2018 at 10:49 AM, Hardy, Andrew wrote: > > Does bind support wildcard prefix > > I want to install bind DNS server on my LAN to locally test a web application that is designed to support receiving requests on different url domain prefixes. > > Map *.mydomain.com to > For example 192.168.12.12 > > Use > abc.mydomain.com > def.mydomain.com > www.mydomain.com > etc > > All arrive at http server on 192.168.12.12 > > Hope that makes sense > > This is my primary need so I don't want to install if this is not my best option. > > Many thanks. > > ___ > 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 > -- - Andrew "lathama" Latham - ___ 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: Wildcard prefix
Perfect! Thank you so much. Yes I know http is not really relevant, but I was just kind of providing some kind of (unnecessary) context. Thank you again. Will try the install soon. 😊 On Thu, Apr 12, 2018, 17:21 Matus UHLAR - fantomas wrote: > On 12.04.18 16:11, Andrew Hardy wrote: > >Does bind support wildcard prefix > > > >I want to install bind DNS server on my LAN to locally test a web > >application that is designed to support receiving requests on different > url > >domain prefixes. > > > >Map *.mydomain.com to > >For example 192.168.12.12 > > *.mydomain.com. IN A 192.168.12.12 > > >Use > >abc.mydomain.com > >def.mydomain.com > >www.mydomain.com > >etc > > > >All arrive at http server on 192.168.12.12 > > bind does not care about HTTP. BIND will point A records to your IP but > that's all. > > Note that wildcard DNS has caveats, e.g. it only applies to otherwise > non-existent records, not to any existent, so if you e.g. define > > abc.mydomain.comMX ... > www.def.mydomain.comA ... > > then the *.mydomain.com will NOT apply to abc.mydomain.com > some more info at https://en.wikipedia.org/wiki/Wildcard_DNS_record > > >This is my primary need so I don't want to install if this is not my best > >option. > > -- > 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. > 42.7 percent of all statistics are made up on the spot. > ___ > 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: Wildcard prefix
On 12.04.18 16:11, Andrew Hardy wrote: Does bind support wildcard prefix I want to install bind DNS server on my LAN to locally test a web application that is designed to support receiving requests on different url domain prefixes. Map *.mydomain.com to For example 192.168.12.12 *.mydomain.com. IN A 192.168.12.12 Use abc.mydomain.com def.mydomain.com www.mydomain.com etc All arrive at http server on 192.168.12.12 bind does not care about HTTP. BIND will point A records to your IP but that's all. Note that wildcard DNS has caveats, e.g. it only applies to otherwise non-existent records, not to any existent, so if you e.g. define abc.mydomain.comMX ... www.def.mydomain.comA ... then the *.mydomain.com will NOT apply to abc.mydomain.com some more info at https://en.wikipedia.org/wiki/Wildcard_DNS_record This is my primary need so I don't want to install if this is not my best option. -- 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. 42.7 percent of all statistics are made up on the spot. ___ 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
Wildcard prefix
I am so so sorry, This is my final attempt to send this from the correct (subscribed) email address. I am having problems with my email client selecting the correct "from" address. So sorry. ... Here's the question: Does bind support wildcard prefix I want to install bind DNS server on my LAN to locally test a web application that is designed to support receiving requests on different url domain prefixes. Map *.mydomain.com to For example 192.168.12.12 Use abc.mydomain.com def.mydomain.com www.mydomain.com etc All arrive at http server on 192.168.12.12 Hope that makes sense This is my primary need so I don't want to install if this is not my best option. Many thanks. ___ 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
Wildcard prefix
Does bind support wildcard prefix I want to install bind DNS server on my LAN to locally test a web application that is designed to support receiving requests on different url domain prefixes. Map *.mydomain.com to For example 192.168.12.12 Use abc.mydomain.com def.mydomain.com www.mydomain.com etc All arrive at http server on 192.168.12.12 Hope that makes sense This is my primary need so I don't want to install if this is not my best option. Many thanks. ___ 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: Wildcard DNS records
Hello Stefano, Chiesa, Stefano writes: > Hello all. > I manage several BIND 9.10.4-P8 servers with more of less 600 DNS zones. > Anyway I never used wildcard DNS record and I hope you can help me to > understand. > > The need is: > * I have a dns zone i.e. example.com > * this zone will have an unknown number of sub domains, let's say > siteA.example.com, siteB.example.com, siteC.example.com with other record > inside > > I need to know if it is possible create an A record valid for all the sub > domains, WWW for instance. > > I thought that a record like this: > www.* IN A 1.2.3.4 > > could work and if I'd query www.siteA.example.com it would return 1.2.3.4 ... > but it does not work. > > Can you tell me if it is possible and how? I've did a webinar for Men & Mice a while ago explaining DNS wildcards and their limits. Video and Slides are online: <https://www.menandmice.com/resources/webinar-dns-wildcards-demystified/> Slides: <https://de.slideshare.net/MenandMice/dns-wildcards-webinar-april-2014> > I thought that a record like this: > www.* IN A 1.2.3.4 DNS Wildcards only work on the leftmost label, not "inside" a domain name. See also RFC 4592 for a good discussion on DNS wildcards. Best regards Carsten ___ 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
Wildcard DNS records
Hello all. I manage several BIND 9.10.4-P8 servers with more of less 600 DNS zones. Anyway I never used wildcard DNS record and I hope you can help me to understand. The need is: * I have a dns zone i.e. example.com * this zone will have an unknown number of sub domains, let's say siteA.example.com, siteB.example.com, siteC.example.com with other record inside I need to know if it is possible create an A record valid for all the sub domains, WWW for instance. I thought that a record like this: www.* IN A 1.2.3.4 could work and if I'd query www.siteA.example.com it would return 1.2.3.4 ... but it does not work. Can you tell me if it is possible and how? Thanks in advance. Stefano. Stefano Chiesa | NTT DATA Italia Viale Cassala, 14/A - 20143 Milano, Italia | M: +39 337 1534214 | stefano.chi...@nttdata.com | Learn more at www.nttdata.com/it __ Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding. ___ 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: wildcard not working after record deleted
On Tue, Jun 20, 2017 at 11:29:27PM +0100, Cathy Almond wrote: > On 20/06/2017 14:17, Maria Iano wrote: > > As has been explained already, no answer, no error means that the name > exists, but not an RRset of the type you queried for. > > Since the ANY query also comes back empty, you've probably got a > situation something like this in the zone: > > sample7200IN A 192.0.2.53 > child.sample 7200IN A 192.0.2.54 > * 7200IN A 192.0.2.101 > > If you delete the 'sample' RR, the wildcard will still not match any > queries for sample. This is because the existence of 'child.sample' > means that 'sample' also exists, even though it has no RRsets of any type. > > 'sample' in this case is what's called an 'Empty Non-Terminal'. > > Does this scenario explain what you are seeing? > > Cathy Yes it does, that is exactly what was happening and we are in good shape now. I was able to explain to the users and they plan to delete the child records. I did recommend to them that they not use wildcard records, but they continue to need them. Thank you for the detailed explanation! Maria ___ 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: wildcard not working after record deleted
On 20/06/2017 14:17, Maria Iano wrote: > On Mon, Jun 19, 2017 at 09:08:33PM -0500, /dev/rob0 wrote: >> On Mon, Jun 19, 2017 at 06:19:31PM -0400, Maria Iano wrote: >>> We have a group of users that need to use a wildcard record in >>> their zone. Their wildcard works in general, but they have a >>> situation where it isn't working. They had some records that they >>> deleted, and expected the wildcard to take over, but it hasn't. If >>> we query a record that doesn't exist and never has in the zone, >>> then we get the answer from the wildcard. If we query a record that >>> used to exist but was deleted and now doesn't exist, then we get no >>> answer. We don't get NXDOMAIN, we get As has been explained already, no answer, no error means that the name exists, but not an RRset of the type you queried for. Since the ANY query also comes back empty, you've probably got a situation something like this in the zone: sample 7200IN A 192.0.2.53 child.sample7200IN A 192.0.2.54 * 7200IN A 192.0.2.101 If you delete the 'sample' RR, the wildcard will still not match any queries for sample. This is because the existence of 'child.sample' means that 'sample' also exists, even though it has no RRsets of any type. 'sample' in this case is what's called an 'Empty Non-Terminal'. Does this scenario explain what you are seeing? Cathy ___ 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: wildcard not working after record deleted
On Tue, Jun 20, 2017 at 12:22:42PM -0400, wbr...@e1b.org wrote: > Can you post a copy of the zone file, changing any server names that > absolutely must be obscure? > Thank you for your help with this, and you are right, if I had sent you the edited zone file that would have revealed the cause - i.e. the subdomain records of the deleted records. I had searched for records beginning with the deleted names, and not records that were subdomains of the deleted names. Also, our secondary DNS providers hand out the wildcard record even though the subdomain records exist. Thanks! Maria ___ 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: wildcard not working after record deleted
Can you post a copy of the zone file, changing any server names that absolutely must be obscure? Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ 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: wildcard not working after record deleted
On Tue, Jun 20, 2017 at 05:39:46PM +0200, Matus UHLAR - fantomas wrote: > > note that existande of "something.sample" subdomain also means that > "sample" exists and is empty. > That's it! They have www.deletedrecord in the zone! I missed it because I was searching for deletedrecord* and not *.deletedrecord*. It didn't help that both of our secondary dns providers do hand back the wildcard answer to the query. I take it that means they are not using bind, and their implementations follow different rules for wildcards. Thank you all for your time! Maria ___ 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: wildcard not working after record deleted
On Tue, Jun 20, 2017 at 10:08:44AM -0500, Bryan Bradsby wrote: > On Tue, 2017-06-20 at 10:51 -0400, Maria Iano wrote: > > > > The queries are being directed at an authoritative server, exactly as > > you describe above. > > > > We also pay for a secondary dns provider who pulls our zones from the > > same authoritative servers of ours which have this issue. > > The wildcard works when we send the query to one of our secondary > > provider's name servers. > > > > Here is the answer from one of the secondary provider's servers: > > > > ; <<>> DiG 9.10.2-P3 <<>> @ any > > > > ;; OPT PSEUDOSECTION: > > ; EDNS: version: 0, flags:; udp: 4096 > > ;; QUESTION SECTION: > > ; IN ANY > > > > ;; ANSWER SECTION: > > 300 IN CNAME > > BIND does not allow a CNAME at the apex of the zone, some other flavors > of DNS servers allow this. At first I was really hopeful that we had our explanation, but then I realized you are talking about a CNAME for the zone itself, which we don't have. I think this was a misunderstanding because of my sloppy editing of the dig results. Replacing our zone name with example.com, our wildcard record looks like this: *.example.com. 300 IN CNAME name.cname.points.to. Here are the results of a dig query for a record that was deleted, and a dig query for a record that never existed, this time with the names again replaced (sorry) with something more helpful. $ dig @ns1.domain.com. deletedname.example.com. any ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-25.P1.el5_11.12 <<>> @ns1.domain.com. deletedname.example.com. any ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4107 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;deletedname.example.com. IN ANY ;; AUTHORITY SECTION: example.com.300 IN SOA ns1.domain.com. dnsadmin.example.com. 2017062002 1200 600 604800 300 ;; Query time: 6 msec ;; SERVER: IPofns1#53(IPofns1) ;; WHEN: Tue Jun 20 11:27:17 2017 ;; MSG SIZE rcvd: 96 $ dig @ns1.domain.com. nonexistentname.example.com. any ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-25.P1.el5_11.12 <<>> @ns1.domain.com. nonexistentname.example.com. any ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8568 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 16, ADDITIONAL: 4 ;; QUESTION SECTION: ;nonexistentname.example.com. IN ANY ;; ANSWER SECTION: nonexistentname.example.com.300 IN CNAME name.cname.points.to. ;; AUTHORITY SECTION: list of all of our NS records ;; ADDITIONAL SECTION: list of IPs of our name servers ;; Query time: 1 msec ;; SERVER: IPofns1#53(IPofns1) ;; WHEN: Tue Jun 20 11:27:26 2017 ;; MSG SIZE rcvd: 462 > > Was the wildcard changed to a CNAME in the last edit? > I just checked, and the wildcard record hasn't been changed since 2015. Thanks, Maria ___ 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
[Fwd: Re: wildcard not working after record deleted]
On Tue, 2017-06-20 at 10:51 -0400, Maria Iano wrote: BIND does not allow a CNAME at the apex of the zone, some other flavors of DNS servers allow this. Was the wildcard changed to a CNAME in the last edit? ___ 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: wildcard not working after record deleted
On Mon, Jun 19, 2017 at 09:08:33PM -0500, /dev/rob0 wrote: sample 7200IN A 192.0.2.53 sample 7200IN TXT "This is a sample." * 7200IN A 192.0.2.101 If you delete the A record, the TXT is still there, and your wildcard A record in the zone would not be used for that name. On 20.06.17 09:17, Maria Iano wrote: Thanks for your answer. There are no other records with that name in the zone, and an ANY query comes back empty but still with status of NOERROR. Unfortunately, I can't provide the query and zone data, and I do understand that prevents you from helping. I was hoping someone else had come across this at some point. note that existande of "something.sample" subdomain also means that "sample" exists and is empty. -- 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. Micro$oft random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0... ___ 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: wildcard not working after record deleted
-- At your service, Bryan Bradsby 512.936.2248 DIR/CTS/NOC-IT On Tue, 2017-06-20 at 10:51 -0400, Maria Iano wrote: > > The queries are being directed at an authoritative server, exactly as > you describe above. > > We also pay for a secondary dns provider who pulls our zones from the > same authoritative servers of ours which have this issue. > The wildcard works when we send the query to one of our secondary > provider's name servers. > > Here is the answer from one of the secondary provider's servers: > > ; <<>> DiG 9.10.2-P3 <<>> @ any > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ; IN ANY > > ;; ANSWER SECTION: > 300 IN CNAME BIND does not allow a CNAME at the apex of the zone, some other flavors of DNS servers allow this. Was the wildcard changed to a CNAME in the last edit? ___ 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: wildcard not working after record deleted
On Tue, Jun 20, 2017 at 09:37:04AM -0500, /dev/rob0 wrote: > On Tue, Jun 20, 2017 at 09:29:59AM -0500, /dev/rob0 wrote: > > On Tue, Jun 20, 2017 at 09:17:58AM -0400, Maria Iano wrote: > > > Thanks for your answer. There are no other records with that name > > > in the zone, and an ANY query comes back empty but still with > > > status of NOERROR. Unfortunately, I can't provide the query and > > > zone data, and I do understand that prevents you from helping. > > > > > > I was hoping someone else had come across this at some point. > > > > I can continue to waste our time with guesses, however. :) > > > > Have you tried directed queries to an authoritative nameserver? > > Today's guess is that you might be seeing some kind of caching > > issue. > > Today's guess retracted, I just saw your followup. :) > > > Is the authoritative nameserver BIND? > > If so, what version? You might need to file a bug report (and as of > now the bug database is entirely private; that will be changing soon, > but if you ask them, ISC will keep your bug report private.) > Good to know, we may go ahead and file a report if we can't figure this out. Thanks! Maria ___ 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: wildcard not working after record deleted
On Tue, Jun 20, 2017 at 09:29:59AM -0500, /dev/rob0 wrote: > On Tue, Jun 20, 2017 at 09:17:58AM -0400, Maria Iano wrote: > > Thanks for your answer. There are no other records with that name > > in the zone, and an ANY query comes back empty but still with > > status of NOERROR. Unfortunately, I can't provide the query and > > zone data, and I do understand that prevents you from helping. > > > > I was hoping someone else had come across this at some point. > > I can continue to waste our time with guesses, however. :) > I really appreciate that! :) > Have you tried directed queries to an authoritative nameserver? > Today's guess is that you might be seeing some kind of caching issue. > A directed query like this: > > $ dig sample.example.com. any @ > > should return the wildcard if all records at "sample.example.com" > have been removed. The queries are being directed at an authoritative server, exactly as you describe above. This issue applies to some records that were deleted on June 18th. I can't recreate it. I have deleted other records and found that the wildcard immediately takes over. As far as I can tell this only applies to the particular set of records deleted on the 18th. I'm told they were deleted in the same way we always do. We also pay for a secondary dns provider who pulls our zones from the same authoritative servers of ours which have this issue. The wildcard works when we send the query to one of our secondary provider's name servers. Here is the answer from one of the secondary provider's servers: ; <<>> DiG 9.10.2-P3 <<>> @ any ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13930 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ; IN ANY ;; ANSWER SECTION: 300 IN CNAME ;; Query time: 29 msec ;; SERVER: ;; WHEN: Tue Jun 20 10:40:18 EDT 2017 ;; MSG SIZE rcvd: 82 > > If in fact you were querying a caching resolver, is that BIND? Is > the authoritative nameserver BIND? Our servers are running bind. Thanks, Maria ___ 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: wildcard not working after record deleted
On Tue, Jun 20, 2017 at 09:29:59AM -0500, /dev/rob0 wrote: > On Tue, Jun 20, 2017 at 09:17:58AM -0400, Maria Iano wrote: > > Thanks for your answer. There are no other records with that name > > in the zone, and an ANY query comes back empty but still with > > status of NOERROR. Unfortunately, I can't provide the query and > > zone data, and I do understand that prevents you from helping. > > > > I was hoping someone else had come across this at some point. > > I can continue to waste our time with guesses, however. :) > > Have you tried directed queries to an authoritative nameserver? > Today's guess is that you might be seeing some kind of caching > issue. Today's guess retracted, I just saw your followup. :) > Is the authoritative nameserver BIND? If so, what version? You might need to file a bug report (and as of now the bug database is entirely private; that will be changing soon, but if you ask them, ISC will keep your bug report private.) Of course, if the server in question is *not* BIND, you're in the wrong place to ask. :) -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: ___ 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: wildcard not working after record deleted
On Tue, Jun 20, 2017 at 09:17:58AM -0400, Maria Iano wrote: > Thanks for your answer. There are no other records with that name > in the zone, and an ANY query comes back empty but still with > status of NOERROR. Unfortunately, I can't provide the query and > zone data, and I do understand that prevents you from helping. > > I was hoping someone else had come across this at some point. I can continue to waste our time with guesses, however. :) Have you tried directed queries to an authoritative nameserver? Today's guess is that you might be seeing some kind of caching issue. A directed query like this: $ dig sample.example.com. any @ should return the wildcard if all records at "sample.example.com" have been removed. If in fact you were querying a caching resolver, is that BIND? Is the authoritative nameserver BIND? -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: ___ 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: wildcard not working after record deleted
On Tue, Jun 20, 2017 at 10:02:04AM -0400, wbr...@e1b.org wrote: > > Thanks for your answer. There are no other records with that name in the > > zone, and an ANY query comes back empty but still with status of > > NOERROR. Unfortunately, I can't provide the query and zone data, and I > > do understand that prevents you from helping. > > Not even an SOA record? > There is an SOA record under the AUTHORITY SECTION. There is no ANSWER SECTION. Here is what comes back from a dig command, and I apologize for having to remove the names: ; <<>> DiG 9.10.2-P3 <<>> @ any ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19780 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ; IN ANY ;; AUTHORITY SECTION: 300 IN SOA 2017062002 1200 600 604800 300 ;; Query time: 59 msec ;; SERVER: ;; WHEN: Tue Jun 20 10:14:58 EDT 2017 ;; MSG SIZE rcvd: 108 That is the entire output from the dig command! Thanks, Maria ___ 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: wildcard not working after record deleted
> Thanks for your answer. There are no other records with that name in the > zone, and an ANY query comes back empty but still with status of > NOERROR. Unfortunately, I can't provide the query and zone data, and I > do understand that prevents you from helping. Not even an SOA record? Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ 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: wildcard not working after record deleted
On Mon, Jun 19, 2017 at 09:08:33PM -0500, /dev/rob0 wrote: > On Mon, Jun 19, 2017 at 06:19:31PM -0400, Maria Iano wrote: > > We have a group of users that need to use a wildcard record in > > their zone. Their wildcard works in general, but they have a > > situation where it isn't working. They had some records that they > > deleted, and expected the wildcard to take over, but it hasn't. If > > we query a record that doesn't exist and never has in the zone, > > then we get the answer from the wildcard. If we query a record that > > used to exist but was deleted and now doesn't exist, then we get no > > answer. We don't get NXDOMAIN, we get > > NXDOMAIN means there is no data of any type for the queried owner > name. > > > status: NOERROR > > > > and no answer. > > NOERROR means the query completed successfully, with no error. It > might mean in your case that there is other data with that owner > name, but no RRset of the requested type. > > IOW, when you have a TXT and A record with the same owner: > > sample7200IN A 192.0.2.53 > sample7200IN TXT "This is a sample." > * 7200IN A 192.0.2.101 > > If you delete the A record, the TXT is still there, and your wildcard > A record in the zone would not be used for that name. > > > Has anyone else come across this? > > That's the best guess I can come up with without seeing the query and > the zone data. If you need more help you will have to share that > information. Thanks for your answer. There are no other records with that name in the zone, and an ANY query comes back empty but still with status of NOERROR. Unfortunately, I can't provide the query and zone data, and I do understand that prevents you from helping. I was hoping someone else had come across this at some point. Thanks again, Maria ___ 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: wildcard not working after record deleted
On Mon, Jun 19, 2017 at 06:19:31PM -0400, Maria Iano wrote: > We have a group of users that need to use a wildcard record in > their zone. Their wildcard works in general, but they have a > situation where it isn't working. They had some records that they > deleted, and expected the wildcard to take over, but it hasn't. If > we query a record that doesn't exist and never has in the zone, > then we get the answer from the wildcard. If we query a record that > used to exist but was deleted and now doesn't exist, then we get no > answer. We don't get NXDOMAIN, we get NXDOMAIN means there is no data of any type for the queried owner name. > status: NOERROR > > and no answer. NOERROR means the query completed successfully, with no error. It might mean in your case that there is other data with that owner name, but no RRset of the requested type. IOW, when you have a TXT and A record with the same owner: sample 7200IN A 192.0.2.53 sample 7200IN TXT "This is a sample." * 7200IN A 192.0.2.101 If you delete the A record, the TXT is still there, and your wildcard A record in the zone would not be used for that name. > Has anyone else come across this? That's the best guess I can come up with without seeing the query and the zone data. If you need more help you will have to share that information. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: ___ 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
wildcard not working after record deleted
We have a group of users that need to use a wildcard record in their zone. Their wildcard works in general, but they have a situation where it isn't working. They had some records that they deleted, and expected the wildcard to take over, but it hasn't. If we query a record that doesn't exist and never has in the zone, then we get the answer from the wildcard. If we query a record that used to exist but was deleted and now doesn't exist, then we get no answer. We don't get NXDOMAIN, we get status: NOERROR and no answer. Has anyone else come across this? Thanks, Maria ___ 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: Wildcard SRV record?
Yeah, as I said in one of the other emails, I can script something
with nsupdate if necessary. I was just hoping there was a way to add a
simple record that'd take care of it all, but now I understand that
wildcards don't really work that way, so I've scripted something.
I don't have separate zones for each of the domains; rather there's a
single top level "foo" zone. A and Ptr records are added via
DHCP/rndc, and DHCP assigns "username.foo" domain names.
My approach feels a bit "hackish" to me. Now I have several hundred
CNAME records in the .foo zone, all pointing to the same SRV record.
I'll have to deal with removing old records as users are removed, and
I'll have to make sure the script runs reliably, but it works.
I appreciate the help, anyway!
-Stephen
On Mon, Oct 31, 2016 at 6:04 PM, Mark Andrews wrote:
>
> In message
>
> , Stephen Pape writes:
>> That doesn't work for me. When machine1.domain1.foo tries to look up
>> the SRV record, it queries for _vlmcs._tcp.domain1.foo. Bind doesn't
>> have that record, so it doesn't work.
>
> Well add it.
>
> If you need need change control independent of domain1.foo then get
> _vlmcs._tcp.domain1.foo delegated to you and set up a zone rather
> like this.
>
> _vlmcs._tcp.domain1.foo. 3600 SOA ...
> _vlmcs._tcp.domain1.foo. 3600 NS ...
> _vlmcs._tcp.domain1.foo. 3600 NS ...
> _vlmcs._tcp.domain1.foo. 3600 SRV ...
>
> or setup dynamic update with the right permission and use nsupdate
> to modifiy the records using SIG(0).
>
> _vlmcs._tcp.domain1.foo. 3600 KEY ...
>
> update-policy {
> grant * self * SRV KEY;
> };
>
> Which allows someone with the matching private key to update the
> SRV and KEY records for records with names which match the KEY's
> name.
>
> update-policy {
> grant * selfsub *;
> };
>
> This allows a host once a KEY record is added to update its address
> records and add SRV and other records below itself using SIG(0).
>
> If you put a key record at the zone apex you can use that to add
> KEY records for each of the hosts to let them control their own DNS
> presence.
>
> Mark
>
>> On Mon, Oct 31, 2016 at 1:08 PM, Eldridge, Rod A [ITNET]
>> wrote:
>> >
>> > Wouldn't you just need this one SRV record:
>> >
>> > _vlmcs._tcp.foo IN SRV 0 0 1688 ais-dc01.ainfosec.com.
>> >
>> > [ see https://blogs.technet.microsoft.com/odsupport/2011/11/14/how-to-disco
>> ver-office-and-windows-kms-hosts-via-dns-and-remove-unauthorized-instances/ ]
>> >
>> >
>> > --
>> > Rod Eldridge
>> > Networks & Communications
>> > IT Services, Iowa State University of Science and Technology
>> >
>> >
>> >
>> >> On Oct 31, 2016, at 11:35 AM, Stephen Pape wrote:
>> >>
>> >> Hello all,
>> >>
>> >> I have bind configured with a single TLD (.foo), and inside that are
>> >> records for a large number of subdomains (machine1.a.foo,
>> >> machine2.a.foo, machine1.b.foo, machine2.b.foo, etc.). DHCP clients
>> >> are assigned a domain based on some factors, but it might be a.foo,
>> >> b.foo, c.foo, etc.
>> >>
>> >> I'm trying to add a SRV record for everyone under .foo. I've tried:
>> >>
>> >> _vlmcs._tcp.*.foo.IN SRV 0 0 1688 ais-dc01.ainfosec.com.
>> >>
>> >> ... but it seems that wildcards don't work that way. I've tried
>> >> something similar with CNAMEs, but that didn't work either.
>> >>
>> >> What DOES work is adding a CNAME record for each and every domain that
>> >> I need. So a CNAME for _vlmcs._tcp.a.foo, _vlmcs._tcp.b.foo, etc.
>> >>
>> >> Is there a better way for me to do this, or do I have to generate a
>> >> whole lot of specific CNAME records?
>> >>
>> >> Thanks!
>> >>
>> >> -Stephen
>> >> ___
>> >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscr
>> ibe 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
> --
> 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: Wildcard SRV record?
In message
, Stephen Pape writes:
> That doesn't work for me. When machine1.domain1.foo tries to look up
> the SRV record, it queries for _vlmcs._tcp.domain1.foo. Bind doesn't
> have that record, so it doesn't work.
Well add it.
If you need need change control independent of domain1.foo then get
_vlmcs._tcp.domain1.foo delegated to you and set up a zone rather
like this.
_vlmcs._tcp.domain1.foo. 3600 SOA ...
_vlmcs._tcp.domain1.foo. 3600 NS ...
_vlmcs._tcp.domain1.foo. 3600 NS ...
_vlmcs._tcp.domain1.foo. 3600 SRV ...
or setup dynamic update with the right permission and use nsupdate
to modifiy the records using SIG(0).
_vlmcs._tcp.domain1.foo. 3600 KEY ...
update-policy {
grant * self * SRV KEY;
};
Which allows someone with the matching private key to update the
SRV and KEY records for records with names which match the KEY's
name.
update-policy {
grant * selfsub *;
};
This allows a host once a KEY record is added to update its address
records and add SRV and other records below itself using SIG(0).
If you put a key record at the zone apex you can use that to add
KEY records for each of the hosts to let them control their own DNS
presence.
Mark
> On Mon, Oct 31, 2016 at 1:08 PM, Eldridge, Rod A [ITNET]
> wrote:
> >
> > Wouldn't you just need this one SRV record:
> >
> > _vlmcs._tcp.foo IN SRV 0 0 1688 ais-dc01.ainfosec.com.
> >
> > [ see https://blogs.technet.microsoft.com/odsupport/2011/11/14/how-to-disco
> ver-office-and-windows-kms-hosts-via-dns-and-remove-unauthorized-instances/ ]
> >
> >
> > --
> > Rod Eldridge
> > Networks & Communications
> > IT Services, Iowa State University of Science and Technology
> >
> >
> >
> >> On Oct 31, 2016, at 11:35 AM, Stephen Pape wrote:
> >>
> >> Hello all,
> >>
> >> I have bind configured with a single TLD (.foo), and inside that are
> >> records for a large number of subdomains (machine1.a.foo,
> >> machine2.a.foo, machine1.b.foo, machine2.b.foo, etc.). DHCP clients
> >> are assigned a domain based on some factors, but it might be a.foo,
> >> b.foo, c.foo, etc.
> >>
> >> I'm trying to add a SRV record for everyone under .foo. I've tried:
> >>
> >> _vlmcs._tcp.*.foo.IN SRV 0 0 1688 ais-dc01.ainfosec.com.
> >>
> >> ... but it seems that wildcards don't work that way. I've tried
> >> something similar with CNAMEs, but that didn't work either.
> >>
> >> What DOES work is adding a CNAME record for each and every domain that
> >> I need. So a CNAME for _vlmcs._tcp.a.foo, _vlmcs._tcp.b.foo, etc.
> >>
> >> Is there a better way for me to do this, or do I have to generate a
> >> whole lot of specific CNAME records?
> >>
> >> Thanks!
> >>
> >> -Stephen
> >> ___
> >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscr
> ibe 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
--
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: Wildcard SRV record?
Correct, wildcards don't work that way; in fact, it would be more accurate to say that _vlmcs._tcp.*.foo. isn't a wildcard at all (it's just a DNS name that happens to have an asterisk as one of its labels). See RFC 4592. - Kevin -Original Message- From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Stephen Pape Sent: Monday, October 31, 2016 12:36 PM To: bind-users@lists.isc.org Subject: Wildcard SRV record? Hello all, I have bind configured with a single TLD (.foo), and inside that are records for a large number of subdomains (machine1.a.foo, machine2.a.foo, machine1.b.foo, machine2.b.foo, etc.). DHCP clients are assigned a domain based on some factors, but it might be a.foo, b.foo, c.foo, etc. I'm trying to add a SRV record for everyone under .foo. I've tried: _vlmcs._tcp.*.foo.IN SRV 0 0 1688 ais-dc01.ainfosec.com. ... but it seems that wildcards don't work that way. I've tried something similar with CNAMEs, but that didn't work either. What DOES work is adding a CNAME record for each and every domain that I need. So a CNAME for _vlmcs._tcp.a.foo, _vlmcs._tcp.b.foo, etc. Is there a better way for me to do this, or do I have to generate a whole lot of specific CNAME records? Thanks! -Stephen ___ 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: Wildcard SRV record?
That doesn't work for me. When machine1.domain1.foo tries to look up the SRV record, it queries for _vlmcs._tcp.domain1.foo. Bind doesn't have that record, so it doesn't work. On Mon, Oct 31, 2016 at 1:08 PM, Eldridge, Rod A [ITNET] wrote: > > Wouldn't you just need this one SRV record: > > _vlmcs._tcp.foo IN SRV 0 0 1688 ais-dc01.ainfosec.com. > > [ see > https://blogs.technet.microsoft.com/odsupport/2011/11/14/how-to-discover-office-and-windows-kms-hosts-via-dns-and-remove-unauthorized-instances/ > ] > > > -- > Rod Eldridge > Networks & Communications > IT Services, Iowa State University of Science and Technology > > > >> On Oct 31, 2016, at 11:35 AM, Stephen Pape wrote: >> >> Hello all, >> >> I have bind configured with a single TLD (.foo), and inside that are >> records for a large number of subdomains (machine1.a.foo, >> machine2.a.foo, machine1.b.foo, machine2.b.foo, etc.). DHCP clients >> are assigned a domain based on some factors, but it might be a.foo, >> b.foo, c.foo, etc. >> >> I'm trying to add a SRV record for everyone under .foo. I've tried: >> >> _vlmcs._tcp.*.foo.IN SRV 0 0 1688 ais-dc01.ainfosec.com. >> >> ... but it seems that wildcards don't work that way. I've tried >> something similar with CNAMEs, but that didn't work either. >> >> What DOES work is adding a CNAME record for each and every domain that >> I need. So a CNAME for _vlmcs._tcp.a.foo, _vlmcs._tcp.b.foo, etc. >> >> Is there a better way for me to do this, or do I have to generate a >> whole lot of specific CNAME records? >> >> Thanks! >> >> -Stephen >> ___ >> 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: Wildcard SRV record?
Wouldn't you just need this one SRV record: _vlmcs._tcp.foo IN SRV 0 0 1688 ais-dc01.ainfosec.com. [ see https://blogs.technet.microsoft.com/odsupport/2011/11/14/how-to-discover-office-and-windows-kms-hosts-via-dns-and-remove-unauthorized-instances/ ] -- Rod Eldridge Networks & Communications IT Services, Iowa State University of Science and Technology > On Oct 31, 2016, at 11:35 AM, Stephen Pape wrote: > > Hello all, > > I have bind configured with a single TLD (.foo), and inside that are > records for a large number of subdomains (machine1.a.foo, > machine2.a.foo, machine1.b.foo, machine2.b.foo, etc.). DHCP clients > are assigned a domain based on some factors, but it might be a.foo, > b.foo, c.foo, etc. > > I'm trying to add a SRV record for everyone under .foo. I've tried: > > _vlmcs._tcp.*.foo.IN SRV 0 0 1688 ais-dc01.ainfosec.com. > > ... but it seems that wildcards don't work that way. I've tried > something similar with CNAMEs, but that didn't work either. > > What DOES work is adding a CNAME record for each and every domain that > I need. So a CNAME for _vlmcs._tcp.a.foo, _vlmcs._tcp.b.foo, etc. > > Is there a better way for me to do this, or do I have to generate a > whole lot of specific CNAME records? > > Thanks! > > -Stephen > ___ > 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: Wildcard SRV record?
Thanks, but the names aren't predictable; they're usernames. I could script something with nsupdate, if necessary, but I'd rather have a simple record than have scripting/cron. On Mon, Oct 31, 2016 at 12:44 PM, Matthew Pounsett wrote: > > > On 31 October 2016 at 12:35, Stephen Pape wrote: >> >> Is there a better way for me to do this, or do I have to generate a >> whole lot of specific CNAME records? > > > If your subdomains follow a predictable pattern, then this seems like a > prime use of the $GENERATE statement. You could either use it to generate > the CNAMEs, or directly generate the SRV records themselves. > > > ___ 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: Wildcard SRV record?
On 31 October 2016 at 12:35, Stephen Pape wrote: > Is there a better way for me to do this, or do I have to generate a > whole lot of specific CNAME records? > If your subdomains follow a predictable pattern, then this seems like a prime use of the $GENERATE statement. You could either use it to generate the CNAMEs, or directly generate the SRV records themselves. ___ 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
Wildcard SRV record?
Hello all, I have bind configured with a single TLD (.foo), and inside that are records for a large number of subdomains (machine1.a.foo, machine2.a.foo, machine1.b.foo, machine2.b.foo, etc.). DHCP clients are assigned a domain based on some factors, but it might be a.foo, b.foo, c.foo, etc. I'm trying to add a SRV record for everyone under .foo. I've tried: _vlmcs._tcp.*.foo.IN SRV 0 0 1688 ais-dc01.ainfosec.com. ... but it seems that wildcards don't work that way. I've tried something similar with CNAMEs, but that didn't work either. What DOES work is adding a CNAME record for each and every domain that I need. So a CNAME for _vlmcs._tcp.a.foo, _vlmcs._tcp.b.foo, etc. Is there a better way for me to do this, or do I have to generate a whole lot of specific CNAME records? Thanks! -Stephen ___ 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: Wildcard
rams wrote: > When we have widlcard in middle labels, are we not treating as wildcard > record? In the DNS, a wildcard only occurs when the leftmost label is a *. > Do we have any specific RFC for this. https://tools.ietf.org/html/rfc4592#section-2.1 NOTE that wildcard rules can be confusingly different, in particular the rules for X.509 wildcards are incompatible with DNS wildcards except for the most simple uses. https://tools.ietf.org/html/rfc6125#section-6.4.3 Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Cromarty, Forth: Variable 3 or 4, becoming south or southwest 5 or 6. Slight or moderate. Showers. Moderate or good. ___ 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: Wildcard
Am 22.09.2016 um 14:37 schrieb rams: Greetings. When we have "something.*." with cname record, if we query domain as "something.abc." , bind is not returning answer and if i query with same name "something.*.", getting answer in bind. When we have widlcard in middle labels, are we not treating as wildcard record? Kindly share info. Do we have any specific RFC for this Google "dnf rfc wildcards" points to https://tools.ietf.org/html/rfc4592 ___ 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: Wildcard
In message , rams writes: > > Hi, > Greetings. When we have "something.*." with cname record, if we > query domain as "something.abc." , bind is not returning answer and > if i query with same name "something.*.", getting answer in bind. > When we have widlcard in middle labels, are we not treating as wildcard > record? Kindly share info. > Do we have any specific RFC for this. > > Thanks & Regards, > Ramesh That isn't how wildcard records work. something.abc. matches *. See RFC 1034 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 bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Wildcard
Hi, Greetings. When we have "something.*." with cname record, if we query domain as "something.abc." , bind is not returning answer and if i query with same name "something.*.", getting answer in bind. When we have widlcard in middle labels, are we not treating as wildcard record? Kindly share info. Do we have any specific RFC for this. Thanks & Regards, Ramesh ___ 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: Interesting behavior with wildcard domains
On Wed, Feb 24, 2016 at 12:30 PM Mark Andrews wrote: > > In message , Mathew Ian Eis > write > s: > Illegal character '-' in input file. > > Hi BIND, > > > > Ive encountered (quite by accident) an interesting behavior in BIND with > > wildcard domains: > > > > The relevant configuration is a zone; e.g. bar.com, with what Ill call a > > second level wildcard host, e.g. *.foo.bar.com A 10.10.10.5 in that > zone. > > (as opposed to what might be considered the more usual wildcard host > > record of *.bar.com). > > > > buz.foo.bar.com returns A 10.10.10.5 as expected. > > > > However, a query for foo.bar.com returns NOERR with zero results, when I > > would expect a NXDOMAIN. > > Why? If *.foo.bar.com exists then foo.bar.com, bar.com and com all exist. > > > Anyone know if the NOERR with zero results is the expected / correct > > behavior? > > It is the expected behaviour > Nah, it is the *correct* behavior, fairly clearly it is not the *expected* behavior :-P W (sorry, I'm feeling ornery today...) > > Thanks in advance, > > > > Mathew Eis > > Northern Arizona University > > Information Technology Services > > > ___ > 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: Interesting behavior with wildcard domains
This is what I was looking for - thanks! From: mailto:bind-users-boun...@lists.isc.org>> on behalf of "Darcy Kevin (FCA)" mailto:kevin.da...@fcagroup.com>> Date: Tuesday, February 23, 2016 at 4:29 PM To: "bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>" mailto:bind-users@lists.isc.org>> Subject: RE: Interesting behavior with wildcard domains See “empty non-terminal” in https://www.rfc-editor.org/rfc/rfc4592.txt. - Kevin From: bind-users-boun...@lists.isc.org<mailto:bind-users-boun...@lists.isc.org> [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Noel Butler Sent: Tuesday, February 23, 2016 6:19 PM To: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org> Subject: Re: Interesting behavior with wildcard domains On 24/02/2016 09:13, Mathew Ian Eis wrote: Hi BIND, I've encountered (quite by accident) an interesting behavior in BIND with wildcard domains: The relevant configuration is a zone; e.g. bar.com, with what I'll call a "second level" wildcard host, e.g. *.foo.bar.com A 10.10.10.5 in that zone. (as opposed to what might be considered the more usual wildcard host record of *.bar.com). buz.foo.bar.com returns A 10.10.10.5 as expected. However, a query for foo.bar.com returns NOERR with zero results, when I would expect a NXDOMAIN. Anyone know if the NOERR with zero results is the expected / correct behavior? Thanks in advance, Mathew Eis Northern Arizona University Information Technology Services It's expected, since its a * "." foo... you are asking for anything thast dot foo, your not asking for foo -- If you have the urge to reply to all rather than reply to list, you best first read http://members.ausics.net/qwerty/ ___ 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: Interesting behavior with wildcard domains
In message , Mathew Ian Eis write s: Illegal character '-' in input file. > Hi BIND, > > Ive encountered (quite by accident) an interesting behavior in BIND with > wildcard domains: > > The relevant configuration is a zone; e.g. bar.com, with what Ill call a > second level wildcard host, e.g. *.foo.bar.com A 10.10.10.5 in that zone. > (as opposed to what might be considered the more usual wildcard host > record of *.bar.com). > > buz.foo.bar.com returns A 10.10.10.5 as expected. > > However, a query for foo.bar.com returns NOERR with zero results, when I > would expect a NXDOMAIN. Why? If *.foo.bar.com exists then foo.bar.com, bar.com and com all exist. > Anyone know if the NOERR with zero results is the expected / correct > behavior? It is the expected behaviour. > Thanks in advance, > > Mathew Eis > Northern Arizona University > Information Technology Services > ___ 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: Interesting behavior with wildcard domains
See “empty non-terminal” in https://www.rfc-editor.org/rfc/rfc4592.txt. - Kevin [FCA_Pantone_email] -- Kevin Darcy NAFTA Information Security Projects FCA US LLC 1075 W Entrance Dr, Auburn Hills, MI 48326 USA Telephone: +1 (248) 838-6601 Mobile: +1 (810) 397-0103 Email: kevin.da...@fcagroup.com From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Noel Butler Sent: Tuesday, February 23, 2016 6:19 PM To: bind-users@lists.isc.org Subject: Re: Interesting behavior with wildcard domains On 24/02/2016 09:13, Mathew Ian Eis wrote: Hi BIND, I've encountered (quite by accident) an interesting behavior in BIND with wildcard domains: The relevant configuration is a zone; e.g. bar.com, with what I'll call a "second level" wildcard host, e.g. *.foo.bar.com A 10.10.10.5 in that zone. (as opposed to what might be considered the more usual wildcard host record of *.bar.com). buz.foo.bar.com returns A 10.10.10.5 as expected. However, a query for foo.bar.com returns NOERR with zero results, when I would expect a NXDOMAIN. Anyone know if the NOERR with zero results is the expected / correct behavior? Thanks in advance, Mathew Eis Northern Arizona University Information Technology Services It's expected, since its a * "." foo... you are asking for anything thast dot foo, your not asking for foo -- If you have the urge to reply to all rather than reply to list, you best first read http://members.ausics.net/qwerty/ ___ 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: Interesting behavior with wildcard domains
On 24/02/2016 09:13, Mathew Ian Eis wrote: > Hi BIND, > > I've encountered (quite by accident) an interesting behavior in BIND with > wildcard domains: > > The relevant configuration is a zone; e.g. bar.com, with what I'll call a > "second level" wildcard host, e.g. *.foo.bar.com A 10.10.10.5 in that zone. > (as opposed to what might be considered the more usual wildcard host record > of *.bar.com). > > buz.foo.bar.com returns A 10.10.10.5 as expected. > > However, a query for foo.bar.com returns NOERR with zero results, when I > would expect a NXDOMAIN. > > Anyone know if the NOERR with zero results is the expected / correct > behavior? > > Thanks in advance, > > Mathew Eis > Northern Arizona University > Information Technology Services It's expected, since its a * "." foo... you are asking for anything thast dot foo, your not asking for foo -- If you have the urge to reply to all rather than reply to list, you best first read http://members.ausics.net/qwerty/ ___ 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
Interesting behavior with wildcard domains
Hi BIND, I’ve encountered (quite by accident) an interesting behavior in BIND with wildcard domains: The relevant configuration is a zone; e.g. bar.com, with what I’ll call a “second level” wildcard host, e.g. *.foo.bar.com A 10.10.10.5 in that zone. (as opposed to what might be considered the more usual wildcard host record of *.bar.com). buz.foo.bar.com returns A 10.10.10.5 as expected. However, a query for foo.bar.com returns NOERR with zero results, when I would expect a NXDOMAIN. Anyone know if the NOERR with zero results is the expected / correct behavior? Thanks in advance, Mathew Eis Northern Arizona University Information Technology Services ___ 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
NSEC3 wildcard validation failures [was: Wrong NSEC3 for wildcard cname]
Hi Folks, I think we can wrap this up thanks to assistance from the reporting site - they're running BIND 9.8.1-P1 (stock package in Ubuntu 12.04 LTS). This means they don't have the following fix, which appeared in 9.8.2b1. 3175. [bug] Fix how DNSSEC positive wildcard responses from a NSEC3 signed zone are validated. Stop sending a unnecessary NSEC3 record when generating such responses. [RT #26200] I can recreate the problem with a validating resolver running 9.8.1-P1 (Ubuntu 12.04), and the problem is not present using 9.8.2rc1 (stock package in CentOS 6), so I'm fairly sure it's this bug. (For posterity, validation fails with "validating @0x7f4b44014fe0: foo.cnametest.lancs.ac.uk A: noqname proof not found", whilst "validating @0x7f2b3c0008b0: foo.cnametest.lancs.ac.uk A: closest encloser from wildcard signature 'cnametest.lancs.ac.uk'" is *not* logged) The stock Ubuntu configuration is to enable validation (this is good), unfortunately 12.04 LTS is supposedly being (security?) supported into 2017, so it could be quite a while before sites (even the ones who perform package updates regularly) advance into a situation of being able to resolve our wildcard entries. The most recent Ubuntu LTS (14.04) is not affected. I have logged an Ubuntu bug[1] to request this fix is 'back ported' into 12.04. To give a sizing hint on the probabilistic risk of being affected, lancs.ac.uk (an affected zone) has ~50,000 unique owner names, whilst palatine.ac.uk (unaffected), has ~10. We signed lancs.ac.uk in early/mid September, and this is the first real report of DNSSEC-related issues I've seen. > delv +vtrace continues to report "NSEC3 at super-domain" only for > foo.cnametest2.palatine.ac.uk <http://foo.cnametest2.palatine.ac.uk> > records, and not for > foo.cnametest2.lancs.ac.uk <http://foo.cnametest2.lancs.ac.uk>. Is > this a similar > miscalculating-the-owner-name as for DNSViz? > > > Don't know, but I would guess that this is simply recognizing the fact > that in addition to covering the non-existent name, the NSEC3 record > also happens to correspond to palatine.ac.uk <http://palatine.ac.uk>. delv reports the validation as succeeding, so after further reflection I believe this additional message is merely a helpful (?to whom?) diagnostic. Unfortunately there's no obvious (to me, at least) distinction between 'debug', 'interesting' and 'this is where it's gone wrong' log levels in delv +vtrace's output (but I'm not really complaining that much). Graham [1] https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1395216 ___ 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: Wrong NSEC3 for wildcard cname
On Wed, Nov 19, 2014 at 7:03 PM, Graham Clinch wrote: > Thanks - that's certainly looking less red. DNSViz is an exceptionally > useful tool! > > Thanks! > ... > > delv +vtrace continues to report "NSEC3 at super-domain" only for > foo.cnametest2.palatine.ac.uk records, and not for > foo.cnametest2.lancs.ac.uk. Is this a similar > miscalculating-the-owner-name as for DNSViz? Don't know, but I would guess that this is simply recognizing the fact that in addition to covering the non-existent name, the NSEC3 record also happens to correspond to palatine.ac.uk. I think this might be one of those cases where I should have trusted my > gut instinct (to blame the validating resolver), but the more I > investigated the more red and missing lines in output... > What version is your validating resolver? For example, there are some earlier versions of BIND that required that inclusion of the closest encloser NSEC3, even though the closest encloser could be derived from the RRSIG covering the wildcard. As such, they would fail validation when the authoritative server didn't send that (normally unnecessary) record. At the start of the year, I received a piece of wisdom regarding NSEC3 > "It is much harder to understand and debug". At the time I was sure > that I could outsmart it. Maybe not so much now. > Join the crowd :) There is probably a local NSEC3 support group in your area. Casey ___ 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: Re: Wrong NSEC3 for wildcard cname
On 19-Nov-14 19:03, Graham Clinch wrote: > Hi Casey & List folks, >> My apologies - this was actually a bug in DNSViz. The NSEC3 computation >> was being performed on the wrong name (the wrong origin was being >> applied). It should be fixed now, as shown in: >> >> http://dnsviz.net/d/foo.cnametest.lancs.ac.uk/VGzlkA/dnssec/ >> http://dnsviz.net/d/foo.cnametest.palatine.ac.uk/VGzrqg/dnssec/ > Thanks - that's certainly looking less red. DNSViz is an exceptionally > useful tool! > > The cnametest records were an attempt at simplifying a real issue that's > been reported to us. > > An unsimplified version is cnametest2.lancs.ac.uk (here the RR is > *.cnametest2 CNAME cnametest2, with an A RR for cnametest2), which (now) > passes DNSViz, but not Verisign's DNSSEC debugger > (http://dnssec-debugger.verisignlabs.com/foo.cnametest2.lancs.ac.uk). > > I'm more confident that this is a bug in Verisign's debugger, as the > error is 'No DS records found for cnametest2.lancs.ac.uk in the > cnametest2.lancs.ac zone' (where's the .uk gone, and why the interest in > a DS where there's no zone cut?). Do any Verisign DNSSEC debugger > maintainers lurk on bind-users? (The 'Contact Us' link on the page > looks very corporate and not very useful) Try the dnssec-deployment mailing list. dnssec-deploym...@dnssec-deployment.org > delv +vtrace continues to report "NSEC3 at super-domain" only for > foo.cnametest2.palatine.ac.uk records, and not for > foo.cnametest2.lancs.ac.uk. Is this a similar > miscalculating-the-owner-name as for DNSViz? I'll try to dig (haha!) > into the delv source tomorrow. Tested with delv 9.10.0 & 9.10.1. > > I think this might be one of those cases where I should have trusted my > gut instinct (to blame the validating resolver), but the more I > investigated the more red and missing lines in output... > > I'm attempting to discover more about the validating resolver, but since > I have no access to it and the reporter is just a user of that resolver, > odds are not stacked in our favour. > >> *snipping the bits where I obviously need to read about >> NSEC3 again* > At the start of the year, I received a piece of wisdom regarding NSEC3 > "It is much harder to understand and debug". At the time I was sure > that I could outsmart it. Maybe not so much now. > > Regards, > > Graham > > smime.p7s Description: S/MIME Cryptographic Signature ___ 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: Wrong NSEC3 for wildcard cname
Hi Casey & List folks, > My apologies - this was actually a bug in DNSViz. The NSEC3 computation > was being performed on the wrong name (the wrong origin was being > applied). It should be fixed now, as shown in: > > http://dnsviz.net/d/foo.cnametest.lancs.ac.uk/VGzlkA/dnssec/ > http://dnsviz.net/d/foo.cnametest.palatine.ac.uk/VGzrqg/dnssec/ Thanks - that's certainly looking less red. DNSViz is an exceptionally useful tool! The cnametest records were an attempt at simplifying a real issue that's been reported to us. An unsimplified version is cnametest2.lancs.ac.uk (here the RR is *.cnametest2 CNAME cnametest2, with an A RR for cnametest2), which (now) passes DNSViz, but not Verisign's DNSSEC debugger (http://dnssec-debugger.verisignlabs.com/foo.cnametest2.lancs.ac.uk). I'm more confident that this is a bug in Verisign's debugger, as the error is 'No DS records found for cnametest2.lancs.ac.uk in the cnametest2.lancs.ac zone' (where's the .uk gone, and why the interest in a DS where there's no zone cut?). Do any Verisign DNSSEC debugger maintainers lurk on bind-users? (The 'Contact Us' link on the page looks very corporate and not very useful) delv +vtrace continues to report "NSEC3 at super-domain" only for foo.cnametest2.palatine.ac.uk records, and not for foo.cnametest2.lancs.ac.uk. Is this a similar miscalculating-the-owner-name as for DNSViz? I'll try to dig (haha!) into the delv source tomorrow. Tested with delv 9.10.0 & 9.10.1. I think this might be one of those cases where I should have trusted my gut instinct (to blame the validating resolver), but the more I investigated the more red and missing lines in output... I'm attempting to discover more about the validating resolver, but since I have no access to it and the reporter is just a user of that resolver, odds are not stacked in our favour. > *snipping the bits where I obviously need to read about > NSEC3 again* At the start of the year, I received a piece of wisdom regarding NSEC3 "It is much harder to understand and debug". At the time I was sure that I could outsmart it. Maybe not so much now. Regards, Graham ___ 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: Wrong NSEC3 for wildcard cname
Hi Graham, On Wed, Nov 19, 2014 at 11:59 AM, Graham Clinch wrote: > Using bind 9.9.5 with inline-signing, I have a test wildcard cname > record in two zones: > > *.cnametest.lancs.ac.uk CNAME www.lancs.ac.uk > *.cnametest.palatine.ac.uk CNAME www.palatine.ac.uk > > dnsviz is showing the error > "NSEC3 proving non-existence of foo.cnametest.lancs.ac.uk./CNAME: > QNAME_NOT_COVERED" > for the lancs.ac.uk version (but the palatine.ac.uk version is fine). > > My apologies - this was actually a bug in DNSViz. The NSEC3 computation was being performed on the wrong name (the wrong origin was being applied). It should be fixed now, as shown in: http://dnsviz.net/d/foo.cnametest.lancs.ac.uk/VGzlkA/dnssec/ http://dnsviz.net/d/foo.cnametest.palatine.ac.uk/VGzrqg/dnssec/ > ... > For palatine.ac.uk: > > AEP7P2GGD4GEBNRMSBP4I97SU0MKR5R9.palatine.ac.uk. 3600 IN NSEC3 1 0 10 > BB1150B39E44B92F E92VAEN6BQ1T2N54AA2RSA1V49RM394S > > (AEP... is the hash of cnametest.palatine.ac.uk) > > Yes, but more importantly it happens to be the owner name of the NSEC3 record that covers the NSEC3 hash of the next closest encloser ( foo.cnametest.palatine.ac.uk, whose hash starts with E8T9...). The fact that it also matches the NSEC3 hash of the closest encloser ( cnametest.palatine.ac.uk) is coincidental (and also probabilistic, depending on the size of the zone). > > For lancs.ac.uk: > > RA9FSQ8NSK36A6568UHF8L26UFV2B1PG.lancs.ac.uk. 3600 IN NSEC3 1 0 10 > 9B6EFFBA177399A0 RA9V2QS7NE6Q5VLKU2EF4QONHP5CGIJR A RRSIG > > (RA9... isn't the hash of cnametest.lancs.ac.uk, and it's claiming there > are A and RRSIG records!?). > Correct - this is the hash of some other record, the record that covers the hash of the next closest encloser (foo.cnametest.lancs.ac.uk). The hash of the closest encloser is not necessary as this is for a wildcard response, and the closest encloser (cnametest.lancs.ac.uk) can be inferred from the labels field in the RRSIG. In this case, the number of labels (i.e., in the RRSIG) is 4, so the closest encloser is cnametest.lancs.ac.uk. > > Both cnametest records were added today, so the signature inception time > of the lancs.ac.uk NSEC3's RRSIG being yesterday (20141118125729), is > very odd... > Again, the NSEC3 in question corresponds to some other (most likely) preexisting name, so it is not surprising that the inception date on its RRSIG is older than today. > > What's going on? Both zones are being signed by the same instance of > bind and there are no interesting log messages. > Hope that helps. Cheers, Casey ___ 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
Wrong NSEC3 for wildcard cname
Hello list (and this time it's not the DHCP list...), Using bind 9.9.5 with inline-signing, I have a test wildcard cname record in two zones: *.cnametest.lancs.ac.uk CNAME www.lancs.ac.uk *.cnametest.palatine.ac.uk CNAME www.palatine.ac.uk dnsviz is showing the error "NSEC3 proving non-existence of foo.cnametest.lancs.ac.uk./CNAME: QNAME_NOT_COVERED" for the lancs.ac.uk version (but the palatine.ac.uk version is fine). According to delv, both are fully validated, but the palatine output has one extra line: ;; validating foo.cnametest.palatine.ac.uk/A: NSEC3 at super-domain cnametest.palatine.ac.uk I can see a discrepancy in the NSEC3 records in the Authority section: For palatine.ac.uk: AEP7P2GGD4GEBNRMSBP4I97SU0MKR5R9.palatine.ac.uk. 3600 IN NSEC3 1 0 10 BB1150B39E44B92F E92VAEN6BQ1T2N54AA2RSA1V49RM394S (AEP... is the hash of cnametest.palatine.ac.uk) For lancs.ac.uk: RA9FSQ8NSK36A6568UHF8L26UFV2B1PG.lancs.ac.uk. 3600 IN NSEC3 1 0 10 9B6EFFBA177399A0 RA9V2QS7NE6Q5VLKU2EF4QONHP5CGIJR A RRSIG (RA9... isn't the hash of cnametest.lancs.ac.uk, and it's claiming there are A and RRSIG records!?). Both cnametest records were added today, so the signature inception time of the lancs.ac.uk NSEC3's RRSIG being yesterday (20141118125729), is very odd... What's going on? Both zones are being signed by the same instance of bind and there are no interesting log messages. Thanks, Graham -- Graham Clinch Systems Programmer, Lancaster University ___ 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: Wildcard oddity
On Mon, Sep 29, 2014 at 08:52:41PM -0700, Ronald F. Guilmette wrote: > *.colors IN A 127.0.0.2 > *.jason.purple.colors IN A 127.0.0.3 > ; *.purple.colors IN A 127.0.0.4 > === > > Note that that last line is commented out. > > Curiously, when I do this query: > >dig simon.purple.colors.test0.tristatelogic.com > > I get back NXDOMAIN. Why? > > Intutively I would have thought that this query would have been matched > by "*.colors", but the presence of jason seems to be throwing a monkey > wrench into the works for simon! See RFC 1034 section 4.3.3: Wildcard RRs do not apply: - When the query name or a name between the wildcard domain and the query name is know to exist. For example, if a wildcard RR has an owner name of "*.X", and the zone also contains RRs attached to B.X, the wildcards would apply to queries for name Z.X (presuming there is no explicit information for Z.X), but not to B.X, A.B.X, or X. Also see RFC 4592 section 2.2.2 (empty non-terminals) which would apply above and make purple.colors.test0.tristatelogic.com "exist". Mukund pgpLT8asSUKv0.pgp Description: PGP signature ___ 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: Wildcard oddity
In message <20703.1412049...@server1.tristatelogic.com>, "Ronald F. Guilmette" writes: > > > My apologies for my earlier, arguably off-topic questions. > > Now I have a real honest-to-goodness BIND question. > > I have the following simple zone file installed as "test0.tristatelogic.com": > > === > $TTL 3600 > @ IN SOA server1.tristatelogic.com. hostmaster.tristatelogic.c > om. ( > 1412047583 10800 3600 604800 3600 ) > IN NS server1.tristatelogic.com. > > *.colors IN A 127.0.0.2 > *.jason.purple.colors IN A 127.0.0.3 > ; *.purple.colors IN A 127.0.0.4 > === > > Note that that last line is commented out. > > Curiously, when I do this query: > >dig simon.purple.colors.test0.tristatelogic.com > > I get back NXDOMAIN. Why? Because that is how wildcard processing works. Go read RFC 1034, Section 4.3.2. Algorithm. Note the words "label by label". Does the label colors exist? Does the label purple exist? Does the label simon exist? Does the label "*" exist? Mark > Intutively I would have thought that this query would have been matched > by "*.colors", but the presence of jason seems to be throwing a monkey > wrench into the works for simon! > > It is also rather perplexing that when I uncomment that final line, > then things seem to work as expected, i.e. the dig shown above then > matches _that_ record, and I get back 127.0.0.4 (which is indeed > what intutively _should_ happen). > > There must be something quirky about the wildcard matching rules that > I'm not understanding. Why do these two rules cause something (i.e. > anything) within the colors subdomain to *not* resolve? > > *.colors IN A 127.0.0.2 > *.jason.purple.colors IN A 127.0.0.3 > > ___ > 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
Wildcard oddity
My apologies for my earlier, arguably off-topic questions. Now I have a real honest-to-goodness BIND question. I have the following simple zone file installed as "test0.tristatelogic.com": === $TTL 3600 @ IN SOA server1.tristatelogic.com. hostmaster.tristatelogic.com. ( 1412047583 10800 3600 604800 3600 ) IN NS server1.tristatelogic.com. *.colors IN A 127.0.0.2 *.jason.purple.colors IN A 127.0.0.3 ; *.purple.colors IN A 127.0.0.4 === Note that that last line is commented out. Curiously, when I do this query: dig simon.purple.colors.test0.tristatelogic.com I get back NXDOMAIN. Why? Intutively I would have thought that this query would have been matched by "*.colors", but the presence of jason seems to be throwing a monkey wrench into the works for simon! It is also rather perplexing that when I uncomment that final line, then things seem to work as expected, i.e. the dig shown above then matches _that_ record, and I get back 127.0.0.4 (which is indeed what intutively _should_ happen). There must be something quirky about the wildcard matching rules that I'm not understanding. Why do these two rules cause something (i.e. anything) within the colors subdomain to *not* resolve? *.colors IN A 127.0.0.2 *.jason.purple.colors IN A 127.0.0.3 ___ 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: BUG? Wildcard lookup masked by more specific record of alternative type
On 14 February 2014 12:01, Tony Finch wrote: > Terry Burton wrote: >> Is the following expected or is it a bug? > > It is correct. See RFC 4592 for the full explanation of how wildcards work. For sake of Google... RFC 4592 3.3.1 defines "The closest encloser is the node in the zone's tree of existing domain names that has the most labels matching the query name ... The source of synthesis is defined in the context of a query process as that wildcard domain name immediately descending from the closest encloser." Adding the TSLA record for _443._tcp.test.domain amended the closest encounter for the query from "domain" to the "test.domain" empty non-terminal, hence no synthesis. ___ 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: BUG? Wildcard lookup masked by more specific record of alternative type
Terry Burton wrote: > > Is the following expected or is it a bug? It is correct. See RFC 4592 for the full explanation of how wildcards work. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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
BUG? Wildcard lookup masked by more specific record of alternative type
Hi, Is the following expected or is it a bug? All the best, Terry ; This wildcard allows the lookup of "test.domain A": ; *.domain IN A 1.2.3.4 ; ; This TLSA record breaks the lookup of "test.domain A": ; _443._tcp.test.domain IN TLSA 1 0 1 83cfeec8dbe315e9f93e9ec87beda3619033876f1f96729c9939964961f6aa9c ; ; Workaround: Adding a specific record restores the lookup of "test.domain A": ; ;test.domain IN A 1.2.3.4 ___ 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: Unexpected wildcard matching
ip admin wrote: > > Any idea why the wildcard matching is affected by the individual > levels/labels of > hello.test.com? See RFC 4592 "The Role of Wildcards in the Domain Name System", section 2.2 "Existence Rules" and especially 2.2.2 "Empty Non-terminals": 2.2. Existence Rules The notion that a domain name 'exists' is mentioned in the definition of wildcards. In section 4.3.3 of RFC 1034: # Wildcard RRs do not apply: # ... # - When the query name or a name between the wildcard domain and # the query name is know[n] to exist. . . . "Existence" is therefore an important concept in the understanding of wildcards. Unfortunately, the definition of what exists, in RFC 1034, is unclear. So, in sections 2.2.2. and 2.2.3, another look is taken at the definition of existence. 2.2.2. Empty Non-terminals Empty non-terminals [RFC2136, section 7.16] are domain names that own no resource records but have subdomains that do. In section 2.2.1, "_tcp.host1.example." is an example of an empty non-terminal name. Empty non-terminals are introduced by this text in section 3.1 of RFC 1034: # The domain name space is a tree structure. Each node and leaf on # the tree corresponds to a resource set (which may be empty). The # domain system makes no distinctions between the uses of the # interior nodes and leaves, and this memo uses the term "node" to # refer to both. The parenthesized "which may be empty" specifies that empty non- terminals are explicitly recognized and that empty non-terminals "exist". Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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
Unexpected wildcard matching
Hello, I want to have a dummy (internal) root NS to resolve specific name hello.test.com to 4.5.6.7, everything else to 1.2.3.4. Using a wildcard does not work as expected (by me), though. 1st attempt: # cat db.root $TTL 86400 @ IN SOA ns1.root.internal. dnsadmin.root.internal. 1 21600 3600 604800 600 IN NS ns1.root.internal. * IN A 1.2.3.4 hello.test.com. IN A 4.5.6.7 # dig +short @localhost hello.test.com 4.5.6.7 # dig +short @localhost hello.test.net 1.2.3.4 # dig +short @localhost other.test.com # dig +short @localhost other.test-it.com # dig +short @localhost other.test.org 1.2.3.4 # dig +short @localhost other.test.net 1.2.3.4 Result: returns NXDOMAIN for anything ending in .com - probably because of hello.test.com! 2nd attempt: # cat db.root $TTL 86400 @ IN SOA ns1.root.internal. dnsadmin.root.internal. 1 21600 3600 604800 600 IN NS ns1.root.internal. * IN A 1.2.3.4 *.com. IN A 1.2.3.4 hello.test.com. IN A 4.5.6.7 # dig +short @localhost hello.test.com 4.5.6.7 # dig +short @localhost hello.test.net 1.2.3.4 # dig +short @localhost other.test.com # dig +short @localhost other.com 1.2.3.4 Result: returns NXDOMAIN for anything matching label1.label2.com, works for label1.com however. Again existing entry for hello.test.com seems to override wildcards in an unexcpected way. 3rd attempt: # cat db.root $TTL 86400 @ IN SOA ns1.root.internal. dnsadmin.root.internal. 1 21600 3600 604800 600 IN NS ns1.root.internal. * IN A 1.2.3.4 *.com. IN A 1.2.3.4 *.test.com. IN A 1.2.3.4 hello.test.com. IN A 4.5.6.7 # dig +short @localhost hello.test.com 4.5.6.7 # dig +short @localhost hello.test.net 1.2.3.4 # dig +short @localhost other.test.com 1.2.3.4 # dig +short @localhost other.test-it.com 1.2.3.4 # dig +short @localhost other.test.org 1.2.3.4 # dig +short @localhost other.test.net 1.2.3.4 Result: finally what I wanted Any idea why the wildcard matching is affected by the individual levels/labels of hello.test.com? If multiple enties exist in addition to the wildcard the strange behaviour applies to them as well, e.g. I need: # cat db.root $TTL 86400 @ IN SOA ns1.root.internal. dnsadmin.root.internal. 1 21600 3600 604800 600 IN NS ns1.root.internal. * IN A 1.2.3.4 *.com. IN A 1.2.3.4 *.test.com. IN A 1.2.3.4 hello.test.com. IN A 4.5.6.7 *.bar.INA1.2.3.4 *.foo.bar.INA1.2.3.4 hello.foo.bar. IN A 8.9.10.11 to resolve specific names hello.test.com and hello.foo.bar to their respective IPs and everything else to 1.2.3.4. (DNS-Server version happens to be BIND 9.7.4-P1) Regards 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: Wildcard CNAME record?
Matus UHLAR - fantomas wrote: On 16.01.13 14:57, Baird, Josh wrote: > Is it acceptable to have a wildcard CNAME? Example: > > * IN CNAMEsomewhere.com. > > Or, would it be advised to only use wildcard 'A' records? while it is technically valid, I don't think it's acceptable to use solutions that require wildcards ;-) On 16.01.13 15:16, Tony Finch wrote: RFC 4592 is enlightening in a rather unpleasant manner. yes, very unpleasant. I read that more than once and was repeatedly not able to fully understand 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. I don't have lysdexia. The Dog wouldn't allow that. ___ 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: Wildcard CNAME record?
On Wed, Jan 16, 2013 at 10:33:03AM -0500, Barry Margolin wrote: > In article , > Oliver Peter wrote: > > > On Wed, Jan 16, 2013 at 02:57:48PM +, Baird, Josh wrote: > > > Is it acceptable to have a wildcard CNAME? Example: > > > > > > * IN CNAMEsomewhere.com. > > > > > > Or, would it be advised to only use wildcard 'A' records? > > > > Not valid since there should be SOA and NS records for somewhere.com, > > the CNAME would conflict with them. > > But wildcards only synthesize records that are actually queried for. If > no one ever asks for these SOA and NS records, the conflicts will never > occur. They're the DNS equivalent of trees falling in a forest. Gah, mixed it up, was thinking the other way round. Sorry. -- Oliver PETER oli...@opdns.de 0x456D688F "You need healthy, natural sleep. Chew some Valerian root and get more exercise." signature.asc Description: Digital signature ___ 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: Wildcard CNAME record?
In article , Oliver Peter wrote: > On Wed, Jan 16, 2013 at 02:57:48PM +, Baird, Josh wrote: > > Is it acceptable to have a wildcard CNAME? Example: > > > > * IN CNAMEsomewhere.com. > > > > Or, would it be advised to only use wildcard 'A' records? > > Not valid since there should be SOA and NS records for somewhere.com, > the CNAME would conflict with them. But wildcards only synthesize records that are actually queried for. If no one ever asks for these SOA and NS records, the conflicts will never occur. They're the DNS equivalent of trees falling in a forest. -- Barry Margolin Arlington, MA ___ 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: Wildcard CNAME record?
On Wed, Jan 16, 2013 at 02:57:48PM +, Baird, Josh wrote: > Is it acceptable to have a wildcard CNAME? Example: > > * IN CNAMEsomewhere.com. > > Or, would it be advised to only use wildcard 'A' records? Not valid since there should be SOA and NS records for somewhere.com, the CNAME would conflict with them. This should be OK: * IN CNAMEsub.somewhere.com. Cheers ~ollie -- Oliver PETER oli...@opdns.de 0x456D688F "You need healthy, natural sleep. Chew some Valerian root and get more exercise." signature.asc Description: Digital signature ___ 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: Wildcard CNAME record?
Matus UHLAR - fantomas wrote: > On 16.01.13 14:57, Baird, Josh wrote: > > Is it acceptable to have a wildcard CNAME? Example: > > > > * IN CNAMEsomewhere.com. > > > > Or, would it be advised to only use wildcard 'A' records? > > while it is technically valid, I don't think it's acceptable to use solutions > that require wildcards ;-) RFC 4592 is enlightening in a rather unpleasant manner. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: Wildcard CNAME record?
On 16.01.13 14:57, Baird, Josh wrote: Is it acceptable to have a wildcard CNAME? Example: * IN CNAMEsomewhere.com. Or, would it be advised to only use wildcard 'A' records? while it is technically valid, I don't think it's acceptable to use solutions that require wildcards ;-) -- 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. They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759 ___ 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
Wildcard CNAME record?
Is it acceptable to have a wildcard CNAME? Example: * IN CNAMEsomewhere.com. Or, would it be advised to only use wildcard 'A' records? Thanks. ___ 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: Clarification on wildcard falls into glue records
At 07:08 15-05-2012, Alexander Gurvitz wrote: From wikipedia: To quote RFC 1912, "A common mistake is thinking that a wildcard Using Wikipedia to quote RFC 1912 is odd ... Regards, -sm ___ 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: Clarification on wildcard falls into glue records
Sam Wilson wrote: > > Not I - another poster. Sorry! Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty, Forth, Tyne, Dogger: Northwest 5 to 7, occasionally 4 in Forth and Tyne. Moderate or rough, occasionally very rough in Forties and Dogger. Showers. Good, occasionally moderate. ___ 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: Clarification on wildcard falls into glue records
In article , Tony Finch wrote: > Sam Wilson wrote: > > > > Is a name on the RHS of an RR regarded as existing enough to prevent > > wildcard lookup? > > No, only RR owner names. > > > In this I would have expected the NS lookup to be followed by an A > > lookup for abc.a.example.com which would match the wildcard, assuming no > > other records match that name on the LHS. > > Yes that should work. The latter answer might appear to be missing because > additional section processing is a bit special. In your original question > you mentioned glue, ... Not I - another poster. Sam -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ 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: Clarification on wildcard falls into glue records
Sam Wilson wrote: > > Is a name on the RHS of an RR regarded as existing enough to prevent > wildcard lookup? No, only RR owner names. > In this I would have expected the NS lookup to be followed by an A > lookup for abc.a.example.com which would match the wildcard, assuming no > other records match that name on the LHS. Yes that should work. The latter answer might appear to be missing because additional section processing is a bit special. In your original question you mentioned glue, which is only necessary for delegations above the zone cut, and probably should not rely on wildcards. If this is a zone apex NS RRset then the server doesn't have to fill in the additional section. See the example below, from a nameserver that has minimal-responses turned on. ; <<>> DiG 9.8.1-P1 <<>> ns dotat.at ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41609 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;dotat.at. IN NS ;; ANSWER SECTION: dotat.at. 3600IN NS ns1.gratisdns.dk. dotat.at. 3600IN NS black.dotat.at. dotat.at. 3600IN NS puck.nether.net. dotat.at. 3600IN NS ns3.gratisdns.dk. ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue May 15 15:52:19 2012 ;; MSG SIZE rcvd: 123 Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty, Forth, Tyne, Dogger: Northwest 5 to 7, occasionally 4 in Forth and Tyne. Moderate or rough, occasionally very rough in Forties and Dogger. Showers. Good, occasionally moderate. ___ 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: Clarification on wildcard falls into glue records
In article , Alexander Gurvitz wrote: > You should NOT get A records. Wildcard works only for hostnames > that have NO records of ANY type. Excuse me while I delirk, but this is interesting. Is a name on the RHS of an RR regarded as existing enough to prevent wildcard lookup? In this I would have expected the NS lookup to be followed by an A lookup for abc.a.example.com which would match the wildcard, assuming no other records match that name on the LHS. Sam > >From wikipedia: > To quote RFC 1912, "A common mistake is thinking that a wildcard > MX for a zone will apply to all hosts in the zone. A wildcard MX will > apply only to names in the zone which aren't listed in the DNS at all. > " That is, if there is a wild card MX for *.example.com, and an > A record (but no MX record) for www.example.com, the correct > response (as per RFC 1034) to an MX request for www.example.com > is "no error, but no data"; this is in contrast to the possibly expected > response of the MX record attached to *.example.com. > > Regards, > Alexander, > net-me.net > > On Tue, May 15, 2012 at 9:34 AM, rams wrote: > > Hi, > > I have NS record points a record [A/] which is falls into wildcard . But > > when I query for NS record against bind, we are not getting these records as > > glue records. > > > > ex: > > *.a.example.com A 1.1.1.1 > > example.com. NS abc.a.example.com. > > > > Querying example.com with any or ns. > > don't we get glue records for this scenario? please confirm. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ 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: Clarification on wildcard falls into glue records
You should NOT get A records. Wildcard works only for hostnames that have NO records of ANY type. >From wikipedia: To quote RFC 1912, "A common mistake is thinking that a wildcard MX for a zone will apply to all hosts in the zone. A wildcard MX will apply only to names in the zone which aren't listed in the DNS at all. " That is, if there is a wild card MX for *.example.com, and an A record (but no MX record) for www.example.com, the correct response (as per RFC 1034) to an MX request for www.example.com is "no error, but no data"; this is in contrast to the possibly expected response of the MX record attached to *.example.com. Regards, Alexander, net-me.net On Tue, May 15, 2012 at 9:34 AM, rams wrote: > Hi, > I have NS record points a record [A/] which is falls into wildcard . But > when I query for NS record against bind, we are not getting these records as > glue records. > > ex: > *.a.example.com A 1.1.1.1 > example.com. NS abc.a.example.com. > > Querying example.com with any or ns. > don't we get glue records for this scenario? please confirm. > > ___ > 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
