Re: Intent and implementation of dig's +crypto option
On Fri, Sep 22, 2023 at 8:46 AM Anand Buddhdev wrote: > Hi folks, > > I wanted to open a GitLab issue about this, but then thought it might be > nice to have a discussion to hear the views of users. > > dig 9.18.19's man page says: > >+crypto, +nocrypto > This option toggles the display of cryptographic fields in DNSSEC > records. The contents of these fields are unnecessary for debugging > most DNSSEC validation failures and removing them makes it easier to > see the common failures. The default is to display the fields. When > omitted, they are replaced by the string [omitted] or, in the DNSKEY > case, the key ID is displayed as the replacement, > e.g. [ key id = value ]. > > When I query using dig, and use the combination "+nocrypto +dnssec" then > dig suppresses the crypto material for DNSKEY, DS and RRSIG records. > This is in agreement with the man page. > > But when I query for the newly introduced ZONEMD record, dig also hides > the hash. In my opinion, ZONEMD is not a DNSSEC-related record, and so > its hash should not be hidden (according to the man page). > > On the other hand, the hash displayed for ZONEMD, like with hashes of DS > records, is not especially useful for eyeballing. For me, it is enough > to see that there's a ZONEMD record, but I don't need to see all the hex > (which is only needed by code that actually wants to verify it). So I'm > actually fine with the ZONEMD hash being suppressed, but the man page > needs to be updated. > > In a similar way, the hashes displayed in TLSA and similar records could > also be suppressed, but dig currently doesn't. > > Do you think that dig should be adjusted to suppress cryptographic > material from other records such as TLSA, SSHFP, CDNSKEY, CDS, etc, and > the man page updated to reflect this? > > Regards, > Anand Buddhdev > -- > > Just my opinion, but I would like it to apply to all crypto fields. And that's a useful option, I had not been using it, but I will now, thanks. -- Bob Harold -- 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: Forwarders working differently on bind9.8 & bind9.11
On Tue, Sep 19, 2023 at 7:28 AM Prashasti Arora
wrote:
> I have configured a new zone to forward certain queries to my application
> on 2 VMs (One local and the other in my network) through a specific port. I
> have 2 similar setups - they are identical, except that one uses bind9.8
> and the other uses bind9.11. Configuration is also identical for both.
>
> On the first setup (using bind9.8): the traffic I send gets distributed
> uniformly.
> On the second setup (using bind9.11): the traffic gets distributed barely.
> 99% of the traffic is sent to one VM.
>
> I have verified that forwarding is working correctly on both, the issue is
> not with the application because both VMs on each setup can handle traffic
> individually, the firewall is not blocking the queries, and the
> configuration is correct.
>
> This is the zone:
>
> zone "example.com" IN {
> type forward;
> forwarders { 127.0.0.1 port xxx; a.b.c.d port xxx; };
> forward only;
> };
>
>
> Please share any other possible solutions.
> --
>
Note that the 'forwarders' line, from the BIND 9.11 manual: "There may be
one or more forwarders, and they are queried in turn until the list is
exhausted
or an answer is found." So the first one will get all the traffic, the
second is just a backup to be used if the first fails.
If you expect that to do load balancing, it will not. Try a real load
balancer, or 'dnsdist'.
---
Bob Harold
--
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
Does DNSSEC increased packet size reach end computers?
I was in the process of setting up a test server with DNSSEC signed domains, and asking users to point at the test server to see if the larger packets affected their application, when I realized I might be wrong. DNS Resolvers will get bigger responses from DNS Authoritative servers because of DNSSEC signatures. But clients, running stub resolvers, will likely set the +AD flag and expect the DNS Resolver to validate, but the client will get a response that does not include any DNSSEC records. Is that correct? So I only need to worry about increased packet sizes between DNS Resolvers and DNS Authoritative servers? (Granted, the actual answer size to the client could be large enough to cause fall-back to TCP, but that is not because of DNSSEC.) -- Bob Harold -- 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
DNS DDoS protection
Before answering this question, can you tell me the proper place where I should be asking this question? "We are researching DDoS protection, including DNS. What companies or products or methods should I be looking at?" -- Bob Harold -- 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: Proxy requests but filter out IPv4 address
RPZ should be able to do that. Read up on RPZ in the BIND manual, and search online for more info. -- Bob Harold On Fri, Aug 19, 2022 at 2:56 AM Matthias Fechner wrote: > Dear all, > > I'm not sure if bind can do this, but let me explain what I would like > to do. > > It is a hostname from a foreign domain, like: > test.myfritz.net > > it is returning an IPv4 and IPv6 address: > host test.myfritz.net > test.myfritz.net has address 100.91.114.161 > test.myfritz.net has IPv6 address 2a02:6d40:17:9dc7:e228:6dff:fe8d:1f41 > > The IPv4 address will not work due to carrier-nat, so only the IPv6 > address would be reachable from outside. > > Is there a way to configure bind that if I resolve test.myfritz.net (it > must not be under the domain myfritz.net, but can also be in a way > aliased to a domain I own) that it only returns the IPv6 address but > totally skip the IPv4 address? > The IPv4 and IPv6 addresses are not permanent and change at least once a > day. > > > Gruß > Matthias > > -- > > "Programming today is a race between software engineers striving to > build bigger and better idiot-proof programs, and the universe trying to > produce bigger and better idiots. So far, the universe is winning." -- > Rich Cook > > -- > 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: RE: DNSSEC adoption
I think the best way to soften the effect, and make DNSSEC much less brittle, without losing any of the security, is to reduce the TTL of the DS record in the parent zone (usually TLD's) drastically - from 2 days to like 30 minutes. That allows quick recovery from a failure. I realize that will cause an increase in DNS traffic, and I don't know how much of an increase, but the 24-48 hour TTL of the DS record is the real down-side of DNSSEC, and why it is taking me so long to try to develop a bullet-proof process before signing my zones. -- Bob Harold University of Michigan On Tue, Aug 2, 2022 at 2:21 PM Timothe Litt wrote: > > On 02-Aug-22 13:51, Brown, William wrote: > > my guess is that they see dnssec as fragile, have not seen _costly_ > dns subversion, and measure a dns outages in thousands of dollars a > minute. > > No one wants to be this > guy:http://www.dnssec.comcast.net/DNSSEC_Validation_Failure_NASAGOV_201201 > 18_FINAL.pdf > > so, to me, a crucial question is whether dnssec ccould be made to fail more > softly and/or with a smaller blast radius? > > randy > > I'm more of a mail guy than DNS, so yes, like hard v. soft fail in SPF. Or > perhaps some way of the client side deciding how to handle hard v./ soft > failure. > > As Mark has pointed out, validation is a client issue. Setting up DNSSEC > properly and keeping it running is for the server admin - which bind is > incrementally automating. > > For bind, the work-around for bad servers (which is mentioned in the > article) is to setup negative trust anchors in the client for zones that > fail. And notify the zone administrator to fix the problem. I usually > point them to a DNSVIZ report on their zone. > > The nasa.gov failure was avoidable. nasawatch, which is an excellent > resource for space news, jumped to an incorrect conclusion about the outage > - and never got the story straight. In fact, all validating resolvers > (including mine) correctly rejected the signatures. It wasn't comcast's > fault - they were a victim. > > It is an unfortunate reality that admins will make mistakes. And that > there is no way to get all resolvers to fix them - you can't even find all > the resolvers. (Consider systemd-resolved, or simply finding all the > recursive bind, powerdns, etc instances...) > > There is no global "soft" option - aside from unsigning the zone and > waiting for the TTLs to expire. And besides being a really bad idea, it's > easier to fix the immediate problem and learn not to repeat it. > > Long term, automation of the (re-)signing and key roll-overs will reduce > the likelihood of these outages. It is truly unfortunate that it's so late > in coming. > > It may take a flag day to get major resolver operators, dns servers, and > client resolvers all on the same page. I'm not holding my breath. > > Timothe Litt > ACM Distinguished Engineer > -- > This communication may not represent the ACM or my employer's views, > if any, on the matters discussed. > > > -- > 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: BIND9 TSIG from Windows Server 2016 DNS Server Zone
d/named.conf.default-zones";
>
> zone "grf.hr.internal" in { // workaround zone to get a zone xfer to
> secondary
> type master;
> file "/etc/bind/zones/grf.hr.internal";
> allow-transfer { key grf.hr-tsig; };
> also-notify { 161.53.83.3; };
> forwarders {};
> };
>
> zone "grf.hr" in { // real internal zone name with the same data
> zone-alias-for "grf.hr.internal";
>};
>
> ...
>
> };
>
> view "universe" {
>
>
> match-clients { any; };
>
> recursion no;
>
> zone "grf.hr" in {
> type master;
> file "/etc/bind/zones/grf.hr"; // database for the external view
> allow-transfer { 161.53.2.70; };
> also-notify { 161.53.2.70; 161.53.83.3; };
> forwarders {};
> };
> ...
>
> };
>
> SECONDARY:
>
> view "internal" {
>
> match-clients { 161.53.83.0/24; 10.0.0.0/16; 31.147.204.224;
> localhost; };
>
> recursion yes;
>
> zone "grf.hr.internal" in {
> type secondary;
> file "/var/cache/bind/grf.hr.internal.db";
> masters { 31.147.204.224; };
> allow-transfer { none; };
> forwarders {};
> };
>
> *zone "grf.hr <http://grf.hr>" in {*
> *zone-alias-for "grf.hr.internal";*
> *};*
>
> ...
>
> };
>
> view "universe" {
>
> match-clients { any; };
>
> recursion no;
>
> zone "grf.hr" in {
> in-view "internal";
> };
>
> ...
>
> };
>
> Because that's what I really need, for the same zone to have internal and
> external variant of data, equal on both primary and secondary server.
>
> (Of course, this is not a suggestion for a change in BIND9 configuration
> syntax, just a semantic example of what is semantically required.)
>
> Thank you.
>
> Kind regards,
> Mirsad
> On 26. 05. 2022. 08:07, Crist Clark wrote:
>
> As far as I know, GSS-TSIG is only used for DNS updates, not zone
> transfers.
>
> https://bind9.readthedocs.io/en/v9_16_5/advanced.html#dynamic-update
>
> Sorry, don't know what capabilities AD has for securing zone transfers
> beyond IP ACLs, which of course is not much security at all. I've never had
> luck getting AD admins to offer anything better. I'm definitely no AD
> expert myself.
>
> One possibility of course is to secure at the IP layer, a.k.a. IPsec. You
> could secure all traffic between the servers with transport mode AH. That
> would probably blow some minds in your organization. There are many who
> only know IPsec as encrypted tunnels, i.e. VPNs.
>
> On Wed, May 25, 2022 at 3:38 PM Mirsad Goran Todorovac <
> mirsad.todoro...@alu.unizg.hr> wrote:
>
>> Dear all,
>>
>> I have a zone local.grf.hr administered by AD, DHCP and DDNS ran by
>> Windows Server 2016
>> (not by my architectural choice). However, since Windows Server 2016 had
>> round-robin
>> strategy of inquiring the forwarders, it performed worse than BIND9 on
>> old Debian server.
>>
>> So, I had the BIND9 as the secondary server ("slave" is somewhat
>> politically incorrect) and I
>> wanted to secure transactions with TSIG HMAC-SHA256 or stronger, as
>> between Debian
>> BIND9 servers.
>>
>> I've been Googling around, and they say it cannot be done, because
>> Windows Server uses
>> special proprietary GSS-TSIG. The article was for an earlier version of
>> WS.
>>
>> Has there been some improvement in the meantime?
>>
>> We are thinking about moving DHCP server to Linux, but it is a huge job
>> to convert the
>> reservations, so it may not be done in the next couple of months.
>>
>> I would like to secure DNS xfers from zone poisoning in the meantime,
>> considering the recent
>> surge of cyber attacks since the recent war started, and our country
>> voted support for the
>> defending party.
>>
>> Frankly, I am not in deep with Microsoft DNS, and I guess there can be
>> some tweaking with
>> the PowerShell, and maybe even some undocumented features, but right now
>> I am presented
>> with a problem I can't seem to solve because it is not an open system.
>>
>> Thanks for any help.
>>
>> Kind regards,
>> Mirsad Todorovac
>>
>> --
>> Mirsad Goran Todorovac
>> CARNet sistem inženjer
>> Grafički fakultet | Akademija likovnih umjetnosti
>> Sveučilište u Zagrebu
>>
>> --
>> CARNet system engineer
>> Faculty of Graphic Arts | Academy of Fine Arts
>> University of Zagreb, Republic of Croatia
>> tel. +385 (0)1 3711 451
>> mob. +385 91 57 88 355
>>
>> --
>> 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
>>
>> --
> Mirsad Goran Todorovac
> CARNet sistem inženjer
> Grafički fakultet | Akademija likovnih umjetnosti
> Sveučilište u Zagrebu
> --
> CARNet system engineer
> Faculty of Graphic Arts | Academy of Fine Arts
> University of Zagreb, Republic of Croatia
> tel. +385 (0)1 3711 451
> mob. +385 91 57 88 355
>
>
>
See
https://kb.isc.org/docs/aa-00851
the standard solution is to use TSIG keys to direct the notify messages and
zone transfers to the correct views.
--
Bob Harold
--
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: Determining Which Authoritative Sever to Use
On Wed, May 11, 2022 at 4:34 PM Grant Taylor via bind-users <
bind-users@lists.isc.org> wrote:
> On 5/11/22 2:19 PM, Bob Harold wrote:
> > Not sure who set it up, but my DHCP servers have for some zones:
> >
> > zone x.y.z.in-addr.arpa
> > {
> > primary 10.2.3.4;
> > }
>
> I'm assuming that is BIND's named.conf syntax.
>
> > Which I believe overrides the MNAME lookup.
>
> Doesn't that just tell BIND where to initiate a zone transfer from?
>
> I didn't think that it altered the zone contents in any way.
>
> Aside: I'm not connecting the dots of what this has to do with the
> larger conversation, /unless/ you are thinking that it alters the zone
> contents or at least what's returned to clients querying this DNS server.
>
>
>
> --
> Grant. . . .
> unix || die
>
>
If DHCP clients are doing the dynamic DNS updates, then what I said is
irrelevant.
If the DHCP server is doing the dynamic DHCP updates for the clients, then
the DHCP server can be configured as shown (in /etc/dhcpd.conf) to tell
them what DNS server to use. I use this because I trust the server more
than the clients, but I am sure there are more trade offs to consider.
--
Bob Harold
--
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: Determining Which Authoritative Sever to Use
On Wed, May 11, 2022 at 1:50 PM Grant Taylor via bind-users <
bind-users@lists.isc.org> wrote:
> On 5/11/22 11:24 AM, Bob McDonald wrote:
> > It would seem that using an anycast cloud name (An anycast cloud
> > of the NS device IPs) for the MNAME might provide the same level of
> > distribution as per Windows. However, again, you run into the issues
> > of forwarded updates.
>
> Another thing that I've seen discussed -- but haven't tested myself --
> is to play tricks like having the MNAME be it's own zone hosted on each
> DNS server wherein the zone resolves the MNAME to the local DNS server.
>
> This seems like a varient on anycasting, which operates on the IP layer.
> Except this provides similar functionality at the DNS application layer.
>
> You could probably achieve similar results with an RPZ overriding the
> MNAME with the local server's IP address.
>
> }:-)
>
>
>
> --
> Grant. . . .
> unix || die
>
>
Not sure who set it up, but my DHCP servers have for some zones:
zone x.y.z.in-addr.arpa
{
primary 10.2.3.4;
}
Which I believe overrides the MNAME lookup.
--
Bob Harold
--
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: Supporting LOC RR's
On Wed, Apr 13, 2022 at 9:39 AM Bjørn Mork wrote: > Timothe Litt writes: > > > Anyhow, it's not clear exactly what problem you're asking LOC (or > > anything) to solve. > > Which problems do LOC solve? > > I remember adding LOC records for fun?() in the previous millennium when > RFC 1876 was fresh out of the press. But even back then paranoia > finally took over, and I deleted all of them. > > Don't think I ever found anything to actually use them for. > > > Bjørn > -- > > WIth regard to locating access points: Self-locating wifi APs https://www.youtube.com/watch?v=kVdFNR0R3EE -- 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: Merging DNS servers
On Tue, Apr 26, 2022 at 11:36 AM Leroy Tennison via bind-users < bind-users@lists.isc.org> wrote: > I am working on shutting down a site which has an isc-bind server that is > master for a domain and subnet which will exist elsewhere once the site is > closed. The few remaining systems don't warrant such a server. My goal is > to merge what remains of the domain/subnet into an existing server which is > master for other domains/subnets. My current thinking is to: > > freeze changes on the server being retired (fortunately DHCP's DDNS won't > be an issue by that point) > shut down that server > take the data files (forward and reverse zone with associated journal > files) and place them on the remaining server > make sure the data file types are consistent > change the the remaining server's type from slave to master for the zones > in question > restart the remaining server > > Is this a good plan? If not, how should I proceed? > Anything I'm missing? > > Thanks in advance for your input. > -- > > Sounds good to me. If you use "rndc freeze", then you should not need to copy the journal files. If there are any other secondary servers (and you almost always want more than just the master), then change those to pull from the new server, and make sure that is working, before starting the steps you listed. -- Bob Harold -- 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: Ask for automated KSK roll with DS checking
On Thu, Apr 15, 2021 at 12:44 PM Tony Finch wrote: > Matthijs Mekking wrote: > > On 15-04-2021 16:35, Bob Harold wrote: > > > > > > If BIND holds both the child and parent zone, will it add the DS record > > > at the correct time? Or do I still need to write scripts to update the > > > DS records in all my sub-zones? And is there some signal from BIND at > > > the time the DS record should be written, or do i need to calculate the > > > right time? > > > > Currently you still have to write scripts to update DS records in all > > your parent zones. > > > > The CDS/CDNSKEY records are published in the child zones that indicate > > the DS should be published, so I would script against that. > > > > Then when the DS is seen in the parent, call the rndc dnssec -checkds > > published/withdrawn command. > > dnssec-cds can tell you what the parental DS record(s) should be. It > can maintain a dsset file for each child zone that you can $INCLUDE in the > parent. It's fairly bare so it needs to be wrapped with a script that does > the necessary queries and updates. > > I don't know if the dnssec-policy stuff includes timing parameters or > checks to protect against parental publication delays; if not then the > wrapper script will have to keep track of time or poll the parent servers > or something. > > Tony. > -- > f.anthony.n.finchhttps://dotat.at/ > Fair Isle: South 3 to 5, occasionally 6 later. Slight or moderate, > becoming rough later in west. Fair. Good. Seeing that I still need some scripting, does anyone already have scripts that work? -- Bob Harold ___ 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: Ask for automated KSK roll with DS checking
On Thu, Apr 15, 2021 at 8:50 AM Bob Harold wrote: > > On Thu, Apr 15, 2021 at 2:57 AM Matthijs Mekking wrote: > >> >> >> On 14-04-2021 22:30, Greg Rivers via bind-users wrote: >> > On Wednesday, 14 April 2021 15:00:38 CDT Bob Harold wrote: >> >> Does anyone have an automated KSK roll process, that checks for the DS >> >> record at the parent, that they can share? >> >> >> >> As far as I can tell, the automated signing in BIND will roll the KSK >> if I >> >> set the timing in the policy file, but it won't check the DS record, >> so it >> >> will happily break DNSSEC if some other process does not update the DS >> >> record at the right time. That's too big a risk for me, the process >> needs >> >> to check the DS record before completing the KSK roll. Surely someone >> has >> >> done this. I would rather not reinvent the wheel. But I have >> searched and >> >> not found anything yet. >> >> >> > As I understand it, the way it works now is that the actual KSK >> rollover won't occur until you execute `rndc dnssec -checkds ...` [1]. >> >> That is correct. >> >> > I'm hopeful that named will fully automate this check at some point >> soon. >> >> It is on the roadmap: >> >> https://gitlab.isc.org/isc-projects/bind9/-/issues/1126 >> >> - Matthijs >> >> >> > [1] < >> https://dnssec-guide.readthedocs.io/en/latest/signing.html#working-with-the-parent-zone-2 >> > >> > >> >> Thank you both very much. I missed that, and I am testing with the > RedHat RHEL7 version of BIND 9.11, which does not seem to wait. Looks like > I will need to run a newer version of BIND, at least on my in-line signing > server. > > -- > Bob Harold > University of Michigan > > If BIND holds both the child and parent zone, will it add the DS record at the correct time? Or do I still need to write scripts to update the DS records in all my sub-zones? And is there some signal from BIND at the time the DS record should be written, or do i need to calculate the right time? -- Bob Harold ___ 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: Ask for automated KSK roll with DS checking
On Thu, Apr 15, 2021 at 2:57 AM Matthijs Mekking wrote: > > > On 14-04-2021 22:30, Greg Rivers via bind-users wrote: > > On Wednesday, 14 April 2021 15:00:38 CDT Bob Harold wrote: > >> Does anyone have an automated KSK roll process, that checks for the DS > >> record at the parent, that they can share? > >> > >> As far as I can tell, the automated signing in BIND will roll the KSK > if I > >> set the timing in the policy file, but it won't check the DS record, so > it > >> will happily break DNSSEC if some other process does not update the DS > >> record at the right time. That's too big a risk for me, the process > needs > >> to check the DS record before completing the KSK roll. Surely someone > has > >> done this. I would rather not reinvent the wheel. But I have searched > and > >> not found anything yet. > >> > > As I understand it, the way it works now is that the actual KSK rollover > won't occur until you execute `rndc dnssec -checkds ...` [1]. > > That is correct. > > > I'm hopeful that named will fully automate this check at some point soon. > > It is on the roadmap: > > https://gitlab.isc.org/isc-projects/bind9/-/issues/1126 > > - Matthijs > > > > [1] < > https://dnssec-guide.readthedocs.io/en/latest/signing.html#working-with-the-parent-zone-2 > > > > > > Thank you both very much. I missed that, and I am testing with the RedHat RHEL7 version of BIND 9.11, which does not seem to wait. Looks like I will need to run a newer version of BIND, at least on my in-line signing server. -- Bob Harold University of Michigan ___ 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
Ask for automated KSK roll with DS checking
Does anyone have an automated KSK roll process, that checks for the DS record at the parent, that they can share? As far as I can tell, the automated signing in BIND will roll the KSK if I set the timing in the policy file, but it won't check the DS record, so it will happily break DNSSEC if some other process does not update the DS record at the right time. That's too big a risk for me, the process needs to check the DS record before completing the KSK roll. Surely someone has done this. I would rather not reinvent the wheel. But I have searched and not found anything yet. -- Bob Harold DNS and DHCP Hostmaster - UMNet Information and Technology Services (ITS) rharo...@umich.edu ___ 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: Options for named startup docker
On Mon, Feb 1, 2021 at 10:29 AM Christian Link wrote: > Hello everyone, > > I am using the BIND Docker image in a Docker Compose setup. In this setup > I would like to disable ipv4 and start the named daemon with the option > "-4". > "-4" means "use IPv4 only" Perhaps you want "-6" to use IPv6 only ? -- Bob Harold > > Normally you can do this via the file /etc/default/named (In the options > variable). Unfortunately, this file is ignored. I also tried it with the > "Environment" parameter in docker-compose.yml, but this does not work > either. > > What possibility do I have to give options to the named daemon without > redefining the start command completely (e.g. via "command")? > > This is my docker-compose.yml > > > version: '3.8' > services: > bind: > image: internetsystemsconsortium/bind9:9.16 > container_name: bind > volumes: > - ./etc/bind:/etc/bind > - ./etc/default/named:/etc/default/named > - ./var/cache/bind:/var/cache/bind > - ./var/lib/bind:/var/lib/bind > - ./var/log:/var/log > ports: > - 53:53/udp > - 53:53/tcp > - 127.0.0.1:953:953/tcp > restart: always > ___ > 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 > ___ 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: How can I launch a private Internet DNS server?
On Thu, Nov 5, 2020 at 7:00 AM Michael De Roover wrote: > On Thu, 2020-11-05 at 11:31 +0100, Alessandro Vesely wrote: > > A good secondary offloads your server > > noticeably, and > > keeps the domain alive in case of temporary failures. > > AFAIK, authoritative slave servers are only used when the master is > confirmed to be down. Lookups take significantly longer in such cases > since for every request, the master will be asked first. This can take > between 2-4s. There are no performance benefits to running multiple > name servers as master-slave, though it's fairly easy and offers good > redundancy (a slow lookup is still better than no lookup). A commercial > service will have to support zone transfer from your master, and said > master has to have that commercial service authorized to pull your > zone(s). I haven't personally heard of such services, and would > probably just run another BIND box somewhere else (different hosting > provider or something like that). > -- > Michael De Roover > You appear to have confused 'secondary' authoritative servers with a second 'resolver'. Authoritative servers - listed in the NS records - are used by other DNS servers, not by end users, and they will get used equally with the slaves, if your parent zone has the right NS records also. Those are good to outsource the secondaries. But a second resolver - the addresses listed in /etc/resolv.conf or the "DNS servers" seen in windows client settings, will only be used by the client if the first server does not respond. For that, you can use a public resolver like Google 8.8.8.8 as the second choice for your users. -- Bob Harold ___ 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: forwarders used in order or based on RTT ?
That is certainly not obvious. How do I request improving the manual? "in turn" would seem to imply "in order", and the order would logically be the order I listed them. -- Bob Harold DNS and DHCP Hostmaster - UMNet Information and Technology Services (ITS) rharo...@umich.edu 734-512-7038 On Fri, Oct 16, 2020 at 10:21 AM Matus UHLAR - fantomas wrote: > On 16.10.20 09:56, Bob Harold wrote: > >The BIND ARM (9.16.2) says: > >"There may be one or more forwarders, and they are queried in turn until > >the list is exhausted > >or an answer is found." > > > >But > >https://lists.isc.org/pipermail/bind-users/2015-August/095544.html > >says: > >"Forwarders are selected based on an RTT(round-trip-time)-based algorithm" > > > >So which is correct? > > both are. The ARM does not say they are queried in defined order. > The order is defined by RTT > > >And did it change at some point? > > -- > 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. > Fucking windows! Bring Bill Gates! (Southpark the movie) > ___ > 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 > ___ 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
forwarders used in order or based on RTT ?
The BIND ARM (9.16.2) says: "There may be one or more forwarders, and they are queried in turn until the list is exhausted or an answer is found." But https://lists.isc.org/pipermail/bind-users/2015-August/095544.html says: "Forwarders are selected based on an RTT(round-trip-time)-based algorithm" So which is correct? And did it change at some point? -- Bob Harold DNS and DHCP Hostmaster - UMNet Information and Technology Services (ITS) rharo...@umich.edu 734-512-7038 ___ 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
BIND log format Splunk regex
I am told from my Splunk experts that the vendor supplied Splunk app for isc-bind matches the BIND 9.8 version used in RHEL6, but not the BIND 9.11 version using in RHEL7. I have a mix now. Does anyone have a REGEX for 9.11, or better yet, a regex that matches both formats? -- Bob Harold ___ 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: How to disable recursion on ONE domain? (Bind-9.11.14)
On Fri, May 15, 2020 at 12:22 PM Chris Palmer via bind-users <
bind-users@lists.isc.org> wrote:
> Hi Ondřej
>
> At first glance your suggestion looked like what I had done. But...
> I used:
>
> view "a" {
>match-clients { 172.16.n.n/24; }
>allow-recursion { any; };
>zone "x.y.zzz" {
> type static-stub;
> server-addresses {
>10.n.n.n;
>10.n.n.m;
> };
>};
> };
>
> If the 10.n.n.n addresses are not reachable, it still recurses and does
> a public query resulting in an NXDOMAIN. However, I don't know what I
> have done differently this time, but the NXDOMAIN is no longer being
> cached. Each attempt causes it to query upstream, and when I bring the
> VPN up it uses the 10.n.n.n server correctly. Which is acceptable,
> although I'm still unsure why it is recursing at all (or at least why I
> can't prevent it).
>
> Out of curiosity I then changed to what you suggested:
>
> view "a" {
>match-clients { 172.16.n.n/24; }
>allow-recursion { any; };
>zone "x.y.zzz" {
> type static-stub;
> server-names {
>"10.n.n.n";
>"10.n.n.m";
> };
>};
> };
>
> This ALWAYS gives a SERVFAIL though regardless of whether the 10.n.n.n
> addresses are reachable or not...
>
"server-names" must be given a list of NAMES, not addresses. "10.n.n.n" is
probably not the right name, looks more like an address.
--
Bob Harold
>
> So I have something that works, although it is sub-optimal when the VPN
> is down.
>
> Cheers, Chris
>
> On 15/05/2020 14:26, Ondřej Surý wrote:
> > Hi Chris,
> >
> > why don’t you just delegate the x.y.zzz to the server in the VPN?
> >
> > Generally, the static-stub should work in this case, but your email
> doesn’t have
> > enough details why it would not.
> >
> > I properly get SERVFAILs with this minimal config:
> >
> > zone "sury.org" {
> >type static-stub;
> >server-names {
> > "192.168.1.1";
> >};
> > };
> >
> > and named -g reports:
> >
> > 15-May-2020 15:25:00.015 network unreachable resolving '192.168.1.1/A/IN':
> 2001:503:c27::2:30#53
> > 15-May-2020 15:25:00.015 network unreachable resolving '
> 192.168.1.1//IN': 2001:503:c27::2:30#53
> >
> > Cheers,
> > Ondrej
> > --
> > Ondřej Surý
> > ond...@isc.org
> >
> >> On 15 May 2020, at 14:40, Chris Palmer wrote:
> >>
> >> Hi Ondřej
> >>
> >> That could work for eliminating the caching delay when the VPN comes
> up. I'd just have to get that into the VPN config so people didn't have to
> do it manually.
> >>
> >> Is there any way to stop the recursion for that domain happening in the
> first place though?
> >>
> >> Thanks, Chris
> >>
> >>
> >> On 15/05/2020 13:34, Ondřej Surý wrote:
> >>> Hi Chris,
> >>> when your vpn comes up, you need to issue:
> >>> rndc flushtree
> >>> command to the BIND 9 instance.
> >>> Ondrej
> >>> --
> >>> Ondřej Surý
> >>> ond...@isc.org
> >>>> On 15 May 2020, at 14:16, Chris Palmer via bind-users <
> bind-users@lists.isc.org> wrote:
> >>>>
> >>>> There is much discussion about recursion but I can't find anything
> that matches this use case...
> >>>>
> >>>> - In-house Bind-9.11.14 server, master for some local zones,
> recursion enabled; not accessible from external networks
> >>>> - Two views for in-house networks
> >>>> - Intermittent VPN access from in-house network to another private
> network that is master for DNS zone x.y.zzz; this network is not publicly
> reachable
> >>>> - Need queries from one of our views for x.y.zzz to be sent to the
> static address for the x.y.zzz server that is only reachable via the VPN
> >>>> - When the VPN is not connected, need the lookup on to fail/timeout
> rather than go through the recursion path
> >>>> - When the VPN is again connected need lookups to succeed without
> undue delay.
> >>>>
> >>>> Within the required view I have tried a zone with type forward
> (specifying forwarders and forward only), and also a zone of type
> static-stub (specifying server-addresses). Both work fine when the VPN is
> up. Both have two problems though when the VPN is disconnected:
> >>>>(a) the queries are recursed and an NXDOMAIN response cached.
> >>>>(b) When the VPN comes back up the cached NXDOMAIN is served
> until it expires.
> >>>>
> >>>> I have been trying to force a SERVFAIL when the specified servers for
> that domain are unreachable, rather than recursing. And presumably that
> would then cause the queries to quickly flow to the required servers once
> they are reachable again. Is that possible, or is there another approach to
> this problem?
> >>>>
> >>>> Many thanks, Chris
>
>
___
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: TSIG DDNS and windows clients
On Wed, May 13, 2020 at 3:49 PM Grant Taylor via bind-users < bind-users@lists.isc.org> wrote: > On 5/13/20 6:29 AM, Bob Harold wrote: > > Your ACL looks right. I think Ben has the key - Windows uses GSS-TSIG, > > not regular TSIG. Not sure how or if that can be solved. > > I would bet someone a coffee and doughnut that it can. > > Check out Jan-Piet Mens' article: > > Link - RFC 2136 Dynamic DNS Updates using GSS-TSIG and Kerberos > - > > https://jpmens.net/2012/06/29/dynamic-dns-updates-using-gss-tsig-and-kerberos/ > > > > -- > Grant. . . . > unix || die > Thanks for the link. Lots of pieces to get working there. Not nearly as simple as TSIG. But good if you are already using Kerberos. -- Bob Harold ___ 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: TSIG DDNS and windows clients
On Wed, May 13, 2020 at 3:20 AM Pete Fry wrote:
> Bob
> thanks for the reply and the correction ( the acl dones't have a ! it was
> a cut and paste error when i was trying to remove some information.
>
> the TSIG works when from other linux machine via nsupdate etc, however i'm
> trying to figure out how to get the windows machines to do the same and was
> trying to follow this
>
> http://serverfault.com/questions/376578/bind9-combining-key-and-acl-for-
> allow-update
>
> Regards
>
> Pete
>
Your ACL looks right. I think Ben has the key - Windows uses GSS-TSIG, not
regular TSIG. Not sure how or if that can be solved.
--
Bob Harold
> On Tue, 12 May 2020 at 13:40, Bob Harold wrote:
>
>>
>> On Tue, May 12, 2020 at 5:57 AM Pete Fry via bind-users <
>> bind-users@lists.isc.org> wrote:
>>
>>> All
>>>
>>> I've inherited a BIND environment and i'm trying to understand a few
>>> things as currently we are experiences an issue related to DDNS.
>>>
>>> we have
>>>
>>> site 1
>>> hostA
>>>
>>> site 2
>>> hostB
>>>
>>> We have a HArecord, and we want HostA or HostB to be able to update the
>>> HArecord (i.e. failover cluster type configuration)
>>>
>>> config:
>>> Zone file:
>>>
>>> zone "TEST" {
>>> check-names ignore;
>>> type master;
>>> file "/var/named/dynamic/TEST";
>>> allow-update {
>>> auth-dns;
>>> dynamic-TEST;
>>> };
>>> };
>>>
>>> lists.conf
>>>
>>> acl dynamic-update-ads {
>>>192.168.2.1 // hostA
>>>192.168.5.1 // hostB
>>>dynamic-TEST-tsig;
>>> };
>>>
>>> acl dynamic-TEST-tsig {
>>>// any host which is not..
>>>!{
>>> // not in the new acls
>>> !dynamic-test-site1;
>>> !dynamic-test-site2;
>>> any;
>>>};
>>>// but has the key
>>>key TEST-key;
>>> };
>>>
>>
>> For testing purposes, start with a simpler acl, like:
>>
>> acl dynamic-TEST-tsig {
>>key TEST-key;
>> };
>>
>> And see if that works.
>>
>>
>>>
>>> acl !dynamic-test-site1 {
>>> 192.168.2.1/32; // HostA
>>> };
>>>
>>> acl !dynamic-test-site2 {
>>> 192.168.5.1/32; // HostB
>>> };
>>>
>>>
>> "acl !" seems wrong to me. Is that a legal syntax? And if so, what does
>> it mean?
>>
>> --
>> Bob Harold
>>
>>
>>> however these windows machines keep saying bad key, I know i'm missing
>>> something obvious but how do i get this to work?
>>>
>>> happy to be able to give the key to the windows boxes if anyone knows but
>>> i'm drawing a blank
>>>
>>> Regards
>>>
>>> Cade
>>>
>>>
>>
>
___
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: What is the proper way to delegate to a private / hidden sub-domain?
On Wed, May 6, 2020 at 3:28 PM Grant Taylor via bind-users <
bind-users@lists.isc.org> wrote:
> On 5/6/20 11:38 AM, Sten Carlsen wrote:
> > I have been doing that for quite some time without knowing it should be
> > difficult.
>
> I'm not saying that it should be difficult. I'm asking what people
> think the proper method is.
>
> > I have a domain (in the mail address) which is properly delegated to
> > servers and signed. Internally in house I have a number of other
> > internal both hosts and one subdomain.
>
> It looks like your domain is delegated to Gratis DNS servers and that
> they resolve specific records to your external IP.
>
> I'm not seeing a delegation beyond that. But that could simply be
> because I don't know what name to query. (AXFRs are properly refused.)
>
> > The internal versions have RFC1812 IPs and the outside ones have public
> IPs.
> >
> > Both sides are signed by the same key.
> >
> > The way this is organised is that I use two views, one internal and one
> > external, I set both to be signed using:
> >
> > options {
> > directory "/var/named/data";
> > auth-nxdomain no;
> > dnssec-enable yes;
> > dnssec-validation auto;
> > allow-query { any; };
> > allow-transfer { any; };
> > listen-on-v6 { any; };
> > sig-validity-interval 30 20;
> > dnssec-loadkeys-interval 60;
> > };
> >
> > Never caused any problems. The downside is that I use views and have to
> > manage both sides.
>
> Your scenario, presuming I understand it correctly, does not match what
> I'm asking about.
>
> I'll try to restate.
>
> I want example.net to:
> - Follow all standard DNS best practices.
> - Delegate lab1.example.net to using the same standard DNS
> best practices.
> - , which is publicly accessible, to host the public
> version of the lab1.example.net zone.
> - , which is not publicly accessible, to host the
> private version of the lab1.example.net zone.
>
> I want clients on the Internet, e.g. you, to be able to "dig +trace a
> host.lab1.example.net" and get a proper DNS delegation chain from root
> zone through net zone through example zone to lab1 zone on the external
> publicly accessible DNS servers.
>
> I want clients in the lab to be able to do the same "dig +trace a
> host.lab1.example.net" and get a proper DNS delegation chain from root
> zone through net zone through example zone to lab1 zone on the internal
> private accessible DNS servers.
>
> The difference is that the external publicly accessible lab1 DNS server
> is a separate server from the internal private accessible lab1 DNS
> server. Separate in the sense that external can be a zone on a VPS
> server and the internal being an isolated VM in the lab. More
> specifically, external public and internal private are NOT even remotely
> the same system thus can't use views or multiple instances of BIND.
>
> E: "." ({a..m}.root-servers.net) -> "net." ({a..m}.root-servers.net) ->
> "example.net." (ns{1,2}.example.net) -> lab1.example.net
> (extns{1,2}.lab1.example.net)
> I: "." ({a..m}.root-servers.net) -> "net." ({a..m}.root-servers.net) ->
> "example.net." (ns{1,2}.example.net) -> lab1.example.net
> (intns{a,b}.lab1.example.net)
>
> As I type the previous lines, I think that the delegation from
> example.net to lab1.example.net will need to be to the same named &
> addressed servers. However, the external and internal servers for
> lab1.example.net are completely different systems and could easily be in
> different parts of the Internet / country / world.
>
> The only way that I see how to make this work is to anycast the names
> and IPs of the name servers that lab1.example.net is delegated to. One
> anycast instance being external publicly accessible and the other
> anycast instance being internal private accessible.
>
> I don't see another way to delegate the same zone to different (sets of)
> name servers without using anycast. Hence my email to the list asking
> if anyone had any suggestions.
>
>
>
> --
> Grant. . . .
> unix || die
>
Good questions. I think one possibility (to avoid anycast) is to have an
internal and external view for the "example.net" zone, so it can delegate
the lab zones to different servers internally and externally. But that can
make the "example.net" zone harder to manage.
It would be easier to have a split view for "split.example.net" and lab
zones "lab#.split.example.net", if the extra level was acceptable.
--
Bob Harold
___
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: Question About Recursion In A Split Horizon Setup
On Fri, Apr 17, 2020 at 12:45 PM Tim Daneliuk wrote: > On 4/17/20 10:17 AM, julien soula wrote: > > On Fri, Apr 17, 2020 at 09:56:21AM -0500, Tim Daneliuk wrote: > >> On 4/17/20 9:50 AM, Bob Harold wrote: > >>> > >>> Agree, that's odd, and not what the man page says. Any chance that > there is some other DNS helper running, like resolved, nscd, dnsmasq, etc? > >> > >> Nope. This is vanilla FreeBSD with vanilla bind running. > >> > >>> 'dig' should tell you what address it used, at the bottom of the > output - what does it say? > >> > >> > >> > >> ;; Query time: 0 msec > >> ;; SERVER: ::1#53(::1) > >> ;; WHEN: Fri Apr 17 09:53:51 CDT 2020 > >> ;; MSG SIZE rcvd: 83 > >> > >> > >> Does the SERVER line indicate it's trying to get to the local instance > via > >> IPV6 or is this just standard notation? (This is an IPV4 only > environment). > > > > "::1" is locahost in IPv6. It is not the same as 127.0.0.1 . A least, > > you should add this IP to trustedhosts to check if it works. > > > > best regard, > > > > > Aha! That was it. What is curious to me is that bind uses this even in > the absence > of any IPV6 in the environment. > > Problem solved. Thanks all! > > > > -- > > > Tim Daneliuk tun...@tundraware.com > PGP Key: http://www.tundraware.com/PGP/ > > As a separate issue: Check the logs to see if BIND is trying to use IPv6 to resolve queries. Look for messages like: address not available resolving with some IPv6 address I have to start named with the "-4" option on my servers that do not yet have IPv6 connectivity. -- Bob Harold ___ 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: Question About Recursion In A Split Horizon Setup
On Fri, Apr 17, 2020 at 11:03 AM Konstantin Stefanov wrote: > On 17.04.2020 17:56, Tim Daneliuk wrote: > > On 4/17/20 9:50 AM, Bob Harold wrote: > >> > >> Agree, that's odd, and not what the man page says. Any chance that > there is some other DNS helper running, like resolved, nscd, dnsmasq, etc? > > > > Nope. This is vanilla FreeBSD with vanilla bind running. > Lately vanilla FreeBSD has unbound as caching and recursive DNS server. > Did you turn it off? > > > > >> 'dig' should tell you what address it used, at the bottom of the output > - what does it say? > > > > > > > > ;; Query time: 0 msec > > ;; SERVER: ::1#53(::1) > > ;; WHEN: Fri Apr 17 09:53:51 CDT 2020 > > ;; MSG SIZE rcvd: 83 > > > > > > Does the SERVER line indicate it's trying to get to the local instance > via > > IPV6 or is this just standard notation? (This is an IPV4 only > environment). > The server is using IPv6 locally, so you need to include "::1" in the "trustedhosts" and view match statements. Or just create /etc/resolv.conf with: nameserver 127.0.0.1 So the man page was right, just not specific. -- Bob Harold > > -- > Konstantin Stefanov > > ___ 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: Question About Recursion In A Split Horizon Setup
On Fri, Apr 17, 2020 at 10:34 AM Tim Daneliuk wrote:
> On 4/17/20 7:26 AM, Bob Harold wrote:
> >
> > On Thu, Apr 16, 2020 at 7:17 PM Tim Daneliuk <mailto:tun...@tundraware.com>> wrote:
> >
> > We have split horizon setup and enable our internal and trusted hosts
> > to do things as follows:
> >
> > allow-recursion { trustedhosts; };
> > allow-transfer { trustedhosts; };
> >
> > 'trustedhosts' includes a number of public facing IPs as well as the
> > 192.168.0/24 CIDR block. It also includes the IPs of the Master and
> > Slave bind servers.
> >
> > So here's the part that has me wondering. If I do a reverse lookup
> of
> > an IP, it works as expected _except_ if I do it on either the Master
> > or Slave machines. They will not only look up reverses on our
> > own IPs, they won't do it for ANY IP and returns the warning:
> >
> > WARNING: recursion requested but not available
> >
> > This is replicable with 9.14 or 9.16 (or was until today's assert
> borkage)
> > running on FreeBSD 11.3-STABLE. Master is on a cloud server, Slave
> is
> > on a physical machine. Neither instance is jailed.
> >
> > Ideas?
> >
> > --
> >
>
> > Tim Daneliuk tun...@tundraware.com <mailto:tun...@tundraware.com
> >
> > PGP Key: http://www.tundraware.com/PGP/
> >
> >
> > Is 127.0.0.1 in the 'trustedhosts' list?
>
> Yes
>
> > Are you telling 'dig' what server to use - dig @*MailScanner warning:
> numerical links are often malicious:* 127.0.0.1 <http://127.0.0.1>
>
> No. But when I do, it works properly. Doesn't dig default to localhost
> (in this case the host running bind)?
>
> > What servers are listed in /etc/resolv.conf? Do they resolve the
> reverse zones?
>
> There is no resolv.conf on these machines. They are the ones running the
> nameservers.
>
> > Are local queries hitting the right 'view' (if you have multiple views) ?
>
> Yes, IF I explicitly point dig to the right nameserver.
>
>
> So ... what's going on is that dig appears to not be using localhost first
> to resolve reverses.
>
>
Agree, that's odd, and not what the man page says. Any chance that there
is some other DNS helper running, like resolved, nscd, dnsmasq, etc?
'dig' should tell you what address it used, at the bottom of the output -
what does it say?
--
Bob Harold
> >
> > --
> > Bob Harold
> >
>
>
> --
>
>
> Tim Daneliuk tun...@tundraware.com
> PGP Key: http://www.tundraware.com/PGP/
>
___
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: Question About Recursion In A Split Horizon Setup
On Thu, Apr 16, 2020 at 7:17 PM Tim Daneliuk wrote:
> We have split horizon setup and enable our internal and trusted hosts
> to do things as follows:
>
> allow-recursion { trustedhosts; };
> allow-transfer { trustedhosts; };
>
> 'trustedhosts' includes a number of public facing IPs as well as the
> 192.168.0/24 CIDR block. It also includes the IPs of the Master and
> Slave bind servers.
>
> So here's the part that has me wondering. If I do a reverse lookup of
> an IP, it works as expected _except_ if I do it on either the Master
> or Slave machines. They will not only look up reverses on our
> own IPs, they won't do it for ANY IP and returns the warning:
>
> WARNING: recursion requested but not available
>
> This is replicable with 9.14 or 9.16 (or was until today's assert borkage)
> running on FreeBSD 11.3-STABLE. Master is on a cloud server, Slave is
> on a physical machine. Neither instance is jailed.
>
> Ideas?
>
> --
>
>
> Tim Daneliuk tun...@tundraware.com
> PGP Key: http://www.tundraware.com/PGP/
Is 127.0.0.1 in the 'trustedhosts' list?
Are you telling 'dig' what server to use - dig @127.0.0.1
What servers are listed in /etc/resolv.conf? Do they resolve the reverse
zones?
Are local queries hitting the right 'view' (if you have multiple views) ?
--
Bob Harold
___
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: DHCPD - BIND DDNS: dnssec-keygen hmac-md5 removed
I would suggest: tsig-keygen your-key-name It does not need any options, the defaults are fine. -- Bob Harold On Fri, Apr 10, 2020 at 7:52 PM moo can via bind-users < bind-users@lists.isc.org> wrote: > Hello, > > For educational purpose I need to setup an DDNS between DCHPD and BIND. > > Everywhere, debian, zytrax, freeipa, veritas ... use dnssec-keygen. > > Zytrax: > dnssec-keygen -a HMAC-SHA512 -b 512 -n HOST keyname > > Veritas: > dnssec-keygen -a HMAC-MD5 -b 128 -n HOST example.com. > > Debian: > dnssec-keygen -a HMAC-MD5 -b 128 -r /dev/urandom -n USER DDNS_UPDATE > > HMAC-* support seems to have been removed from dnssec-keygen > https://gitlab.isc.org/fanf/bind9/commit/80788e72d0698f93e92a0e8f1aa60ff982623997 > > It seems we need to use tsig-keygen but it is not clear. > > I try to follow this guide from debian > https://wiki.debian.org/DDNS#How_to_set_up_DDNS as example but there is no -n > USER or -n HOST option with tsig-keygen. > > I do not find any clear example. > > Thanks you in advance for your help. > > Kind Regards > Fabien > > > > > > > > ___ > 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: Machine friendly alternative to nsupdate
I recently tried using dnspython to replay captured queries and found that it refuses to do any "meta" queries, including "ANY". But since the real world occasionally uses meta queries, I need to be able to make them. I ended up using https://github.com/paulc/dnslib, but I don't see where that handles updates. -- Bob Harold On Wed, Apr 1, 2020 at 9:39 AM Ondřej Surý wrote: > I would recommend dnspython as a start. The API is very non-Python, > but once you get hang of it, it’s not that bad. > > Ondrej > -- > Ondřej Surý > ond...@isc.org > > > On 1 Apr 2020, at 15:21, Petr Bena wrote: > > > > like a "proper DNS library" you talk about, is there any such a thing? > > ___ > 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: Localhost view is not working for me
Try without the "match-destinations". Only use match-clients to determine
the view. (Or try only match-destinations as a separate test.)
(I have never used match-destinations.)
Turn on query logging and see what source and destination your queries are
using. Make fake queries to unique names just to be sure which queries you
are looking at.
That's the best that I can suggest.
--
Bob Harold
On Mon, Mar 30, 2020 at 1:07 PM Marc Chamberlin via bind-users <
bind-users@lists.isc.org> wrote:
> Hello - I am running the Bind server
>
> > named -v
> BIND 9.11.2
>
> under OpenSuSE Leap 15.0. In order to support other servers running on the
> same system that my Bind server is running on I am trying to set up 3
> views, one for the localhost, one for my internal network to use, and one
> for the external Internet. (yes this is also a gateway system with 2 NIC
> cards.) What I am having troubles with is getting the localhost view to
> work properly. I have tried a number of ways to get this to work and will
> show the apropos segment of my named.conf file below. Commented out
> sections show things I have tried already but rejected because the results
> I get from queries, from other servers on this gateway/localhost system,
> that are not what I want. For example if I use the definition in with
> localhost is defined, rather than 127.0.0.1, I will get results that are
> defined by my internal view which is not acceptable. If I use 127.0.0.1
> instead, lookup query results from/for the other servers running on my
> gateway/localhost fail completely with no results returned. I don't
> understand why 127.0.0.1 fails, it seems like this should be the proper way
> to limit the scope of localhost queries so that they are answered by
> definitions defined in my "localhost_resolver" view. What am I missing?
> How to I set up the "localhost_resolver" view so that it will answer
> queries from localhost without falling through to my "internal" view?
> (The keys are also necessary to restrict certain types of queries but I
> tried not using them and got the same inadequate responses to queries from
> the localhost.)
>
> I have also used dig to show exactly what view was answering queries from
> localhost and it verified that the queries were indeed being answered by my
> internal view when I used localhost in the match-clients and
> match-destinations statements. If necessary I can post other files, such
> as the local_zones.conf or some of the domain definition files themselves
> but will have to edit them to remove actual URLs and other sensitive
> information. I checked the log files also, after setting the debug level
> to 10, and the Bind server reports no errors or warnings when it is started
> up. Thanks for any help offered, and below is what I think is the relevant
> part of my named.conf file.
>
> Marc
>
> view "localhost_resolver"
> {
> //match-clients { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; localhost; };
> //match-destinations { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; localhost; };
>
> match-clients { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; 127.0.0.1; };
> match-destinations { ! key letsencrypt.; ! key rndc-key.; !
> key letsencrypt_amcrest.; 127.0.0.1; };
>
> // match-clients { 127.0.0.1; };
> // match-destinations { 127.0.0.1; };
>
> recursion yes;
> zone "." in {
> type hint;
> file "root.hint";
> };
> zone "localhost" in {
> type master;
> file "localhost.zone";
> allow-update { none; };
> };
> zone "0.0.127.in-addr.arpa" in {
> type master;
> file "127.0.0.zone";
> allow-update { none; };
> };
> zone
> "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" in
> {
> type master;
> file "127.0.0.zone";
> };
> include "/etc/named.d/local/local_zones.conf";
> };
>
> view "internal" { // What the home network will see
> // match-clients { ! key letsencrypt.; ! key rndc-key.; ! key
> letsencrypt_amcrest.; localnets; localhost; };
> // match-destinations { ! key letsencrypt.; ! key rndc-key.; ! key
> letsencrypt_amcrest.; localnets; localhost; };
>
> // match-clients { ! key letsencrypt.; ! key rndc-key.; ! key
> letsencrypt_amcrest.; 192.168.10.0/24; 127.0.0.1; };
> // match-destinations {
Re: How to get random subset of large rrset (30+ IPs for round robin)?
On Fri, Mar 20, 2020 at 1:16 PM Warren Kumari wrote: > On Fri, Mar 20, 2020 at 1:04 PM Matus UHLAR - fantomas > wrote: > > > > >On Fri, Mar 20, 2020 at 3:14 AM David Klatt wrote: > > >> I can't find a way to do the following although I invested plenty of > time > > >> in research - maybe you guys have an idea: > > >> > > >> With bind, I'd need to serve a single A record with 30+ IP > addresses and > > >> these addresses have to be returned in random order round robin, > > >> which is done with: > > > > >> Now I'd like bind to just return a random subset of e.g. 5 IP > addresses > > >> if someone requests this A record. > > > > On 20.03.20 10:37, Warren Kumari wrote: > > >I realize that this is the BIND list, but this sounds like an almost > > >perfect example of PowerDNS's LUA record type (or something with > > >CoreDNS) > > >Other than that, the only thing I can think of is BIND with DLZ and a > > >database that returns a random subset from a DB query, but that sounds > > >awful... > > > > I don't think BIND can do this at all. And I don't think it should... > > > > >> Reason for this are in my case some (thousands) older clients (that I > can't control) > > >> that seem not being able to handle that many IPs - the OS resolver > just returns an error. > > > > why no use IPVS-like load balancer and hide all hosts behind one or two > IPs? > > that would help you much more, amongst others when any of those machines > > fails. > > That's almost definitely the right answer, but there *are* cases where > something like what the OP was asking for - 0.pool.ntp.org springs to > mind as one example. > But, yes, a load balancer / anycast is almost definitely going to be a > better choice... > > Warren. > > > > > > > > -- > > 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 > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. >---maf > > Do you know why the OS is having a problem? It just occurs to me that the problem might be that the result does not fit in a UDP packet, (without EDNS?) and the fallback to TCP is not working. Can you try 'dig ...' and 'dig +tcp ...' on that OS to see if both are working? If it is DNS TCP issue, there might be a solution in fixing firewalls/acls/iptables or such. -- Bob Harold ___ 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: bind9 memory leak with TreeMemTotal, and TotalUse stat seems fictional
>From Oct 2019 to Jan 2020 our RedHat RHEL6 BIND DNS servers had a memory leak and the named process had to be restarted weekly or so. Vendor updates caused and later fixed the problem. I do not think that the BIND version changed when it got fixed, so I think it must have been some library. -- Bob Harold On Thu, Feb 27, 2020 at 3:23 PM Alistair Bayley < alistair.bay...@kordia.co.nz> wrote: > Hello, > > I didn't get any response to this. Is there some documentation that I > haven't yet found that explains what these measurements mean? Has anyone > else experienced a similar memory leak with bind9? > > Thanks, > Alistair > > This email and attachments: are confidential; may be protected by > privilege and copyright; if received in error may not be used, copied, or > kept; are not guaranteed to be virus-free; may not express the views of > Kordia(R); do not designate an information system; and do not give rise to > any liability for Kordia(R). > ___ > 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: NS failover as opposed to A record failover
gt; 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 > > Scott, To directly give an opinion on your last question - client applications can often be slow to recover from failed connections, so updating the A records in the zone is a good idea - best to use nsupdate, do not edit zone file and reload. DNS Recursive resolvers should failover in seconds and remember which authoritative servers are down, so don't worry too much about taking down a server for maintenance, just try to keep it short, and only one at a time. -- Bob Harold ___ 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: "overlay" views
On Mon, Jan 20, 2020 at 8:28 AM Brian J. Murrell wrote: > I'm really not sure about what the name of this feature I am going to > describe would be. I would probably call it an "overlay view". But I > am sure there are better names. > > Imagine I have a BIND 9 server for the following network topology: > > > Network 1 > 192.168.1.0/24 > -|.254 | > | Router | > Network 2| | > 192.168.2.0/24 | | > -|.254 | > | | > Network 3| | > 192.168.3.0/24 | | > -|.254 | > > > There are a few dozen hosts/services on Network 3 which hosts from > Network 1 and Network 2 need to resolve names of. All pretty > straightforward. > > But the hosts on Network 1 and Network 2 need to resolve the same name > (let's call it "gateway") to the address of their interface on Router. > So that is, hosts on Network 1 want a query of "gateway." to resolve to > 192.168.1.254 and hosts on Network 2 want a query of "gateway." to > resolve to 192.168.2.254. > > So this is currently all achievable through "views" in BIND 9, but > requires that the zone data for each view be 98% duplicate (Network 3 > resources) and continually copy-n-paste updated whenever names on > Network 3 are added. > > What I am looking for is a way to save the duplicate copying of Network > 3 resources to the views for Network 1 and Network 2. This is where > the term "overlay" comes in. What I'd like to do is reference a single > copy of data from Network 3 in Network 1 and 2's views but "overlay" > some view-specific resources on top of that, namely the "gateway." > name, with it's per-view specific value. > > Thoughts? > > b. > > What I have set up, is for the few names that need to be different, use CNAME to a zone that is different in each view: This zone is same in all views: zone example.com host1.example.com IN A 10.0.0.4 host2.example.com IN A 10.1.1.7 router.example.com CNAME router.splitview.example.com Then in one view: zone splitview.example.com router.splitview.example.com IN A 10.0.0.1 And the other view: zone splitview.example.com router.splitview.example.com IN A 10.1.1.1 Any downsides that I have not thought about? -- Bob Harold ___ 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: What is wrong in the view matching below
On Thu, Dec 5, 2019 at 8:49 AM Harshith Mulky
wrote:
> Thank you. I corrected this
>
> acl internal {
>10.54.8.0/24;
>localhost;
> };
>
> view "external" {
> match-clients { any; };
> recursion no;
> zone "nixcraft.com" IN {
> type master;
> file "internet.master.nixcraft.com";
> };
> };
> view "internal" {
> match-clients { internal; };
> allow-recursion { any; };
> zone "." in {
> type hint;
> file "root.hint";
> };
>
> zone "localhost" in {
> type master;
> file "localhost.zone";
> };
>
> zone "0.0.127.in-addr.arpa" in {
> type master;
> file "127.0.0.zone";
> };
>
> zone
> "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN
> {
> type master;
> file "127.0.0.zone";
> };
>
> zone "internal.nixcraft.com" IN {
> type master;
> file "lan.master.nixcraft.com";
> };
> };
>
>
> But still getting same error
>
> /var/lib/named # named-checkzone internal.nixcraft.com
> lan.master.nixcraft.com
> lan.master.nixcraft.com:3: ignoring out-of-zone data (nixcraft.com)
> lan.master.nixcraft.com:10: ignoring out-of-zone data (nixcraft.com)
> lan.master.nixcraft.com:11: ignoring out-of-zone data (nixcraft.com)
> lan.master.nixcraft.com:13: ignoring out-of-zone data (nixcraft.com)
> lan.master.nixcraft.com:14: ignoring out-of-zone data (nixcraft.com)
> lan.master.nixcraft.com:16: ignoring out-of-zone data (nixcraft.com)
> lan.master.nixcraft.com:17: ignoring out-of-zone data (ns1.nixcraft.com)
> lan.master.nixcraft.com:18: ignoring out-of-zone data (ns2.nixcraft.com)
> lan.master.nixcraft.com:19: ignoring out-of-zone data (mail1.nixcraft.com)
> lan.master.nixcraft.com:20: ignoring out-of-zone data (mail2.nixcraft.com)
> lan.master.nixcraft.com:21: ignoring out-of-zone data (
> out-router.nixcraft.com)
> lan.master.nixcraft.com:23: ignoring out-of-zone data (wks1.nixcraft.com)
> lan.master.nixcraft.com:24: ignoring out-of-zone data (wks2.nixcraft.com)
> lan.master.nixcraft.com:25: ignoring out-of-zone data (wks3.nixcraft.com)
> lan.master.nixcraft.com:26: ignoring out-of-zone data (
> in-router.nixcraft.com)
> zone internal.nixcraft.com/IN: has 0 SOA records
> zone internal.nixcraft.com/IN: has no NS records
> zone internal.nixcraft.com/IN: not loaded due to errors.
>
>
> --
> *From:* Ondřej Surý
> *Sent:* Thursday, December 5, 2019 6:42 PM
> *To:* Sten Carlsen
> *Cc:* Harshith Mulky ;
> bind-users@lists.isc.org
> *Subject:* Re: What is wrong in the view matching below
>
> There’s a space after com
>
> O.
> --
> Ondřej Surý
> ond...@isc.org
>
> > On 5 Dec 2019, at 13:29, Sten Carlsen wrote:
> >
> >>
> >> zone "internal.nixcraft.com " IN {
> >> type master;
> >> file "lan.master.nixcraft.com";
> >> };
> >> };
> >
> > Looks like the file lan.master.nixcraft.com has no data.
> >
> >>
> >> Dec 05 17:51:54 sataradnsVM1 named[4038]: zone
> >> internal.nixcraft.com\032/IN/internal:
> has 0 SOA records
> >> Dec 05 17:51:54 sataradnsVM1 named[4038]: zone
> >> internal.nixcraft.com\032/IN/internal:
> has no NS records
> >> Dec 05 17:51:54 sataradnsVM1 named[4038]: zone
> >> internal.nixcraft.com\032/IN/internal:
> not loaded due to errors.
> >>
> >> Please help
> >>
> >> Thanks
>
named.conf says:
zone "internal.nixcraft.com" IN {
type master;
file "lan.master.nixcraft.com";
But the zone file has:
$ORIGIN nixcraft.com.
Is the zone "nixcraft.com" or "internal.nixcraft.com" ? They need to match.
--
Bob Harold
___
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: Internal CNAME in RPZ
On Thu, Oct 24, 2019 at 9:20 AM Andrey Geyn wrote: > Hi, Bob, thank you for response! > > What if I want to make following configuration (as an example): > > domain.comA10.10.10.10 > *.domain.com CNAMEdomain.com > > I don't want to write 10.10.10.10 twice, I want to use magic of CNAME's > here. > Sorry, that is not how RPZ was designed to work. You can make the second one: *.domain.com CNAMEmy10.realdomain.com. Where there is a real domain (not the RPZ domain) with: my10.realdomain.com. A 10.10.10.10 Or make them both "A" records. Or both CNAME. But one RPZ entry cannot point to another. Use scripts to automate the process, if you don't want to enter 10.10.10.10 twice. p.s. The decision not to re-lookup the results of RPZ lookups is probably for speed and to avoid loops. Trying to patch around that is not a good idea. -- Bob Harold > > > Do you want cname.domain.com to point to 10.10.10.10? Then use an A > record to 10.10.10.10. > This sentence sounds like «CNAME are useless at all» :-). Do you want some > domain to point to some address? The use an A record, not CNAME! > > Additionally, I already use patched version of BIND. Maybe it is possible > to make some patch for allowing this behaivor? > > Andrey > > 24.10.2019, 18:06, "Bob Harold" : > > > On Wed, Oct 23, 2019 at 10:34 AM Andrey Geyn > wrote: > > Hello, I would like to set up RPZ with CNAME and A. There are two options: > > 1. > cname.domain.comCNAME test.domain.com(without trailing dot) > test.domain.com A 10.10.10.10 > > > There is a misunderstanding here. You would never redirect a domain in > RPZ to another domain in RPZ. > Domains in RPZ must always be redirected to a real domain. You cannot > point it to the wrong place, and then expect it to be redirected again. It > does not work that way. > Those two RPZ entries are completely separate. > Do you want cname.domain.com to point to 10.10.10.10? Then use an A > record to 10.10.10.10. > Do you want cname.domain.com to point to some real domain name (probably > a name you control, like a walled garden, or error page)? Then CNAME to > that real name. > > -- > Bob Harold > > > > > In this case I receive > > # dig cname.domain.com @127.0.0.1 > ... > cname.domain.com. 5 IN CNAME test.domain.com.rpz. > test.domain.com.rpz.3600IN A 10.10.10.10 > ... > > So, it looks good, but RPZ name is visible, which is unwanted for me. > > 2. > cname.domain.comCNAME test.domain.com. (with trailing dot) > test.domain.com A 10.10.10.10 > > In this case I receive > > > # dig cname.domain.com @127.0.0.1 > cname.domain.com. 5 IN CNAME test.domain.com. > test.domain.com.531 IN A 66.96.162.92 > > (66.98.162.92 is real, «internet» address of test.domain.com) > > > Is it possible to make configuration for internal CNAME's in RPZ in which > RPZ name will be not visible to user? > > Best regards, > Andrey Geyn > ___ > 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: Internal CNAME in RPZ
On Wed, Oct 23, 2019 at 10:34 AM Andrey Geyn wrote: > Hello, I would like to set up RPZ with CNAME and A. There are two options: > > 1. > cname.domain.comCNAME test.domain.com(without trailing dot) > test.domain.com A 10.10.10.10 > There is a misunderstanding here. You would never redirect a domain in RPZ to another domain in RPZ. Domains in RPZ must always be redirected to a real domain. You cannot point it to the wrong place, and then expect it to be redirected again. It does not work that way. Those two RPZ entries are completely separate. Do you want cname.domain.com to point to 10.10.10.10? Then use an A record to 10.10.10.10. Do you want cname.domain.com to point to some real domain name (probably a name you control, like a walled garden, or error page)? Then CNAME to that real name. -- Bob Harold > > In this case I receive > > # dig cname.domain.com @127.0.0.1 > ... > cname.domain.com. 5 IN CNAME test.domain.com.rpz. > test.domain.com.rpz.3600IN A 10.10.10.10 > ... > > So, it looks good, but RPZ name is visible, which is unwanted for me. > > 2. > cname.domain.comCNAME test.domain.com. (with trailing dot) > test.domain.com A 10.10.10.10 > > In this case I receive > > > # dig cname.domain.com @127.0.0.1 > cname.domain.com. 5 IN CNAME test.domain.com. > test.domain.com.531 IN A 66.96.162.92 > > (66.98.162.92 is real, «internet» address of test.domain.com) > > > Is it possible to make configuration for internal CNAME's in RPZ in which > RPZ name will be not visible to user? > > Best regards, > Andrey Geyn > ___ > 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: dns latency
518400 IN NS j.root-servers.net. > > . 518400 IN NS k.root-servers.net. > > . 518400 IN NS l.root-servers.net. > > . 518400 IN NS m.root-servers.net. > > . 518400 IN NS a.root-servers.net. > > . 518400 IN NS b.root-servers.net. > > . 518400 IN NS c.root-servers.net. > > . 518400 IN NS d.root-servers.net. > > . 518400 IN NS e.root-servers.net. > > . 518400 IN NS f.root-servers.net. > > . 518400 IN NS g.root-servers.net. > > . 518400 IN NS h.root-servers.net. > > ;; Received 239 bytes from 192.5.6.30#53(192.5.6.30) in 32 ms > > > > net.172800 IN NS a.gtld-servers.net. > > net.172800 IN NS b.gtld-servers.net. > > net.172800 IN NS c.gtld-servers.net. > > net.172800 IN NS d.gtld-servers.net. > > net.172800 IN NS e.gtld-servers.net. > > net.172800 IN NS f.gtld-servers.net. > > net.172800 IN NS g.gtld-servers.net. > > net.172800 IN NS h.gtld-servers.net. > > net.172800 IN NS i.gtld-servers.net. > > net.172800 IN NS j.gtld-servers.net. > > net.172800 IN NS k.gtld-servers.net. > > net.172800 IN NS l.gtld-servers.net. > > net.172800 IN NS m.gtld-servers.net. > > net.86400 IN DS 35886 8 2 > 7862B27F5F516EBE19680444D4CE5E762981931842C465F00236401D 8BD973EE > > net.86400 IN RRSIG DS 8 1 86400 > 2019042505 2019041204 25266 . > Uk5bsrr1dgoBFUYfzSYTi6D+QXow1CZglnE3BUZ7I/I0HjuywiSf2YLx > eU1crjlYOJQdYPxDFQIH5/aItTtrM7wgvTOhfhHPHQuAj2f8ovYIlwCt > hguq+9jcNTMAzrUXvi6Tb8oTb36lprYIfg21yO1d8RO6cx3L0dJMcuez > WN2kxNAg+wrx+dWbOexFO7Hs0gzDPpsMx0lEOkJHcfyb/V71AnMV+nob > 48G/azRzQ2fJfs849OyYmjTXA88bAcxxz3kNCoddOfWuMU+WKV5Lfy7J > NkegEfRCzRZYYKiDMwI0zURTg+CdZAYKuxvJQW9ddzSiK5UnYXZVSO1d fPXfYQ== > > ;; Received 1168 bytes from 198.97.190.53#53(h.root-servers.net) in 19 > > ms > > > > comcast.net.172800 IN NS dns101.comcast.net. > > comcast.net.172800 IN NS dns102.comcast.net. > > comcast.net.172800 IN NS dns103.comcast.net. > > comcast.net.172800 IN NS dns104.comcast.net. > > comcast.net.172800 IN NS dns105.comcast.net. > > comcast.net.86400 IN DS 40909 5 2 > 30C0F50E68DCC9A2F279A994C07CF22CED97AADF44C2B1FE38A1B32B A1A34174 > > comcast.net.86400 IN DS 40909 5 1 > DDC19733884EE533B35B4B57717BEA9B0EF2C4D1 > > comcast.net.86400 IN RRSIG DS 8 2 86400 > 20190417054136 20190410043136 51638 net. > l2Vj2W+qzAziqzcC+Y+t4+6b6ADTwyILCzbySVmj5mj5J9vscR4mYf+f > XzNGKen73GecLw+HiwwSzUG8jYkGtvNOMrj9ZbC4v+XWuq0EFcxDEhbJ > yTAq2wPMGD6evSUSDLfqYu8hoJH9svqS06KlBjWkKQqx8X+ZIIqmUMVk ivk= > > ;; Received 612 bytes from 192.42.93.30#53(g.gtld-servers.net) in > > 25090 ms > > > > comcast.net.30 IN A 69.252.80.75 > > comcast.net.30 IN RRSIG A 5 2 30 20190418174157 > 20190411143657 26550 comcast.net. > YegwZlzjBoJ+b9nWTHwRZQbce619UcOVdo6FUPG056Sod4MEchv/GCHu > 7BpREAUm0CBoE4qbipTiS47wIk7QJYzz10B78wRgMGNwMTUXQ571YRyq > P0I3I0Dzag28j607walJOZms3lAXDzSnyvv9wocaH2MJ7Z3j68Qf5pKh YpM= > > ;; Received 227 bytes from 69.252.250.103#53(dns101.comcast.net) in 14 > > ms > > > > ___ > > 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 > > I get 57ms max for the various gtld servers. Could you try this: for x in a b c d e f g h i j k l m; do echo " $x "; dig comcast.net. +norec +noall +auth +stats @$x.gtld-servers.net.; done -- Bob Harold ___ 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: allow-update in global options (was Re: bind and certbot with dns-challenge)
On Wed, Apr 3, 2019 at 7:08 PM Evan Hunt wrote: > On Tue, Apr 02, 2019 at 06:28:02PM +0200, Alan Clegg wrote: > > The answer to your question is: "someone at ISC". > > Oh, I'm willing to take the public blame here, Alan. It's not like the > commits don't have my name on them. > > The code the processes allow-update was written in an oddly circuitious > fashion, and this combined with a badly misleading C comment led me to > believe that allow-update and update-policy had the same rules about > where they could be set - and, update-policy can only be set in zone > statements. (This is personally embarrassing, but if you read the relevant > code and comments in configure_view() you might see how easy it is to be > misled.) > > I actually do still think that *ought* to be the rule for allow-update, > but it wasn't, so when I cleaned things up I cleaned them up wrong, mea > culpa. > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. > > I think we should simplify the rules (and probably the code) to simply say: "Options can be set at any level and apply to everything included in that scope, unless overridden." Why have exceptions to this? This seems like expected behavior, and will allow for simpler configurations in some cases. No one is forced to use this, it is optional, but often convenient. -- Bob Harold ___ 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: allow-update in global options (was Re: bind and certbot with dns-challenge)
On Mon, Mar 18, 2019 at 5:26 PM Grant Taylor via bind-users <
bind-users@lists.isc.org> wrote:
> On 3/18/19 1:32 PM, Victoria Risk wrote:
> > - We have decided to treat this change as a regression bug, and to fix
> > it in 9.14.1. Alan argued that we should hold 9.14.0 and fix it there:
> > however we have decided to go ahead with 9.14.0 with the change we
> > already made in allow-update, which we will highlight in the release
> > notes as a ‘known issue'. People who rely on a global-allow-update will
> > simply have to wait for 9.14.1 where we will attempt to restore the
> > prior behavior. This is not a ’neat’ resolution, as it violates our
> > normal policy of not changing configuration defaults in the middle of a
> > stable branch, but it should be an adequate solution.
>
> From my naive point of view, this seems perfectly reasonable. I hoist
> my drink to the global community and the ISC community for the the
> efforts and discussions that have ensued over this.
>
> > - Reasonable people (some of my colleagues at ISC) feel that users may
> > ’self-foot-shoot’ with an inherited allow-update, and that the inherited
> > behavior may not be obvious (similar options such as update-policy are
> > not inherited). At ISC we hear not infrequently from people who have
> > inherited a BIND implementation after the original administrator left,
> > and they are maintaining a configuration they don’t understand. This
> > experience, coupled with a generally increasing concern about DNS
> > security makes a reasonable argument for limiting opportunities to
> > ‘accidentally’ allow updates when adding new zones.
>
> As I was reading this, I found myself wondering if there is (I'll go
> look in a few minutes) an ability to have BIND dump the config it has
> read in. Or conversely dump what it thinks the effective config is.
> The difference being an (inadvertent) global option { allow-update {…};
> }; could be omitted from the global options {…}; section but included in
> each zone {…}; section.
>
> Perhaps something like this would help people identify what the
> effective config is. I think it would help people produce config files
> that match (or approach) the output of such a utility.
>
> I would be tempted to have said utility omit comments, at least by
> default. After all, that's not the config in memory. Perhaps an option
> to pass comments from config file(s) through unmodified and possibly out
> of context would be of value.
>
>
>
> --
> Grant. . . .
> unix || die
>
I use:
named-checkconf -p > named.conf.out
which I think is close enough, except for the comments.
You just need to know that view-level settings are at the end of the view,
not where you might expect.
It makes for a very lot of text to read through, but it is a 'standardized'
format.
--
Bob Harold
___
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: allow-update in global options (was Re: bind and certbot with dns-challenge)
On Sun, Mar 17, 2019 at 4:38 PM Alan Clegg wrote: > On 3/17/19 2:51 PM, Alan Clegg wrote: > > On 3/17/19 7:13 AM, Stephan von Krawczynski wrote: > >> Hello all, > >> > >> I am using "BIND 9.13.7 (Development Release) " on arch > linux. Up > >> to few days ago everything was fine using "certbot renew". I had > >> "allow-update" in nameds' global section, everything worked well. > Updating to > >> the above version threw a config error that "allow-update" has no > global scope > >> and is to be used in every single zone definition. > > > > And you may have found a bug. I'm checking internally at this time. > > So, after a discussion with one of the BIND engineers this afternoon, > this turned out to be quite an interesting and deep-rooted issue. > > During a cleanup of other code (specifically named-checkconf), code was > changed that enforced what was believed to have been the default > previously: specifically, allow-update was only allowed in zone stanzas. > The chain of changes follows: > > 5136. [cleanup] Check in named-checkconf that allow-update and > allow-update-forwarding are not set at the > view/options level; fix documentation. [GL #512] > > This, if the change remains, will be updated to [func] and additional > documentation will be added to the release notes. > > The other changes down this long and twisting passage are: > > 4836. [bug] Zones created using "rndc addzone" could > temporarily fail to inherit an "allow-transfer" > ACL that had been configured in the options > statement. [RT #46603] > > and > > 2373. [bug] Default values of zone ACLs were re-parsed each >time a new zone was configured, causing an >overconsumption of memory. [RT #18092] > > It turns out that this series of changes, taken as a whole, removed > allow-update as a global option. > > The question now becomes: Is there a need for the ability to apply > allow-update across all zones in your configuration? > > Smaller operators should be able to add the allow-update per zone very > easily, and large operators should (probably) be doing things at a much > more granular level. > > I'm sure that there will be internal discussion here at ISC regarding > this topic over the next week. > > We are hoping to release 9.14.0 soon and this would be an "allowed" > change (at a .0 release). If we don't make this change in 9.14.0, it > won't be allowed in an official production release until 9.16.0 due to > the "no changes to the configuration file except at .0 releases" rule. > > At this moment, I (personally) believe that the change is fixing a bug, > as "allow-update" was not planned and is not a good idea at the global > option level. I believe that it should be allowed only in zone stanzas. > > If you have thoughts/opinions, please let us know! > > Alan Clegg, ISC > Thanks for the explanation, and for asking for input. And thanks for maintaining BIND, we depend on it. My group manages about 3000 zones. In my opinion, 'everything' should be inherited, to make the configuration as simple as possible. And it should be possible to override any setting at a lower level, for the exceptions. It would be even better if I could 'group' zones and set configurations on the group. Repeating the same configuration thousands of times seems like a waste. I would even set "masters" and 'type' at the top level if I could, since 90% of my zones come from the same hidden master. And if the file name could have a default or a pattern, that could be set at the top also, leaving only a list of zones names for most zones. If you make the change, I can live with it, but it is not my preference, and does not seem like an improvement. -- Bob Harold ___ 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: Advice for DNS reverse zones
On Wed, Feb 6, 2019 at 1:03 PM Mik J via bind-users < bind-users@lists.isc.org> wrote: > Hello, > > I would like to know how do you manage reverse zones and the 10.x.x.x zone > particularly. > > I can see three choices: > - One global 10.in-addr.arpa zone > - Many /24 zones 1.1.10.in-addr.arpa zone > - Something in between > > One global zone: > The problem is that I end having a very populated zone and if someone asks > me to setup an acl or anything like that it has to be global. > This solution might be the easiest but definatly not the best in terms of > scalability > > Many /24 zones: > The problem is that I end creating zones all the time or make them first > in one go, so 65536 zones... > And when someone has a /16 network I need to delete the 256 x /24 zones to > make one single. > > What do you people do on your DNS servers ? > > And is it possible to make a 1.1.10.in-addr.arpa for the 16 first > adresses (a /28 network) ? > > Regards > For ranges with few records, that don't need to be acl'ed or delegated, put them in the 10.in-addr.arpa zone. Any /16 that has a lot of records can be split off into its own 2.10.in-addr.arpa. An if a /24 gets really busy, you can split it out 5.1.10.in-addr.arpa There is no need to create all 256 /16's or all the /24's, just create them as needed. If having different sizes is too confusing, I suggest all /16's. -- Bob Harold ___ 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: Selective forwarding?
On Tue, Jan 29, 2019 at 10:56 AM @lbutlr wrote: > > > > On 29 Jan 2019, at 00:25, ObNox wrote: > > > > On 24/01/2019 10:26, Sam Wilson wrote: > > > >>>> Note: I'm assuming a zone expiry of a week to a month. I think that > would accommodate most outages. > >>> > >>> I thought of that too :-) A week would be far enough in my case. > >> Be careful of what you mean by "a week". If a problem happens on a > Friday just after you leave for a week's holiday/vacation then you need a > 10-day timeout to be able to fix it on the Monday you come back. > > > > Sorry for the late reply. > > > > I really like how sysadmins think :-) I always take that into account. > When I setup something to a "week" or a "month", in reality it's > + 2~3 days depending on the situation. > > A "week" is a minimum of 10 days, because 5 works days plus two weekends > in 9 days. > I also assume that either the Friday before their vacation week, or the Monday after, might be a holiday, so I use 11 days. :) -- Bob Harold ___ 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: RPZ question autoritative/recursive servers
On Tue, Jan 22, 2019 at 9:41 AM Mik J via bind-users < bind-users@lists.isc.org> wrote: > Hello, > > I tried to dissociate roles and have: > - 1 set of authoritative master/slave server > - 1 set of recursive servers > > For a zone that I owned, the "recursive" servers forwards the request to > the authoritative server. Otherwise the server resolves the query directly > on the Internet. > The authoritative servers hold my zones and recursion is disabled. > > I was reading about RPZ zones but it seems to me these are implemented on > authoritative servers ? > I'm interested in RPZ zone in order to intercept some queries aiming to > the internet youp*rn or wannacry. > > As I explained, my authoritative servers are not on the path to Internet, > only my forward servers are, should I implement the RPZ functionality on > these forward only servers ? > > Any thoughts on this ? > > Thank you > The RPZ function only runs on the Recursive DNS servers. The RPZ zone could be mastered on an Authoritative server, but it should not be visible to the public. Better to keep it only on internal servers, like only on the resolvers. -- Bob Harold ___ 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: Questions about delegation
On Wed, Dec 19, 2018 at 10:51 AM Bob McDonald wrote: > I have a DNS server that serves a zone for domain example.org. > That DNS server lives at 192.0.2.53 > As part of hosting that domain, a child domain is delegated. ( > gtm-int.example.org.) > There are two NS records as follows: > gtm-int.example.org. IN NS gtm-int-east.example.org. > gtm-int.example.org. IN NS gtm-int-west.example.org. > gtm-int-east.example.org. IN A 203.0.113.53 > gtm-int-west.example.org. IN A 198.51.100.53 > (and yes, in this case the delegated child domain lives on two F5 GTMs) > > The devices hosting the delegated child domain both contain NS records > which match the parent's NS records for the child domain and they contain > glue records which also match the parent's A records for the NS records. > > Here are my curiosities: > > 1) should the NS records for the delegated child domain be hosts which > reside in the parent domain or the delegated child domain? (or does it > matter as long as the glue is correct?) > gtm-int.example.org. IN NS gtm-int-east.example.org. > gtm-int.example.org. IN NS gtm-int-west.example.org. > gtm-int-east.example.org. IN A 203.0.113.53 > gtm-int-west.example.org. IN A 198.51.100.53 > -OR- > gtm-int.example.org. IN NS gtm-int-east.gtm-int.example.org > <http://gtm-int-east.example.org/>. > gtm-int.example.org. IN NS gtm-int-west.gtm-int.example.org > <http://gtm-int-west.example.org/>. > gtm-int-east.gtm-int.example.org <http://gtm-int-east.example.org/>. IN A > 203.0.113.53 > gtm-int-west.gtm-int.example.org <http://gtm-int-west.example.org/>. IN A > 198.51.100.53 > > 2) Do I need to specify a null forwarder statement for the parent domain? > (to prevent query forwarding to the delegated child domain) > > Regards, > > Bob > If I get this wrong, someone will correct me. But as I understand it... 1. Your choice. Glue is needed if the servers are in the child zone. 2. No. I don't know what a "null" forwarder statement is, but your F5's are acting as Authoritative DNS servers. Forwarding only applies to DNS Resolvers, and is only used if you don't want the resolver to follow the NS records (like when firewalls are in the way). -- Bob Harold ___ 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: 2 Questions - forward zone and DNS firewalling
On Thu, Oct 25, 2018 at 4:34 PM N6Ghost wrote: > Hi All, > > have two questions first, I am not a huge fan of using forwarding zones > and our "load balancing" team, has there zone delegated to them in a > way that needs an internal forward zone to work properly on the inside > and not rely on on internet POP. > > I want to move a core namespace to the load balancer but i want them to > let me assign them a new zone thats internally authoritative and use it > as the LB domain. > > which would be: > cname name.domain.com -> newname.newzone.domain.com > > they want: > cname name.domain.com -> newname.oldzone.domain.com > > old zone is directly delagated from outside to them so we need an > internal forward zone for it. i dont want to rely on that. > > any thoughts on this? what can i use to present to management to win > this? > The users should never see the domain that the CNAME points at, it is just an internal name used by DNS. If they can change where " newname.oldzone.domain.com" points more easily than " newname.newzone.domain.com" then they might have a valid reason to want it. Otherwise, newname.newzone.domain.com will be a faster and more reliable choice. Definitely avoid forwarding when possible. It causes slower lookups and more points of failure. (There will occasional be times when it has some advantage, or requirement.) -- Bob Harold > > next, we where a bind shop but switched to infoblox for some stuff and > now out grew it. and are going back to bind. > > but we started using the dns firewall part of it and they actually > really liked it. any ideas for domain blacklisting? via some sort of > feed etc? what is everyone doing for that sort of thing? > > thanks > > -N6Ghost > ___ > 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: Modifying data files while named is reloading
On Thu, Oct 18, 2018 at 9:01 AM Laurent Weislo wrote: > Hi, > > We had a strange behaviour with our old master running bind version: 9.3.6 > release: 20.P1.el5. > > We modify NSC m4 data files when adding one or more A records and use the > make command to build the full environment on the master itself. At the end > of the build, an HUP signal is sent to the named process. After the signal > is sent, if a new change comes in, the process occurs again, thus modifying > the files (that are supposed to be already loaded by named). > After a bunch of years and under heavy load on the master, we lost almost > 4K records because the domain file seems to have been loaded while being > generated. > > My questions are: > - is 'rndc reload' returning when all zone files have been reloaded or is > it returning while the loading process is ongoing ? > I believe that rndc returns immediately, while the loading process is just starting. > - same question with sending a HUP signal ? does it behave like 'rndc > reload' ? > Signals like 'HUP' always return immediately, they have no way of knowing what the process will do with the signal, if anything. > - how to ensure that named has loaded the files before modifying them > again since they are at the same location ? > Good question. For sure, as Anne says, you want to build temporary files and 'move' them to the final location, so that there are never partial files in place. > > The log message reports 'loading configuration', but why not > 'configuration files loaded' ? > I believe that the process starts with: 18-Oct-2018 12:55:29.975 general: info: received control channel command 'reload' 18-Oct-2018 12:55:29.975 general: info: loading configuration from '/etc/named.conf' And ends with: 18-Oct-2018 12:55:30.358 general: notice: all zones loaded -- Bob Harold > > Below is the event timeline, I hope it is clear enough for everyone: > 1. Oct 16 17:24:18 SLAVE1 named[29671]: [ID 873579 daemon.info] transfer > of 'our.domain.com/IN' from 192.168.122.100#53: Transfer completed: 10 > messages, *14890* records, 413507 bytes, 0.249 secs (1660670 bytes/sec) > 2. (10/16/2018 17:28:57.202:1683726) : user pid=7501 uid=root > auid=unknown(65030) msg='cmd=/sbin/service named reload (terminal=? > res=success)' > 3. Oct 16 17:28:57 MASTER named[3292]: loading configuration from > '/etc/named.conf' -> 2018101639 > 4. AUTOMATION TOOL:16-10 17:28:57 newhostname 1045 Add DNS START > 5. 2018-10-16 17:29:00 +0200 (Tue, 16 Oct 2018) | 1 line IDXXX: Add DNS > entry newhostname with 10.10.10.10 | r20907 | > 6. Oct 16 17:29:02 MASTER named[3292]: zone/our.domain.com:11473: file > does not end with newline<- NSC make is running, generating new files > because newhostname is added to a m4 file. > 7. Oct 16 17:29:02 MASTER named[3292]: zone our.domain.com/IN: loaded > serial 2018101640 > 8. Oct 16 17:29:02 MASTER named[3292]: zone our.domain.com/IN: sending > notifies (serial 2018101640) > 9. Oct 16 17:29:19 SLAVE1 named[29671]: [ID 873579 daemon.info] transfer > of 'our.domain.com/IN' from 192.168.122.100#53: Transfer completed: 7 > messages, *10806* records, 302763 bytes, 0.192 secs (1576890 bytes/sec) > 10. (10/16/2018 17:34:27.798:1683828) : user pid=12079 uid=root > auid=unknown(65030) msg='cmd=/sbin/service named reload (terminal=? > res=success)' > 11. Oct 16 17:34:27 MASTER named[3292]: loading configuration from > '/etc/named.conf' -> 2018101640 > 12. AUTOMATION TOOL:16-10 17:34:28 newhostname 1045Add DNSSUCCESS > 13. Oct 16 17:34:33 MASTER named[3292]: zone our.domain.com/IN: zone > serial unchanged > 14. Oct 16 17:34:33 MASTER named[3292]: zone our.domain.com/IN: loaded > serial 2018101640 > 15. Oct 16 17:34:33 MASTER named[3292]: zone our.domain.com/IN: sending > notifies (serial 2018101640) > 16. (10/16/2018 17:39:59.934:1683878) : user pid=15753 uid=root > auid=unknown(65030) msg='cmd=/sbin/service named reload (terminal=? > res=success)' > 17. Oct 16 17:40:52 SLAVE1 named[29671]: [ID 873579 daemon.info] transfer > of 'our.domain.com/IN' from 192.168.122.100#53: Transfer completed: 10 > messages, *14893* records, 413605 bytes, 0.255 secs (1621980 bytes/sec) > > > Thank you for you help and sorry to bother you with 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 > ___ 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: Zone transfer failure
On Wed, Oct 17, 2018 at 9:56 AM Andreas Brandino wrote:
> Both servers receive the NOTIFY message from NS1. What I see on the logs:
>
> *NS3:*
> 17-Oct-2018 16:41:00.688 notify: info: client 1.1.1.1#19513/key
> ns1ns3_key: view external: received notify for zone 'myzone.com': TSIG
> 'ns1ns3_key'
>
Notice the "view external" in the line above, compared to ns5, which got
the notify on the internal view. That appears to be the issue.
Try adding the IP of NS1 to the "match" list for the internal view on NS3.
--
Bob Harold
> *NS5:*
> 17-Oct-2018 16:40:56.131 notify: info: client 1.1.1.1#32586/key
> ns1ns5_key: received notify for zone 'myzone.com': TSIG 'ns1ns5_key'
> 17-Oct-2018 16:40:56.139 notify: info: zone myzone.com/IN: sending
> notifies (serial 2018101910)
>
> The 2nd line is missing on NS3.
> At this point NS5 starts the zone copy (*NS1 *logs):
>
> 17-Oct-2018 16:41:01.233 xfer-out: info: client 5.5.5.5#40909/key
> ns1ns5_key (myzone.com): view internal: transfer of 'myzone.com/IN': AXFR
> started: TSIG ns1ns5_key
> 17-Oct-2018 16:41:01.234 xfer-out: info: client 5.5.5.5#40909/key
> ns1ns5_key (myzone.com): view internal: transfer of 'myzone.com/IN': AXFR
> ended
>
> At this point NS3 does nothing.
>
> This is not a firewall or networking problem because I can start the
> transfer manually.
>
> Best Regards
>
> Στις Τετ, 17 Οκτ 2018 στις 4:35 μ.μ., ο/η Bob Harold
> έγραψε:
>
>>
>> On Wed, Oct 17, 2018 at 7:23 AM Andreas Brandino
>> wrote:
>>
>>> Hello all,
>>>
>>> I wonder if anyone can help me to find the cause of the problem I am
>>> currently having.
>>> All servers are running on Debian and BIND 9.10.3-P4-Debian.
>>>
>>> I have a master server and 4 slaves.
>>> The zone is transfered from the master [ns1] to all slaves [ns3,ns4,ns5
>>> and ns6].
>>> I am also using TSIG with a different key for each server.
>>> Moreover, the zone file refers to the internal view.
>>>
>>> When I change the myzone.com, I always update the serial and I reload
>>> the zone.
>>>
>>> The problem:
>>> ns3 and ns4 never get the updated zone file automatically.
>>> On the other hand, ns4 and ns5 always get the updated zone file
>>> immediately.
>>>
>>> If I initialize the transfer manually from ns3 and ns4, I get no errors.
>>>
>>> Here is the config:
>>>
>>> NS1 config: (IP 1.1.1.1 - master DNS)
>>>
>>> zone "myzone.com" {
>>> type master;
>>> file"/etc/bind/master/myzone.com.INSIDE";
>>> allow-transfer { key ns1ns3_key; key ns1ns4_key; key
>>> ns1ns5_key; key ns1ns6_key; };
>>> also-notify {
>>> 3.3.3.3 port 53 key ns1ns3_key;
>>> 4.4.4.4 port 53 key ns1ns4_key;
>>> 5.5.5.5 port 53 key ns1ns5_key;
>>> 6.6.6.6 port 53 key ns1ns6_key;
>>> };
>>> notify explicit;
>>> notify-source 1.1.1.1 ;
>>> };
>>>
>>>
>>> NS3 config: (IP 3.3.3.3 - transfer fails)
>>>
>>>zone " myzone .com" {
>>> file"/etc/bind/master/myzone.com.INSIDE";
>>> type slave;
>>> allow-update { key ns1ns3_key; };
>>> masters { 1.1.1.1; };
>>> allow-notify { 1.1.1.1; };
>>> notify yes;
>>> request-ixfr no;
>>> };
>>>
>>> NS5 config: (IP 5.5.5.5, successful transfer)
>>>
>>> zone "myzone.com" {
>>> file"/etc/bind/master/myzone.com.INSIDE";
>>> type slave;
>>> allow-update { key ns1ns5_key; };
>>> masters { 1.1.1.1; };
>>> notify yes;
>>> request-ixfr no;
>>> };
>>>
>>> Do you see any errors in the above configuration that could cause this
>>> problem?
>>>
>>> Best Regards
>>>
>>
>> What you don't show is the 'match' statement for your views. Perhaps 1
>> does not match the internal view on 3, so the notify packet hits the wrong
>> view. Check the notify messages in the logs on 3, compared to 5. Here is
>> a typical notify log message:
>>
>> 30-Sep-2018 23:12:37.135 general: info: zone
>> psych.lsa.umich.edu/IN/oncampus: notify from 141.211.147.150#38695: zone
>> is up to date
>>
>>
>> Note the zone/class/view contains ".../IN/oncampus" - check the view in
>> your logs.
>>
>>
>> If you cannot find the notify, you might need to turn on logging for
>> category "general". Or check routing and firewall rules if the packet is
>> not being received.
>>
>>
>> --
>>
>> Bob Harold
>>
>>
>>
___
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: Zone transfer failure
On Wed, Oct 17, 2018 at 7:23 AM Andreas Brandino wrote:
> Hello all,
>
> I wonder if anyone can help me to find the cause of the problem I am
> currently having.
> All servers are running on Debian and BIND 9.10.3-P4-Debian.
>
> I have a master server and 4 slaves.
> The zone is transfered from the master [ns1] to all slaves [ns3,ns4,ns5
> and ns6].
> I am also using TSIG with a different key for each server.
> Moreover, the zone file refers to the internal view.
>
> When I change the myzone.com, I always update the serial and I reload the
> zone.
>
> The problem:
> ns3 and ns4 never get the updated zone file automatically.
> On the other hand, ns4 and ns5 always get the updated zone file
> immediately.
>
> If I initialize the transfer manually from ns3 and ns4, I get no errors.
>
> Here is the config:
>
> NS1 config: (IP 1.1.1.1 - master DNS)
>
> zone "myzone.com" {
> type master;
> file"/etc/bind/master/myzone.com.INSIDE";
> allow-transfer { key ns1ns3_key; key ns1ns4_key; key
> ns1ns5_key; key ns1ns6_key; };
> also-notify {
> 3.3.3.3 port 53 key ns1ns3_key;
> 4.4.4.4 port 53 key ns1ns4_key;
> 5.5.5.5 port 53 key ns1ns5_key;
> 6.6.6.6 port 53 key ns1ns6_key;
> };
> notify explicit;
> notify-source 1.1.1.1 ;
> };
>
>
> NS3 config: (IP 3.3.3.3 - transfer fails)
>
>zone " myzone .com" {
> file"/etc/bind/master/myzone.com.INSIDE";
> type slave;
> allow-update { key ns1ns3_key; };
> masters { 1.1.1.1; };
> allow-notify { 1.1.1.1; };
> notify yes;
> request-ixfr no;
> };
>
> NS5 config: (IP 5.5.5.5, successful transfer)
>
> zone "myzone.com" {
> file"/etc/bind/master/myzone.com.INSIDE";
> type slave;
> allow-update { key ns1ns5_key; };
> masters { 1.1.1.1; };
> notify yes;
> request-ixfr no;
> };
>
> Do you see any errors in the above configuration that could cause this
> problem?
>
> Best Regards
>
What you don't show is the 'match' statement for your views. Perhaps 1
does not match the internal view on 3, so the notify packet hits the wrong
view. Check the notify messages in the logs on 3, compared to 5. Here is
a typical notify log message:
30-Sep-2018 23:12:37.135 general: info: zone psych.lsa.umich.edu/IN/oncampus:
notify from 141.211.147.150#38695: zone is up to date
Note the zone/class/view contains ".../IN/oncampus" - check the view in
your logs.
If you cannot find the notify, you might need to turn on logging for
category "general". Or check routing and firewall rules if the packet is
not being received.
--
Bob Harold
___
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: Issues configuring delegated subdomain zone
On Wed, Sep 12, 2018 at 5:49 AM BARAJAS BERMEJO, Sergio < sergio.bara...@econocom.com> wrote: > Hello, > I have an issue configuring delegated subdomain zone from one NS to > another one. > For security reasons I will obviously not put real domain data (I imagine > you will understand). > > Let's suppose that the delegated subdomain is: > midominio.principal.hosting.com > If we make a "dig" query, putting the hosting server's NS as the domain > name server: > > > > > > > > > > > > > > > > > > > > > > > > > > > > *dig @ns1.hosting.com <http://ns1.hosting.com> > midominio.principal.hosting.com <http://midominio.principal.hosting.com> ; > <<>> DiG 9.10.3-P4-Debian <<>> @ns1.hosting.com <http://ns1.hosting.com> > midominio.principal.hosting.com <http://midominio.principal.hosting.com> ; > (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- > opcode: QUERY, status: NOERROR, id: 40831 ;; flags: qr rd; QUERY: 1, > ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3 ;; WARNING: recursion requested but > not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: ;midominio.principal.hosting.com > <http://midominio.principal.hosting.com>. IN A ;; AUTHORITY SECTION: > midominio.principal.hosting.com <http://midominio.principal.hosting.com>. > 125 IN NS sb2.principal.hosting.com <http://sb2.principal.hosting.com>. > midominio.principal.hosting.com <http://midominio.principal.hosting.com>. > 125 IN NS sb1.principal.hosting.com <http://sb1.principal.hosting.com>. ;; > ADDITIONAL SECTION: sb1.principal.hosting.com > <http://sb1.principal.hosting.com>. 125 IN A xxx.xxx.xxx.52 > sb2.principal.hosting.com <http://sb2.principal.hosting.com>. 125 IN A > xxx.xxx.xxx.53 ;; Query time: 12 msec ;; SERVER: > 31.193.224.20#53(31.193.224.20) ;; WHEN: Wed Sep 12 08:09:36 CEST 2018 ;; > MSG SIZE rcvd: 133* > > From which we deduce several things: > > >1. That in the zone principal.hosting.com of the main server of the >hosting there are created two registers of type A: >1. > *sb1.principal.hosting.com <http://sb1.principal.hosting.com>. 125 IN A > xxx.xxx.xxx.52 sb2.principal.hosting.com > <http://sb2.principal.hosting.com>. 125 IN A xxx.xxx.xxx.53* >2. That the authorized DNS servers on the subdomain >midominio.principal.hosting.com are: >*sb1.principal.hosting.com <http://sb1.principal.hosting.com>* y el > *sb2.principal.hosting.com ><http://sb2.principal.hosting.com>* > > Having said that, in my vps I have defined the following: > > > > > > > *; BIND reverse data file for empty rfc1918 zone ; ; DO NOT EDIT THIS FILE > - it is used for multiple zones. ; Instead, copy it, edit named.conf, and > use that copy. ; * > *$TTL 86400* > > *@ IN SOA sb1. sb2. mail. (* > The first field after "SOA" is the *ONE* master server for the domain. You cannot list two. Should be: @ IN SOA sb1. mail. ( -- Bob Harold > > > > > > > * 10 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 86400 ) ; > Negative Cache TTL ; REGISTROS NS sb1.* > *principal.hosting.com <http://principal.hosting.com>. NS sb2.* > *principal.hosting.com <http://principal.hosting.com>. IN MX 10 mail.* > *midominio.principal.hosting.com <http://midominio.principal.hosting.com>. > sb1 IN A * > *xxx.xxx.xxx.52 sb2 IN A * > *xxx.xxx.xxx.53 www IN A * > *xxx.xxx.xxx.53 mail IN A * > > *xxx.xxx.xxx.53 webmail IN CNAME mail * IN A **xxx.xxx.xxx.53* > > > However I can not get it to solve for example > www.midominio.principal.hosting.com What am I doing wrong?. > Thank you very much in advance > > ___ > 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: SRV record not working
On Fri, Aug 17, 2018 at 1:28 PM Thomas Strike wrote: > I have created a SRV record for a new subdomain A record. I set nslookup > to use my DNS server directly and when I query for the A record it > returns it. When I set type=SRV and ask for the srv record nothing is > returned. > > My SRV record: _minecraft._tcp.skyblock.mc-game.us.IN SRV0 5 > 25567 skyblock.mc-game.us. > > I need a 2nd pair of eyes on this one. > > Thanks, Tom Strike > > Works for me: nslookup -q=srv _minecraft._tcp.skyblock.mc-game.us. 8.8.8.8 Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: _minecraft._tcp.skyblock.mc-game.us service = 0 5 25567 skyblock.mc-game.us. Authoritative answers can be found from: dig srv _minecraft._tcp.skyblock.mc-game.us. @8.8.8.8 ; <<>> DiG 9.10.3-P4-Ubuntu <<>> srv _minecraft._tcp.skyblock.mc-game.us. @ 8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53437 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;_minecraft._tcp.skyblock.mc-game.us. IN SRV ;; ANSWER SECTION: _minecraft._tcp.skyblock.mc-game.us. 299 IN SRV 0 5 25567 skyblock.mc-game.us. ;; Query time: 56 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Fri Aug 17 13:38:35 EDT 2018 ;; MSG SIZE rcvd: 103 -- Bob Harold ___ 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: Need help on RPZ sever, bit urgent
I don't know what else to check. If possible, I would avoid forwarding by
putting both functions on the same server. You could turn on BIND
debugging - Cricket's "DNS and BIND" book has a chapter on debugging - but
that could be a lot of work.
--
Bob Harold
On Mon, Aug 13, 2018 at 10:58 AM Blason R wrote:
> Its there!!!
>
> On Mon, Aug 13, 2018 at 6:58 PM Bob Harold wrote:
>
>>
>>
>> --
>> Bob Harold
>> hostmaster, UMnet, ITcom
>> Information and Technology Services (ITS)
>> rharo...@umich.edu
>> 734-647-6524 desk
>>
>>
>> On Sun, Aug 12, 2018 at 2:38 AM Blason R wrote:
>>
>>> Hi Bob,
>>>
>>> I guess my scenario is not exactly understood I believe. Before that if
>>> I have set forwarder in Global option then ideally BIND should forward all
>>> queries to the forwarder, right?
>>>
>>> Lets say 192.168.3.15 is client
>>> 192.168.3.42 is BIND Server
>>> 192.168.3.78 is RPZ server
>>>
>>> I have one zone on 192.168.3.42 by name test.com and have all the
>>> entries on 192.168.3.42, so on users desktop 192.168.3.15 I have DNS
>>> configured as 192.168.3.42.
>>>
>>
>> Make sure 3.42 has in the global options:
>> forward only;
>> forwarders { 192.168.3.78; };
>>
>> If you are missing the "forward only;" then bind will try to forward, but
>> if it does not get a quick answer it will try to resolve itself.
>>
>> --
>> Bob Harold
>>
>>
>>> So,
>>>
>>> When query goes for ftp.test.com it will be resolved by 192.168.3.42
>>> When query goes for bad.malware.com. it will be forwarded 192.168.3.78
>>> where it will be wall-gardened.
>>>
>>> Now what I noticed is certain RPZ entries on 3.78 are not getting
>>> resolved from 192.168.3.15. And then I observed that certain .com entries
>>> 3.42 is trying resolve on his own even though he is not authoritative
>>> server and supposedly those ALL queries should have been forwarded to
>>> 192.168.3.78.
>>>
>>> PS: I guess there are certain folks are on list from commercial RPZ
>>> services, are they facing same issue?
>>>
>>> On Sun, Aug 12, 2018 at 10:12 AM Bob Harold wrote:
>>>
>>>>
>>>> On Fri, Aug 10, 2018 at 10:53 PM Blason R wrote:
>>>>
>>>>> Infact what I observed that the intermediate DNS servers are not
>>>>> forwarding he queries for .com and .net servers to my RPZ servers and it
>>>>> tries resolves directly on his own from TLD servers
>>>>>
>>>>
>>>> You need to work on the intermediate server to get it to forward. If
>>>> it is running Microsoft DNS, then I don't know enough to help you with
>>>> that.
>>>>
>>>> I would suggest that you have the RPZ server be a 'slave' for the '
>>>> test.com' zone (and all the zones that the AUTH server has). Then
>>>> point users directly at the RPZ server.
>>>>
>>>> --
>>>> Bob Harold
>>>>
>>>>
>>>>
>>>>> 192.168.3.72 End User
>>>>> 192.168.3.15 [AUTH Server for test.com] and has forwarder to
>>>>> 192.168.3.44 [RPZ]
>>>>>
>>>>> So, 3.15 should only resolve for test.com else all queries should be
>>>>> forwarded to 192.168.3.44
>>>>>
>>>>> *Which is not happening.*
>>>>>
>>>>> dig 003bbhq9.com
>>>>>
>>>>> ; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7 <<>> 003bbhq9.com
>>>>> ;; global options: +cmd
>>>>> ;; Got answer:
>>>>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6844
>>>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>>>>>
>>>>> ;; OPT PSEUDOSECTION:
>>>>> ; EDNS: version: 0, flags:; udp: 4096
>>>>> ;; QUESTION SECTION:
>>>>> ;003bbhq9.com. IN A
>>>>>
>>>>> *;; AUTHORITY SECTION:*
>>>>> *com.530 IN SOA a.gtld-servers.net
>>>>> <http://a.gtld-servers.net>. nstld.verisign-grs.com
>>>>> <http://nstld.verisign-grs.com>. 1533954938 1800 900 604800 86400*
>>>>>
>>>>> ;; Query time: 0 msec
>>>>> ;; SERVER: 192.168.3.15#53(192.168.3.15)
>>>&g
Re: Need help on RPZ sever, bit urgent
--
Bob Harold
hostmaster, UMnet, ITcom
Information and Technology Services (ITS)
rharo...@umich.edu
734-647-6524 desk
On Sun, Aug 12, 2018 at 2:38 AM Blason R wrote:
> Hi Bob,
>
> I guess my scenario is not exactly understood I believe. Before that if I
> have set forwarder in Global option then ideally BIND should forward all
> queries to the forwarder, right?
>
> Lets say 192.168.3.15 is client
> 192.168.3.42 is BIND Server
> 192.168.3.78 is RPZ server
>
> I have one zone on 192.168.3.42 by name test.com and have all the entries
> on 192.168.3.42, so on users desktop 192.168.3.15 I have DNS configured as
> 192.168.3.42.
>
Make sure 3.42 has in the global options:
forward only;
forwarders { 192.168.3.78; };
If you are missing the "forward only;" then bind will try to forward, but
if it does not get a quick answer it will try to resolve itself.
--
Bob Harold
> So,
>
> When query goes for ftp.test.com it will be resolved by 192.168.3.42
> When query goes for bad.malware.com. it will be forwarded 192.168.3.78
> where it will be wall-gardened.
>
> Now what I noticed is certain RPZ entries on 3.78 are not getting resolved
> from 192.168.3.15. And then I observed that certain .com entries 3.42 is
> trying resolve on his own even though he is not authoritative server and
> supposedly those ALL queries should have been forwarded to 192.168.3.78.
>
> PS: I guess there are certain folks are on list from commercial RPZ
> services, are they facing same issue?
>
> On Sun, Aug 12, 2018 at 10:12 AM Bob Harold wrote:
>
>>
>> On Fri, Aug 10, 2018 at 10:53 PM Blason R wrote:
>>
>>> Infact what I observed that the intermediate DNS servers are not
>>> forwarding he queries for .com and .net servers to my RPZ servers and it
>>> tries resolves directly on his own from TLD servers
>>>
>>
>> You need to work on the intermediate server to get it to forward. If it
>> is running Microsoft DNS, then I don't know enough to help you with that.
>>
>> I would suggest that you have the RPZ server be a 'slave' for the '
>> test.com' zone (and all the zones that the AUTH server has). Then point
>> users directly at the RPZ server.
>>
>> --
>> Bob Harold
>>
>>
>>
>>> 192.168.3.72 End User
>>> 192.168.3.15 [AUTH Server for test.com] and has forwarder to
>>> 192.168.3.44 [RPZ]
>>>
>>> So, 3.15 should only resolve for test.com else all queries should be
>>> forwarded to 192.168.3.44
>>>
>>> *Which is not happening.*
>>>
>>> dig 003bbhq9.com
>>>
>>> ; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7 <<>> 003bbhq9.com
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6844
>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>>>
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 4096
>>> ;; QUESTION SECTION:
>>> ;003bbhq9.com. IN A
>>>
>>> *;; AUTHORITY SECTION:*
>>> *com.530 IN SOA a.gtld-servers.net
>>> <http://a.gtld-servers.net>. nstld.verisign-grs.com
>>> <http://nstld.verisign-grs.com>. 1533954938 1800 900 604800 86400*
>>>
>>> ;; Query time: 0 msec
>>> ;; SERVER: 192.168.3.15#53(192.168.3.15)
>>> ;; WHEN: Sat Aug 11 08:12:17 IST 2018
>>> ;; MSG SIZE rcvd: 114
>>>
>>>
>>> On Sat, Aug 11, 2018 at 7:57 AM Blason R wrote:
>>>
>>>> Ok - Now I added like this and it disappeared.
>>>>
>>>> response-policy { zone "whitelist.allow" policy passthru;
>>>> zone "malware.trap";
>>>> zone "ransomwareips.block"; }
>>>> qname-wait-recurse no break-dnssec no;
>>>>
>>>>
>>>> On Sat, Aug 11, 2018 at 7:51 AM Blason R wrote:
>>>>
>>>>> This is not accepting and giving my syntax error.
>>>>>
>>>>> named-checkconf /etc/bind/named.conf
>>>>> /etc/bind/named.conf.options:29: syntax error near '}'
>>>>>
>>>>>
>>>>> And here is I added
>>>>>
>>>>> response-policy { zone "whitelist.allow" policy passthru;
>>>>> zone "malware.trap";
>>>>> zone "ransomwareips.block"; }
>>>>
Re: Need help on RPZ sever, bit urgent
On Fri, Aug 10, 2018 at 10:53 PM Blason R wrote:
> Infact what I observed that the intermediate DNS servers are not
> forwarding he queries for .com and .net servers to my RPZ servers and it
> tries resolves directly on his own from TLD servers
>
You need to work on the intermediate server to get it to forward. If it is
running Microsoft DNS, then I don't know enough to help you with that.
I would suggest that you have the RPZ server be a 'slave' for the 'test.com'
zone (and all the zones that the AUTH server has). Then point users
directly at the RPZ server.
--
Bob Harold
> 192.168.3.72 End User
> 192.168.3.15 [AUTH Server for test.com] and has forwarder to
> 192.168.3.44 [RPZ]
>
> So, 3.15 should only resolve for test.com else all queries should be
> forwarded to 192.168.3.44
>
> *Which is not happening.*
>
> dig 003bbhq9.com
>
> ; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7 <<>> 003bbhq9.com
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6844
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;003bbhq9.com. IN A
>
> *;; AUTHORITY SECTION:*
> *com.530 IN SOA a.gtld-servers.net
> <http://a.gtld-servers.net>. nstld.verisign-grs.com
> <http://nstld.verisign-grs.com>. 1533954938 1800 900 604800 86400*
>
> ;; Query time: 0 msec
> ;; SERVER: 192.168.3.15#53(192.168.3.15)
> ;; WHEN: Sat Aug 11 08:12:17 IST 2018
> ;; MSG SIZE rcvd: 114
>
>
> On Sat, Aug 11, 2018 at 7:57 AM Blason R wrote:
>
>> Ok - Now I added like this and it disappeared.
>>
>> response-policy { zone "whitelist.allow" policy passthru;
>> zone "malware.trap";
>> zone "ransomwareips.block"; } qname-wait-recurse
>> no break-dnssec no;
>>
>>
>> On Sat, Aug 11, 2018 at 7:51 AM Blason R wrote:
>>
>>> This is not accepting and giving my syntax error.
>>>
>>> named-checkconf /etc/bind/named.conf
>>> /etc/bind/named.conf.options:29: syntax error near '}'
>>>
>>>
>>> And here is I added
>>>
>>> response-policy { zone "whitelist.allow" policy passthru;
>>> zone "malware.trap";
>>> zone "ransomwareips.block"; } qname-wait-recurse
>>> no break-dnssec no; };
>>>
>>>
>>>
>>> On Sat, Aug 11, 2018 at 1:17 AM Carl Byington wrote:
>>>
>>>> -BEGIN PGP SIGNED MESSAGE-
>>>> Hash: SHA512
>>>>
>>>> On Fri, 2018-08-10 at 13:17 +0530, Blason R wrote:
>>>> > Nah I dont think that is the answer since you need a termination after
>>>> > clause.
>>>>
>>>> Did you actually try the answer below?
>>>>
>>>>
>>>> > On Fri, Aug 10, 2018 at 12:58 PM Vadim Pavlov
>>>> wrote:
>>>>
>>>> > Should be:
>>>>
>>>>
>>>> > response-policy {zone "whitelist.allow" policy passthru;
>>>> > zone "malware.trap";
>>>> > zone "ransomwareips.block";
>>>> > } qname-wait-recurse no break-dnssec no;
>>>>
>>>>
___
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: Need help on RPZ sever, bit urgent
On Thu, Aug 9, 2018 at 9:31 AM Blason R wrote:
> For example this one.
>
> 18:59:26.905177 IP 192.168.1.120.65049 > 192.168.1.42.53: 42074+ A?
> 0351dag.com. (29)
> 18:59:26.905299 IP 192.168.1.42.53 > 192.168.1.120.65049: 42074 NXDomain
> 0/1/0 (102)
>
With RPZ, the name is looked up normally first, and only if there is an
answer, is RPZ invoked. If it gets NXDOMAIN or some error, it returns that
and does not use RPZ.
If that is not what you want, then you probably want to set the option:
qname-wait-recurse no;
--
Bob Harold
>
> On Thu, Aug 9, 2018 at 6:59 PM Blason R wrote:
>
>> Hi Bind-Users,
>>
>> I would really appreciate if someone can help me understanding my issue
>> with BIND RPZ server?
>>
>> I have one windows server say 192.168.1.42 and then RPZ server with
>> 192.168.1.179. I noticed that there are certain domains which are not
>> getting resolved from end users.
>>
>> Ideally since those end user has 192.168.1.42 DNS Server set and has
>> forwarder set to 192.168.1.179 should forward all queries to 1.179, right?
>>
>> But certain domains from my response-policy are even though wall-gardened
>> those are being catered as NXdomain.
>>
>> Anything I am missing pertaining to RPZ?
>>
>> Or if I am querying all those domains directly to RPZ server then I am
>> getting proper answer. This issue is noticed when I have forwarder server
>> is between
>>
>> options {
>> version "test";
>> allow-query { localhost;subnets; };
>> directory "/var/cache/bind";
>> recursion yes;
>> querylog yes;
>> forwarders {
>> 1.1.1.1;9.9.9.9;208.67.222.222;8.8.8.8;
>> };
>> // dnssec-validation auto;
>> request-ixfr yes;
>> auth-nxdomain no;# conform to RFC1035
>> // listen-on-v6 { any; };
>> listen-on port 53 { any; };
>> listen-on port 15455 {any;};
>> response-policy { zone "whitelist.allow" policy passthru;
>> zone "wg.block";
>> zone "bad.trap";
>> zone "block.tld";
>> zone "ransomwareips.block"; };
>> };
>>
>>
___
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: Removing an NS server
On Tue, Aug 7, 2018 at 5:01 PM John Miller wrote: > Hal, we've done this before - it's not particularly hard, just takes a > bit for everyone to pick up the new set of NS records. You just make > the change upstream and also remove the NS records that reference the > system. It's kind of weird: during the interim, you'll have a running > nameserver that doesn't return itself in its NS records. If the same > set of servers also serves your reverse zones, don't forget to update > ARIN as well as Educause. > > Educause sets their upstream TTLs to two days (ARIN's 1 day), but > people shouldn't be caching the referral, only your actual NS records. > If you're at all concerned, you can always set a low TTL ahead of time > on your NS records, so everyone will pull the updated records > relatively quickly once you make your changes. > > John > > On Tue, Aug 7, 2018 at 4:46 PM, King, Harold Clyde (Hal) > wrote: > > I don't think I made my point. I need to pull/remove a DNS nameserver > from my set of nameservers. > > My plan was to put the reference to it from our domain name provider. > Then pull it from the list of NS records. I am not changing my SOA record. > Just the nameserver. Did I make a mistake? Did you mean pull the NS reord > for that server, then pull it from the name provider. I'll still have 4 > servers running the SOA, and I don't plan to stop the old nameserver until > well after a week of running. > > > > > > -- > > Hal King - h...@utk.edu > > Systems Administrator > > Office of Information Technology > > Shared Systems Services > If I remember correctly, setting my NS ttl lower than my parent caused a problem when one of my servers failed and I took it out of the NS record set. I think it went something like this: resolver asks tld (before the change) and gets: example.com 2d NS dns1.example.com example.com 2d NS dns2.example.com example.com 2d NS dns3.example.com dns3 fails and I remove it from the NS records, both locally and at the parent TLD. Resolver talks to my servers (a few hours later, after the change) and gets: example.com 1h NS dns1.example.com example.com 1h NS dns2.example.com Resolver cache now has: example.com 1h NS dns1.example.com example.com 1h NS dns2.example.com example.com 2d NS dns3.example.com An hour later the two shorter NS records expire and the resolver is left with: example.com 2d NS dns3.example.com If dns3.example.com is down, the resolver will fail to reach my zone, and will not ask the TLD until that record expires. So I think the TTL on NS records needs to match the parent zone, whether I like that ttl or not. In your case, removing the NS records from both your zone and the parent zone, two days (or whatever the ttl) before you turn off the server, should be fine. -- Bob Harold ___ 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: socket.c:2135: unexpected error:
On Mon, Jun 4, 2018 at 10:57 PM wrote: > > Hi, > > After upgrading BIND from 9.9.9-P5 to 9.11.3., the following messages > have been displayed continuously in the file /var/log/messages as below. > > - > May 29 02:36:50 dns01 nanny[5609]: debug start 1 > May 29 02:37:08 dns01 named[1679]: socket.c:2135: unexpected error: > May 29 02:37:08 dns01 named[1679]: internal_send: [global IPv6 > address]#38306: Invalid argument > May 29 02:37:20 dns01 nanny[5617]: debug start 1 > May 29 02:37:24 dns01 named[1679]: socket.c:2135: unexpected error: > May 29 02:37:24 dns01 named[1679]: internal_send: [global IPv6 > address]#36987: Invalid argument > May 29 02:37:47 dns01 named[1679]: socket.c:2135: unexpected error: > May 29 02:37:47 dns01 named[1679]: internal_send: [global IPv6 > address]#35862: Invalid argument > May 29 02:37:48 dns01 named[1679]: socket.c:2135: unexpected error: > May 29 02:37:48 dns01 named[1679]: internal_send: [global IPv6 > address]#39895: Invalid argument > May 29 02:37:50 dns01 nanny[5632]: debug start 1 > May 29 02:38:00 dns01 named[1679]: socket.c:2135: unexpected error: > May 29 02:38:00 dns01 named[1679]: internal_send: [global IPv6 > address]#38979: Invalid argument > : > - > > OS : Red Hat Enterprise Linux Server 6.5 > > DNS service seems to be working fine, but I don't understand the cause > and how to fix the errors. > > Any advice would be greatly appreciated. > > > Regards, > Hotta > Just guessing, but it sounds like " [global IPv6 address]" is either malformed, or it is expecting an IPv4 address. -- Bob Harold ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unable to resolve the A records, not sure what is wrong
On Fri, Jun 1, 2018 at 2:01 PM Blason R wrote:
> Yes that was the issue :) and got resolved.
>
Glad it was an easy fix.
--
Bob Harold
> On Fri, Jun 1, 2018 at 11:29 PM, Blason R wrote:
>
>> I guess this could be the issue
>>
>> zone "malware.trap" {
>> type master;
>> file "/var/lib/bind/zones/malware.trap.db";
>> allow-query { localhost;};
>>
>>
>> On Fri, Jun 1, 2018 at 11:28 PM, Blason R wrote:
>>
>>> Well this is I am getting in network.log what could be the issue?
>>>
>>> 01-Jun-2018 23:27:42.274 client 192.168.5.103#58425 (wg.block.tld):
>>> query 'wg.block.tld/A/IN' denied
>>>
>>>
>>> On Fri, Jun 1, 2018 at 11:27 PM, Bob Harold wrote:
>>>
>>>>
>>>> On Fri, Jun 1, 2018 at 1:36 PM Blason R wrote:
>>>>
>>>>> Hi there,
>>>>>
>>>>> I am writing a RPZ zone and here is my zone file. RPZ is working fine
>>>>> but somehow A records are not getting resovled hence I am unable to do the
>>>>> wall-gardening.
>>>>>
>>>>> Can someone please help
>>>>>
>>>>>
>>>>> $TTL 3h
>>>>> @ IN SOA ns1.malware.trap.
>>>>> admin.malware.trap.(
>>>>> 2006060301 ; Serial
>>>>> 21600 ; Refresh
>>>>> 3600; Retry
>>>>> 604800 ; Expire
>>>>> 3600 ) ; Minimum TTL
>>>>>
>>>>> IN NSns1.malware.trap.
>>>>> ns1.malware.trap. A 172.16.3.48
>>>>> wg.malware.trap.A 172.16.3.48
>>>>> baddomain.co CNAME wg.malware.trap.
>>>>> block.thisCNAME wg.malware.trap.
>>>>>
>>>>> ###
>>>>>
>>>>> ;; ANSWER SECTION:
>>>>> block.this.5 IN CNAME wg.malware.trap.
>>>>>
>>>>>
>>>>> ***
>>>>> ;; QUESTION SECTION:
>>>>> ;wg.malware.trap. IN A
>>>>>
>>>>> Answer not getting what could be wrong??
>>>>>
>>>>
>>>> Not sure what is a normal configuration, but on my servers users cannot
>>>> query the RPZ domain, it is only used for RPZ.
>>>> Try putting the A record in a normal zone, and CNAME to that, rather
>>>> than having the A record in the RPZ zone.
>>>> Or try doing a direct query for the A record and see if it resolves.
>>>>
>>>> --
>>>> Bob Harold
>>>>
>>>>
>>>
>>>
>>
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Unable to resolve the A records, not sure what is wrong
On Fri, Jun 1, 2018 at 1:36 PM Blason R wrote: > Hi there, > > I am writing a RPZ zone and here is my zone file. RPZ is working fine but > somehow A records are not getting resovled hence I am unable to do the > wall-gardening. > > Can someone please help > > > $TTL 3h > @ IN SOA ns1.malware.trap. admin.malware.trap.( > 2006060301 ; Serial > 21600 ; Refresh > 3600; Retry > 604800 ; Expire > 3600 ) ; Minimum TTL > > IN NSns1.malware.trap. > ns1.malware.trap. A 172.16.3.48 > wg.malware.trap.A 172.16.3.48 > baddomain.co CNAME wg.malware.trap. > block.thisCNAME wg.malware.trap. > > ### > > ;; ANSWER SECTION: > block.this.5 IN CNAME wg.malware.trap. > > > *** > ;; QUESTION SECTION: > ;wg.malware.trap. IN A > > Answer not getting what could be wrong?? > Not sure what is a normal configuration, but on my servers users cannot query the RPZ domain, it is only used for RPZ. Try putting the A record in a normal zone, and CNAME to that, rather than having the A record in the RPZ zone. Or try doing a direct query for the A record and see if it resolves. -- Bob Harold ___ 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: RPZ logging
On Sat, Apr 28, 2018 at 11:29 PM, Blason R <blaso...@gmail.com> wrote:
> Hi Folks,
>
> I have been struggligng with exact RPZ/Bind option/statement which enables
> the logging for RPZ and shows if the query matches RPZ zone.
>
> Can someone please help me?
>
>
I think the required rpz logging related lines in my named.conf are:
logging {
channel "rpz_file" {
file "/var/log/named/rpz.log" versions 10 size 104857600;
severity dynamic;
print-time yes;
print-severity yes;
print-category yes;
};
category "rpz" {
"rpz_file";
};
};
You might want less versions and/or a smaller size - my values allow rpz
logs to fill 1gb of disk.
--
Bob Harold
___
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: Facing weird issue with DNS-RPZ
f.root-servers.net.
> . 2972IN NS d.root-servers.net.
> . 2972IN NS l.root-servers.net.
>
> ;; Query time: 128 msec
>
>
> Any clue why this is happening?
>
Check the logs for an error message saying that the zone failed to load,
and which line # had the error.
Also try this:
cat /tmp/sinkhole.zones | awk '{print $2}' | sed -e 's/\"//g' | egrep -v
'^[-0-9a-zA-Z.]*$'
There might be names that don't fit that pattern that are still ok, but it
is a start.
If not, then edit the zone and delete the last half of the lines, reload,
if it fails delete half of the remaining names, etc, until you find it by
binary search.
--
Bob Harold
___
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: "Hiding" version.bind in /etc/bind/named.conf.options doesn't work
On Wed, Feb 28, 2018 at 8:55 AM, Ing. Pedro Pablo Delgado Martell <
ppmart...@eleka.co.cu> wrote:
> Good morning, I'm trying to make it more difficult for an attacker to get
> my DNS server version. I have been following several posts about doing this
> and mostrly all of them suggest to modify the
> */etc/bind/named.conf.options* file and add the lines:
>
> options {
>
> version "Not available"; // Or any bogus info or
> just none without quotes
>
> }
>
> Then restart the service (*service bind9 restart*) and the version will
> not be shown, only the defined text, in this case "Not available". However,
> after doing this and restarting the service I'm still getting my server
> version. Am I placing this lines in the wrong file? Thanks in advance!
>
>
>
> Bind version: 9.10.2-P3
>
> OS:Debian GNU/Linux 8 (jessie)
>
> Those instructions assume that the */etc/bind/named.conf.options* file
is 'included' in the main named.conf file.
Just add the "version" line to your named.conf file options section.
If you don't know where your named.conf file is, try this command:
ps -ef | grep named
which should get some result, like maybe:
named 1728 1 0 Feb11 ?01:55:51 /usr/local/sbin/named -t
/replicated/jail/named -u named -n 2 -U 2 -S 16384
If there was a "-c" option, it would tell you the name of the config file.
If not, like this example, the default is "/etc/named.conf".
Note the "-t" option, which says we are doing chroot to
/replicated/jail/named
So my config file is at:
/replicated/jail/named/etc/named.conf
--
Bob Harold
___
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: questions on allow-query
On Wed, Feb 21, 2018 at 8:18 AM, Tony Finch <d...@dotat.at> wrote: > Evan Hunt <e...@isc.org> wrote: > > > > One thing to keep in mind, though, is that the two services will share > each > > other's fates. If I were deploying a really big high-traffic server, I > > might consider whether I wanted my recursive service to have to wait for > > all the zones to load before it could function, or whether I wanted to > have > > to update my authoritative server because it was vulnerable to a crash > bug > > in the recursive code. > > On our recursive servers we have authoritative copies of all our local > zones so that they can give answers for on-site stuff even when bits of > the network are broken. (Downstream validating resolvers will probably be > out of luck tho.) This is about 70 zones, average size about 2MB, biggest > about 30MB. But, we also have RPZ and the biggest blocklist is about half > a gig and this dominates the startup time (it takes nearly 20 seconds). > This isn't an availability problem, tho, because the recursive servers are > in an HA cluster using keepalived and the health checker won't bring a > node into service until it has finished starting. > > Our authoritative servers are separate. Probably the main reason for not > turning them into views on the recursive servers is that the auth servers > have to be more exposed to attack from the Internet. Our recursive servers > can do things like firewall off external TCP connection attempts, to avoid > connection pool exhaustion attacks. I've done less HA engineering on our > auth servers, and I'm relatively relaxed about patching them, because I > (foolishly?) trust other resolvers out on the Internet to make effective > use of my secondaries. > > Tony. > -- Likewise. My resolvers are stealth slaves for all my zones. Mainly because they get updates faster - users do not have to wait for the old data to expire its ttl before the resolver gets the new data. Also, there is no chance of cache poisoning for my zones, since they are slaved, not cached. -- Bob Harold ___ 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: Minimum TTL?
On Thu, Feb 8, 2018 at 4:34 PM, Grant Taylor via bind-users < bind-users@lists.isc.org> wrote: > On 02/08/2018 08:51 AM, Mukund Sivaraman wrote: > >> Also, just for argument's sake, one user wants to extend TTLs to 5s. >> Another wants 60s TTLs. What is OK and what is going too far? >> > > I think what is "OK" is up to each administrator. > > Obviously the zone administrators have decided that they want people to > use the 2s TTL. > > That being said, it is up to each individual recursive server operator if > they want to honor what the zone administrators have published, or if the > recursive administrators want to override published desires. > > It really is something for the zone owner to consider. >> > > Yes and no. Yes it's up to the zone owner to consider what intentions > that they want to publish. No, the zone owner has no influence on how I > operate my servers. I choose how I operate my servers. > > If I choose to operate my servers in a manner that ignores the zone > owner's published desires, that's on me. > > I feel like this discussion is really two issues: 1) Does the capability > to override published values and 2) should I use said capability. They > really are two different questions. I personally would like to see BIND > have the option to do #1, even if I never use it. > > +1 > > -- > Grant. . . . > unix || die > > -- Bob Harold ___ 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: response-rate-limiting - "window" explained?
On Tue, Jan 9, 2018 at 11:11 AM, Tony Finch <d...@dotat.at> wrote: > Tom <tomtux...@gmail.com> wrote: > > > > Slip is set to "0" (always drop). After stopping the flood, I'm > immediately > > able to query the same record (www.example.com) with a positive answer. > Does > > the "window 5;" or "window 30;" or "window 3600;" possibly has no effect? > > The script below works for me. My server is configured with > > responses-per-second 2; > slip 0; > > The script "floods" at 10 qps for 15 seconds (enough to fill the window), > then drops to 1qps and times how long it takes to recover. At the end it > says the recovery time was 20 seconds. This is a bit more than the window > size because I wasn't completely quiet during the recovery time. > > > > #!/bin/sh > > set -eu > > dig='dig +ignore +tries=1 +timeout=1 +norec dotat.at @grey.dotat.at' > > start=$(date +%s) > > while [ $(date +%s) -lt $(($start + 15)) ] > do > $dig | grep aa & > sleep 0.1 > done > > end=$(date +%s) > > while ! $dig | grep aa > do > :; > done > > echo $(( $(date +%s) - $end )) > > > > Tony. > -- > f.anthony.n.finch <d...@dotat.at> http://dotat.at/ - I xn--zr8h > punycode > Irish Sea: Southeast 5 to 7, becoming cyclonic 4 or 5 later. Moderate or > rough, becoming slight or moderate. Occasional rain. Good, occasionally > poor. > Tony, That's a good test, with the default window of 15 seconds, but could you please repeat it with a window like 120, and see if it changes accordingly? Tom's testing indicates that the 'window' parameter has no effect, which seems wrong. -- Bob Harold ___ 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: Recommended values for a zone
On Wed, Jan 3, 2018 at 5:58 PM, Mik J <mikyde...@yahoo.fr> wrote: > Thank you Bob for your answer. > I continued to search and saw rfc1912 page 4 > It's much higher than I first thought > > > > Le mercredi 3 janvier 2018 à 20:05:57 UTC+1, Bob Harold < > rharo...@umich.edu> a écrit : > > > > On Wed, Jan 3, 2018 at 1:57 PM, Mik J via bind-users < > bind-users@lists.isc.org> wrote: > > Hello, > > I would like to have your thoughts about what should be the best values > for refresh, retry, expire and negative cache. > > In my case I have 2 DNS which are hosted in 2 different locations. These > location are near one another (100km). The latency is very low and packet > is 0. > I configured a lot of zones on my DNS and they not master for someone else. > This is a very simple setup in termes of master/slave. > > I would be tempted to > * configure a high refresh period since I have notify configured on the > master. What about 7200s ? > * Configure a high retry period because I don't expect the master to be > offline, what about 3600 ? > * configure a expire very high like 2 days so that the DNS service would > work even if the master is down > * I don't have any opinion about the negative ttl yet but any advices are > welcomed. > > What about your setups if it looks like mine ? > > Regards > > > I typically use an expire time of 14 days or a month. But that said, you > need some way to get notified that zone transfers are failing. > The refresh and retry are ok, but personally I would set them lower > because they don't generate a lot of traffic, and a notify could get lost. > It depends on how sensitive you are to extra traffic. > > Negative TTL depends partly on how fast you want new (or accidentally > deleted) records to be usable. I use 10 minutes. > > -- > Bob Harold > > Thanks for mentioning rfc1912. I just read it again, and the advice is good. One update - I think that "minimum" is now used only as the TTL for NXDOMAIN (domain name does not exist) replies. The default TTL is set with a $TTL record (usually at the top of the zone file). -- Bob Harold ___ 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: Recommended values for a zone
On Wed, Jan 3, 2018 at 1:57 PM, Mik J via bind-users < bind-users@lists.isc.org> wrote: > Hello, > > I would like to have your thoughts about what should be the best values > for refresh, retry, expire and negative cache. > > In my case I have 2 DNS which are hosted in 2 different locations. These > location are near one another (100km). The latency is very low and packet > is 0. > I configured a lot of zones on my DNS and they not master for someone else. > This is a very simple setup in termes of master/slave. > > I would be tempted to > * configure a high refresh period since I have notify configured on the > master. What about 7200s ? > * Configure a high retry period because I don't expect the master to be > offline, what about 3600 ? > * configure a expire very high like 2 days so that the DNS service would > work even if the master is down > * I don't have any opinion about the negative ttl yet but any advices are > welcomed. > > What about your setups if it looks like mine ? > > Regards > I typically use an expire time of 14 days or a month. But that said, you need some way to get notified that zone transfers are failing. The refresh and retry are ok, but personally I would set them lower because they don't generate a lot of traffic, and a notify could get lost. It depends on how sensitive you are to extra traffic. Negative TTL depends partly on how fast you want new (or accidentally deleted) records to be usable. I use 10 minutes. -- Bob Harold ___ 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: DDNS - limitation and excluding updates from certain networks
On Wed, Dec 20, 2017 at 8:54 AM, Mukund Sivaraman <m...@isc.org> wrote: > On Wed, Dec 20, 2017 at 01:27:17PM +, MAYER Hans wrote: > > > > Dear Mukund, > > > > Many thanks for coming back. > > > > > You'll have to explain what you mean better for a more specific answer, > > > but see the manual for the "allow-update" ACL config option > > > > In my zone configuration I have an “allow-update” statement. > > Here I define all networks which are allowed to dynamically update the > DNS entries. > > > > But my zone contains other IP addresses too. Not only those of the PCs. > > These are static names/addresses which are seldom changed. > > > > And of course the complete zone is a dynamic zone. > > > > And I don’t wont that this static names can by changed by someone out of > an IP range, where it is allowed. > > I didn’t find any hint to block certain IP ranges to be updated within a > dynamic zone. > > > > Hopefully this explains my question a little bit better. > > The allow-update ACL applies to the whole zone. The ACL code doesn't > discriminate using the contents of the update. > > You could put the names requiring update into a child zone (but > obviously it'll add another label) or another zone altogether (but > obviously it'll have a different name). > > Mukund Just guessing here, but I see a TXT record beside each A record, and am told that Windows clients check the TXT record to see if they "own" the A record. The TXT record is hex encoded data, maybe the client identifier. So if you created a TXT record for each A record, like: servername IN TXT "do not dynamically update" (or might need to be valid hex?) servername IN A 10.11.12.13 That might reduce the chances of a Windows client overwriting it. -- Bob Harold ___ 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: Forwarding from delegated zone not working
On Tue, Oct 10, 2017 at 11:21 AM, seanliam73 <sean.orei...@landg.com> wrote:
> Hi
>
> I have a subdomain delegated from AD to a bind9 instance I have running
> that
> so that all requests for that subdomain are sent to the bind 9 instance. I
> would then like to set up zone forwarding so that further subdomains can be
> managed by other bind 9 instances.
>
> I know the forwarding is working because I can query the main bind9
> instance
> at receive the expected results. However if I query from the AD server that
> is doing the delegation I get a SERVFAIL error.
>
> Am I trying to do something that is not possible or am I just missing some
> configuration.
>
> *main instance config*
>
> options {
> directory "/var/named";
> listen-on port 53 { listen addr; };
> auth-nxdomain yes;
> recursion yes;
> allow-query { ip addresses; };
>
----- You might also need to add:
allow-recursion { ip addresses; };
--
Bob Harold
> listen-on-v6 { any; };
> dnssec-enable no;
> dnssec-validation no;
> dnssec-lookaside auto;
> };
>
> logging {
> channel default_debug {
> file "data/named.run";
> severity debug 3;
> };
>
> channel querylog {
> file "data/query.log";
> severity debug 5;
> };
>
> category default { default_debug; };
> category queries { querylog; };
> };
>
> zone "example.company.com" IN {
> type forward;
> forward only;
> forwarders { ip address; };
> };
>
> zone "development.example.company.com" IN {
> type forward;
> forward only;
> forwarders { ip address; };
> };
>
>
>
___
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: DNS traffic accounting
On Wed, Jul 19, 2017 at 6:20 AM, Abi Askushi <rightkickt...@gmail.com> wrote: > > I enabled logging for the queries and am getting now queries from clients > in the below form: > > 19-Jul-2017 10:11:29.310 client 192.168.200.102#27975: view auth: query: > mobile.in.gr IN A + (192.168.200.1) > 19-Jul-2017 10:11:29.794 client 192.168.200.102#32874: view auth: query: > static.adman.gr IN A + (192.168.200.1) > 19-Jul-2017 10:11:31.564 client 192.168.200.102#36746: view auth: query: > android.clients.google.com IN A + (192.168.200.1) > 19-Jul-2017 10:11:32.721 client 192.168.200.102#60248: view auth: query: > mobilefeed.in.gr IN A + (192.168.200.1) > 19-Jul-2017 10:11:39.440 client 192.168.200.102#53832: view auth: query: > stats.g.doubleclick.net IN A + (192.168.200.1) > 19-Jul-2017 10:11:44.523 client 192.168.200.102#22693: view auth: query: > mqtt-mini.facebook.com IN A + (192.168.200.1) > 19-Jul-2017 10:11:51.429 client 192.168.200.102#37734: view auth: query: > www.googleapis.com IN A + (192.168.200.1) > 19-Jul-2017 10:11:55.603 client 192.168.200.102#62531: view auth: query: > clients3.google.com IN A + (192.168.200.1) > 19-Jul-2017 10:11:57.352 client 192.168.200.102#11788: view auth: query: > clients4.google.com IN A + (192.168.200.1) > 19-Jul-2017 10:11:57.353 client 192.168.200.102#19409: view auth: query: > clients4.google.com IN A + (192.168.200.1) > 19-Jul-2017 10:12:06.365 client 192.168.200.102#51726: view auth: query: > graph.instagram.com IN A + (192.168.200.1) > > I could count the queries by parsing the logs though this seems to be > somehow inefficient. > Is there any way that bind9 could be queries otherwise to provide such > info? > > Read up on the statistics channel in the BIND manual. -- Bob Harold > Many thanx, > Abi > > On Wed, Jul 19, 2017 at 12:04 AM, Abi Askushi <rightkickt...@gmail.com> > wrote: > >> This could do. >> I just have to get those counters. >> >> Thanx, >> Abi >> >> On Jul 18, 2017 18:37, "Matthew Seaman" <m.sea...@infracaninophile.co.uk> >> wrote: >> >> On 07/18/17 16:09, Abi Askushi wrote: >> > I am trying to figure out how could I account the DNS traffic generated >> > from clients in terms of bytes. My setup is a simple caching DNS with >> > several clients querying the DNS server. I can measure the DNS traffic >> > that is generated from the DNS server on the WAN side by using some >> > monitoring tool (pmacct) but I am not sure how could I account this >> traffic >> > to the clients that are generating this traffic. By simply monitoring >> the >> > internal DNS traffic from clients I expect to not be accurate since it >> will >> > include also cached responses which do not generate WAN traffic. >> > >> > Any suggestion how to approach this problem? >> >> The implication of what you're suggesting is that if client A looks up >> some address that isn't in the cache, then they will be charged for >> that. However, if client B then comes along and looks up the exact same >> address shortly afterwards, they'll get a response from cache and so not >> be charged. That seems a bit arbitrary. >> >> Why not charge your clients based simply on the number of queries they >> make against your resolver? You know or can easily find out how many >> queries your resolver is handling in total and how much the WAN traffic >> that generates is costing you so it should be fairly easy to come up >> with a charging scheme based on the average cost per DNS query. >> >> Cheers, >> >> Matthew >> >> ___ 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: delegation NS records
On Thu, Jul 13, 2017 at 8:39 PM, <b...@zq3q.org> wrote:
> Hi Bob:
>
> These examples help! Thank you.
>
> On Thu 7/13/17 15:53 -0400 Bob Harold wrote:
> > Let's illustrate one NS record, for each of the cases:
> > (I think your case is #2)
> >
> > 1. Name server name inside the domain itself
> >
> > example.com zone:
> > example.com IN NS ns.example.com
> > ns.example.com IN A x.x.x.x
> >
> > the TLD com would have (entered by the registrar)
> > example.com IN NS ns.example.com
> > ns.example.com IN A x.x.x.x (this is a "glue" record)
>
> OK. This example is the most commonly seen in web searches.
>
> > 2. Name server name in another domain:
> >
> > example.com zone:
> > example.com IN NS ns.otherdomain.com
> >
> > TLD com zone:
> > example.com IN NS ns.otherdomain.com
> > (no glue record)
>
> Exactly one delegation NS record.
>
> Several have made that clear; ie I now clearly understand there is
> *not* another NS delegation record needed in the zone with the $ORIGIN
> that is part of the ("non vanity") nameserver's FQDN.
>
> > otherdomain.com zone:
> > ns.otherdomain.com IN A x.x.x.x
>
> Almost goes without saying that above A record is needed.
>
> > 3. Sibling domains with name servers for each other: (should be avoided?)
> >
> > example.com zone:
> > example.com IN NS ns.otherdomain.com
> > ns.example.com IN A x.x.x.x
> >
> > otherdomain.com zone:
> > otherdomain.com IN NS ns.example.com
> > ns.otherdomain.com IN A x.x.x.x
> >
> > TLD com zone:
> > example.com IN NS ns.otherdomain.com
> > ns.example.com IN A x.x.x.x (glue record?)
> > ns.otherdomain.com IN A x.x.x.x (glue record?)
>
> Interesting. I think the glue record make sense.
> I'm not planning to do this. :->
>
> I do not see any delegation NS record for otherdomain.com above.
> Is this right?:
>
> TLD com zone:
> example.comIN NS ns.otherdomain.com
> ns.example.com IN A x.x.x.x (glue record?)
> otherdomain.comIN NS ns.example.com
> ns.otherdomain.com IN A x.x.x.x (glue record?)
>
> --
> thanks,
> Tom
>
You are correct, the TLD needs the records that you show.
And as others have said, there should be at least 2 or 3 name servers for
every zone, and they should be on different networks. I was trying to show
the various cases that apply to each *one* of the NS and glue records.
--
Bob Harold
___
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: delegation NS records
On Thu, Jul 13, 2017 at 3:33 PM, <b...@zq3q.org> wrote: > Hi Niall: > > On Tue 7/11/17 22:56 +0100 "Niall O'Reilly" wrote: > > On 11 Jul 2017, at 22:01, b...@zq3q.org wrote: > > > > > As I wrote to Niall (msg dated 11 Jul 2017 15:04:32 -0500) , > > > > That hasn't reached me yet. > > > > > I **do not** have a NS record for each of my two > > > nameservers, in the domain zone that the respective nameserver itself > is in. > > > That is a mistake, I need to fix, right? > > > > Short answer: just no. > > > > Long answer: not unless either of your servers is providing name service > for > > the zone that the nameserver itself is in. As I understand from your > > original message, this is not the case, so just no. > > Thanks much! > > -- > Check my comprehension: > > So, **delegation** NS records are only needed in the zone which has an > $ORIGIN, > which is 1 level up from the $ORIGIN in the zone that contains the > nameserver SOA, and > authority NS records in. If this zone with delegation NS records is a > subdomain > of a TLD, then one adds these delegation NS records by using the > registrar's > interface to the TLD registry. > > -- > regards, > Tom > Let's illustrate one NS record, for each of the cases: (I think your case is #2) 1. Name server name inside the domain itself example.com zone: example.com IN NS ns.example.com ns.example.com IN A x.x.x.x the TLD com would have (entered by the registrar) example.com IN NS ns.example.com ns.example.com IN A x.x.x.x (this is a "glue" record) 2. Name server name in another domain: example.com zone: example.com IN NS ns.otherdomain.com TLD com zone: example.com IN NS ns.otherdomain.com (no glue record) otherdomain.com zone: ns.otherdomain.com IN A x.x.x.x 3. Sibling domains with name servers for each other: (should be avoided?) example.com zone: example.com IN NS ns.otherdomain.com ns.example.com IN A x.x.x.x otherdomain.com zone: otherdomain.com IN NS ns.example.com ns.otherdomain.com IN A x.x.x.x TLD com zone: example.com IN NS ns.otherdomain.com ns.example.com IN A x.x.x.x (glue record?) ns.otherdomain.com IN A x.x.x.x (glue record?) -- Bob Harold ___ 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: Experiences with RPZ in multiple views
On Tue, Jul 4, 2017 at 4:10 AM, Matthias Seitz <matthias.se...@switch.ch>
wrote:
> Hi,
>
> after a couple of test runs it looks like that multiple RPZs in multiple
> views works fine, example code snippet bellow (for better understanding)
>
> view "view1" {
> ...
>
> response-policy {
> RPZ Feed 1
> RPZ Feed 2
> RPZ Feed 3
> }; };
>
> view "view2" {
> ...
>
> response-policy {
> RPZ Feed 1
> RPZ Feed 4
> RPZ Feed 5
> }; };
>
> Locally the RPZ feeds needs different file name, that it will work. See
> also the bind-users post from Tom <tomtux...@gmail.com> "BIND-RPZ
> and Views"
> Does anybody runs RPZ in multiple views in *productive environment* and
> do you have any feedback regarding stability, feedback if this runs
> smoothly and any other hints?
>
> Cheers,
> Matthias
>
We use RPZ in two views. In one view the RPZ zones are active (policy
given), and in the other view they are logging-only (policy disabled).
Departments opt-in to RPZ and we add their subnets to the first view. The
second view gives us logs and we can tell departments what would be
redirected if they opt-in.
--
Bob Harold
___
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: strange problem with query being dropped/ignored by the BIND process
On Thu, Jun 29, 2017 at 9:51 AM, Marc Richter <marc.rich...@de.verizon.com> wrote: > Hi Dennis, > > > Do you have any adjustments in /etc/system ? > > No. And as mentioned before this is a Solaris 11 system, so /etc/system is > (mostly) irrelevant, as the IP settings are all done with ipadm now. > > > > > # ndd -get /dev/ip \? | grep "read" > > # ndd -get /dev/tcp \? | grep "read" > > > > That, as well as the script and examples you provided, won't help me a lot, > as I am looking at UDP receive buffer overflows, not TCP. > > I have set udp_max_buf to 4MB now and udp_send_buf & udp_recv_buf to 2MB > each, then restarted BIND. > It seems to be working better now as I don't see that much receive buffer > overflows anymore. > > However, the initial question still stands. How can I reconfigure BIND to > pick up the data faster from the receive buffer ? > > > Since you are on contract ( me too .. arn't we all these days ) then I > > have to assume you have reasonable kernel updates and tcp patches in > > this Solaris server ? > > Yes, of course. > > Regards > Marc > I tend to distrust "CPU(30%)" if it is averaged over more than one cpu. Could you run "top" and hit the number "1" so that it shows each cpu separately? With 8 cpu's, "30%" could be one cpu at 100% and others lower, where the one cpu at 100% is your bottleneck. Just a guess at something to look at. -- Bob Harold ___ 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: RPZ zone load failure ran out of space
On Wed, Jun 28, 2017 at 3:44 PM, Jim Yang <z...@cornell.edu> wrote: > Hi, > > > > In the example below, when the length of bad.domain.com reaches 241 > bytes, named-checkconf reports the following error: > > > > “zone db.rpz.zone/IN: loading from master file db.rpz.zone failed: ran out > of space > > _default/db.rpz.zone/IN: ran out of space” > > > > As per RFC1035, the DNS name maximum length is 255 bytes and each label > length limit is 63 bytes. > > > > I wonder what is the maximum length for bad.domain.com in the RPZ zone? > > > > $ORIGIN rpz.example.com. > > $TTL 1H > > @ SOA LOCALHOST. named-mgr.example.com (1 1h 15m 30d > 2h) > > NS LOCALHOST. > > > > ; QNAME policy records. > > ; Note: There are no periods (.) after the (relativised) owner names. > > > > bad.domain.com A 10.0.0.1 ; redirect to walled garden > > 2001:2::1 > > > > Thanks, > > Jim > I just hit the same problem (we probably use the same block list source). The actual DNS name is the combination of the ORIGIN and the entry: bad.domain.com.rpz.example.com. which exceeds 255 characters including the trailing dot, most likely. -- Bob Harold ___ 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: inline-signing a zone that exists in two views
On Fri, May 19, 2017 at 8:56 AM, Matus UHLAR - fantomas <uh...@fantomas.sk> wrote: > Gordon Messmer <gordon.mess...@gmail.com> wrote: >>> > Is it considered best-practice (or just normal) for authoritative >>> > servers to just not use the local server for resolution? >>> >> > On Wed, May 10, 2017 at 5:56 AM, Tony Finch <d...@dotat.at> wrote: >> >>> Mine don't :-) >>> >> > On 18.05.17 16:38, Bob Harold wrote: > >> My authoritative servers are non-recursive. They use the same DNS >> resolvers that any other server uses, and not themselves. >> > > this configuration will make your recursive servers provide correct data > when your customers move their domains out without telling you so (which > happend quite often)... > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Very true, and I use that fact when I know a zone is in transition. But most of the time I have stealth slave copies (meaning not listed in NS records) on my resolvers. That is more complicated, and has the problem you mention, which happens often. But it has some advantages: Updates reaching my users more quickly, no waiting for cache timeout on the resolvers (there are still other caches, but it helps) Cache poisoning attacks don't work against my zones on my resolvers, since they are authoritative and not cached. I hope sometime to automate monitoring for zones moving without warning me in advance. -- Bob Harold ___ 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: inline-signing a zone that exists in two views
On Wed, May 10, 2017 at 5:56 AM, Tony Finch <d...@dotat.at> wrote: > Gordon Messmer <gordon.mess...@gmail.com> wrote: > ... > > > Is it considered best-practice (or just normal) for authoritative > > servers to just not use the local server for resolution? > > Mine don't :-) > > Tony. > > My authoritative servers are non-recursive. They use the same DNS resolvers that any other server uses, and not themselves. -- Bob Harold ___ 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: Clean up dynamic names
On Wed, Feb 8, 2017 at 1:09 PM, Cuttler, Brian R (HEALTH) < brian.cutt...@health.ny.gov> wrote: > Kevin, > > I understand. Let me refocus the question. > > DHCP: > I know DHCP will remove the info when the old lease expires, will it > remove this information for me in the case of the device falling off line, > and how can I accelerate that process so that I can reassign the printer > tag to a new IP address. > > BIND: > Knowing that I have a "A", "TXT" and "PTR" record, is # nsupdate the > correct mechanism, and how do I specify the commands to remove the "TXT" > record as it is missing column 1 in the tables. I have previously manually > both created and removed forward and reverse records, but text records are > different, I just don't know how different. > > The forward table looks like this > > hr16038 A 10.57.48.209 > TXT "00f8e5793e94da14990f27763448c54a00" > > If the first field is shown as blank, it means "same as previous", so "hr16038" in this case. If the ttl is not shown, it is "same as last $TTL record" (or taken from 'minimum' field in SOA if no $TTL) If no class is shown, it is probably "IN", I forget now where it defaults that. If the first field is not fully qualified, the domain is taken from the last $ORIGIN, or SOA?, or named.conf. So the records if listed in full would be something like: hr16038.somedomain.tld. IN A 10.57.48.209 hr16038.somedomain.tld. INTXT " 00f8e5793e94da14990f27763448c54a00" nsupdate is probably the best tool for removing the old records. -- Bob Harold > Thank you, > Brian > > > -Original Message- > > From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of > > Darcy Kevin (FCA) > > Sent: Wednesday, February 08, 2017 12:58 PM > > To: Users of ISC DHCP <dhcp-us...@lists.isc.org>; > bind-users@lists.isc.org > > Subject: RE: Clean up dynamic names > > > > ATTENTION: This email came from an external source. Do not open > > attachments or click on links from unknown senders or unexpected emails. > > > > > > Honestly, this is like asking for a closet that automatically throws out > > the items you pitch into it, once the items are deemed obsolete or junk. > > > > The DNS database is a repository of information, like a closet, but it > has > > no inherent way of knowing the value or currency of the information that > > is put into it. Therefore any "auto-cleaning" mechanism is going to be > > unreliable, at best. > > > > Now, if you want, you can add "metadata" alongside your regular data, or > > in a parallel database, e.g. a timestamp or something like that. You > could > > then use that "metadata" to make decisions on what to delete. Various > > layers on top of DNS itself can perform "aging" and "scavenging" in this > > way (Microsoft's solution does this). But that's not perfect either -- > > we've had major infrastructure outages due to erroneous scavenging of > > Microsoft-hosted DNS data. > > > > The bottom line is that the processes which read and write data into/out > > of the DNS database are responsible for keeping track of it, evaluating > > it, and getting rid of data that is no longer needed or wanted. This is > > not something the database itself can do. > > > > > > - Kevin > > > > > > > > -Original Message- > > From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of > > Cuttler, Brian R (HEALTH) > > Sent: Wednesday, February 08, 2017 11:59 AM > > To: Users of ISC DHCP; bind-users@lists.isc.org > > Subject: Clean up dynamic names > > > > Hello Bind and DHCP users, > > > > Sorry for the post to both lists, but it is a dynamic DNS question and > I'm > > not sure where the answer will come from. > > > > We replaced the network card in a printer, which had been working, we had > > a DHCP lease, we had created from DHCP a dynamic DNS forward and reverse > > record for the printer. > > > > The new network card was configured to provide the same HOSTNAME > > information as the old card, we do this because the printers now carry > > network names that reflect their inventory tags. > > > > I need the cleanest/best way to remove the old DNS records so that the > > DHCP server will be able to register the IP information in DNS. > > > > Needless to say the TXT fingerprint information for th
Re: Reverse IPv6
On Thu, Feb 2, 2017 at 5:44 AM, Cathy Almond <cat...@isc.org> wrote: > > > On 02/02/2017 02:52, Filho Arrais wrote: > > Hi, > > > > Hello, > > Excuse me the question, is there anything native to IPv6 like in IPv4 > > for PTR input? > > > > $GENERATE 1-254 $ PTR 100.200.236.$.examplae.com <http://examplae.com > >. > > > > -- > > Bear in mind that that reverse populating your IPv6 space in entirety is > potentially going to hurt you (the $GENERATE command actually generates > an RR for each record which will be held in the zone in memory). Think > about how many records your $GENERATE is going to create. You don't > want to have named failing to start because it does not have enough > memory (or the machine on which it is running does not have enough > memory) to hold all of the PTR RRsets in the zone. > > Please also think about whether you need to do this or not, especially > as the names are going to follow a generic pattern and not provide any > useful intelligence about the host using that address. > > Instead, I would suggest that you just create PTR entries for the IPv6 > hosts that actually need them for some reason, or to use dynamic DNS to > add/replace/delete them as addresses are used/discarded by dynamic clients. > Note that there is future work being done to solve the 'too many entries' issue with GENERATE (does not solve the other concerns): https://www.ietf.org/internet-drafts/draft-woodworth-bulk-rr-03.txt -- Bob Harold ___ 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: rDNS
On Fri, Jan 20, 2017 at 10:57 AM, Ron Wingfield <ron.wingfi...@archaxis.net> wrote: > I am having difficulty configuring reverse DNS. This has been a problem > for over a year between my server(s) and my ISP, AT Specifically, I > cannot eMail to any recipient that requires rDNS verification, e.g., > SBCglobal.net, Comcast.net, or AOL. Very frustrating. > > Two examples of dig: > > # dig -t mx alpha.archaxis.net > ANSWER: 0, AUTHORITY: 1, > > Why does this first example, digging the FQDN of alpha.archaxis.net > reports one authority but no answers? > > # dig -t mx archaxis.net > ANSWER: 2, AUTHORITY: 0, > > . . .yet this second example. digging the FQDN of archaxis.net reports no > authority but 2 answers? > > (The) ;; ANSWER SECTION: (of both examples) reports: > archaxis.net. 10800 IN MX 30 bravo.archaxis.net. > archaxis.net. 10800 IN MX 20 alpha.archaxis.net. > > In both cases, the reported server is an AT server ;; SERVER: > 68.94.157.9#53 > . . .why shouldn’t this “point” to my server, 162.202.233.81 and not > AT’s? > Just to clear up the confusion on this point: dig is telling you that "SERVER: 68.94.157.9#53" is the DNS resolver that your computer used to answer the DNS question. That server is not part of the answer to the question. > > I have coded my BIND 9 in-addr.arpa zone file as follows: > > $ORIGIN 233.202.162.in-addr.arpa. > $TTL 3h > @ IN SOA ns1.archaxis.net. me.archaxis.net. ( > 2017012002 <(201)%20701-2002>; Serial > 1h ; Refresh > 1h ; Retry > 1h ; Expire > 1h ); Negative cashing TTL > > 3600IN NS ns1.archaxis.net. > 3600IN NS ns2.archaxis.net. > > 80 3600IN PTR network.archaxis.net. > 81 3600IN PTR alpha.archaxis.net. > 82 3600 IN PTR bravo.archaxis.net. > 87 3600IN PTR broadcast.archaxis.net. > > What is wrong? Is this my problem, or with AT? > -- Bob Harold ___ 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: Graphing BIND 9.11/9.10 Queries
On Wed, Jan 18, 2017 at 9:16 AM, Welisson Tomé <welissont...@ig.com.br> wrote: > Hi All, > > I'd like to know what kind of tools are you using to graphing queries on > Bind as Recursion Server? > > BestRegards, > > -- > > Welisson Tomébr.linkedin.com/in/welissontome/ > > > https://www.dns-oarc.net/tools/dsc -- Bob Harold ___ 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: How to get the CNAME for a domain?
On Tue, Jan 10, 2017 at 6:52 AM, Mark Andrews <ma...@isc.org> wrote:
>
> Use named-checkconf to get the list of master and slave zones from
> named.conf then transfer them all and extract the CNAME ownername
> that matches.
>
> named-checkconf -p |
> awk '$1 == "zone" { zone = $2; next; }
> $1 == "type" && ( $2 == "slave;" || $2 == "master;" ) { print zone }' |
> sed -e 's/^"//' -e 's/"$//' |
> dig axfr -f - |
> awk -v VSERVER=${VSERVER} '$4 == "CNAME" && $5 == VSERVER { print $1 }'
>
> --
> Mark Andrews, ISC
>
> I think this is a very interesting solution because:
- named-checkconf and dig format in a standard way, so it is easy to parse
- since DNS holds the data in ram, this avoids reading the files from disk,
so it could be much faster (unless the pipes | write to disk)
--
Bob Harold
___
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: Enterprise DNS Architecture - AD and BIND
On Wed, Dec 14, 2016 at 1:41 PM, Veaceslav Revutchi <slavarevut...@gmail.com > wrote: > On Wed, Dec 14, 2016 at 10:35 AM, Barry S. Finkel <bsfin...@att.net> > wrote: > > On 12/14/2016 Veaceslav Revutchi <slavarevut...@gmail.com> wrote: > > > >> Since this thread is still fresh, what is the current best practice > >> when slaving from AD? Do you pick one DC and list it as master or is > >> it safe to list multiple? We are looking to do the same and just > >> started the conversation with our AD team. The serial numbers among > >> DCs authoritative for the same zone are quite spread out and it takes > >> a few minutes for the DC with the lowest number to catch up. I'm not > >> sure if I can assume that two DCs with the same serial number have the > >> same zone contents. Haven't done a zone transfer comparizon yet. > >> > >> Curious to know what your experience is when slaving from AD. > >> > >> Thank you, > >> Slava > > > > > > I have not included the previous text in this reply. > > > > When I was managing a BIND/AD DNS infrastructure, I chose > > ONLY ONE of the AD DNS Servers as a master. There is a problem > > with serial numbers (KB282826 - I have that number memorized). > > If a MS DNS Server is not a master for a slave, then the zone > > serial number does not matter, as the zone is internal only to > > the Windows infrastructure. If the DNS Server is a master for > > the zone, then the zone serial number does matter. > > > > Assume, for example, that you have two MS DNS Servers for a zone, > > one on each of two Domain Controllers - DCA, and DCB. Assume > > that for a given zone both DCs have the same zone contents and > > zone serial number, say 100. Now, a machine sends a dynamic update for > > the zone to DCA at the same time that another machine sends another > > update to that zone to DCB. Each DC DNS now has a copy of the zone > > with an increased serial number (101) BUT with different contents. > > Sometime, under the covers of AD, the MS code will synchronize the > > zone contents between DCA and DCB, but what serial number should be > > assigned to the combined zone? It can't be 101, as that has already > > been used. Can it be 102? What happens if another dynamic update > > is sent to DCA or DCB while the synchronization is occurring? > > This is the problem, and why I chose only one DC to be the master > > for all of the DC zones. > > > > Also note that with the MS "_" zones, there are dynamic updates that > > do not change the contents of a zone but do increase the zone serial > > number. Thus there are lots of unnecessary zone transfers from the > > AD DNS Server to the BIND slave server(s). (This was true when I was > > the DNS manager, and I never got permission to ask MS why the serial > > number was incremented when the zone had not changed. Things might > > have changed in the past five years.) > > Barry, > > Appreciate you sharing this. This is good info. > > Thank you! > > My experience slaving AD zones with BIND servers: Ignore "failed while receiving responses: not exact " errors. I think that just means that the serial number changed during the transfer. I had them turn off 'notify' and we use the 'refresh' timer (15 minutes) to pull updates. I also ignore these errors for those servers: failed to connect: timed out failed while receiving responses: REFUSED I list more than one, for redundancy, and ignore serial number mismatches. Since it is constantly increasing, updates missed on one transfer should be in the next transfer. That 'works'. Whether that means "works fine" or "users have gotten used to it" is hard to say. -- Bob Harold ___ 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: delegation broken after migrating to new BIND config
On Thu, Dec 8, 2016 at 11:09 PM, blrmaani <blrma...@gmail.com> wrote: > I migrated our bind resolvers to a new config (new named.conf) and I see > delegation broken. How do I trouble-shoot? > > - The resolvers (are slaves) and are authoritative for zone1.example.com > and example.com > - the resolvers forward queries to our companies DNS to resolve external > names like microsoft.com, isc.com etc > - The resolver has views and match same destinations in both old and new > config. > > > > the zone is zone1.example.com which contains a record > name1.zone1.example.com as below: > name1.zone1.example.com. NS othername1.example.com. > othername1.example.com.A 1.2.3.4 > > > dig @localhost name1.zone1.example.com. # this doesn't give any hint. > > Here are the steps I tried and still no luck: > > 1. Compared zone transfer output of zone1.example.com before and after > migration, both look similar and contains delegation entry. > > 2. I tried this and works ok (before and after migration) in both cases > indicating that the NS > is still reachable and respond to DNS queries before and after > migration. > > dig @othername1.example.com. name1.zone1.example.com. > ## Returns 5.6.7.8 as expected ACLs broken > > > 3. Checked cache dump file (db file) - I see the following entry when it > works (pre-migration): > cache_dump.db:; 1.2.3.4 [srtt 0] [flags ] [ttl 1797] > > however, the above entry is missing after I migrate to new BIND config. > > > I compared the BIND configs before and after migration and I don't see any > significant difference which might cause this issue.. wondering what am I > missed? > > Thanks > Blr > Looks to me like "othername1.example.com" is not in the zone " zone1.example.com" and is not below that zone, so it is not proper glue, and should not be in that zone at all. The name server should ignore it. It is in zone "example.com <http://othername1.example.com/>" and that zone should be queried to find it. -- Bob Harold ___ 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: What to report for "refresh: failure trying master ... operation canceled" bug?
On Mon, Nov 21, 2016 at 7:02 PM, schilling <schilling2...@gmail.com> wrote: > added both tcp and udp port 53, still seeing the log messages. > > Best, > > Shiling > > On Mon, Nov 21, 2016 at 5:45 PM, Anand Buddhdev <ana...@ripe.net> wrote: > >> On 22/11/2016 00:27, schilling wrote: >> >> > Thanks for the insight. >> > I added the following rule >> > sudo firewall-cmd --permanent --direct --get-all-rules >> > [sudo] password for admin: >> > ipv4 filter OUTPUT 0 -d 10.10.10.100 -p tcp -m tcp --dport=53 -j ACCEPT >> > where 10.10.10.100 is our DNS master, still receiving the error. >> >> Why have you only allowed TCP port 53? What about UDP port 53? BIND >> first sends a UDP query to the master for the zone's SOA record, to >> determine if it needs to transfer the zone or not. >> >> Regards, >> Anand >> > > I don't have a solution, but some debugging options: I would suggest running packet traces with the same steps, with and without the firewall, and compare the traces. Also, if possible, turn on logging in the firewall and see what is being blocked. You could also turn on BIND debugging - see the appendix of the "DNS and BIND" book for debugging help. -- Bob Harold ___ 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: BIND statistics?
On Wed, Nov 16, 2016 at 8:45 AM, Voigt, Thomas <thomas.vo...@netkom.de> wrote: > Hi all, > > I need to create some statistics for our BIND resolvers here. One of the > measures is the number of unique ip addresses per day which are querying > our resolvers. > > I've already checked "rndc stats" output as well as BIND's XML statistics > channels. But I didn't found any value that satisfies this question. > > Another way could be to apply some "grep | sort --unique" logic to the > named_querylog file(s). But those files are around >2Gig per day and > resolver here. That's to much work... > > Is there another way to get this measure? > > -- > Regards > > Thomas > > I suspect that "DSC" collects the data you want, but you might need to configure a graph to show it. https://www.dns-oarc.net/tools/dsc -- Bob Harold ___ 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: ECS prefix and EDNS Client subnet question
N: > ;areaxx.sub.example.com.IN A > > ;; ANSWER SECTION: > areaxx.sub.example.com. 60 IN A 10.0.255.255 > > ==Test 1 : in view area01 "no-ecs-area01" > exist=== > C:>dig areaxx.sub.example.com. @dns2.sub.example.com. > > ; <<>> DiG 9.11.0 <<>> areaxx.sub.example.com. @dns2.sub.example.com. > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32403 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ; COOKIE: ec76aa0d6063ddfac0fb42b958118fa3039eae3d58015a05 (good) > ;; QUESTION SECTION: > ;areaxx.sub.example.com.IN A > > ;; ANSWER SECTION: > areaxx.sub.example.com. 60 IN A 10.0.0.10 > > ==Test 3 : in view area01 "no-ecs-area01" no exist > === > C:>dig areaxx.sub.example.com. @dns2.sub.example.com. > +subnet=192.168.164.1 > > ; <<>> DiG 9.11.0 <<>> areaxx.sub.example.com. @dns2.sub.example.com. > +subnet=192.168.164.1 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62641 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ; COOKIE: cb35db4f91e921970f85303858118f1128a20c69c0e0b995 (good) > ; CLIENT-SUBNET: 192.168.164.1/32/24 > ;; QUESTION SECTION: > ;areaxx.sub.example.com.IN A > > ;; ANSWER SECTION: > areaxx.sub.example.com. 60 IN A 10.0.0.10 > > ==Test 4 : from example.com. domain DNS Server > query === > C:>dig areaxx.sub.example.com. @dns2.example.com. > > ; <<>> DiG 9.11.0 <<>> areaxx.sub.example.com. @dns2.example.com. > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53897 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ; COOKIE: da1119758607734a0e0355755811906b9703987cbc318f84 (good) > ;; QUESTION SECTION: > ;areaxx.sub.example.com.IN A > > ;; ANSWER SECTION: > areaxx.sub.example.com. 60 IN A 10.0.255.255 > > > C:>dig areaxx.sub.example.com. @dns2.example.com. +subnet=192.168.164.1 > > ; <<>> DiG 9.11.0 <<>> areaxx.sub.example.com. @dns2.example.com. > +subnet=192.168.164.1 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8782 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ; COOKIE: 342acccf1e48e80572a35255581190a7a6a2857252dd6c05 (good) > ; CLIENT-SUBNET: 192.168.164.1/32/0 > ;; QUESTION SECTION: > ;areaxx.sub.example.com.IN A > > ;; ANSWER SECTION: > areaxx.sub.example.com. 60 IN A 10.0.255.255 > > === > The EDNS Client Subnet (ECS) option is used by a recursive resolver to > inform an authoritative name server of the network address block from > which the original query was received, enabling authoritative servers > to give different answers to the same resolver for different resolver > clients. > An ACL containing an element of the form ecs prefix will match > if a request arrives in containing an ECS option encoding an address > within that prefix. > If the request has no ECS option, then "ecs" elements are simply ignored. > Addresses in ACLs that are not prefixed with "ecs" are matched only > against the source address. > > Above section was from ARM page 176, when i careful check my config file > I don't know where i was wrong > > > > > > Client subnet information will store in which log > > > -- > 本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請銷毀此信件。 This email may contain > confidential information. Please do not use or disclose it in any way and > delete it if you are not the intended recipient. > > The first three dig commands look correct. 1. No ecs, so it does not match. 2. No ecs, matches "no-ecs-area01" 3. ecs matches 4. and 5. use "@dns2.example.com." instead of "@dns2.sub.example.com." - is that a different server? -- Bob Harold ___ 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: Bind 9.11 question (ACL ecs )
;;
> include "d:\isc bind 9\etc\no-ecs-acl-list.txt";
> include "d:\isc bind 9\etc\KeyFiles.txt";
> include "d:\isc bind 9\etc\logging.conf";
>
> options {
> directory "d:\isc bind 9\var\named";
> allow-update {none;};
> notify explicit;
> allow-transfer { none; };
> allow-query { none; };
> };
>
> // End Options
>
> view "area01" {
> match-clients { area01; ecs-area01; !{!ecs-area01; any; } ; key
> Area01.mydomain.idv.;};
> zone "sub.mydomain.idv" in {
> type slave;
> allow-query { area01; ecs-area01; };
> file "sub/area01.mydomain.idv.ca";
> masters { a.b.c.d key Area01.mydomain.idv.; };
> };
> }; // End View
>
> view "area02" {
> match-clients { area02; ecs-area02; !{!ecs-area02; any; } ; key
> Area02.mydomain.idv.;};
> zone "sub.mydomain.idv" in {
> type slave;
> allow-query { area02; ecs-area02; };
> file "sub/area02.mydomain.idv.ca";
> masters { a.b.c.d key Area02.mydomain.idv.; };
> }; // End View
>
> view "area03" {
> match-clients { area03; ecs-area03; !{!ecs-area03; any; } ; key
> Area03.mydomain.idv.;};
> zone "sub.mydomain.idv" in {
> type slave;
> allow-query { area03; ecs-area03; };
> file "sub/area03.mydomain.idv.ca";
> masters { a.b.c.d key Area03.mydomain.idv.; };
> }; // End View
>
> view "deafult" { // Default
> match-clients { any; };
> zone "sub.mydomain.idv" in {
> type slave;
> allow-query { any; };
> file "sub/default.mydomain.idv.ca";
> masters { a.b.c.d key default.mydomain.idv.; };
> };
> }; // End View
>
>
>
> My dns server was install windows 2012 r2.
>
> My client pc at area02 subnet so when i use dig test (if not area02 - ACL
> entry) then it willget default view
>
> enrty record. But from above red word it means it query packet not include
> ecs it will ignore ecs function.
>
>
>
> when i use dig query sub.mydomain.idv entry through mydomain.idv then it
> alway return default view entry not view area02 entry.
>
>
>
> Did anyone can help me where was wrong...
>
> use ecs prefix
>
I cannot answer your question, but I have some questions, if you would be
so kind as to answer.
I did not know that you could use sub-groups {...} inside and acl list -
thanks for that!
I don't understand "!{!ecs-area03; any; }" - is that really the same as
just "ecs-area03" ?
Could you try "ecs-area03" without "!{!ecs-area03; any; }" ?
--
Bob Harold
___
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: BIND 9.11.0 RPZ performance issue
On Tue, Oct 18, 2016 at 3:26 AM, Mukund Sivaraman <m...@isc.org> wrote: > > Firstly, RPZ in BIND 9.9 (vanilla) is broken, unmaintained and should > not be used by anyone. If you know people using BIND 9.9 (vanilla) for > RPZ, please ask them to upgrade to 9.10 at least. RPZ in 9.9 > subscription branch is OK. > > Is RPZ in BIND 9.8 ok to use? (Using RedHat 9.8.2 plus they backport security patches.) -- Bob Harold ___ 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: Master/Slave communication not working if I use HMAC-SHA* algorithms when views are implemented
On Fri, Oct 14, 2016 at 1:30 AM, Nagesh Thati <nagesh.th...@tcpwave.com> wrote: > Hi, > > Can anybody implemented master/slave communication with views and > algorithm HMAC-SHA* algorithms. I tried with all the HMAC-SHA* algorithms > it didn't work for me, only HMAC-MD5 algorithm worked for communication. If > anybody has any idea please help me. > Thanks. > > > -- > Thanks, > Nagesh Thati > > That appears to depend on the version of BIND: The BIND manual for 9.8 says that only HMAC-MD5 can be used for TSIG. The BIND manual for 9.9 lists HMAC-MD5 and lots of HMAC-SHA* versions. See "dnssec-keygen" in the appendix. -- Bob Harold ___ 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: Multiple $TTL values
On Thu, Sep 22, 2016 at 3:36 PM, Woodworth, John R < john.woodwo...@centurylink.com> wrote: > Hello, > > > > We’ve recently noticed multiple $TTL values in transferred zonefiles which > do not exist in the original zonefiles. They appear to be aggregates of > TTLs set for individual records and I am definitely a fan of the organized > look and feel. > > > > However, I am curious about how they should be interpreted where $ORIGIN > is concerned. I just re-read rfc2308 and it states quite simply: > > “ All resource records appearing after the directive, and which do not > > explicitly include a TTL value, have their TTL set to the TTL given > > in the $TTL directive. “ > > > > My confusion is $ORIGIN basically defines the default origin while reading > in the file and creates a mini-universe for interpreting records until > redefined. Would a $TTL after a $ORIGIN be encapsulated by and restricted > to records within that $ORIGIN block? > > > > My gut tells me no, and to follow the RFC literally (or loosely stated > “from this point down”) but looking at the file it seems as if the $TTL is > intended to be for the records within the $ORIGIN only (i.e. it is not > reset to global value at the end). > > > > I need to investigate this more on my own but I thought it might prove > useful to ask the group as part of my research. > > > > > > Thanks in advance, > > John > > > This is a common point of confusion. DNS does not transfer zoneFILES. Zone files are read and converted into the in-memory tree structure. Zones are sent in wire format from the in-memory tree. The receiving end populates its in-memory tree. It can then convert the information to zone file format, and write it out, but do not expect it to look anything like the original zone file. It has no idea what the original file looked like, or what order the records were in. $ORIGIN and $TTL only apply to the zone they are in, so no need to reset them at the end of the file since they cease to exist at that point. They apply "from this line down until changed" and are merely a convenience to shorten the size of the file. -- Bob Harold ___ 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: DNS views and zone transfers, cont
On Tue, Sep 13, 2016 at 10:58 AM, project722 <project...@gmail.com> wrote:
> I have moved the new views into production, and all seems to be working
> fine. I have an "internal" view and an "external" view. I have noticed a
> few re-occuring messages in the logs of the master server that I'd like to
> suppress. Here is what I am seeing:
>
> 1) Warning: view external: 'empty-zones-enable/disable-empty-zone' not
> set: disabling RFC 1918 empty zones: 37 Time(s)
>
> 2) connect(fe80::216:3eff:fe37:b866#53) 22/Invalid argument: 7 Time(s)
>
> 3) zone
> 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA/IN/external:
> (master) removed: 1 Time(s)
> zone 112/x.x.x.IN-ADDR.ARPA/IN: (master) removed: 1 Time(s)
> zone x.x.x.in-addr.arpa/IN: (master) removed: 1 Time(s)
>
> For # 3 I basically see an entry for each of our reverse mapping zones,
> which are valid and I don't want them "removed" as the message states And I
> think these are related to #1. I believe I can fix #1 with the
> "empty-zones-enable
> no;" in my external view, but I am not sure what effect it would have on
> the message generation or how it would affect zone behavior in that view.
>
> I have "empty-zones-enable yes;" in my options, and then
"empty-zones-enable no;" in the view that is forwarding. So either define
it in every view, or define a default in the options.
> For #2, - I already have a statement "server fe80::/16 { bogus yes; };" in
> my named.conf. However it is above the options statement and I am now
> wondering if I need this defined in each view now. Also this
> fe80::216:3eff:fe37:b866
> is not even my actual link local IP so I am not sure where/how that is
> being generated. My actual link local is
> fe80::f21f:afff:fedd:6a26/64
>
>
I have the "server ... bogus ..." statement in each view, so try it there.
> Any help is greatly appreciated.
>
> On Thu, Sep 8, 2016 at 11:33 AM, project722 <project...@gmail.com> wrote:
>
>> I am not seeing that but thanks for the heads up. I will keep an eye on
>> it.
>>
>> On Thu, Sep 8, 2016 at 10:14 AM, Bob Harold <rharo...@umich.edu> wrote:
>>
>>> I changed the subject slightly, because I had to cut out a lot of the
>>> forwarded message - the list server was complaining about the size of the
>>> messages.
>>>
>>> I just found that my setup was not working completely as I expected.
>>> The view with only a few zones and forwarding to another view automatically
>>> got the "empty zones" created, so any queries in those zones did not get
>>> forwarded. I am fixing it by adding to that view the line:
>>>empty-zones-enable no;
>>>
>>> --
>>> Bob Harold
>>>
>>>
>>> On Thu, Sep 8, 2016 at 9:41 AM, Bob Harold <rharo...@umich.edu> wrote:
>>>
>>>>
>>>> On Thu, Sep 8, 2016 at 9:13 AM, project722 <project...@gmail.com>
>>>> wrote:
>>>>
>>>>> Bob, in our prod environment, we are allowing 127.0.0.1 to make zone
>>>>> transfers. First off, what is the reasoning or benefit of allowing
>>>>> localhost to make zone transfers? Secondly, In my new view config since I
>>>>> will be using 127.0.0.1 as a forwarder, would this in any way cause a
>>>>> problem or a conflict if I was to leave the localhost IP in the ACL for
>>>>> zone transfers?
>>>>>
>>>>
>>>> I would allow 127.0.0.1 to do zone transfers for troubleshooting
>>>> purposes, if I am on the server and want to look at a whole zone. But it
>>>> is not required, if you don't use it for transfers.
>>>> Allowing zone transfers should not affect its use for forwarding, as
>>>> far as I can see.
>>>>
>>>> --
>>>> Bob Harold
>>>>
>>>>
>>>>
>>>>> On Wed, Sep 7, 2016 at 2:30 PM, Bob Harold <rharo...@umich.edu> wrote:
>>>>>
>>>>>> You should change:
>>>>>> match-clients { internal; key tsigkey; !key tsigkeyext;
>>>>>> To:
>>>>>> match-clients { !key tsigkeyext; internal; key tsigkey;
>>>>>>
>>>>>> The 'not' (!) won't work if it is last, they are checked in order, so
>>>>>> it needs to be first.
>>>>>>
>>>>>> --
>>>>>> Bob Harold
>>>>>>
>>>>>>
>>>&g
Re: DNS views and zone transfers, cont
I changed the subject slightly, because I had to cut out a lot of the
forwarded message - the list server was complaining about the size of the
messages.
I just found that my setup was not working completely as I expected. The
view with only a few zones and forwarding to another view automatically got
the "empty zones" created, so any queries in those zones did not get
forwarded. I am fixing it by adding to that view the line:
empty-zones-enable no;
--
Bob Harold
On Thu, Sep 8, 2016 at 9:41 AM, Bob Harold <rharo...@umich.edu> wrote:
>
> On Thu, Sep 8, 2016 at 9:13 AM, project722 <project...@gmail.com> wrote:
>
>> Bob, in our prod environment, we are allowing 127.0.0.1 to make zone
>> transfers. First off, what is the reasoning or benefit of allowing
>> localhost to make zone transfers? Secondly, In my new view config since I
>> will be using 127.0.0.1 as a forwarder, would this in any way cause a
>> problem or a conflict if I was to leave the localhost IP in the ACL for
>> zone transfers?
>>
>
> I would allow 127.0.0.1 to do zone transfers for troubleshooting purposes,
> if I am on the server and want to look at a whole zone. But it is not
> required, if you don't use it for transfers.
> Allowing zone transfers should not affect its use for forwarding, as far
> as I can see.
>
> --
> Bob Harold
>
>
>
>> On Wed, Sep 7, 2016 at 2:30 PM, Bob Harold <rharo...@umich.edu> wrote:
>>
>>> You should change:
>>> match-clients { internal; key tsigkey; !key tsigkeyext;
>>> To:
>>> match-clients { !key tsigkeyext; internal; key tsigkey;
>>>
>>> The 'not' (!) won't work if it is last, they are checked in order, so it
>>> needs to be first.
>>>
>>> --
>>> Bob Harold
>>>
>>>
>>> On Wed, Sep 7, 2016 at 3:21 PM, project722 <project...@gmail.com> wrote:
>>>
>>>> I think I have found the problem. I did not need dnssec enabled after
>>>> all. All this time I thought it was needed for TSIG to work. But
>>>> apparently, the forwarding is working, and zone transfers are going to the
>>>> right view without it enabled.
>>>>
>>>> On Wed, Sep 7, 2016 at 1:15 PM, project722 <project...@gmail.com>
>>>> wrote:
>>>>
>>>>> Ok I'm with you now. I have reconfigured my servers and I cant get the
>>>>> forwarding to work. Since 127.0.0.1 is forwarding request, I made sure in
>>>>> the options stanza to set it to a listen IP. I have tried several
>>>>> different
>>>>> variations of this method and all end up with SERVFAIL's using dig from a
>>>>> client that gets the "internal" view. Here is my config.
>>>>>
>>>>> acl internal {
>>>>> 192.168.254.0/23; // corpnet
>>>>> };
>>>>>
>>>>> acl external {
>>>>> 192.168.155.0/24;
>>>>> 192.168.160.0/24;
>>>>> };
>>>>>
>>>>> options {
>>>>> listen-on port 53 { 192.168.155.128; 127.0.0.1; }; #Master DNS
>>>>> Servers IP
>>>>> directory "/var/named";
>>>>> dump-file "/var/named/data/cache_dump.db";
>>>>> statistics-file "/var/named/data/named.stats";
>>>>> memstatistics-file "/var/named/data/named_mem_stats.txt";
>>>>> allow-query{ internal; external; };
>>>>> dnssec-enable yes;
>>>>> dnssec-validation auto;
>>>>> dnssec-lookaside auto;
>>>>> zone-statistics yes;
>>>>>
>>>>> /* Path to ISC DLV key */
>>>>> bindkeys-file "/etc/named.iscdlv.key";
>>>>>
>>>>> managed-keys-directory "/var/named/dynamic";
>>>>>
>>>>> };
>>>>>
>>>>> key "tsigkey" {
>>>>> algorithm HMAC-SHA512;
>>>>> secret "x";
>>>>> };
>>>>>
>>>>> key "tsigkeyext" {
>>>>> algorithm HMAC-SHA512;
>>>>> secret "xx";
>>>>> };
>>>>>
>>>>> // Start internal view
>>>>>
>>>>> view "corpnet" {
>>>>> match-clients { interna
Re: DNS views and zone transfers
On Wed, Sep 7, 2016 at 12:49 PM, project722 <project...@gmail.com> wrote:
> Bob, I have few questions regarding your sample config. First off it is
> slightly different than mine, which does work BTW at least in a lab
> environment. In your internal view what is the purpose of having this line:
>
> // this list must not match 127.0.0.1
> !key "external"; // use this key to test the external
> view
> 10.0.0.0/8;
>
> Why use 127.0.0.1 and what is the 10.0.0.0/8 block for? I also noticed
> you did not include the external key indie the external view. Why is that?
>
The "internal" and "external" keys are so that I can test both views from
anywhere with:
dig something -k key.internal
dig something -k key.external
The keys are also used if you need to do notify's or zone transfers and get
them to the right view.
127.0.0.1 is used to talk from one view to the other, so it needs to match
the external view in this case
10.0.0.0/8 are the "internal" addresses in this example.
The external view could have included the external key, but 'any' covers
that. If your match is not "any', then you would want to include the
external key and 127.0.0.1.
> On Wed, Sep 7, 2016 at 10:48 AM, Bob Harold <rharo...@umich.edu> wrote:
>
>>
>> On Wed, Sep 7, 2016 at 11:37 AM, project722 <project...@gmail.com> wrote:
>>
>>> Thanks Bob, I will look into this. Do you know if the forwarders feature
>>> is supported in Bind 9.8.2?
>>>
>>>
>> Yes, forwarders is an old and stable feature.
>>
>> ("in-view" is new and experimental)
>>
>> --
>> Bob Harold
>>
>>
>>> On Wed, Sep 7, 2016 at 9:38 AM, Bob Harold <rharo...@umich.edu> wrote:
>>>
>>>>
>>>> On Tue, Sep 6, 2016 at 5:23 PM, project722 <project...@gmail.com>
>>>> wrote:
>>>>
>>>>> I'm interested in the "view forwarding" method. I'm only setting up
>>>>> views to resolve a split DNS issue with one domain. I'd like to have that
>>>>> one zone/domain in my internal view and then if the source IP requests
>>>>> info
>>>>> for any other zone forward that to my external view. To me this sounds
>>>>> like
>>>>> a whole lot less work. Do you have any specifics on how I would go about
>>>>> setting that up or can you point me in the direction where I can get info
>>>>> on setting that up? Ideally, I'd want my "internal" clients to still find
>>>>> example.com even if the internal view only had example.org in it.
>>>>> Something like this but how do I incorporate the forwarding?
>>>>>
>>>>> view internal {
>>>>>
>>>>>match clients - internal;
>>>>>
>>>>> zone - example.org
>>>>>
>>>>> };
>>>>>
>>>>> view external {
>>>>>
>>>>> match clients - external {
>>>>>
>>>>> zone example.org {
>>>>> };
>>>>>
>>>>> zone example.com {
>>>>> };
>>>>>
>>>>> };
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Aug 30, 2016 at 2:53 PM, Bob Harold <rharo...@umich.edu>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> On Thu, Aug 25, 2016 at 12:56 PM, project722 <project...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I have successfully setup TSIG keys for "views" using a DNS
>>>>>>> master/server pair. Zone transfers are working as expected between the 2
>>>>>>> servers for each view. Before we go live into production with this I
>>>>>>> need
>>>>>>> some clarification on a couple things. Our prod servers are also
>>>>>>> allowing
>>>>>>> zone transfers to a few other servers besides the slave server. We have
>>>>>>> an
>>>>>>> acl setup that looks similar to this:
>>>>>>>
>>>>>>> other_xfer_allowed_ns {
>>>>>>> x.x.x.x; // This is our Secondary DNS server
>>>>>>> 127.0.0.1; // localhost can make zone transfers
>>>>>>> x.x.x.x/24; // Server Farm Range is allowed to make zone-transfers
>>>>>>> x.x.x.x/24; // NAT pool for internal DNS server
Re: DNS views and zone transfers
On Wed, Sep 7, 2016 at 12:34 PM, /dev/rob0 <r...@gmx.co.uk> wrote:
> On Wed, Sep 07, 2016 at 11:48:54AM -0400, Bob Harold wrote:
> > On Wed, Sep 7, 2016 at 11:37 AM, project722 <project...@gmail.com>
> wrote:
> >
> > > Thanks Bob, I will look into this. Do you know if the forwarders
> > > feature is supported in Bind 9.8.2?
> > >
> > Yes, forwarders is an old and stable feature.
> >
> > ("in-view" is new and experimental)
>
> "New" is fair to say, if you call BIND 9.10 "new". OTOH it is
> unfair/wrong to call it "experimental". 9.10 has been in stable
> release form for quite some time now, and there have been no problems
> with the in-view zone feature, AFAIK.
My apologies. You are correct, it is just not fossilized enough to be the
default in most Linux distros.
> > > On Wed, Sep 7, 2016 at 9:38 AM, Bob Harold <rharo...@umich.edu> wrote:
> > >
> > >>
> > >> On Tue, Sep 6, 2016 at 5:23 PM, project722 <project...@gmail.com>
> wrote:
>
> snip
> > >> Here is the basic structure:
> > >>
> > >> view "internal" {
> > >> match-clients {
> > >> // this list must not match 127.0.0.1
> > >> !key "external"; // use this key to test the external view
> > >> 10.0.0.0/8;
> > >> key "internal"; // use this key to test the internal view
> > >> };
> > >> zone "itd.umich.edu" {// this zone is different in the two
> views
> > >> type master;
> > >> file "internal/itd.umich.edu";
> > >> };
> > >> forwarders {
> > >> // forward to external view
> > >> 127.0.0.1;
>
> I have never thought to try this, but I would not expect it to work.
> Does it?
It works, and avoids having extra copies of the zones on disk and in memory
(I don't have 9.10). Downsides are the caching in both views, and query
logging (if enabled) logs it twice.
> >> };
> > >> forward only;// optional
> > >> };
> > >> view "external" {
> > >> match-clients {
> > >> // this list must match 127.0.0.1
> > >> any;
> > >> };
> > >> zone "itd.umich.edu" {// this zone is different in the two
> views
> > >> type master;
> > >> file "external/itd.umich.edu";
> > >> };
> > >> zone "10.in-addr.arpa" { // all other zones will be seen by
> everyone
> > >> type master;
> > >> file "external/arpa.in-addr.10";
> > >> };
> > >> zone "umich.edu" {
> > >> type master;
> > >> file "external/com.umich";
> > >> };
> > >> };
>
> --
> 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: DNS views and zone transfers
On Wed, Sep 7, 2016 at 11:37 AM, project722 <project...@gmail.com> wrote:
> Thanks Bob, I will look into this. Do you know if the forwarders feature
> is supported in Bind 9.8.2?
>
>
Yes, forwarders is an old and stable feature.
("in-view" is new and experimental)
--
Bob Harold
> On Wed, Sep 7, 2016 at 9:38 AM, Bob Harold <rharo...@umich.edu> wrote:
>
>>
>> On Tue, Sep 6, 2016 at 5:23 PM, project722 <project...@gmail.com> wrote:
>>
>>> I'm interested in the "view forwarding" method. I'm only setting up
>>> views to resolve a split DNS issue with one domain. I'd like to have that
>>> one zone/domain in my internal view and then if the source IP requests info
>>> for any other zone forward that to my external view. To me this sounds like
>>> a whole lot less work. Do you have any specifics on how I would go about
>>> setting that up or can you point me in the direction where I can get info
>>> on setting that up? Ideally, I'd want my "internal" clients to still find
>>> example.com even if the internal view only had example.org in it.
>>> Something like this but how do I incorporate the forwarding?
>>>
>>> view internal {
>>>
>>>match clients - internal;
>>>
>>> zone - example.org
>>>
>>> };
>>>
>>> view external {
>>>
>>> match clients - external {
>>>
>>> zone example.org {
>>> };
>>>
>>> zone example.com {
>>> };
>>>
>>> };
>>>
>>>
>>>
>>> On Tue, Aug 30, 2016 at 2:53 PM, Bob Harold <rharo...@umich.edu> wrote:
>>>
>>>>
>>>> On Thu, Aug 25, 2016 at 12:56 PM, project722 <project...@gmail.com>
>>>> wrote:
>>>>
>>>>> I have successfully setup TSIG keys for "views" using a DNS
>>>>> master/server pair. Zone transfers are working as expected between the 2
>>>>> servers for each view. Before we go live into production with this I need
>>>>> some clarification on a couple things. Our prod servers are also allowing
>>>>> zone transfers to a few other servers besides the slave server. We have an
>>>>> acl setup that looks similar to this:
>>>>>
>>>>> other_xfer_allowed_ns {
>>>>> x.x.x.x; // This is our Secondary DNS server
>>>>> 127.0.0.1; // localhost can make zone transfers
>>>>> x.x.x.x/24; // Server Farm Range is allowed to make zone-transfers
>>>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>>>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>>>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>>>>> }; // end of "other_xfer_allowed" ACL
>>>>>
>>>>> And in the "allow transfer" statement we have included that ACL. My
>>>>> question is:
>>>>>
>>>>> Now that we are using TSIG, will I need to get with the admins of all
>>>>> these other servers and provide them my TSIG key so they can request zone
>>>>> transfers? I would think somehting like that needs to be done since it was
>>>>> required to be configured on slave server, but I am not sure.
>>>>>
>>>>
>>>> No, if you allowed the IP range in your ACL, they don't need the TSIG
>>>> key.
>>>> It might be more secure to hand out TSIG keys and remove the IP ranges
>>>> from the ACL, so only the TSIG key will allow transfers, since IP addresses
>>>> are easier to spoof, but since a zone transfer requires TCP, spoofing is
>>>> not likely.
>>>>
>>>> The TSIG key was required on the slave in order to get the right view,
>>>> if I remember correctly.
>>>>
>>>>
>>>>>
>>>>> Next,
>>>>>
>>>>> I setup views so that clients on the "internal" network when
>>>>> requesting a record would be presented with different records than clients
>>>>> on the outside. And at the moment there is only one zone that is required
>>>>> to have different records. However, It is my understanding that since
>>>>> views
>>>>> are based off source IP's, if I was to ONLY include that one zone in my
>>>>> "internal" view, if a record was requested for another zone from that same
>>&g
Re: DNS views and zone transfers
On Tue, Sep 6, 2016 at 5:23 PM, project722 <project...@gmail.com> wrote:
> I'm interested in the "view forwarding" method. I'm only setting up views
> to resolve a split DNS issue with one domain. I'd like to have that one
> zone/domain in my internal view and then if the source IP requests info for
> any other zone forward that to my external view. To me this sounds like a
> whole lot less work. Do you have any specifics on how I would go about
> setting that up or can you point me in the direction where I can get info
> on setting that up? Ideally, I'd want my "internal" clients to still find
> example.com even if the internal view only had example.org in it.
> Something like this but how do I incorporate the forwarding?
>
> view internal {
>
>match clients - internal;
>
> zone - example.org
>
> };
>
> view external {
>
> match clients - external {
>
> zone example.org {
> };
>
> zone example.com {
> };
>
> };
>
>
>
> On Tue, Aug 30, 2016 at 2:53 PM, Bob Harold <rharo...@umich.edu> wrote:
>
>>
>> On Thu, Aug 25, 2016 at 12:56 PM, project722 <project...@gmail.com>
>> wrote:
>>
>>> I have successfully setup TSIG keys for "views" using a DNS
>>> master/server pair. Zone transfers are working as expected between the 2
>>> servers for each view. Before we go live into production with this I need
>>> some clarification on a couple things. Our prod servers are also allowing
>>> zone transfers to a few other servers besides the slave server. We have an
>>> acl setup that looks similar to this:
>>>
>>> other_xfer_allowed_ns {
>>> x.x.x.x; // This is our Secondary DNS server
>>> 127.0.0.1; // localhost can make zone transfers
>>> x.x.x.x/24; // Server Farm Range is allowed to make zone-transfers
>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>>> }; // end of "other_xfer_allowed" ACL
>>>
>>> And in the "allow transfer" statement we have included that ACL. My
>>> question is:
>>>
>>> Now that we are using TSIG, will I need to get with the admins of all
>>> these other servers and provide them my TSIG key so they can request zone
>>> transfers? I would think somehting like that needs to be done since it was
>>> required to be configured on slave server, but I am not sure.
>>>
>>
>> No, if you allowed the IP range in your ACL, they don't need the TSIG key.
>> It might be more secure to hand out TSIG keys and remove the IP ranges
>> from the ACL, so only the TSIG key will allow transfers, since IP addresses
>> are easier to spoof, but since a zone transfer requires TCP, spoofing is
>> not likely.
>>
>> The TSIG key was required on the slave in order to get the right view, if
>> I remember correctly.
>>
>>
>>>
>>> Next,
>>>
>>> I setup views so that clients on the "internal" network when requesting
>>> a record would be presented with different records than clients on the
>>> outside. And at the moment there is only one zone that is required to have
>>> different records. However, It is my understanding that since views are
>>> based off source IP's, if I was to ONLY include that one zone in my
>>> "internal" view, if a record was requested for another zone from that same
>>> IP, they would probably get an nxdomain answer since that IP is limited to
>>> that one view.
>>>
>>> So, my question is, will I need to include all zones in both views so
>>> that all clients can get results, even though I would only have (at the
>>> moment) one zone that points to two different zone files? All others in
>>> both views would point to the same zone file, unless of course there is
>>> another zone we need to present a different view to for internal clients.
>>>
>>
>> You have a few choices:
>> - Copies of zones in both views. More memory used, more zone transfers,
>> but probably safest and best performance. This is what I do. The zones in
>> the two views will need to be in separate files, if they are "slave" zones,
>> otherwise Bind will get confused and complain, because it does not realize
>> that two different views are trying to write the same file.
>> - One view could 'forward' to the other view for zones it does not have.
>> (Doubles the query logg
Re: Request reverse dns mapping advice
On Tue, Sep 6, 2016 at 1:39 AM, Dave Warren <da...@hireahit.com> wrote: > On Mon, Sep 5, 2016, at 09:46, John Levine wrote: > > >1. pick a primary domain from the list of virtual hosts (example2.com) > > >2. use the "real" host name of the server (juvat.example1.com) > > >3. the mail server name (mail.example1.com) > > >4. the dns server name (ns2.example1.com) > > >5. another domain from the virtual hosts list (example 3.com) > > > > Publish a PTR with the mail server name, forget about the rest of > > them. > > > > On today's Internet, you want your mail server to EHLO with a name > > that has matching forward and reverse DNS with the server's IP. If > > you don't, you look unnecessarily like a spambot. > > > > Everyone knows that web servers and DNS servers have multiple names, > > and neither should be sending unsolicited traffic, so matching rDNS > > doesn't matter. > > Perhaps I'm old fashioned, but I like to see things done "correctly", > and rDNS is one of those things that shows a competent host who worries > about getting the details right, vs a host who has no technical skills > or knowledge and does the bare minimum. Does it make for an operational > difference? Not really. But it does make it obvious what entity is > responsible for a machine and I feel that that's important. > > Personally, I set valid and correct names that identify me (the host) on > machines under my control, whether or not they're intended to make > outbound connections (and web servers do). If an IP is dedicated to a > specific client then I'll consider what makes the most sense, but > generally I do assign the client's rDNS to a dedicated IP. > > With that being said, I'd do something like ns2.example.com, or > web.juvat.example.com, or whatever is appropriate within your normal > naming scheme. > > > Opinions vary on how well it works to return multiple PTRs. My > > advice is don't borrow trouble you don't need. > > I agree on this point. Even if it works with only a few PTRs (and it > mostly will, as long as each PTR has a matching and valid A/ > record), what will happen when you have dozens of domains? > > I agree with one PTR per IP. But since you have 5 IP's, you can have one PTR record on each, just be sure there is a matching forward "A" record. Your list of 5 names looks good, but only if each service uses the corresponding IP for its outgoing connections, which could be difficult or not the most efficient. (What is missing here is why 5 IP's - parallel for more traffic, connections to different Internet providers, ...?) -- Bob Harold ___ 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
