Re: Bind to Bind DNS Lookup - Returns wildcard value for defined A record

.{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

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

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:

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

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.

Re: Bind to Bind DNS Lookup - Returns wildcard value for defined A record

stance 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 zo

Re: Bind to Bind DNS Lookup - Returns wildcard value for defined A record

t 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 h

Re: Bind to Bind DNS Lookup - Returns wildcard value for defined A record

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

Bind to Bind DNS Lookup - Returns wildcard value for defined A record

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

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

RPZ wildcard domain passthru not effective in BIND 9.11.21

sserver 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 wil

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

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

Re: update-policy wildcard grant

ello! >>> >>> 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

Re: update-policy wildcard grant

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

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;}; > >

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.

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

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

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

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

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

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

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

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

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.)

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

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 hostna

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

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

Re: Wildcard prefix

9 AM, Hardy, Andrew <andrew-ha...@innerface.net> 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

Re: Wildcard prefix

1, 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.

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

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 se

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

Re: Wildcard DNS records

Hello Stefano, Chiesa, Stefano <stefano.chi...@nttdata.com> 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: &

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

Re: wildcard not working after record deleted

y, 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 wild

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 work

Re: wildcard not working after record deleted

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. Than

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

Re: wildcard not working after record deleted

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. Tha

Re: wildcard not working after record deleted

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 ser

[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

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 you

Re: wildcard not working after record deleted

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

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

Re: wildcard not working after record deleted

iate 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 &quo

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

Re: wildcard not working after record deleted

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

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

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?

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 w

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

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

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

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

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

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 &

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,

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

Re: Wildcard

rams <brames...@gmail.com> 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 NOT

Re: Wildcard

le 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-us

Re: Wildcard

ry 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

Re: Interesting behavior with wildcard domains

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

Re: Interesting behavior with wildcard domains

9 PM To: "bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>" <bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>> Subject: RE: Interesting behavior with wildcard domains See “emp

Re: Interesting behavior with wildcard domains

In message <e7385ef3-1128-4f81-87fd-ef5cb55ed...@nau.edu>, 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

RE: Interesting behavior with wildcard domains

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

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" wi

Re: Wrong NSEC3 for wildcard cname

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

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

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:

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

Re: Wrong NSEC3 for wildcard cname

Hi Graham, On Wed, Nov 19, 2014 at 11:59 AM, Graham Clinch g.cli...@lancaster.ac.uk 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

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/

Wildcard oddity

). 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

Re: Wildcard oddity

? 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

Re: Wildcard oddity

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

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

Re: BUG? Wildcard lookup masked by more specific record of alternative type

Terry Burton t...@terryburton.co.uk 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.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at

Re: BUG? Wildcard lookup masked by more specific record of alternative type

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

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

Re: Unexpected wildcard matching

ip admin ipm...@googlemail.com 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

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

Re: Wildcard CNAME record?

Matus UHLAR - fantomas uh...@fantomas.sk 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

Re: Wildcard CNAME record?

In article mailman.1072.1358349671.11945.bind-us...@lists.isc.org, Oliver Peter li...@peter.de.com 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

Re: Wildcard CNAME record?

On Wed, Jan 16, 2013 at 10:33:03AM -0500, Barry Margolin wrote: In article mailman.1072.1358349671.11945.bind-us...@lists.isc.org, Oliver Peter li...@peter.de.com wrote: On Wed, Jan 16, 2013 at 02:57:48PM +, Baird, Josh wrote: Is it acceptable to have a wildcard CNAME? Example

Re: Wildcard CNAME record?

Matus UHLAR - fantomas uh...@fantomas.sk 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

Clarification on wildcard falls into glue records

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

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

Re: Clarification on wildcard falls into glue records

In article mailman.797.1337090936.63724.bind-us...@lists.isc.org, Alexander Gurvitz a...@net-me.net 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

Re: Clarification on wildcard falls into glue records

Sam Wilson sam.wil...@ed.ac.uk 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

Re: Clarification on wildcard falls into glue records

In article mailman.800.1337093642.63724.bind-us...@lists.isc.org, Tony Finch d...@dotat.at wrote: Sam Wilson sam.wil...@ed.ac.uk 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

Re: Clarification on wildcard falls into glue records

Sam Wilson sam.wil...@ed.ac.uk wrote: Not I - another poster. Sorry! Tony. -- f.anthony.n.finch d...@dotat.at http://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.

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

Clarification on wildcard scenario

Hi, I have zone as follows in bind. $ORIGIN joshfeb1.com. @ IN SOA rboddeti.yahoo.com. rboddeti.gmail.com. ( 2011013101 ; serial 10800 ; refresh 3600 ; retry 2592000 ;

Re: Clarification on wildcard scenario

In message AANLkTi=mms6aghguqyt1pmllyqfz2zp0su6yqwqmx...@mail.gmail.com, rams w rites: Hi, I have zone as follows in bind. $ORIGIN joshfeb1.com. @ IN SOA rboddeti.yahoo.com. rboddeti.gmail.com. ( 2011013101 ; serial 10800 ;

Re: Clarification on wildcard scenario

Hi Mark, Thank You for quick clarify. I have included trailing dot and restart bind. Now when i queired for domain www.joshfeb1.com with type A, I am getting NOERROR and NOANSWER. [root@ zones]# dig www.joshfeb1.com. A ; DiG 9.6.1-P3 www.joshfeb1.com. A ; (1 server found) ;; global options:

Re: Clarification on wildcard scenario

I must admit, I'm kinda confused by what you are actually trying to achieve ?A foo.joshfeb1.com. should be getting returning 1.1.1.1 ?A www.joshfeb1.com. should be returning noerror / nodata because: 1: There is a record at www.joshfeb1.com (so it's not NXDOMAIN), but 2: the record is not an

Clarification on wildcard scenario

Hi, I have zone as follows in bind. $ORIGIN joshfeb1.com. @ IN SOA rboddeti.yahoo.com. rboddeti.gmail.com. ( 2011013101 ; serial 10800 ; refresh 3600 ; retry 2592000 ; expire

  1   2   >