<div dir="ltr">Hi,<div><br></div><div>Actually, that config was from the primary at 192.168.10.3.</div><div><br></div><div>Below is the config from the lab DNS server at <a href="http://10.32.1.6/192.168.10.183">10.32.1.6/192.168.10.183</a>:</div><div><font face="monospace">include "/etc/bind/rndc.key";<br>include "/etc/bind/ddns-key.key";<br><br>zone "<a href="http://lab.domain.com">lab.domain.com</a>" {<br> type master;<br> forwarders {};<br> file "/var/lib/bind/<a href="http://db.lab.domain.com">db.lab.domain.com</a>";<br> update-policy {<br> grant ddns-key wildcard *.<a href="http://lab.domain.com">lab.domain.com</a> A DHCID;<br> };<br> notify yes;<br> allow-transfer { 192.168.10.3; };<br>};<br><br>zone "<a href="http://domain.com">domain.com</a>" {<br> type secondary;<br> masterfile-format text;<br> file "/var/lib/bind/<a href="http://db.domain.com">db.domain.com</a>";<br> primaries { 192.168.10.3; };<br>};<br><br>zone "1.32.10.in-addr.arpa" {<br> type master;<br> forwarders {};<br> file "/var/lib/bind/db.1.32.10.in-addr.arpa";<br> update-policy {<br> grant ddns-key wildcard *.<a href="http://domain.com">domain.com</a> A DHCID;<br> };<br>};<br><br>zone "10.32.10.in-addr.arpa" {<br> type master;<br> forwarders {};<br> file "/var/lib/bind/db.10.32.10.in-addr.arpa";<br> update-policy {<br> grant ddns-key wildcard *.10.32.10.in-addr.arpa PTR;<br> };<br>};<br><br>zone "20.32.10.in-addr.arpa" {<br> type master;<br> forwarders {};<br> file "/var/lib/bind/db.20.32.10.in-addr.arpa";<br> update-policy {<br> grant ddns-key wildcard *.20.32.10.in-addr.arpa PTR;<br> };<br>};<br><br>zone "30.32.10.in-addr.arpa" {<br> type master;<br> forwarders {};<br> file "/var/lib/bind/db.30.32.10.in-addr.arpa";<br> update-policy {<br> grant ddns-key wildcard *.30.32.10.in-addr.arpa PTR;<br> };<br>};<br></font></div><div><br></div><div>I now realize that views is *NOT* what I want to do since it's either one view or the other not an and type of thing.</div><div><br></div><div>The reason I was trying to do just both <a href="http://domain.com">domain.com</a> and <a href="http://lab.domain.com">lab.domain.com</a> is that I have let's encrypt certificates setup through both domain names. Doing the <a href="http://net2.domain.com">net2.domain.com</a>, <a href="http://net3.domain.com">net3.domain.com</a>, etc. I think would mean that I'd need certificates for each of those zones.</div><div><br></div><div>However, I think if I just slightly change the hostname for the <a href="http://lab.domain.com">lab.domain.com</a> like <a href="http://system10.lab.domain.com">system10.lab.domain.com</a>, <a href="http://system20.lab.domain.com">system20.lab.domain.com</a>, etc. and have those setup with different IP addresses, that *should* work. No ambiguity there since it's an entirely different hostname being resolved and still keep the <a href="http://lab.domain.com">lab.domain.com</a> domain name.</div><div><br></div><div>Ultimately, views won't work, which is very clear now, but having distinct hostnames for each instance on a different subnet *should* work and could be put on the <a href="http://lab.domain.com">lab.domain.com</a> system so that when they are replicated to the primary name server they will resolve appropriately.</div><div><br></div><div>Does that sound about right?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 29, 2023 at 7:53 AM Greg Choules <<a href="mailto:gregchoules%2Bbindusers@googlemail.com">gregchoules+bindusers@googlemail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Ubence.<div>That is starting to get complex!</div><div><br></div><div>Firstly, yes BIND parses views top down, so order matters.</div><div>Secondly, most specific domain wins (like more specific routes).</div><div><br></div><div>I now see that you have created three levels of zones:</div><div><a href="http://domain.com" target="_blank">domain.com</a></div><div><a href="http://lab.domain.com" target="_blank">lab.domain.com</a></div><div><a href="http://system.lab.domain.com" target="_blank">system.lab.domain.com</a></div><div><br></div><div>This config looks like it's from the 10... primary, correct? Can you send the config from 192.168.10.183 as well please?</div><div>What zones does it have and are there views on it too?</div><div><br></div><div>Rather than speculate why adding that secondary zone has started the problems, dump the database - rndc dumpdb -all - and see what it contains. That should show you what the server thinks it should be doing. Also, check the logs for what got transferred.</div><div><br></div><div>I don't understand the purpose of both <a href="http://lab.domain.com" target="_blank">lab.domain.com</a> and <a href="http://system.lab.domain.com" target="_blank">system.lab.domain.com</a>, unless the intention is to provide a general zone for all things 'lab' and a set of more specific zones for just this system?</div><div><br></div><div><br></div><div>I stand by my opinion that I still wouldn't use views for this and that the way to do it is to give every numbered interface on every machine its own domain.</div><div>So if "system" has six addresses it has six FQDNs, each one in a different zone. That alone may sound at first like it is complicating matters, but consider this: each address exists for a reason and in a different network (or you wouldn't need a different address), so a domain suffix can be viewed as the domain for a given network and all interfaces of all devices that sit in that network share a domain suffix.</div><div><br></div><div>If "system" is the end host itself I wouldn't give it its own zone. It's not illegal (and can actually be useful in some edge cases), just overly complicated. If this were my network I'd do something like:</div><div><br></div><div>zone "<a href="http://domain.com" target="_blank">domain.com</a>" {</div><div>type primary;</div><div>#contains delegations for net1, net2...net6</div><div><br></div><div>zone "<a href="http://net1.domain.com" target="_blank">net1.domain.com</a>" {</div><div># <a href="http://192.168.10.0/24" target="_blank">192.168.10.0/24</a></div><div>etc...</div><div><br></div><div><div>zone "<a href="http://net2.domain.com" target="_blank">net2.domain.com</a>" {</div><div># <a href="http://10.32.1.0/24" target="_blank">10.32.1.0/24</a></div><div>etc...</div><div><br></div></div><div><div>zone "<a href="http://net3.domain.com" target="_blank">net3.domain.com</a>" {</div><div># <a href="http://10.32.10.0/24" target="_blank">10.32.10.0/24</a></div><div>etc...</div><div><br></div></div><div><div>zone "<a href="http://net4.domain.com" target="_blank">net4.domain.com</a>" {</div><div># <a href="http://10.32.20.0/24" target="_blank">10.32.20.0/24</a></div><div>etc...</div><div><br></div></div><div><div>zone "<a href="http://net5.domain.com" target="_blank">net5.domain.com</a>" {</div><div># <a href="http://10.32.30.0/24" target="_blank">10.32.30.0/24</a></div><div>etc...</div><div><br></div></div><div><div>zone "<a href="http://net6.domain.com" target="_blank">net6.domain.com</a>" {</div><div># ?.?.?.?</div><div>etc...</div><div><br></div></div><div>"system" has A records in all of these, with the relevant interface address for the network. Clients lookup the FQDN of interest to them at the time. This way there is guaranteed no ambiguity.</div><div><br></div><div>Cheers, Greg</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 29 Jun 2023 at 15:00, Ubence Quevedo <<a href="mailto:thatrat@gmail.com" target="_blank">thatrat@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Greg,<div><br></div><div>Here's the most recent config that I tried that seemed to work, but ultimately broke resolution for the main zone <a href="http://domain.com" target="_blank">domain.com</a>, even though I set it to match-clients { any; }.</div><div><br></div><div>What I didn't mention in my original post was that I have other subnets configured for this remote host through vlans with different IP addresses. That's why there are so many other views. I was hoping the match-clients per each view would return the appropriate IP address per subnet making the request.</div><div><br></div><div><font face="monospace">include "/etc/bind/rndc.key";</font><br><font face="monospace">include "/etc/bind/ddns-key.key";</font><br><br><font face="monospace">view "192.168.10-net" {</font><br><font face="monospace"> match-clients { <a href="http://192.168.10.0/24" target="_blank">192.168.10.0/24</a>; };</font><br><font face="monospace"> zone "<a href="http://system.lab.domain.com" target="_blank">system.lab.domain.com</a>" {</font><br><font face="monospace"> type master;</font><br><font face="monospace"> file "/var/lib/bind/db.system.lab.domain.com.192.168.10";</font><br><font face="monospace"> };</font><br><font face="monospace">};</font><br><br><font face="monospace">view "10.32.1-net" {</font><br><font face="monospace"> match-clients { <a href="http://10.32.1.0/24" target="_blank">10.32.1.0/24</a>; };</font><br><font face="monospace"> zone "<a href="http://system.lab.domain.com" target="_blank">system.lab.domain.com</a>" {</font><br><font face="monospace"> type master;</font><br><font face="monospace"> file "/var/lib/bind/db.system.lab.domain.com.10.32.1";</font><br><font face="monospace"> };</font><br><font face="monospace">};</font><br><br><font face="monospace">view "10.32.10-net" {</font><br><font face="monospace"> match-clients { <a href="http://10.32.10.0/24" target="_blank">10.32.10.0/24</a>; };</font><br><font face="monospace"> zone "<a href="http://system.lab.domain.com" target="_blank">system.lab.domain.com</a>" {</font><br><font face="monospace"> type master;</font><br><font face="monospace"> file "/var/lib/bind/db.system.lab.domain.com.10.32.10";</font><br><font face="monospace"> };</font><br><font face="monospace">};</font><br><br><font face="monospace">view "10.32.20-net" {</font><br><font face="monospace"> match-clients { <a href="http://10.32.20.0/24" target="_blank">10.32.20.0/24</a>; };</font><br><font face="monospace"> zone "<a href="http://system.lab.domain.com" target="_blank">system.lab.domain.com</a>" {</font><br><font face="monospace"> type master;</font><br><font face="monospace"> file "/var/lib/bind/db.system.lab.domain.com.10.32.20";</font><br><font face="monospace"> };</font><br><font face="monospace">};</font><br><br><font face="monospace">view "10.32.30-net" {</font><br><font face="monospace">match-clients { <a href="http://10.32.30.0/24" target="_blank">10.32.30.0/24</a>; };</font><br><font face="monospace"> zone "<a href="http://system.lab.domain.com" target="_blank">system.lab.domain.com</a>" {</font><br><font face="monospace"> type master;</font><br><font face="monospace"> file "/var/lib/bind/db.system.lab.domain.com.10.32.30";</font><br><font face="monospace"> };</font><br><font face="monospace">};</font><br><br><font face="monospace">view "main" {</font><br><font face="monospace"> match-clients { any; };</font><br><font face="monospace"> zone "<a href="http://domain.com" target="_blank">domain.com</a>" {</font><br><font face="monospace"> type master;</font><br><font face="monospace"> forwarders {};</font><br><font face="monospace"> file "/var/lib/bind/<a href="http://db.domain.com" target="_blank">db.domain.com</a>";</font><br><font face="monospace"> update-policy {</font><br><font face="monospace"> grant ddns-key wildcard *.<a href="http://domain.com" target="_blank">domain.com</a> A DHCID;</font><br><font face="monospace"> };</font><br><font face="monospace"> notify yes;</font><br><font face="monospace"> allow-transfer { 192.168.10.183; };</font><br><font face="monospace"> };</font><br><font face="monospace"> zone "<a href="http://lab.domain.com" target="_blank">lab.domain.com</a>" {</font><br><font face="monospace"> type secondary;</font><br><font face="monospace"> masterfile-format text;</font><br><font face="monospace"> file "/var/lib/bind/<a href="http://db.lab.domain.com" target="_blank">db.lab.domain.com</a>";</font><br><font face="monospace"> primaries { 192.168.10.183; };</font><br><font face="monospace"> };</font><br><font face="monospace"> zone "10.168.192.in-addr.arpa" {</font><br><font face="monospace"> type master;</font><br><font face="monospace"> forwarders {};</font><br><font face="monospace"> file "/var/lib/bind/db.10.168.192.in-addr.arpa";</font><br><font face="monospace"> update-policy {</font><br><font face="monospace"> grant ddns-key wildcard *.10.168.192.in-addr.arpa PTR;</font><br><font face="monospace"> };</font><br><font face="monospace"> };</font><br><font face="monospace">};</font><br><br><font face="arial, sans-serif">The contents of /var/lib/bind/db.system.lab.domain.com.192.168.10:</font><font face="monospace"><br>$ORIGIN .<br>$TTL 604800 ; 1 week<br><a href="http://system.lab.domain.com" target="_blank">system.lab.domain.com</a> IN SOA <a href="http://ns1.domain.com" target="_blank">ns1.domain.com</a>. <a href="http://thatrat.gmail.com" target="_blank">thatrat.gmail.com</a>. (<br> 2023062800 ; serial<br> 604800 ; refresh (1 week)<br> 86400 ; retry (1 day)<br> 2419200 ; expire (4 weeks)<br> 604800 ; minimum (1 week)<br> )<br> NS <a href="http://ns1.domain.com" target="_blank">ns1.domain.com</a>.<br>$ORIGIN <a href="http://system.lab.domain.com" target="_blank">system.lab.domain.com</a>.<br> A 192.168.10.170</font><br></div><div><br></div><div>The other <span style="font-family:monospace">/var/lib/bind/db.system.lab.domain.com.10.32.X.X </span><font face="arial, sans-serif">follow a similar format with the domain name pointing to a different IP address for each "version" of the domain matching a view for a different entry subnet.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Again, the <a href="http://domain.com" target="_blank">domain.com</a> zone currently has an entry for <a href="http://system.lab.domain.com" target="_blank">system.lab.domain.com</a> for 192.168.10.170 and the secondary <a href="http://lab.domain.com" target="_blank">lab.domain.com</a> has an entry for <a href="http://system.lab.domain.com" target="_blank">system.lab.domain.com</a> with 10.32.10.1.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">This was all working perfectly until I added the secondary domain to my config [essentially just the contents of the main view above] which it started only returning 10.32.10.1 for the <a href="http://system.lab.domain.com" target="_blank">system.lab.domain.com</a> which again I think had some type of precedence on the "fuller" FQDN being served, and the system.lab from the <a href="http://domain.com" target="_blank">domain.com</a> zone taking lesser precedence.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">It also seems that the bind configuration file is read from top down in processing order? I had the main view on top first, but then moved it below the other views, and then the 192.168.10-net view worked...but the main view did not work.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">I know this is an overly complicated setup and probably the simplest answer is just to remove the secondary zone from config so that there is only the one entry that resolves for the <a href="http://system.lab.domain.com" target="_blank">system.lab.domain.com</a>, I just thought that there might be a away to have the hostname resolve differently based on what the requesting IP address was.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">I also have Dynamic DNS setup so that the ISC DHCP server will update <a href="http://domain.com" target="_blank">domain.com</a> with system hostname info which *might* complicate things.</font></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 28, 2023 at 9:33 PM Greg Choules <<a href="mailto:gregchoules%2Bbindusers@googlemail.com" target="_blank">gregchoules+bindusers@googlemail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Ubence.<div>Firstly, may we see your configs please. It's impossible to say exactly what's going on from a human description.</div><div><br></div><div>Secondly, views and different answers. Yes it *is* entirely possible to use views to provide answers based on client IP - `match-clients. I would start with the most specific view first with a `match-clients` clause, then a general view without one. If you only have two choices.</div><div><br></div><div>Thirdly, naming of multi-homed systems. A long time ago, in a previous job, I tried to work out how to make (say) "<a href="http://system.lab.domain.com" target="_blank">system.lab.domain.com</a>" resolve to different addresses, depending on who was asking the question, or from which direction they were asking it and it nearly drove me mad. I concluded that "sytem" should not be regarded as one domain, but one domain *per interface*.<br></div><div>So let's say that the box called "system" has two interfaces with addresses 192.168.10.170 for its lab side and 10.32.10.1 for its production side. I would do this and not bother with views:</div><div><br></div><div>zone "<a href="http://domain.com" target="_blank">domain.com</a>" {</div><div> type primary;</div><div> file "<a href="http://db.domain.com" target="_blank">db.domain.com</a>";</div><div>};</div><div><br></div><div>Contents at least:</div><div>@ SOA etc...<br></div><div>@ IN NS <fqdn_of_production_ns.><br></div><div>lab IN NS <fqdn_of_lab_ns.> ;don't forget the delegation</div><div>system IN A 10.32.10.1</div><div><br></div><div>zone "<a href="http://lab.domain.com" target="_blank">lab.domain.com</a>" {</div><div> type primary;</div><div> file "<a href="http://db.lab.domain.com" target="_blank">db.lab.domain.com</a>";</div><div>};</div><div><br></div><div><div>Contents at least:</div><div>@ SOA etc...<br></div><div><a class="gmail_plusreply" id="m_1548654859745365676m_-6035104330084196614m_-465592153661765148m_6646631177164973265plusReplyChip-2">@</a> IN NS <fqdn_of_lab_ns.></div><div>system IN A 10.32.10.1</div><div><br></div></div><div>Now to reach "system", depending on who you are, which direction you are approaching it from and what network routeing and firewalls will allow you either connect to "<a href="http://system.domain.com" target="_blank">system.domain.com</a>" for its production side or <a href="http://system.lab.domain.com" target="_blank">system.lab.domain.com</a>" for its lab side. There is no ambiguity about what address "system" has because each one now has a unique name.</div><div><br></div><div>Note that this requires clients to use FQDNs, which IMHO is a good thing. I always try to avoid "search...." in resolv.conf because it leaves the OS stub resolver guessing what the user actually wants.</div><div><br></div><div><br></div><div>Hope that helps. But as i said, configs please and then *we* don't have to guess :)</div><div>Cheers, Greg</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 28 Jun 2023 at 23:45, Ubence Quevedo <<a href="mailto:thatrat@gmail.com" target="_blank">thatrat@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<br><br>I have two domains configured, a production and lab/testing domain [let's say <a href="http://domain.com" target="_blank">domain.com</a> and <a href="http://lab.domain.com" target="_blank">lab.domain.com</a>].<br><br>I have a few different networks configured [<a href="http://192.168.10.0/24" target="_blank">192.168.10.0/24</a> and <a href="http://10.32.10.0/24" target="_blank">10.32.10.0/24</a>].<br><br>I have a system that has two network cards on both the 192.168.10.X network and 10.32.10.X network.<br><br>I have a remote system that is also configured to on both networks, with hostnames on both domains/networks.<br><br>I have a hostname entry in my primary master for the <a href="http://domain.com" target="_blank">domain.com</a> [<a href="http://system.lab.domain.com/192.168.10.170" target="_blank">system.lab.domain.com/192.168.10.170</a>], but there are other systems configured via the bind 9 system that serves out <a href="http://lab.domain.com" target="_blank">lab.domain.com</a> with an entry for this system [<a href="http://system.lab.domain.com/10.32.10.1" target="_blank">system.lab.domain.com/10.32.10.1</a>].<br><br>On the primary DNS server, the <a href="http://system.lab.domain.com" target="_blank">system.lab.domain.com</a> worked great and pointed to 192.168.10.170, however I made the lab server a secondary on the primary and vice-a-versa so that the <a href="http://lab.domain.com" target="_blank">lab.domain.com</a> entries would resolve for systems on the 192.168.10.X network so that the dual network capable system would be able to resolve lab hostnames from my primary DNS server. This is a Mac and the primary interface wins for name resolution as far as I can tell even though the other network interface is configured to point to the lab DNS server.<br><br>This makes things work great to be able to resolve lab network host names, but the 10.32.10.X network isn't directly accessible to the 192.168.10.X network.<br><br>What's happening is the that hostname I have configured on the primary name server [<a href="http://system.lab.domain.com/192.168.10.170" target="_blank">system.lab.domain.com/192.168.10.170</a>] is not taking precedence over the secondary domain that is configured [<a href="http://system.lab.domain.com/10.32.10.1" target="_blank">system.lab.domain.com/10.32.10.1</a>].<br><br>Any resolution now for the system.lab.totusmel.coml hostname now brings back 10.32.10.1 instead of the 192.168.10.170.<br><br>I think it's because the lab domain takes precedence because the domain name <a href="http://lab.domain.com" target="_blank">lab.domain.com</a> is a higher priority than <a href="http://domain.com" target="_blank">domain.com</a> even with the system.lab tacked onto the primary domain.<br><br>I started dabbling with views and tried to set up specific views that would return a fully qualified hostname as a domain based on what network the request came from. If the request came from the 10.32.10.X network, return the <a href="http://system.lab.domain.com/10.32.10.1" target="_blank">system.lab.domain.com/10.32.10.1</a> entry and if it came from the 192.168.10.X network, return the <a href="http://system.lab.domain.com/192.168.10.170" target="_blank">system.lab.domain.com/192.168.10.170</a> entry.<br><br>This seemed to work after re-arranging the order of the main configuration file, and I could resolve the <a href="http://system.lab.domain.com" target="_blank">system.lab.domain.com</a> as 192.168.10.170 as I intended but this then broke all of the host entries I had configured for <a href="http://domain.com" target="_blank">domain.com</a> as none were resolvable.<br><br><br>My question is, is there any way to "properly" return a hostname/IP based on what network the request is coming from?<br><br>This seemed like it would work, and it kind of did, but even with a separate view of "any" for the hostnames of the production domain, this didn't quite work.<br><br><br>I know this is a somewhat confusing set up, but I thought it might be possible to resolve a hostname difference with views based on the requesting network.<br><div><br></div><div>Any thoughts or advice would be greatly appreciated!</div></div>
-- <br>
Visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></div>
</blockquote></div>
-- <br>
Visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></div>
</blockquote></div>