Re: MDLZ user activation

[Sten Carlsen]

I got one of those mails too, your explanation is correct. Nothing sofisticated 
here.

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

  "MALE BOVINE MANURE!!!"

> On 7 Jun 2024, at 12.11, Marco Moock  wrote:
> 
> Am 07.06.2024 um 10:58:27 Uhr schrieb G.W. Haywood:
> 
>> On the face of your description, this sounds like a spammer who has
>> slightly more skill than usual.
> 
> The spammer simply used the name in From: after the Nick posted tothe
> list) (Nick Tait via bind-users) and the mail address
> (bind-users@lists.isc.org) as the recipient.
> 
> I assume this was accidentally sent to the list and not Nick himself,
> but this is just a guess.
> 
>> I'd like to see the headers, or better the entire mail.  Please feel
>> free to send privately.
> 
> They are publicly posted on the list.
> 
> Message-ID:
> <6661e181d6fce_20e3f8fc856fcec65140...@sidekiq-frequent-fd-poduseast1-free-blue-fc47b6fff-n44lb.mail>
> 
> If you need it, I can forward it to you.
> 
> --
> Gruß
> Marco
> 
> Send unsolicited bulk mail to 1717750707mu...@cartoonies.org
> --
> 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: Observation: BIND 9.18 qname-minimization strict vs dig +trace

[Sten Carlsen]

Trace from my location dies even earlier:

;; Received 915 bytes from 2001:503:c27::2:30#53(j.root-servers.net) in 17 ms

;; connection timed out; no servers could be reached

Again just a data point.


> On 24 Apr 2024, at 22.03, tale via bind-users  
> wrote:
> 
> Hmm, I wonder if qname-minimisation is at issue here.   My trace dies with:
> 
> 85.191.131.in-addr.arpa. 1800   IN  NS  fs838.click-network.com.
> 85.191.131.in-addr.arpa. 1800   IN  NS  ns102.click-network.com.
> couldn't get address for 'fs838.click-network.com': not found
> couldn't get address for 'ns102.click-network.com': not found
> -- 
> 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



signature.asc
Description: Message signed with OpenPGP
-- 
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: Possibility of using views to properly return appropriate IP address for hostname based on requestor subnet?

[Sten Carlsen]

> On 29 Jun 2023, at 15.59, Ubence Quevedo  wrote:
> 
> Hi Greg,
> 
> Here's the most recent config that I tried that seemed to work, but 
> ultimately broke resolution for the main zone domain.com 
> , even though I set it to match-clients { any; }.

Please remember that ONLY ONE view is matched. Your main view is only used if 
none of the other views match.

> 
> What I didn't mention in my original post was that I have other subnets 
> configured for this remote host through vlans with different IP addresses.  
> That's why there are so many other views.  I was hoping the match-clients per 
> each view would return the appropriate IP address per subnet making the 
> request.
> 
> include "/etc/bind/rndc.key";
> include "/etc/bind/ddns-key.key";
> 
> view "192.168.10-net" {
>   match-clients { 192.168.10.0/24 ; };
>   zone "system.lab.domain.com " {
> type master;
> file "/var/lib/bind/db.system.lab.domain.com.192.168.10";
> };
> };
> 
> view "10.32.1-net" {
>   match-clients { 10.32.1.0/24 ; };
>   zone "system.lab.domain.com " {
> type master;
> file "/var/lib/bind/db.system.lab.domain.com.10.32.1";
> };
> };
> 
> view "10.32.10-net" {
>   match-clients { 10.32.10.0/24 ; };
>   zone "system.lab.domain.com " {
> type master;
>file "/var/lib/bind/db.system.lab.domain.com.10.32.10";
> };
> };
> 
> view "10.32.20-net" {
>   match-clients { 10.32.20.0/24 ; };
>   zone "system.lab.domain.com " {
> type master;
> file "/var/lib/bind/db.system.lab.domain.com.10.32.20";
> };
> };
> 
> view "10.32.30-net" {
> match-clients { 10.32.30.0/24 ; };
>   zone "system.lab.domain.com " {
> type master;
> file "/var/lib/bind/db.system.lab.domain.com.10.32.30";
> };
> };
> 
> view "main" {
>   match-clients { any; };
>   zone "domain.com " {
> type master;
> forwarders {};
> file "/var/lib/bind/db.domain.com ";
> update-policy {
>   grant ddns-key wildcard *.domain.com  A DHCID;
> };
> notify yes;
> allow-transfer { 192.168.10.183; };
> };
>   zone "lab.domain.com " {
> type secondary;
> masterfile-format text;
> file "/var/lib/bind/db.lab.domain.com ";
> primaries { 192.168.10.183; };
>   };
>   zone "10.168.192.in-addr.arpa" {
> type master;
> forwarders {};
> file "/var/lib/bind/db.10.168.192.in-addr.arpa";
> update-policy {
>   grant ddns-key wildcard *.10.168.192.in-addr.arpa PTR;
> };
>   };
> };
> 
> The contents of /var/lib/bind/db.system.lab.domain.com.192.168.10:
> $ORIGIN .
> $TTL 604800 ; 1 week
> system.lab.domain.com  IN SOA 
> ns1.domain.com . thatrat.gmail.com 
> . (
> 2023062800 ; serial
> 604800 ; refresh (1 week)
> 86400  ; retry (1 day)
> 2419200; expire (4 weeks)
> 604800 ; minimum (1 week)
> )
> NS  ns1.domain.com .
> $ORIGIN system.lab.domain.com .
> A   192.168.10.170
> 
> The other /var/lib/bind/db.system.lab.domain.com.10.32.X.X follow a similar 
> format with the domain name pointing to a different IP address for each 
> "version" of the domain matching a view for a different entry subnet.
> 
> Again, the domain.com  zone currently has an entry for 
> system.lab.domain.com  for 192.168.10.170 and 
> the secondary lab.domain.com  has an entry for 
> system.lab.domain.com  with 10.32.10.1.
> 
> This was all working perfectly until I added the secondary domain to my 
> config [essentially just the contents of the main view above] which it 
> started only returning 10.32.10.1 for the system.lab.domain.com 
>  which again I think had some type of 
> precedence on the "fuller" FQDN being served, and the system.lab from the 
> domain.com  zone taking lesser precedence.
> 
> It also seems that the bind configuration file is read from top down in 
> processing order?  I had the main view on top first, but then moved it below 
> the other views, and then the 192.168.10-net view worked...but the main view 
> did not work.
> 
> I know this is an overly complicated setup and probably the simplest answer 
> is just to remove the secondary zone from config so that there is only the 
> one entry that resolves for the system.lab.domain.com 
> 

Re: migration to new isp - now private addresses showing up publicly?

[Sten Carlsen]

> On 23 May 2023, at 19.46, Kaya Saman  wrote:
> 
> 
> 
> On 5/23/23 18:07, Sten Carlsen wrote:
>> 
>>> On 23 May 2023, at 19.00, Kaya Saman  
>>> <mailto:kayasa...@gmail.com> wrote:
>>> 
>>> 
>>>> On 5/23/23 12:47, Matus UHLAR - fantomas wrote:
>>>>> On 23.05.23 12:22, Kaya Saman wrote:
>>>>> I've got a very strange problem that has emerged somehow after migrating 
>>>>> my isp.
>>>>> 
>>>>> 
>>>>> My setup previously used 2x servers in master/slave configuration for my 
>>>>> public "view" and then had 3x servers for the "internal" view. This was 
>>>>> working fine for years and I have been regularly testing using online dns 
>>>>> healthcheck sites such as mxtoolbox etc...
>>>>> 
>>>>> 
>>>>> Now when I try to run any type of check from mxtoolbox or other site eg. 
>>>>> https://dnschecker.org/ I am getting my private IP's showing instead of 
>>>>> the public ones?
>>>>> 
>>>>> 
>>>>> Initially it started off by my external zone files not transferring which 
>>>>> I managed to see that the information was trying to traverse my NAT (I 
>>>>> know, not the best practice to have all dns servers on the same network).
>>>>> 
>>>>> 
>>>>> As a result external emails from my mail server are not working too well 
>>>>> with a hit and miss type thing going on right now.
>>>>> 
>>>>> 
>>>>> Just to go over, my zone files are fine as the 'external' ones only have 
>>>>> public ip addresses in them and do not include any type of internal 
>>>>> addressing whatsoever.
>>>>> 
>>>>> 
>>>>> Here's an example of the config in named.conf for the master:
>>>>> view "external" {
>>>>> match-clients { !internals; any; };
>>>> [...]
>>>>> view "external" {
>>>>> match-clients { !internals; any; };
>>>> I don't see your definition of "internals".
>>>> Also, I don't see your definition of internal view.
>>>> if internal IP addresses are visible on the internet, obviously the 
>>>> internet sources fall into your internal view, not into this one.
>>>> 
>>>> 
>>> Finally, I understand what is going on and things get stranger
>>> 
>>> 
>>> The internal IP addressing is being served up by the slave servers. They 
>>> seem to have pulled the file domain.db and renamed it to 
>>> domain-external.db???
>>> 
>>> 
>>> Of course the 'master' machine is already serving up domain-external.db to 
>>> the public domain. This has the correct IP addressing with everything else 
>>> such as dkim and dmarc.
>>> 
>>> 
>>> So, currently I think the whole problem is stemming from the fact that the 
>>> zone transfers are not working correctly for my external view between 
>>> 'master' and 'slave' servers.
>>> 
>>> 
>>> How can I do that without needing to traverse my NAT?
>>> 
>> When migrating ISP, are you sure that there is not another NAT in the ISP 
>> router?
>> That would explain this. The internet would present itself as 192.168.xx.xx 
>> and match your internals.
> 
> I can certainly ask. Though I am on a business package with multiple static 
> public IPv4 addresses. I think I have a /28 block if memory serves me well
> 
> 
> 
You might find that it has some kind of address translation built-in "to 
protect your business" or whatever. To me it still smells that way.
You might look at the IP address for the port you think is the internet - if 
that has an 192.168.x.x. or 172.16.x.x. or 10.x.x.x it would be clear that is 
what your problem is. It can still be solved but other setup details will be 
needed.
> The crazy thing is that I am using the DNS check tool from mxtoolbox. So far 
> it's telling me:
> 
> 
> 
> Bad Glue Detected
> Parent server gave glue for ns2.domain.com to be int_dns2 but we resolve that 
> hostname to ext_dns2
> 
> 
> 
> Another weird issue is that it's reading the serial from the zone file to be:
> 
> 
> Serial numbers match
> 2022022801
> 
> That's my 'internal' zone! Not the 'external'

Re: migration to new isp - now private addresses showing up publicly?

[Sten Carlsen]

> 
> On 23 May 2023, at 19.00, Kaya Saman  wrote:
> 
> 
>> On 5/23/23 12:47, Matus UHLAR - fantomas wrote:
>>> On 23.05.23 12:22, Kaya Saman wrote:
>>> I've got a very strange problem that has emerged somehow after migrating my 
>>> isp.
>>> 
>>> 
>>> My setup previously used 2x servers in master/slave configuration for my 
>>> public "view" and then had 3x servers for the "internal" view. This was 
>>> working fine for years and I have been regularly testing using online dns 
>>> healthcheck sites such as mxtoolbox etc...
>>> 
>>> 
>>> Now when I try to run any type of check from mxtoolbox or other site eg. 
>>> https://dnschecker.org/ I am getting my private IP's showing instead of the 
>>> public ones?
>>> 
>>> 
>>> Initially it started off by my external zone files not transferring which I 
>>> managed to see that the information was trying to traverse my NAT (I know, 
>>> not the best practice to have all dns servers on the same network).
>>> 
>>> 
>>> As a result external emails from my mail server are not working too well 
>>> with a hit and miss type thing going on right now.
>>> 
>>> 
>>> Just to go over, my zone files are fine as the 'external' ones only have 
>>> public ip addresses in them and do not include any type of internal 
>>> addressing whatsoever.
>>> 
>>> 
>>> Here's an example of the config in named.conf for the master:
>> 
>>> view "external" {
>>> match-clients { !internals; any; };
>> [...]
>>> view "external" {
>>> match-clients { !internals; any; };
>> 
>> I don't see your definition of "internals".
>> Also, I don't see your definition of internal view.
>> if internal IP addresses are visible on the internet, obviously the internet 
>> sources fall into your internal view, not into this one.
>> 
>> 
> 
> Finally, I understand what is going on and things get stranger
> 
> 
> The internal IP addressing is being served up by the slave servers. They seem 
> to have pulled the file domain.db and renamed it to domain-external.db???
> 
> 
> Of course the 'master' machine is already serving up domain-external.db to 
> the public domain. This has the correct IP addressing with everything else 
> such as dkim and dmarc.
> 
> 
> So, currently I think the whole problem is stemming from the fact that the 
> zone transfers are not working correctly for my external view between 
> 'master' and 'slave' servers.
> 
> 
> How can I do that without needing to traverse my NAT?
> 
When migrating ISP, are you sure that there is not another NAT in the ISP 
router?
That would explain this. The internet would present itself as 192.168.xx.xx and 
match your internals.
> 
> Currently I tried putting this into my master config:
> 
> 
> zone "domain.com" {
>type master;
>file "/var/named/var/named/domain-external.db";
> notify explicit;
> also-notify { int_dns2; int_dns3; };
> allow-transfer { ext_dns2; ext_dns3; };
> allow-query { ext_dns2; ext_dns3; !internals; any; };
> };
> 
> 
> 
> And this into my slave config:
> 
> 
> 
> zone "domain.com" {
>type slave;
>file "/var/named/var/named/domain-external.db";
> masters { ext_dns1; };
> // allow-notify { ext_dns1; };
>allow-query { int_dns1; !internals; any; };
> };
> 
> 
> But it doesn't seem to mesh up?
> 
> 
> The general.log file is telling me this:
> 
> zone domain.com/IN/external: refresh: retry limit for master ext_dns1#53 
> exceeded (source 0.0.0.0#0)
> 
> -- 
> 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: address/prefix length mismatch

[Sten Carlsen]

> On 24 Aug 2022, at 16.52, Greg Choules  
> wrote:
> 
> Hi Sten.
> That is absolutely what you do *not* want to do.
> 
> Writing it out in binary might help. /23 means the following:
>   1110 
> 
> '1' bits mean, test an incoming address against the corresponding bit from 
> the address in the mask.
> '0' bits mean, don't test an incoming address against the corresponding bit 
> from the address in the mask.
> 
> The ACL 10.60.0.0/23 <http://10.60.0.0/23> will match *any* address from 
> 10.60.0.0 to 10.60.1.255 *inclusive*.
> 
> There is no concept of network address and broadcast address here. It is just 
> pattern matching.

Yes, I was (incorrectly) thinking in terms of a /24 network and assumed that 
removing the ..0 and ..255 addresses was the issue. The proposal would do that 
by first rejecting (! - means reject) the offending addresses (all have to be 
listed separately) before doing the above pattern matching.

> 
> Cheers, Greg
> 
> On Wed, 24 Aug 2022 at 15:40, Sten Carlsen  <mailto:st...@s-carlsen.dk>> wrote:
> I think you want something like this:
> 
> (!10.60.0.0; !10.60.0.255; 10.60.0.0/24 <http://10.60.0.0/24>)
> 
> First deny the two addresses you want not to be part of the ACL and then 
> accept the whole network.
> 
> First match is used, so 10.60.0.0 would match !10.60.0.0 and be rejected 
> before the next  are tested.
> 
> Thanks
> 
> Sten
> 
>> On 24 Aug 2022, at 16.05, Ondřej Surý > <mailto:ond...@isc.org>> wrote:
>> 
>> 
>>> On 24. 8. 2022, at 15:58, Elias Pereira >> <mailto:empbi...@gmail.com>> wrote:
>>> 
>>> hello Ondrej,
>>> 
>>> Not completely wrong, because 255 is the broadcast.
>> 
>> No, it's not. This is ACL specification, not a interface/network 
>> configuration.
>> 
>>> For a better understanding, then it would be Available range 10.60.0.1 to 
>>> 10.60.1.254.
>> 
>> No, I've already provided you with a correct answer what 10.60.0.0/23 
>> <http://10.60.0.0/23> means in terms of range, why do you insist on this?
>> 
>>> Correctly specified range (without address/host bits) does takes the whole 
>>> range.
>>> 
>>> Like this 10.60/23; ?
>> 
>> I think others have already answered that, I would be just repeating their 
>> answers.
>> 
>> Ondrej
>> --
>> Ondřej Surý (He/Him)
>> ond...@isc.org <mailto:ond...@isc.org>
>> 
>> My working hours and your working hours may be different. Please do not feel 
>> obligated to reply outside your normal working hours.
>> 
>> 
>>> On Wed, Aug 24, 2022 at 10:33 AM Ondřej Surý >> <mailto:ond...@isc.org>> wrote:
>>> 
>>> 
>>>> On 24. 8. 2022, at 15:26, Elias Pereira >>> <mailto:empbi...@gmail.com>> wrote:
>>>> 
>>>> 
>>>> Hello Greg,
>>>> 
>>>> Why doesn't bind work with networks/subnets in the conventional way?
>>> 
>>> It does.
>>> 
>>>> If the private subnet is 10.60.0.0/23 <http://10.60.0.0/23>, then it means 
>>>> that the address range is 10.60.0.1 to 10.60.1.254.
>>> 
>>> That’s wrong. 10.60.0.0/23 <http://10.60.0.0/23> means 10.60.0.0 to 
>>> 10.60.1.255 range.
>>> 
>>>> How do I configure this ACL in named.conf.local so that it takes the whole 
>>>> range?
>>> 
>>> Correctly specified range (without address/host bits) does takes the whole 
>>> range.
>>> 
>>> Ondrej 
>>> --
>>> Ondřej Surý — ISC (He/Him)
>>> 
>>> My working hours and your working hours may be different. Please do not 
>>> feel obligated to reply outside your normal working hours.
>>> 
>>>> On Wed, Aug 24, 2022 at 9:31 AM Anand Buddhdev >>> <mailto:ana...@ripe.net>> wrote:
>>>> On 24/08/2022 14:16, Elias Pereira wrote:
>>>> 
>>>> Hi Elias,
>>>> 
>>>> > Oh, sorry... :D
>>>> > 
>>>> > here it is
>>>> > 
>>>> > # cat named.conf.local
>>>> > # ACL das redes internas
>>>> > # Ultima modificação: 24/08/2022
>>>> > 
>>>> > acl "internal" {
>>>> > 10.60.0.1/23 <http://10.60.0.1/23>;
>>>> 
>>>> This is the issue. The address part of the prefix should be the lowest 
>>&g

Re: address/prefix length mismatch

[Sten Carlsen]

I think you want something like this:

(!10.60.0.0; !10.60.0.255; 10.60.0.0/24)

First deny the two addresses you want not to be part of the ACL and then accept 
the whole network.

First match is used, so 10.60.0.0 would match !10.60.0.0 and be rejected before 
the next  are tested.

Thanks

Sten

> On 24 Aug 2022, at 16.05, Ondřej Surý  wrote:
> 
> 
>> On 24. 8. 2022, at 15:58, Elias Pereira > > wrote:
>> 
>> hello Ondrej,
>> 
>> Not completely wrong, because 255 is the broadcast.
> 
> No, it's not. This is ACL specification, not a interface/network 
> configuration.
> 
>> For a better understanding, then it would be Available range 10.60.0.1 to 
>> 10.60.1.254.
> 
> No, I've already provided you with a correct answer what 10.60.0.0/23 means 
> in terms of range, why do you insist on this?
> 
>> Correctly specified range (without address/host bits) does takes the whole 
>> range.
>> 
>> Like this 10.60/23; ?
> 
> I think others have already answered that, I would be just repeating their 
> answers.
> 
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@isc.org 
> 
> My working hours and your working hours may be different. Please do not feel 
> obligated to reply outside your normal working hours.
> 
> 
>> On Wed, Aug 24, 2022 at 10:33 AM Ondřej Surý > > wrote:
>> 
>> 
>>> On 24. 8. 2022, at 15:26, Elias Pereira >> > wrote:
>>> 
>>> 
>>> Hello Greg,
>>> 
>>> Why doesn't bind work with networks/subnets in the conventional way?
>> 
>> It does.
>> 
>>> If the private subnet is 10.60.0.0/23 , then it means 
>>> that the address range is 10.60.0.1 to 10.60.1.254.
>> 
>> That’s wrong. 10.60.0.0/23  means 10.60.0.0 to 
>> 10.60.1.255 range.
>> 
>>> How do I configure this ACL in named.conf.local so that it takes the whole 
>>> range?
>> 
>> Correctly specified range (without address/host bits) does takes the whole 
>> range.
>> 
>> Ondrej 
>> --
>> Ondřej Surý — ISC (He/Him)
>> 
>> My working hours and your working hours may be different. Please do not feel 
>> obligated to reply outside your normal working hours.
>> 
>>> On Wed, Aug 24, 2022 at 9:31 AM Anand Buddhdev >> > wrote:
>>> On 24/08/2022 14:16, Elias Pereira wrote:
>>> 
>>> Hi Elias,
>>> 
>>> > Oh, sorry... :D
>>> > 
>>> > here it is
>>> > 
>>> > # cat named.conf.local
>>> > # ACL das redes internas
>>> > # Ultima modificação: 24/08/2022
>>> > 
>>> > acl "internal" {
>>> > 10.60.0.1/23 ;
>>> 
>>> This is the issue. The address part of the prefix should be the lowest 
>>> address in that prefix. If you change this to 10.60.0.0/23 
>>> , it will be 
>>> fine. The same goes for all the other prefixes in your list. Change the 
>>> 1's to 0's.
>>> 
>>> > 10.10.1.1/24 ;
>>> > 10.10.2.1/25 ;
>>> > 10.10.3.1/25 ;
>>> > 10.10.4.1/25 ;
>>> > 10.10.5.1/25 ;
>>> > 10.51.0.1/23 ;
>>> > 10.10.6.1/25 ;
>>> > 10.10.7.1/26 ;
>>> > 172.20.0.1/26 ;
>>> > 10.50.0.1/23 ;
>>> > 10.40.0.1/22 ;
>>> > 10.56.0.1/22 ;
>>> > };
>>> 
>>> 
>>> -- 
>>> Elias Pereira
>>> -- 
>>> 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 
>>> 
>> 
>> 
>> -- 
>> Elias Pereira
> 
> -- 
> 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: High memory consumption in bind 9.18.2

[Sten Carlsen]

-- 
Best regards 
Sten Carlsen 

--
Aoccdrnig to rseerach at Cmabrigde Uinervtisy,
it deosn't mttaer in waht oredr the ltteers in a
wrod are, the olny iprmoatnt tihng is taht the
frist and lsat lteter be at the rghit pclae.
The rset can be a ttoal mses and you can slitl
raed it wotihut porbelm. Tihs is bcuseae the
hmuan mnid deos not raed ervey lteter by istlef,
but the wrod as a wlohe. Amzanig, huh?
--

> On 1 Aug 2022, at 17.08, Victoria Risk  wrote:
> 
> Hi Doug,
> 
> I think Ondrej is referring to this post from a prior month: 
> https://lists.isc.org/pipermail/bind-users/2022-June/106350.html 
> <https://lists.isc.org/pipermail/bind-users/2022-June/106350.html>
> 
> ….
> For tips on how to measure memory usage you might want to look at 
> https://stackoverflow.com/questions/131303/how-can-i-measure-the-actual-memory-usage-of-an-application-or-process
>  
> <https://stackoverflow.com/questions/131303/how-can-i-measure-the-actual-memory-usage-of-an-application-or-process>
>  …..
> 
> Also note the comment about ignoring ’total’ memory.
> 
> Vicky
> 
>> On Aug 1, 2022, at 10:32 AM, Ondřej Surý > <mailto:ond...@isc.org>> wrote:
>> 
>>> On 1. 8. 2022, at 16:14, Doug Whitfield >> <mailto:dwhitfi...@perforce.com>> wrote:
>>> 
>>> as monitored from "top" RES value
>> 
>> Please read the whole thread on measuring the real consumed memory.
>> 
>> The '“top” RES value' has little or no value at all.

Looking at this discussion from the outside, it seems to me that the point of 
contention here is the question: What is the correct way to measure memory 
consumption?

From reading the mails, it seems that one side wants to compare what Bind 
reports internally and which may not count everything the OS has allocated for 
that process and the other side just wants to know how much memory is not 
available for other tasks when this is running.

May I suggest that the discussion first agrees what to measure and then agrees 
on a method for measuring that number.

>> 
>> Ondrej
>> --
>> Ondřej Surý (He/Him)
>> ond...@isc.org <mailto:ond...@isc.org>
>> 
>> My working hours and your working hours may be different. Please do not feel 
>> obligated to reply outside your normal working hours.
>> 
>> 
>> -- 
>> 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

-- 
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: resolving www.ecb.europa.eu tages ages

[Sten Carlsen]

From my corner of Eurpoa it looks worse.

% time dig www.ecb.europa.eu 

; <<>> DiG 9.10.6 <<>> www.ecb.europa.eu
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 62609
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.ecb.europa.eu. IN  A

;; Query time: 1571 msec
;; SERVER: 192.168.16.20#53(192.168.16.20)
;; WHEN: Mon Jun 20 17:39:00 CEST 2022
;; MSG SIZE  rcvd: 46

dig www.ecb.europa.eu  0.00s user 0.01s system 0% cpu 8.609 total

With dig +trace it takes longer:

dig +trace www.ecb.europa.eu  0.01s user 0.02s system 0% cpu 1:24.75 total

-- 
Best regards 
Sten Carlsen

Don't be impressed with unintelligible stuff said condescendingly .
-- Radia Perlman.

> On 20 Jun 2022, at 17.04, Robert M. Stockmann  wrote:
> 
> On Fri, 17 Jun 2022, Matus UHLAR - fantomas wrote:
> 
>> Date: Fri, 17 Jun 2022 13:04:51 +0200
>> From: Matus UHLAR - fantomas 
>> To: bind-users@lists.isc.org
>> Subject: resolving www.ecb.europa.eu tages ages
>> 
>> Hello,
>> 
>> I encountered case where resolution of www.ecb.europa.eu takes long time and 
>> I can't find out why.
>> 
>> I'm trying to find the culprit using dig +trace and resolution times change 
>> from < 1 second to > 15 seconds, while response times reported by dig say 
>> miliseconds.
>> 
>> multiple runs of dig seem to fix the issue until I clear named cache.
>> (which indicated problem is in DNS, but I still have no idea where)
>> 
>> I'm out od ideas what to search for.
>> 
>> I have debian 11 with bind version 1:9.16.27-1~deb11u1
>> 
>> an example dig that took 5 seconds pasted:
>> 
>> # time dig +trace www.ecb.europa.eu
>> 
>> ; <<>> DiG 9.16.27-Debian <<>> +trace www.ecb.europa.eu
>> ;; global options: +cmd
>> .   194472  IN  NS  m.root-servers.net.
>> .   194472  IN  NS  k.root-servers.net.
>> //
>> 
>> www.ecb.europa.eu.  300 IN  CNAME   www-ecb-europa-eu.ax4z.com.
>> ;; Received 86 bytes from 156.154.65.109#53(pdns109.ultradns.net) in 11 ms
>> 
>> real0m5.117s
>> user0m0.011s
>> sys 0m0.035s
>> 
> Here's a dig which does RRSIG NSEC records :
> 
> [hubble:stock]:(~)$ time dig +trace www.ecb.europa.eu
> 
> ; <<>> DiG 9.9.9-P6 <<>> +trace www.ecb.europa.eu
> ;; global options: +cmd
> .   518400  IN  NS  j.root-servers.net.
> .   518400  IN  NS  e.root-servers.net.
> .   518400  IN  NS  b.root-servers.net.
> .   518400  IN  NS  a.root-servers.net.
> .   518400  IN  NS  c.root-servers.net.
> .   518400  IN  NS  g.root-servers.net.
> .   518400  IN  NS  i.root-servers.net.
> .   518400  IN  NS  d.root-servers.net.
> .   518400  IN  NS  h.root-servers.net.
> .   518400  IN  NS  f.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  RRSIG   NS 8 0 518400 2022062617 
> 2022061316 47671 . 
> jrgBQZPTZlRoXOe832K5+7SeWQwNqQUdgOChlztTesSGXpg+1GJ5nwJG 
> JIK8bsSHnLXpuzF+AIimRZTu20Ac4cbWkSYoctcsoFgNgMoU2pLVlv0P 
> oQOsBHtLnRZvU/gJByp98PobEAmgnRpD+7vyvnPfZOPw90VQQyARwOC0 
> w7Y2OHfQ02tbAecoy9qCE+bLnupC02Do9cmF4rlLKj40xI/kzQ22HWVQ 
> v1shssV2KRAbUt0wyaLr9bSAoE1IM+2w4zkYQRckfYFnwzTgzktpAosv 
> AiA2y9xzjh+Ntf6Gkxb6YQhnYDhMTlDBL0Z35Tc4Cu2M52Iu3VV4wsh1 SkeqiQ==
> .   86400   IN  NSECaaa. NS SOA RRSIG NSEC DNSKEY
> .   86400   IN  RRSIG   NSEC 8 0 86400 2022062617 
> 2022061316 47671 . 
> HilCUKfturSptxpvGPCJV1tGd0NmCvtEoGKVNlaQEZlP1dL6HpQUR+kg 
> p64n2Sk3nk9Y8WhdQJ0xsPRkH/TWpH3LRbUXqqwP/qoQ2aC9BLZO/rt4 
> 7FgNrEy/aCRByrGHA8Em7gaA2RxDoqC3uS7KHrNSK8DSOZ2dfF8L2I8t 
> rZzqpqjs/uylLMNQOKLJJNhOhay8UKr3jecAJvcCaV5gMv1UJn4zo6ZR 
> GmJLm6hsiNp/HS/S9I8BRoCj+NQ62BJSyE4F0mn1QB1pRE5M9NuJXTaU 
> 5WX9Bq3bUecvoHcuBAdqa7kOrzq8VDECjb0J++23EnMsfux+O8kyMOnJ fpOhdg==
> ;; Received 1324 bytes from 192.168.188.10#53(192.168.188.10) in 0 ms
> 
> eu. 172800  IN  NS  w.dns.eu.
> eu.   

Re: test - ignore

[Sten Carlsen]

Thanks

Sten

> On 26 Jan 2022, at 17.14, Matus UHLAR - fantomas  wrote:
> 
>>> On Jan 25, 2022, at 8:50 AM, Benny Pedersen  wrote:
>>> Authentication-Results: lists.isc.org;
>>> dkim=fail reason="signature verification failed" (1024-bit key; 
>>> unprotected) header.d=isc.org header.i=@isc.org header.b=q/vOEba5;
>>> dkim=fail reason="signature verification failed" (1024-bit key; 
>>> unprotected) header.d=isc.org header.i=@isc.org header.b=ozeUkO/Z
> 
> On 25.01.22 12:25, Dan Mahoney wrote:
>> The headers you cite are lying to you.  :) The message passed DKIM on the
>> way IN to lists.isc.org (the dedicated vm that runs our lists), but then,
>> when the message got to the mailman python scripts and then shot back out
>> via the MTA, they had an altered body and no longer passed, and the header
>> was rewritten to say "fail".  (This is visible from the logging on the
>> servers, but nowhere else).
> 
> there were multiple headers when that mail came here:
> 
> Authentication-Results: fantomas.fantomas.sk;
>   dkim=fail reason="signature verification failed" (1024-bit key; secure) 
> header.d=isc.org header.i=@isc.org header.b="q/vOEba5";
>   dkim=fail reason="signature verification failed" (1024-bit key; secure) 
> header.d=isc.org header.i=@isc.org header.b="ozeUkO/Z";
>   dkim-atps=neutral
> Authentication-Results: lists.isc.org;
>   dkim=fail reason="signature verification failed" (1024-bit key; 
> unprotected) header.d=isc.org header.i=@isc.org header.b=q/vOEba5;
>   dkim=fail reason="signature verification failed" (1024-bit key; 
> unprotected) header.d=isc.org header.i=@isc.org header.b=ozeUkO/Z
> 
> obviously when the mail came to list, DKIM was fine, not so after it left
> (thanks to list signature)
> 
>>> will my dkim fail aswell ?
> 
> it did...
> 
>> Altering the body or headers at all (whch lists do) will often break the
>> hashing.  For this reason, most recent versions of mailman have an option
>> to rewrite your mail from:

When the dkim is set up, you can select which parts of the header you want to 
include in the signature.

I have selected a smaller part of the headers for my signature,  so does this 
go through?

> 
> [...]
> 
>> ...but only in the event you have a restrictive DMARC policy. 
> 
> this explains why both your and Benny's mail did fail here, while Eduard's
> did not - that one was signed by mailman because of his domains' restrictive
> policy.
> 
> I missed this part before.
> 
>> I've argued that it should be possible to do so for *any* dmarc policy,
>> even p=none, but that option is not present in mailman 3, at least.
> 
> I agree.
> spam filter is something that can use dkim fail and should not be ignored.
> 
> -- 
> 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.
> Support bacteria - they're the only culture some people have.
> ___
> 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: Found the bug (was: ERROR: Failed to create fetch for DNSKEY update)

[Sten Carlsen]

As far as I am aware - and what I have always done - the normal thing to do is 
to use a hints file. Lately the hints are built-in, so nothing is really needed.

One question that comes to mind:
What happens if the slaved root zones are not up to date /not correct? might 
that be the cause?

-- 
Best regards 
Sten Carlsen


"No trees were killed in the making of this e-mail... however,
a large number of electrons were terribly inconvenienced."

> On 19 Nov 2021, at 11.52, Peter  wrote:
> 
> 
> Hija,
> 
>  I finally found the cause of the error! As soon as I stop slaving
> the root-zones and instead use the (configured or compiled-in)
> hint-file, the error stops.
> 
> The actual error-condition (zone is not loaded) then becomes
> obvious, because this RFC-5011 action happens very early, before
> any zones are loaded. And with slaved root-zones instead of a
> hint-file, the root zone has to be loaded like the others.
> 
> So the flaw is in the initialization sequence.
> 
> I don't really see why we would need to do this RFC-5011 so early.
> As matters are, it now is failed, postponed, and run an hour later
> successfully, and things should work just as well.
> 
> So You may now fix the issue, or just continue to spamblock the
> bugreports (which is a great scheme to get error-free software, btw).
> 
> cheerio,
> PMc
> ___
> 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: Multisite deployment issue

[Sten Carlsen]

Hi

I am running just that setup.

This may not scale well enough for your needs.

I have one server with two views, one internal and one external.

The external view is the hidden master for a number of public servers. All 
going through the relevant delegations. This is only authoritative.

The internal view is selected by the client address and master files for the 
same domain but with my internal addresses. This is recursing and will answer 
from the master files for those domains and will recurse for any other query.

This has served me well and e.g. I get the internal address for the mail server 
if I query from an internal address and I get the public address if I query 
from an external address.

This setup means that mail clients will make a lookup of the same name always 
and if at home get the internal address and if outside get the public address.

There is often a recommendation to use different domains, e.g. xxx.example.com 
<http://example.com/> for public addresses and xxx.internal.example.com 
<http://internal.example.com/> for the same servers internal addresses. This is 
not very useful since e.g. a mail client would have to know about two different 
server names - with split horizon I can use the same name always.

-- 
Best regards 
Sten Carlsen 

A pessimist is a person that can find a problem for every solution.


> On 26 Jul 2021, at 15.55, Daniel A. Rodriguez 
>  wrote:
> 
> Hi there,
> 
> Currently have a public DNS up & runnin' but, due to brand new
> location, there's a need to add local resolution.
> 
> With that in mind, first idea was to deploy a split horizon setup.
> Sadly just local resolution works so far. Double check config but
> currently I'm stuck with this situation.
> 
> Was wondering if having the same zone both public and private, but
> with different records, could be an issue. Master for the zone is
> public, of course, and the private one -as mentioned- has a different
> set of records just for lan hosts. Idea was to go out just when a
> query for a public subdomain is requested, but that desn't seem to
> work.
> 
> Both forwarders option and recursion are enabled.
> 
> Any hint will be much appreciated.
> ___
> 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: Need Help with BIND9

[Sten Carlsen]

From my place I resolve both to: 98.191.108.149

keiththewebguy.com. does not actually have the two nameservers required though 
that is not the problem. (ns1 and ns2 have same IP)

BIND seems to work ok but your local settings probably don't point your hosts 
to the right NS.

-- 
Best regards 
Sten Carlsen 

--
Aoccdrnig to rseerach at Cmabrigde Uinervtisy,
it deosn't mttaer in waht oredr the ltteers in a
wrod are, the olny iprmoatnt tihng is taht the
frist and lsat lteter be at the rghit pclae.
The rset can be a ttoal mses and you can slitl
raed it wotihut porbelm. Tihs is bcuseae the
hmuan mnid deos not raed ervey lteter by istlef,
but the wrod as a wlohe. Amzanig, huh?
--

> On 11 Jun 2021, at 18.15, Marki  wrote:
> 
> A thing you probably missed is checking the log files. What do they contain 
> when it "isn't working"? What is the actual problem 
> anyway?___
> 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: Bind9.16 zone SOA record issue.

[Sten Carlsen]

> On 23 May 2021, at 16.24, Thomas Strike  wrote:
> 
> ZONE FILE:
> $ttl 3600
> ORIGIN ancienttom.us .
> @IN SOA ancienttom.us . 
> thomas\.strike.sleepyvalley.net . (

The "\" above is what I would suspect. I could be wrong.

> 1588097734
> 1200
> 600
> 86400
> 3600 )

___
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: Preventing a particular type of nameserver abuse

[Sten Carlsen]

Thanks

Sten

> On 14 Apr 2021, at 19.47, Carl Byington via bind-users 
>  wrote:
> 
> Signed PGP part
> On Wed, 2021-04-14 at 12:58 -0400, Paul Kosinski via bind-users wrote:
> > Interesting, although we host different domains, in and from different
> > geographic areas, we got the same queries as yours on the same day,
> > with some at about the same time (we're EDT).
> > 13-Apr-2021 02:19:58.468 security: info: client 76.20.145.58#3074
> > (sl): query (cache) 'sl/ANY/IN' denied
> > 13-Apr-2021 02:19:58.638 security: info: client 76.20.145.58#3074
> > (sl): query (cache) 'sl/ANY/IN' denied
> 
> These times are PDT (-0700)
> 
> Apr 12 23:18:13 ns named[5091]: client @0x7fda540105b8 76.20.145.58#3074
> (sl): view normal: query (cache) 'sl/ANY/IN' denied
> Apr 12 23:18:13 ns named[5091]: client @0x7fda540105b8 76.20.145.58#3074
> (sl): view normal: query (cache) 'sl/ANY/IN' denied
> 
> Apr 12 23:19:15 ns named[5091]: client @0x7fda540105b8 76.20.145.58#3074
> (sl): view normal: query (cache) 'sl/ANY/IN' denied
> 
> So either 76.20.145.58, or someone forging that source ip, made queries
> to servers in (+), (-0400), and (-0700) at the same time. Malware
> running on 76.20.145.58 is one explanation. Would the REFUSED replies
> carry enough information from the original query to be used as a covert
> communication channel into something listening on 76.20.145.58?
> 
> vpn over dns query-refused replies? That seems a bit far-fetched.

I wonder if it may be an attempt to keep track of the Internet speed across the 
world?
If you send off these queries at the same time to different locations what 
would the round trip time tell you?
It would probably be a fair assessment of the speed of the net - might be a 
replacement for pings.

> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
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: underscore in A or PTR records

[Sten Carlsen]

> On 17 Feb 2021, at 12.34, ONRUBIA AVILES Carlos (CCS/MST) 
>  wrote:
> 
> Hello,
> 
> Indeed my question was on A record but the issue is on PTR record.
> I can configure the following line:
> 
> _ptr.dekil.nl.  3600IN  PTR 
> _81.99-129-109.adsl-dyn.isp.dekil.nl
> 
> It workswe can use "_"  in both sides.
> 
> 
> But what is strange is that the following configuration do not work:
> 
> 9.10.238.195.in-addr.arpa.   3600IN  PTR 
> por_tal-bis.skynet.be.
> 
> "_" is not allowed
> 
> Is it due to extra check by bind when it sees it is an arpa zone so no  "_" 
> is allowed?

As previously mentioned, the RFCs expressly forbids the "_" in names.

I assume that a leading "_" slips past Bind's control because it "could" be 
part of a valid but at compile time unknown _tcp -like label.

> 
> 
> Regards,
> 
> Carlos,
> 
> 
> Sensitivity: Internal Use Only
> 
> -Original Message-
> From: Ondřej Surý 
> Sent: 17 February 2021 10:52
> To: ONRUBIA AVILES Carlos (CCS/MST) 
> Cc: Mark Andrews ; bind-users@lists.isc.org
> Subject: Re: underscore in A or PTR records
> 
>> 
>> On 17. 2. 2021, at 9:50, ONRUBIA AVILES Carlos (CCS/MST) 
>>  wrote:
>> 
>> The issue we face is that a telecom provider ask us to implement a PTR 
>> record with a name like “example_try.net"
> 
> You are mixing the two things here. If the provider has asked you to create a 
> PTR record, why do you keep trying to create a forward record? There’s some 
> information missing somewhere.
> 
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@isc.org
> This e-mail cannot be used for other purposes than Proximus business use. See 
> more on https://www.proximus.be/maildisclaimer
> ___
> 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: Serial number question..

[Sten Carlsen]

The modulo arithmetic comes if you need it to be lower than in the slaves since 
they will consider a lower numbered transfer to be out of date and refuse to 
update. Meaning you will need to go to the top and round back to where you need 
to be.

-- 
Best regards 
Sten Carlsen


"No trees were killed in the making of this e-mail... however,
a large number of electrons were terribly inconvenienced."

> On 17 Dec 2020, at 20.02, Reindl Harald  wrote:
> 
> 
> 
> Am 17.12.20 um 19:56 schrieb Bruce Johnson:
>> Someone updated out name server and messed up the serial number on the 
>> primary; as a result our secondaries are not updating properly.
>> Primary:
>> bruces-Mac-Mini:~ johnson$ dig @elixir.pharmacy.arizona.edu -t SOA +noall 
>> +answer pharmacy.arizona.edu
>> pharmacy.arizona.edu.86404   IN  SOA 
>> elixir.pharmacy.arizona.edu. wunz.elixir.pharmacy.arizona.edu. 1297117089 
>> 3600 120 1209600 86400
>> Secondaries:
>> bruces-Mac-Mini:~ johnson$ dig @dhbns1.pharmacy.arizona.edu -t SOA +noall 
>> +answer pharmacy.arizona.edu
>> pharmacy.arizona.edu.86404   IN  SOA 
>> elixir.pharmacy.arizona.edu. wunz.elixir.pharmacy.arizona.edu. 1762233707 
>> 3600 120 1209600 86400
>> bruces-Mac-Mini:~ johnson$ dig @ns-remote.arizona.edu -t SOA +noall +answer 
>> pharmacy.arizona.edu
>> pharmacy.arizona.edu.86404   IN  SOA 
>> elixir.pharmacy.arizona.edu. wunz.elixir.pharmacy.arizona.edu. 1762233707 
>> 3600 120 1209600 86400
>> Is the fix here just setting the serial number on the primary to 1762233708 ?
>> The various things online I’ve found are all based on “you accidentally set 
>> the primary more than 2^32 ahead” so you have to do a bunch of modulo 
>> arithmetic...
> 
> just set it *higher* on the master and you are done
> ___
> 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: Dynamic update rejected within a view

[Sten Carlsen]

-- 
Best regards 
Sten Carlsen 


For every problem, there is a solution that
is simple, elegant, and wrong.
HL Mencken


> On 14 Jul 2020, at 16.25, Mark Andrews  wrote:
> 
> Include the update keys in the view selection. 
> 
> -- 
> Mark Andrews
> 
>> On 14 Jul 2020, at 23:06, Per Weisteen  wrote:
>> 
>> Zones.mydomains.config file contains:
>> 
>>  
>> include "keys/mydomains-keys.conf";
>> include "keys/zone1-keys.conf";
>> include "keys/zone2-keys.conf";
>>  
>> view "external-sites" {
>> match-clients { !key zone2.key; key zone1.key; external; };

   -
>>  
>> zone "aa.example.net" {
>> Error message in /var/log/named/named.log is :
>> 
>> 
>> 10-Jul-2020 13:27:14.695 update: info: client @0x7f0a200a9b30 
>> 10.124.15.148#64606/key arc-zone2.key: view grus-zone2: updating zone 
>> 'pacs.telenor.net/IN': update
>> 


-
Key names do not match.
>> failed: rejected by secure update (REFUSED)
>> 
>> 10-Jul-2020 13:28:13.883 update: info: client @0x7f0a200a9b30 
>> 10.124.15.148#64606/key arc-zone2.key: view grus-zone2: updating zone 
>> 'pacs.telenor.net/IN': update failed: rejected by secure update (REFUSED)
>> 
>>  
>> 
>> 
>> 
>> -- 
>> Best regards,
>> Per Weisteen
>> 
>> 
>> ___
>> 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

___
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: Hints for forwarding a subdomain on a authoritative server

[Sten Carlsen]

Thanks

Sten

> On 6 Jul 2020, at 16.03, Tom  wrote:
> 
> Hi list
> 
> Our BIND (9.16.4) is authoritative for zone "example.com". Now I need to 
> forward a subzone "sub.example.com" to another nameserver instance on the 
> same server, running for example under port 5353:
> 
> A few years ago, this topic was already discussed:
> https://lists.isc.org/pipermail/bind-users/2009-April/076156.html
> 
> My BIND config looks like this:
> == SCHNIPP ==
> zone "example.com" {
>type master;
>file "master/example.com.hosts";
>};
> zone "sub.example.com" {
>type forward;
>forwarders { 127.0.0.1 port 5353; };
>forward only;
>};
> == SCHNAPP ==
> 
> In the zonefile for "example.com" I have a delegation like this (as described 
> in the post above):
> 
> sub.example.com.IN  NS  subns.example.com.
> 
> So, the authoritative server understands not to be responsible for this zone 
> and forwards the request to the other nameserver.
> 
> But: The zone-forwarding is only working, when I enable "recursion" on the 
> authoritative server. Does this means, that zone-forwarding really requires 
> recursion?
Yes.
> Is there a better way with not enabling recursion (perhaps with views) to 
> accomplish this?
Stub zones are normally recommended instead.
> 
> Many thanks for any hints.
> 
> Kind regards,
> Tom
> ___
> 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: What is the proper way to delegate to a private / hidden sub-domain?

[Sten Carlsen]

Thanks

Sten

> On 6 May 2020, at 22.28, Grant Taylor via bind-users 
>  wrote:
> 
> On 5/6/20 2:18 PM, Sten Carlsen wrote:
>> I believe the answer must lie in the lookup of a named DNS server, which 
>> will be resolved to different IPs depending on your location. Then it can 
>> point to different servers.
> 
> If I understand correctly, that would rely on the DNS server's FQDNs being 
> outside of the zone's scope, thus not (potentially) included in the 
> additional information section, which could massively mess with that.

Yes or being answered from your own servers with dat depending on your location.

> 
> 
> 
> --
> Grant. . . .
> unix || die
> 
> ___
> 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



signature.asc
Description: Message signed with OpenPGP
___
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?

[Sten Carlsen]

-- 
Best regards 
Sten Carlsen 


For every problem, there is a solution that
is simple, elegant, and wrong.
HL Mencken


> On 6 May 2020, at 22.10, Grant Taylor via bind-users 
>  wrote:
> 
> On 5/6/20 1:44 PM, Bob Harold wrote:
>> 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 how do you do that if the internal and external views are on different 
> servers with completely different IPs?

I believe the answer must lie in the lookup of a named DNS server, which will 
be resolved to different IPs depending on your location. Then it can point to 
different servers.

> 
> I ask because now you're back to the same issue, just at the parent domain:  
> How does the net zone delegate to different example zones depending on if the 
> client is internal or external.
> 
> I don't see any options that avoid anycast.
> 
>> 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.
> Please elaborate on what you mean by "split view" hear.  I'm used to "split 
> view DNS" being tantamount to what I would use views for.  Which, as 
> previously stated, won't work in this case because the different views are 
> hosted on different servers.
> 
> 
> 
> -- 
> Grant. . . .
> unix || die
> 
> ___
> 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: What is the proper way to delegate to a private / hidden sub-domain?

[Sten Carlsen]

I have been doing that for quite some time without knowing it should be 
difficult.

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.

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.
--
Best regards
Sten Carlsen


For every problem, there is a solution that
is simple, elegant, and wrong.
HL Mencken


> On 6 May 2020, at 19.01, Grant Taylor via bind-users 
>  wrote:
> 
> Hi,
> 
> What is the proper way to delegate to a private / hidden sub-domain?
> 
> I have a globally registered domain, call it example.net for this thread, 
> that has multiple sub-domains that I'd like to be properly delegated to 
> internal labs; lab#.example.net.
> 
> Example.net itself is following all the industry standards and best practices 
> that I'm aware of; registered (read: rented), delegated from roots to 
> multiple public DNS servers which respond to the world.
> 
> I would like to delegate lab1.example.net in such a way that the outside 
> world sees a delegation to what is effectively an empty zone (save for SOA / 
> NS / etc.) on a public server.  However I'd like the internal lab systems see 
> a delegation to a private zone that has all the necessary records in the lab.
> 
> One hack that comes to mind is to have the example.net parent zone delegate 
> to a separate name server with a separate IP and then to anycast that IP & 
> name server inside the lab.  But that would require an additional globally 
> routed IP on the external public Internet.
> 
> I'm not currently worried about supporting DNSSEC, but it would be nice if 
> the solution would allow DNSSEC signing both the public and private zones.  
> With the obvious assumption being the DNS servers would have shared keys to 
> be able to sing their copies of the zone correctly.
> 
> Does anybody have any ProTip(s) on how to go about doing this?  What about 
> gotchas to avoid?
> 
> Thank you and have a nice day.
> 
> 
> 
> --
> Grant. . . .
> unix || die
> 
> ___
> 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



signature.asc
Description: Message signed with OpenPGP
___
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: DoH plugin for BIND

[Sten Carlsen]

On 03-05-2020 01.59, Noel Butler wrote:
>
> On 03/05/2020 02:17, Sten Carlsen wrote:
>
>> About mail servers from residential IPs. I have done that for a
>> number of years, very rarely any issue.
>>  
>  
> Most SP's do this
>  
>  
>> The major problem was that at one time MS required a reverse lookup
>> for the actual mail server name.
>  
> Many SP's still do this, some take it the extra mile and block
> anything with things like  cpe/dsl/cable/hfc/dyn/ppp... etc
> in the hostname, we still do it, have done for over 20 years and seen
> no collateral damage.
>  
>> .
>> In my part of the world it is very bad taste for an ISP to block
>> anything, its not their business.
>>  
>>  
>  
> Ordinarily, I agree, but the overall security and protection of the
> network must come first, the protection of teh majority must come
> first.  Then there's the law, in Australia we are required as part of
> the outcome of the iinet V hollywood, to block pirate sites, 99% do
> this by DNS, the Federal court accepts this method, the Federal court
> knows it can be avoided by most 8yos in under 10 seconds, its the
> sweet spot everybody agreed to so they approved it.
>  
> There are also other laws that require its use as well.  That said we
> dont block any ports and have no intention of.
>  
>
> That said, DoH is fairly pointless here because there is no
> requirement to log DNS queries, most of us have far better things to
> do than to know who's going where, none that I know do it, though
> there is a question of Telstra mobile
>
> lets face it, if we really want to know whos going where, netflow
> tells us a whole lot more anyway
>
I agree, if you really want to be anonymous the only way I know is TOR.
Maybe there should be a way to get DNS through TOR?
>
>
>
> -- 
>
> Kind Regards,
>
> Noel Butler
>
> This Email, including attachments, may contain legally privileged
> information, therefore remains confidential and subject to copyright
> protected under international law. You may not disseminate any part of
> this message without the authors express written authority to do so.
> If you are not the intended recipient, please notify the sender then
> delete all copies of this message including attachments immediately.
> Confidentiality, copyright, and legal privilege are not waived or lost
> by reason of the mistaken delivery of this message.
>
>
> _______
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

"MALE BOVINE MANURE!!!" 

___
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: DoH plugin for BIND

[Sten Carlsen]

About mail servers from residential IPs. I have done that for a number of 
years, very rarely any issue.

The major problem was that at one time MS required a reverse lookup for the 
actual mail server name. That was then fixed by the ISP and all works again.
In my part of the world it is very bad taste for an ISP to block anything, its 
not their business.

-- 
Best regards 
Sten Carlsen 


For every problem, there is a solution that
is simple, elegant, and wrong.
HL Mencken


> On 2 May 2020, at 17.11, Michael De Roover  wrote:
> 
> I'm sure that most of the list members here are aware of how net neutrality 
> and the internet in general works - we're internet operators after all. What 
> we're here for is ports and protocols, not policy or internet culture. On 
> that subject, we are not policy makers. Let's leave that to politicians who 
> studied for it. Vote some technical people in government while we're at it, 
> but I digress.
> 
> The DoT/DoH argument or what a mail server could be operated from is not one 
> of policy.. well maybe mail servers are, to some extent. Perhaps there's some 
> ISP employees here too. Those are in power to allow or disallow things on 
> their network. But DoT/DoH certainly isn't. What are we supposed to worry 
> about? How do we implement this new encrypted DNS. Do we piggyback off an 
> existing port and rely on its ubiquitous allowance on the internet or do we 
> create a new port for it, where we can make a dedicated new protocol suite?
> 
> On 5/2/20 5:03 PM, Reindl Harald wrote:
>> 
>> Am 02.05.20 um 16:39 schrieb Paul Kosinski via bind-users:
>>> I wasn't complaining about port 25, I was just citing it as a
>>> counterexample to the claim that ISPs "must" pass all traffic.
>> https://en.wikipedia.org/wiki/Net_neutrality
>> 
>>> I think that most ISPs tell customers how to set up their email clients
>>> (NUAs) including what port to use. Of course it seems that now most
>>> people use Web based email like Gmail, Yahoo (and even Comcast/Xfinity)
>>> so they never see port numbers.
>>> 
>>> 
>>> On Sat, 2 May 2020 15:51:58 +0200
>>> Reindl Harald  wrote:
>>> 
>>>> Am 02.05.20 um 15:41 schrieb Michael De Roover:
>>>>> In my experience and from what I've heard, very few.
>>>> if that would be true how comes that most mail clients still default to
>>>> 25 for submission and years after closing port 25 on our mailserver i
>>>> still struggle with customers smartphones still not using 587?
>>>> 
>>>> in fact 10 years ago some ISP's *tried* to kill outbound port 25 because
>>>> there is no point in using it from a homemachine and at that time we
>>>> struggeled also to explain our customers that 25 is plain wrong
>>>> 
>>>> finally they gave up because the damage of open port 25 is killed with
>>>> dnsbl but the customer support went crazy with "why can't i send email
>>>> with my internet connection"
>>>> 
>>>>> Even if your ISP allows it, chances are that other mail servers will 
>>>>> reject it
>>>> that's a completl different story
>>>> 
>>>>> On 5/2/20 3:30 PM, Paul Kosinski via bind-users wrote:
>>>>>> How many ISPs allow traffic on port 25? My impression is that even many
>>>>>> (non-enterprise) business customers can't use port 25
>> ___
>> 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
> -- 
> Met vriendelijke groet / Best regards,
> Michael De Roover
> ___
> 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: "lame-servers: info: no valid RRSIG resolving ..."

[Sten Carlsen]

I see lots of lines like this. They all come from people trying to break into 
my SSH.

-- 
Best regards 
Sten Carlsen 


For every problem, there is a solution that
is simple, elegant, and wrong.
HL Mencken


> On 17 Apr 2020, at 17.24, btb via bind-users  wrote:
> 
> hi-
> 
> i'm seeing what i'm wondering if is a lot of "lame-servers: info: no valid 
> RRSIG resolving ..." messages in the logs [on average ~500 messages per day]. 
>  a small snippet:
> 
> 15-Apr-2020 18:11:46.057 lame-servers: info: no valid RRSIG resolving 
> 'jwplayer.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:11:46.150 lame-servers: info: no valid RRSIG resolving 
> 'tranet.net/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:11:47.559 lame-servers: info: no valid RRSIG resolving 
> 'inboxsdk.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:11:49.146 lame-servers: info: no valid RRSIG resolving 
> 'basis.net/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:11:58.474 lame-servers: info: no valid RRSIG resolving 
> 'starfinancial.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:11:59.665 lame-servers: info: no valid RRSIG resolving 
> 'vice.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:09.501 lame-servers: info: no valid RRSIG resolving 
> 'lithium.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:09.756 lame-servers: info: no valid RRSIG resolving 
> 'sc-static.net/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:10.004 lame-servers: info: no valid RRSIG resolving 
> 'snapchat.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:12.638 lame-servers: info: no valid RRSIG resolving 
> 'yimg.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:16.823 lame-servers: info: no valid RRSIG resolving 
> 'transamerica.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:16.932 lame-servers: info: no valid RRSIG resolving 
> 'quantummetric.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:17.129 lame-servers: info: no valid RRSIG resolving 
> 'tealiumiq.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:17.171 lame-servers: info: no valid RRSIG resolving 
> 'bounceexchange.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:22.971 lame-servers: info: no valid RRSIG resolving 
> 'mwefinancial.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:23.248 lame-servers: info: no valid RRSIG resolving 
> 'redditmedia.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:23.869 lame-servers: info: no valid RRSIG resolving 
> 'imtwjwoasak.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:25.189 lame-servers: info: no valid RRSIG resolving 
> 'b.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:25.313 lame-servers: info: no valid RRSIG resolving 
> 'jquery.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:26.555 lame-servers: info: no valid RRSIG resolving 
> 'forter.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:29.008 lame-servers: info: no valid RRSIG resolving 
> 'quovadisoffshore.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:29.029 lame-servers: info: no valid RRSIG resolving 
> 'quovadisglobal.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:29.974 lame-servers: info: no valid RRSIG resolving 
> 'mixpanel.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:35.786 lame-servers: info: no valid RRSIG resolving 
> 'spotify.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:36.982 lame-servers: info: no valid RRSIG resolving 
> 'freeform.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:38.295 lame-servers: info: no valid RRSIG resolving 
> 'edgedatg.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:12:58.190 lame-servers: info: no valid RRSIG resolving 
> 'footprintdns.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:13:01.282 lame-servers: info: no valid RRSIG resolving 
> 'qualifiedaddress.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:13:01.744 lame-servers: info: no valid RRSIG resolving 
> 'dc-msedge.net/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:14:54.009 lame-servers: info: no valid RRSIG resolving 
> 'facebook.com/DS/IN': 192.5.6.30#53
> 15-Apr-2020 18:16:20.039 lame-servers: info: no valid RRSIG resolving 
> 'pphosted.com/DS/IN': 192.5.6.30#53
> 
> a number of these [most?] are zones that are signed, and some don't even 
> exist, so i'm curious about seeing these messages.  what am i not 
> understanding, and/or what can i do to troubleshoot further?
> 
> thanks!
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
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: DNSSEC zones not updated

[Sten Carlsen]

Just a basic question, are you querying the master or a slave. If a slave, it 
could be the notify/transfer.


Thanks

Sten

> On 22 Jan 2020, at 12.11, Jukka Pakkanen  wrote:
> 
> 
> Running BIND 9.14.9 Windows.   The zone data is not updated for some reason 
> anymore, and same problem in all our signed zones. Example "gemtrade.fi 
> ":
> 
> zone "gemtrade.fi " {
> type master;
> file "named.gemtrade";
> inline-signing yes;
> auto-dnssec maintain;
> };
> 
> 
> ;
> ;File:  named.gemtrade
> ;
> $TTL 60
> @IN SOAns1.qnet.fi . helpdesk.qnet.fi 
> . (
>   202001234  ; serial number
>   28800  ; refresh every 12 hours
>   7200   ; retry after 2 hours
>   604800 ; expire after 2 weeks
>   33600) ; default ttl is 2 days
> gemtrade.fi .IN A  62.142.217.154
>  IN MX 55 qntsrv8.qnet.fi 
> .
> IN MX 25 qntsrv9.qnet.fi .
>  IN NS ns1.qnet.fi .
>  IN NS ns2.qnet.fi .
>  IN NS ns3.qnet.fi . 
>  
> www IN A 62.142.217.154
> _autodiscover._tcp  IN SRV0 5 443 mail.qnet.fi .
> localhost.gemtrade.fi .   IN A  
> 127.0.0.1
>  
> 
> Used to work fine, now no matter what change I make to the zone file and 
> reload, it does not show up in queries, but the old data, weeks behind.  The 
> SOA & serial numbers *are* updating in the queries, but the actual records 
> not.  Example the MX records, currently I have priorities 55 and 25, still 
> inquiries return the old 20 and 20. Same with any records, the changes does 
> not get updated.
> 
> Deleting the .jnl file does not help, after "rndc reload gemtrade.fi 
> " a new .jnl file is created, but queries still return 
> old data.
> 
> The named process has all possible rights in the file structure.
> 
> What might be wrong?
> 
> ___
> 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: Zones-unable-update

[Sten Carlsen]

> On 6 Jan 2020, at 09.16, MEjaz  wrote:
> 
>  
> 1. My  primary name server,  /etc/named.conf,  and here am forcing transfer 
> to only few trusted servers, as mentioned in the below clause.  
>  
>  
> transfers-out 2000;
>  
> allow-transfer {212.119.93.5;213.230.0.10; 212.119.93.10; 212.119.92.6;};
>  
> Jan  6 11:03:14 ns2 named[24436]: client @0x7f1228138510 212.119.92.5#33050 
> (kalam.com.sa): zone transfer 'kalam.com.sa/AXFR/IN' denied

Please note that this client is NOT in the list above.

___
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

[Sten Carlsen]

> 
> 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
> 
> ___
> 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: Bind 9 with Views: zone transfer refused from master to slave

[Sten Carlsen]

On 03/07/2019 22.14, Grant Taylor via bind-users wrote:
> On 7/3/19 2:04 PM, Lightner, Jeffrey wrote:
>> You have to use separate IPs for the separate views on the master and
>> the slave.
>
> I thought you could use different TSIG keys to identify different
> zones with a single IP at each end.
>
> Is that not the case?
As far as I am aware the two views must use different keys, with the
same IP the key (or the view's ACL) is the only thing to distinguish
between the views.

You can use the same IP for both views at least on the master, I have
that setup and have for a very long time seen it running without any
problem. I do not use keys but let view ACL do the work.
>
>
>
>
> ___
> 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: [External] Re: Request assistance configuring RPZ

[Sten Carlsen]

To me this looks like it could be done with a bit of programming.
If the addresses of the two hosts needed in 192.168.x.x don't change too
often, a cron job could read those addresses and set them in zurg as
dynamic entries using nsupdate. The time for cron would be smaller than
the TTL of the RRs in their original location.

This is a different look at the task, if not relevant, just ignore.

On 28/05/2019 19.13, David Bank wrote:
> On Tue, 28 May 2019, Grant Taylor via bind-users wrote:
>
> Hello, Grant! Thanks for replying.
>
>> On 5/28/19 10:16 AM, David Bank wrote:
>>> To recap what I'm attempting to create: a host in the 10. network knows
>>> to ask buzz or woody for DNS resolution, and if such a host wants to
>>> resolve andy.internal.local, it gets (for example) 10.0.2.4 (moreover,
>>> the host can't even reach the DNS server on zurg). This part already
>>> exists.
>>
>> Do you want hosts on the 10/8 network (thus not in the bubble) to be
>> able to reach any of the hosts in the bubble?
>
>     No - the bubble is its own world for the most part. No reason for
> general 10/8 inhabitants to try to talk to 192.168/16 - the very, very
> few hosts that need to talk in 192.168/16 already have an IP in there.
>
>> Or is this simply wanting to make sure that hosts (outside the
>> bubble) in 10/8 resolve to IPs in 10/8 and that hosts (inside the
>> bubble) in 192.168/16 resolve to IPs in 192.168/16?
>
>    Hosts in 192.168/16 need to resolve 2 SPECIFIC names to 192.168/16
> when those names would otherwise resolve to 10/8 addresses. All other
> name resolution whould be to 10/8.
>
>> I'm wondering if it might be possible to use a simple flat DNS zones
>> with sorting of replies.
>
>    Perhaps I'm missing something, but I don't see how to make zurg
> reply with 192.168/16 IPs for andy and sid, but correctly resolve the
> rest of *.internal.local - at least not without supplying zurg with a
> flat file to reference (which I don't want to do).
>
>>> However, a host in the 192.168. network has been told to use zurg, and
>>> if it asks to resolve andy.internal.local, I want it to get 192.168.8.9
>>> (even though when zurg forwarded the request to buzz, the response was
>>> 10.0.2.4)
>>
>> Sorting and apex overrides come to mind.
>
>    I'm not familiar with those techniques, but I'm interested in
> learning.
>
>> Can you have a single zone, internal.local that has records for all
>> the hosts, with andy.internal.local, sid.internal.local, and
>> zurg.internal.local having multiple A records, one in each network.
>> Then configure BIND to sort the replies based on the network the
>> client is coming from.
>
>    No, because I don't have a non-manual way to supply zurg with the
> Zone data for *.internal.local. And I'm not too keen on, say, having
> zurg do a routine Zone dump from, say. buzz, and scripting something
> on zurg to massage the information so the records for andy and sid
> return 192.168/16.
>
>> This would mean that any host in the 192.168/16 bubble would get a
>> 192.168/16 address listed first in the reply.  Similarly, any host in
>> the main 10/8 network would get a 10/8 address listed first.
>
>    Hosts in 10/8 don't talk to zurg (aside from the fact zurg will
> talk with buzz and woody) - hosts in 10/8 only talk to buzz and woody,
> and buzz and woody always resolve all queries to 10/8 (e.g. they
> always tell the "truth").
>
>> Also, is there any reason that zurg can't be a slave for the zones
>> that buzz and woody are authoritative for?  (Especially if sorting
>> addresses the issue.)
>
>    No, I don't think so - but I didn't see how that would help, since
> I want zurg to alter the replies for just 2 hosts in the Zone.
> Athough, zurg is BIND on SLES; buzz and woody are Winblows DNS.
>
>> About the only thing that I can see RPZ being used for here would be to
>> override the information that zurg might return if the zone didn't
>> already have the data (multiple A records) which could be sorted.  I see
>> two potential solutions for this:
>>
>> 1)  Apex overrides
>> 2)  RPZ overrides
>>
>> #1 is simply a new zone that is the FQDN of what you want to override
>> and put an A record with the address you want in the apex.
>
>    OK - I have no idea how to do it, but if that would work
>
>> #2 is configuring RPZ to return different IP(s) (in the 192.168/16
>> bubble) for specific query names.  (This is what traditional RPZ /
>> DNS firewalls do.)
>
>    Yes, that's what I was thinking of originally.
>
>> Please ponder this and help me understand why having a single common
>> zone across buzz, woody, and zurg using response sorting wouldn't work.
>
>    Well, I have no control over buzz and woody. I can only control
> zurg. I'm not sure if Winblows can do response sorting, or if zurg
> would be able to impose a sort on the data after he does a Zone transfer.
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe 

Re: Malicious-DNS

[Sten Carlsen]

Or do the combination, setup the fake server and use tcpdump or
wireshark to capture all access. That should catch all ports and protocols.

On 18-02-2019 21.05, Kevin Darcy wrote:
> Another approach is to define a "fake" vitaminc.pro
> <http://vitaminc.pro> domain, point it at an internal webserver
> (assuming you have a spare, or can spin one up for the purpose), and
> see what clients are hitting it.
>
> Of course, that assumes the communication is web-based. If it's some
> other protocol(s), you'd need to monitor that protocol, or those
> protocols, on the "decoy" server. One would need to know more about
> the behavior of the malware involved.
>
> Speaking of which, Virustotal doesn't seem to think there's anything
> suspicious about vitaminc.pro <http://vitaminc.pro>. Haven't checked
> my other sources of Threat Intelligence, but usually there's
> *something* on VT if a domain is being used as a C&C...
>
>                                                                      
>                    - Kevin
>
>
> On Mon, Feb 18, 2019 at 9:24 AM Tony Finch  <mailto:d...@dotat.at>> wrote:
>
> MEjaz mailto:me...@cyberia.net.sa>> wrote:
> >
> > If I enabled the system performs will slow down?
>
> Depends on how much load your servers are under and what their
> capacity
> is.
>
> An alternative to query logs, when you are searching for a known query
> name, is to use tcpdump. It's a tedious and fiddly to convert the
> name to
> DNS wire format and then into a pcap filter expression, so I have
> a little
> script to do that (quoted below after my .sig). The command you
> want is
> like:
>
> tcpdump -np udp port 53 and '(' udp[20] == 8 and udp[21] == 118
> and udp[22] == 105 and udp[23] == 116 and udp[24] == 97 and
> udp[25] == 109 and udp[26] == 105 and udp[27] == 110 and udp[28]
> == 99 and udp[29] == 3 and udp[30] == 112 and udp[31] == 114 and
> udp[32] == 111 ')'
>
> Tony.
> -- 
> f.anthony.n.finch  mailto:d...@dotat.at>> 
> http://dotat.at/
> Southeast Iceland: Northerly 6 to gale 8, veering northeasterly 5
> to 7. Rough
> or very rough. Rain or wintry showers. Good, occasionally poor.
>
>
> #!/usr/bin/perl
>
> use warnings;
> use strict;
>
> use Net::DNS::DomainName;
>
> die "usage: $0 \n"
>     unless @ARGV == 1;
>
> my $text = shift;
> my $wire = new Net::DNS::DomainName($text)->canonical;
>
> my @wire = unpack 'C*', $wire;
>
> pop @wire unless $text =~ m{\.$};
>
> printf "'(' %s ')'\n",
>     join ' and ',
>     map { sprintf "udp[%d] == %d",
>               20 + $_, $wire[$_] }
>     0 .. $#wire;
> #!/usr/bin/perl
>
> use warnings;
> use strict;
>
> die "usage: tcpdump-qname.pl <http://tcpdump-qname.pl> \n"
>     unless @ARGV == 1;
>
> my $name = shift;
>
> my @name = unpack 'C*', $name;
>
> printf "%s\n", join ', ', @name;
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org <mailto: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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

"MALE BOVINE MANURE!!!" 

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

[Sten Carlsen]

Please see below.

On 11/10/2018 18.13, Hardy, Andrew wrote:
> Ok I'm a bit confused.  I have some questions re last post, copied below:
>
> I have done this some time ago, I made sure that there was no link
> from any pages to the new site, 
> ** So the new site (in development) would have no domain name mapped
> in DNS, so it seems unlikely that other sites and pages would have
> links to http://x.x.x.x unless the developer put it there.
Actually I had DNS for this.
>
> Google stayed away until somebody typed the address
> ** You mean typed the IP address? You mean in an actual Google search
> string?
Something in a search string, if this has the address visits from the
bots are next to come. My experience for this and some other cases.
>
>  into the search field, then it was known.
> ** So typing the host IP address as a Google search string would
> (ultimately) in time lead to a Google search string, that could be
> found on the sites web pages, listing pages from the site?
This is my experience. I did this when I wanted the site to be known to
the world.
>
> This is no guarantee of course as mentioned in other place but it
> worked for about 6 months.
> ** Ok, so even if you don't formally register / index (or what ever it
> is) your site on Google, if you use it's IP in a search string, given
> time it could show up in searches using text that's on its pages?
Time in this case is days or less.

There are also bots that search random IP addresses for content, the
only way to keep those away that I know of is to have a welcome page in
http://xx.xx/index.html and using e.g.
http://xx.xx/test/mynewsite/index.html for my test site.
Bots will find the welcome page and if that does not have a link to my
mynewsite, they do not know that there is something to look at.
This has worked for me as well for quite some time, again if it hits a
search in any search engine, you're done.
>
>
> Just to say thank you so much for people commenting.  I do appreciate
> you taking the time.
You're welcome.
>
>
>
> On Thu, Oct 11, 2018, 14:50 Sten Carlsen  <mailto:st...@s-carlsen.dk>> wrote:
>
> I have done this some time ago, I made sure that there was no link
> from any pages to the new site, Google stayed away until somebody
> typed the address into the search field, then it was known.
>
> This is no guarantee of course as mentioned in other place but it
> worked for about 6 months.
>
> On 11/10/2018 13.26, Admin Hardy wrote:
>>
>> I realise this is not specifically a BIND/DNS question and a bit
>> off topic so please ignore if need be I realise people are often
>> very busy.
>>
>> If you you have a website but the host IP you do not list with
>> any domain name in DNS, is it definite that this site could never
>> be reached via Google.  I do not really know the nuts and bolts
>> of how Google gets access to pages.
>>
>> If for 'some particular reason' instead of developing a site on a
>> local dev machine on your LAN and then uploading/installing the
>> site to a remote server, you needed 'for what ever reason' to do
>> the development and testing on the final live host accessing it
>> via the ip address, would this be a way to be 'almost certain' of
>> keeping it hidden from unwanted accidental exposure?
>>
>> Thanks.
>>
>>
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users@lists.isc.org <mailto: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 <mailto: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: Question about visibility

[Sten Carlsen]

I have done this some time ago, I made sure that there was no link from
any pages to the new site, Google stayed away until somebody typed the
address into the search field, then it was known.

This is no guarantee of course as mentioned in other place but it worked
for about 6 months.

On 11/10/2018 13.26, Admin Hardy wrote:
>
> I realise this is not specifically a BIND/DNS question and a bit off
> topic so please ignore if need be I realise people are often very busy.
>
> If you you have a website but the host IP you do not list with any
> domain name in DNS, is it definite that this site could never be
> reached via Google.  I do not really know the nuts and bolts of how
> Google gets access to pages.
>
> If for 'some particular reason' instead of developing a site on a
> local dev machine on your LAN and then uploading/installing the site
> to a remote server, you needed 'for what ever reason' to do the
> development and testing on the final live host accessing it via the ip
> address, would this be a way to be 'almost certain' of keeping it
> hidden from unwanted accidental exposure?
>
> Thanks.
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
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 evisa.dgdi.ga FQDN

[Sten Carlsen]

Works for me:

; <<>> DiG 9.10.6 <<>> evisa.dgdi.ga
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14630
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;evisa.dgdi.ga.            IN    A

;; ANSWER SECTION:
evisa.dgdi.ga.        86400    IN    A    129.35.173.151

;; AUTHORITY SECTION:
dgdi.ga.        300    IN    NS    ns1.francedns.com.
dgdi.ga.        300    IN    NS    ns2.francedns.com.
dgdi.ga.        300    IN    NS    ns3.francedns.com.

;; ADDITIONAL SECTION:
ns2.francedns.com.    172800    IN    A    199.254.31.254
ns3.francedns.com.    172800    IN    A    199.254.56.254

;; Query time: 926 msec
;; SERVER: 192.168.16.20#53(192.168.16.20)
;; WHEN: Tue Oct 09 11:53:38 CEST 2018
;; MSG SIZE  rcvd: 157


On 09-10-2018 04.21, Kuo Loon Pang via bind-users wrote:
> dig evisa.dgdi.ga <http://evisa.dgdi.ga>

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

"MALE BOVINE MANURE!!!" 

___
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 two Domain in Named.local, but not resolv

[Sten Carlsen]

Also be aware that .local is reserved.

-- 
Best regards 
Sten Carlsen 


No improvements come from shouting: 
"MALE BOVINE MANURE!!!" 

On 9 Oct 2018, at 00.40, Kevin Darcy mailto:kevin.da...@fcagroup.com>> wrote:

> Offhand, it looks like  192.168.201.92  is giving SERVFAIL for anything in 
> the carag.local zone, but is fine for the olh.local zone. Did the zone load 
> properly? Look in the logs at startup or reload time.  
> 
> But, the tools you're using, and how you're using them, makes troubleshooting 
> very difficult and confusing. First of all, why mix "ping" troubleshooting 
> with nslookup troubleshooting, if you're sure it's a DNS problem (i.e. no 
> complications with hosts-file entries, nsswitch.conf or other such factors)? 
> If it's a DNS issue, stick with DNS troubleshooting/diagnostic tools
> 
> Secondly, without any options, nslookup won't give you an accurate picture of 
> what's being looked up, behind the scenes. At least use the "-debug" option 
> to nslookup, or, even better, use a real lookup troubleshooting tool like 
> "dig".
> 
> I'd also suggest targeting *specific* nameservers with your queries, rather 
> than just querying generically and allowing failover to occur on errors, 
> which muddies the situation. Single out each nameserver and determine what it 
> can resolve and what it cannot.
> 
> Always use fully-qualified names when troubleshooting, unless the specific 
> thing you're trying to troubleshoot is suffixing/searchlisting behavior by 
> the resolver.
> 
> As for the failure of the reverse lookup, try it with a 4-octet IP address 
> instead of 5. 
> 
>   - Kevin
> 
> On Sun, Oct 7, 2018 at 9:12 AM Maurizio Caloro via bind-users 
> mailto:bind-users@lists.isc.org>> wrote:
> Please i need a little help, about DNS Bind Server… i need to replace the old 
> one « 115 »
> 
> Here i’an on the new one «92 »
> 
>  
> 
> Version
> 
> BIND 9.10.3-P4-Debian 
> 
>  
> 
> I try that my DNS server 192.168.201.92 = MasterDNS Server resposible for 2 
> Network Ranges
> 
> 1192.168.201.
> 
> 2192.168.202.
> 
>  
> 
>  
> 
> Thanks  for your feedback.
> 
> Regards
> 
>  
> 
> --
> 
>  
> 
> root@srvcar012:/etc/bind# ping srvcar002
> 
> PING srvcar002.carag.local (192.168.201.118) 56(84) bytes of data.
> 
> 64 bytes from srvcar002.201.168.192.in-addr.arpa (192.168.201.118): 
> icmp_seq=1 ttl=128 time=0.733 ms
> 
>  
> 
> root@srvcar012:/etc/bind# ping srvcar001.carag.local
> 
> ping: srvcar001.carag.local: Name or service not known
> 
>  
> 
>  
> 
> root@srvcar012:/etc/bind# nslookup srvcar001
> 
> ;; Got SERVFAIL reply from 192.168.201.92, trying next server
> 
> Server:   192.168.201.115
> 
> Address:192.168.201.115#53
> 
>  
> 
> Name:   srvcar001.carag.local
> 
> Address: 192.168.201.117
> 
>  
> 
>  
> 
> root@srvcar012:/etc/bind# nslookup srvcar001
> 
> ;; Got SERVFAIL reply from 192.168.201.92, trying next server
> 
> Server: 192.168.201.115
> 
> Address:192.168.201.115#53
> 
>  
> 
> Name:   srvcar001.carag.local
> 
> Address: 192.168.201.117
> 
>  
> 
> root@srvcar012:/etc/bind# nslookup srvcar001.carag.local
> 
> ;; Got SERVFAIL reply from 192.168.201.92, trying next server
> 
> Server: 192.168.201.115
> 
> Address:192.168.201.115#53
> 
>  
> 
> Name:   srvcar001.carag.local
> 
> Address: 192.168.201.117
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> 
>  
> 
> With the 202 side, this arnt working
> 
>  
> 
> root@srvcar012:/etc/bind# ping srvolh001
> 
> ping: srvolh001: Name or service not known
> 
>  
> 
> root@srvcar012:/etc/bind# ping srvolh001.olh.local
> 
> ping: srvolh001.olh.local: Name or service not known
> 
>  
> 
> root@srvcar012:/etc/bind# nslookup srvolh001
> 
> ;; Got SERVFAIL reply from 192.168.201.92, trying next server
> 
> Server: 192.168.201.92
> 
> Address:192.168.201.92#53
> 
>  
> 
> ** server can't find srvolh001: NXDOMAIN
> 
>  
> 
> And here this are correct, DNS Server ?
> 
>  
> 
> root@srvcar012:/etc/bind# nslookup srvolh001.olh.local
> 
> Server: 192.168.201.92
> 
> Address:192.168.201.92#53
> 
>  
> 
> Name:   srvolh001.olh.local
> 
> Address: 192.168.202.14
> 
>  
> 
>  
> 
> root@srvcar012:/etc/bind

Re: BIND and UDP tuning

[Sten Carlsen]

On 27/09/2018 16.53, Alex wrote:
> Hi,
>
>>> I reported a few weeks ago that I was experiencing a really high
>>> number of "SERVFAIL" messages in my bind-9.11.4-P1 system running on
>>> fedora28, and I haven't yet found a solution. This is all now running
>>> on a 165/35 cable system.
>>>
>>> I found a program named dropwatch which is showing a significant
>>> number of dropped UDP packets, particularly when there are bursts of
>>> email traffic:
>>>
>>> 12 drops at skb_queue_purge+13 (0x9f79a0c3)
>>> 1 drops at __udp4_lib_rcv+1e6 (0x9f83bdf6)
>>> 4 drops at __udp4_lib_rcv+1e6 (0x9f83bdf6)
>>> 5 drops at nf_hook_slow+a7 (0x9f7faff7)
>>> 3 drops at sk_stream_kill_queues+48 (0x9f7a1158)
>>> 3 drops at __udp4_lib_rcv+1e6 (0x9f83bdf6)
>>> ...
>>>
>>> # netstat -us
>>> ...
>>> Udp:
>>> 23449482 packets received
>>> 1724269 packets to unknown port received
>>> 8248 packet receive errors
>>> 31394909 packets sent
>>> 8243 receive buffer errors
>>> 0 send buffer errors
>>> InCsumErrors: 5
>>> IgnoredMulti: 43247
>>>
>>> The SERVFAIL messages don't necessarily correspond to the UDP packet
>>> errors shown by netstat, but the dropwatch output is continuous. The
>>> netstat packet receive errors also don't seem to correspond to
>>> "SERVFAIL" or "Name service" errors:
>>>
>>> 26-Sep-2018 12:42:49.743 query-errors: info: client @0x7fb3c41634d0
>>> 127.0.0.1#44104 (46.36.47.104.wl.mailspike.net): query failed
>>> (SERVFAIL) for 46.36.47.104.wl.mailspike.net/IN/A at
>>> ../../../bin/named/query.c:8580
>>>
>>> Sep 26 12:47:11 mail03 postfix/dnsblog[22821]: warning: dnsblog_query:
>>> lookup error for DNS query 196.91.107.80.bl.spameatingmonkey.net: Host
>>> or domain name not found. Name service error for
>>> name=196.91.107.80.bl.spameatingmonkey.net type=A: Host not found, try
>>> again
>>>
>>> I've been following this thread from some time ago, but nothing I've
>>> done has made a difference. I really don't know what the buffer sizes
>>> should be.
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__bind-2Dusers-
>>> 2Dforum.2342410.n4.nabble.com_Tuning-2Dsuggestions-2Dfor-2Dhigh-2Dcore-
>>> 2Dcount-2DLinux-2Dservers-
>>> 2Dtd3899.html&d=DwICAg&c=MOptNlVtIETeDALC_lULrw&r=udvvbouEjrWNUMab5xo_vLb
>>> UE6LRGu5fmxLhrDvVJS8&m=5XQNuuRQ4kxK03zqoWaJHIdaJvNdsyTKHuFlDKedbpc&s=5Dqh
>>> ne-5w5V_1coBTBvTITwK2EFeankOegTaofy8S5w&e=
>>>
>>> Are there specific bind tunables you might recommend? edns-udp-size,
>>> perhaps?
>>>
>>> Any ideas on other tunables such as net.core.*mem_default etc?
>> *chuckles to self*
>>
>> I was just referring back to that thread myself to try remember what I did.
>>
>> I ended up tuning the following items:
>>
>>   - name: SYSCTL system tuning, basics
>> sysctl:
>>   name: "{{ item.name }}"
>>   value: "{{ item.value }}"
>>   sysctl_set: yes
>>   state: present
>> with_items:
>>   - { name: 'vm.swappiness', value: 0 }
>>   - { name: 'net.core.netdev_max_backlog', value: 32768 }
>>   - { name: 'net.core.netdev_budget', value: 2700 }
>>   - { name: 'net.ipv4.tcp_sack', value: 0 }
>>   - { name: 'net.core.somaxconn', value: 2048 }
>>   - { name: 'net.core.rmem_default', value: 16777216 }
>>   - { name: 'net.core.rmem_max', value: 16777216 }
>>   - { name: 'net.core.wmem_default', value: 16777216 }
>>   - { name: 'net.core.wmem_max', value: 16777216 }
> Were you troubleshooting the same problems as I'm experiencing?
>
> Many of these values I've already tweaked and have had no effect on my
> SERVFAIL issues :-(
>
> I've also been following the performance tuning variables in this RH document:
> https://access.redhat.com/sites/default/files/attachments/20150325_network_performance_tuning.pdf
>
> These errors appear to occur in spurts - there is typically ten or
> more in a row at a time, then any number of minutes/seconds before the
> next one.
>
> It looks like there are periods of as many as 500 queries per second,
> although the usual amount is closer to 200 per second.
>
> I don't believe this is a bind configuration problem, as the "Name
> service error" errors from postfix also occur when testing with
> unbound.
>
> This is also only happening on the two identical systems connected to
> the 165/35mbit cable modem. I've verified with Oponline, and they've
> emphatically asserted there are no problems with the circuit. The
> systems are 8-core Xeon E31240 with 16GB RAM. I've also tried other
> systems, including a 12-core i7 with 32GB.
>
> We have several other systems connected to a 10mbit DIA ethernet
> circuit where these errors don't generally occur. They are also
> similarly configured fedora systems with the same version of bind.
>
> I'm really at a loss as to what the problem(s) are, but feel like it's
> really impacting our ability to query RBLs for processing mail.
>
>> Whilst mentioned in passing on that thread, there was also poking around 
>> with T

Re: How to avoid to listen on specific interfaces

[Sten Carlsen]

In the end I had to look in the BIND ARM.

As I read this, the solution should be:

options {
listen-on { ! 10.0.1.1; any;};
};

The first part tells bind to not listen to 10.0.1.1 and the second part
tells bind to listen on any other address.
Having the Listen-on statement removes the default listen for all addresses.


On 06/09/2018 15.24, He Zhe wrote:
>
> On 2018年09月06日 21:06, Sten Carlsen wrote:
>>
>> On 06/09/2018 14.33, He Zhe wrote:
>>> On 2018年09月06日 20:26, Sten Carlsen wrote:
>>>> On 06/09/2018 12.36, He Zhe wrote:
>>>>> Hi,
>>>>>
>>>>> How can I config to let named NOT listen on specific interfaces? Any 
>>>>> negation config in options like below? Currently it listens on all 
>>>>> interfaces and compete with other DNS daemons in the same system.
>>>>>
>>>>> options {
>>>>> listen-on { ! 10.0.1.1; };
>>>>> };
>>>> You may try to let it specifically listen to all interfaces except the one 
>>>> you want excluded.
>>> Thanks for your hint.
>>>
>>> But the "all" here is hard for me to determine beforehand. Many potential 
>>> different things would use named but some specific one just want to use 
>>> their own DNS services. So I'm looking for the NOT operation.
>> I would assume that there is a limited and fairly fixed number of actual 
>> NICs in the host.
>>
>> example:
>> eth0 -> internal network 192.168.43.17
>> eth1 -> external network 123.45.6.7
>> eth0:7 -> VLAN for location 1  192.168.23.45
>>
>> Listen_on { 192.168.43.17; 192.168.23.45; }  eth1 is missing and should not 
>> be listened to.
> Thanks for the example.
>
> The IPs in my case cannot be determined in advance. They might be configured 
> and then changed to any values. I could fall back to create a script to 
> detect the changes and modify named's config and restart the named service. 
> But that sounds not so good. I hope named can ignore some specific IP and/or 
> interfaces while handles the rest.
>
> Zhe
>
>>> Zhe
>>>
>>>>> Thanks,
>>>>> Zhe
>>>>> ___
>>>>> 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

___
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 avoid to listen on specific interfaces

[Sten Carlsen]

On 06/09/2018 14.33, He Zhe wrote:
>
> On 2018年09月06日 20:26, Sten Carlsen wrote:
>>
>> On 06/09/2018 12.36, He Zhe wrote:
>>> Hi,
>>>
>>> How can I config to let named NOT listen on specific interfaces? Any 
>>> negation config in options like below? Currently it listens on all 
>>> interfaces and compete with other DNS daemons in the same system.
>>>
>>> options {
>>> listen-on { ! 10.0.1.1; };
>>> };
>> You may try to let it specifically listen to all interfaces except the one 
>> you want excluded.
> Thanks for your hint.
>
> But the "all" here is hard for me to determine beforehand. Many potential 
> different things would use named but some specific one just want to use their 
> own DNS services. So I'm looking for the NOT operation.
I would assume that there is a limited and fairly fixed number of actual
NICs in the host.

example:
eth0 -> internal network 192.168.43.17
eth1 -> external network 123.45.6.7
eth0:7 -> VLAN for location 1  192.168.23.45

Listen_on { 192.168.43.17; 192.168.23.45; }  eth1 is missing and should
not be listened to.

>
> Zhe
>
>>> Thanks,
>>> Zhe
>>> ___
>>> 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

___
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 avoid to listen on specific interfaces

[Sten Carlsen]

On 06/09/2018 12.36, He Zhe wrote:
> Hi,
>
> How can I config to let named NOT listen on specific interfaces? Any negation 
> config in options like below? Currently it listens on all interfaces and 
> compete with other DNS daemons in the same system.
>
> options {
> listen-on { ! 10.0.1.1; };
> };
You may try to let it specifically listen to all interfaces except the
one you want excluded.
>
> Thanks,
> Zhe
> ___
> 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: Creating CNAME Resource Records (RR) to Redirect Readers to My Wordpress and Blogspot Blogs Don't Work

[Sten Carlsen]

On 08/08/2018 10.28, Turritopsis Dohrnii Teo En Ming wrote:
> Good afternoon from Singapore,
>
> I have 2 redundant blogs, one at wordpress.com (example.wordpress.com) and 
> another at blogspot.sg (example.blogspot.sg).
>
> I have a Domain Name Service (DNS) server (ns1 and ns2) at home in Singapore.
>
> I would like to create two CNAME resource records to redirect readers to my 
> wordpress and blogspot blogs respectively.
>
> For example,
>
> CNAME: wordpress.mydomain.com REDIRECT to example.wordpress.com
>
> CNAME: blogspot.mydomain.com REDIRECT to example.blogspot.sg
>
> But the CNAME records I have created and redirection don't work at all. Did I 
> miss out anything?
The CNAME RRs do work:

; <<>> DiG 9.10.6 <<>> blogspot.teo-en-ming.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22888
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 9

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;blogspot.teo-en-ming.com.    IN    A

;; ANSWER SECTION:
blogspot.teo-en-ming.com. 3600    IN    CNAME    tdtemcerts.blogspot.sg.
tdtemcerts.blogspot.sg.    600    IN    CNAME   
blogspot.l.googleusercontent.com.
blogspot.l.googleusercontent.com. 300 IN A    216.58.213.193

;; AUTHORITY SECTION:
googleusercontent.com.    66612    IN    NS    ns1.google.com.
googleusercontent.com.    66612    IN    NS    ns4.google.com.
googleusercontent.com.    66612    IN    NS    ns2.google.com.
googleusercontent.com.    66612    IN    NS    ns3.google.com.

;; ADDITIONAL SECTION:
ns2.google.com.        18596    IN    A    216.239.34.10
ns2.google.com.        18596    IN        2001:4860:4802:34::a
ns1.google.com.        18596    IN    A    216.239.32.10
ns1.google.com.        18596    IN        2001:4860:4802:32::a
ns3.google.com.        18596    IN    A    216.239.36.10
ns3.google.com.        18596    IN        2001:4860:4802:36::a
ns4.google.com.        18596    IN    A    216.239.38.10
ns4.google.com.        18596    IN        2001:4860:4802:38::a

;; Query time: 1900 msec
;; SERVER: 192.168.16.20#53(192.168.16.20)
;; WHEN: Wed Aug 08 14:58:27 CEST 2018
;; MSG SIZE  rcvd: 403


The problem you experience is that Google sees the original request:
http://blogspot.teo-en-ming.com/

and respond:

*404.* That’s an error.

The requested URL |/| was not found on this server. That’s all we know.


You probably have to make a redirect from a web server that you own so
the request can be corrected to the appropriate address (header
information) to show Google.
>
> Please advise.
>
> Thank you very much. 
>  
>  ===BEGIN SIGNATURE=== 
> Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 30 Oct 2017 
> [1] https://tdtemcerts.wordpress.com/ 
> [2] http://tdtemcerts.blogspot.sg/ 
> [3] https://www.scribd.com/user/270125049/Teo-En-Ming 
> ===END SIGNATURE=== 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
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: slave-not-updated

[Sten Carlsen]

Don’t forget both UDP and TCP port 53 must be open.


-- 
Best regards

Sten Carlsen

No improvements come from shouting:

  "MALE BOVINE MANURE!!!"

> On 1 Aug 2018, at 13.09, Niall O'Reilly  wrote:
> 
>> On 1 Aug 2018, at 10:01, Mohammed Ejaz wrote:
>> 
>> Is there any way to troubleshoot from the master server why there is no 
>> synchnization to one more Slave.
> 
> Only partly. You may need access to the slave at some stage.
> 
> Master log should record NOTIFY messages sent to all slaves.
> If not all desired slaves are being sent NOTIFY, master needs to be
> configured with relevant directive (BIND named: also-notify).
> 
> If master is sending NOTIFY, next thing to check is whether slave
> is requesting AXFR/IXFR. Master log should show each transfer.
> If not, then you’ll need to ask sysadmin at slave to check whether
> NOTIFY is arriving and being accepted, and whether slave is actually
> requesting transfer. If not, slave configuration may need
> correction (BIND named: allow-notify).
> 
> If there is still a problem, you’ll likely need to use tcpdump or
> the like to investigate at network level, as NOTIFY or transfer
> may be blocked by a misconfigured firewall or other network fault.
> 
> 
> One other thing: avoid using nslookup. In trying to be “helpful”,
> it hides significant information and makes troubleshooting difficult.
> You’ll save time (yours, and that of anyone who tries to help you)
> by using dig.
> 
> Best regards,
> Niall O’Reilly
> ___
> 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: My IXFR/AXFR stopped suddenly

[Sten Carlsen]

On 06-07-2018 23.49, Anand Buddhdev wrote:
> On 06/07/2018 19:36, Matus UHLAR - fantomas wrote:
>
>> customised port, that's why transfers stopped working.
> No Matus, you're wrong.
>
>> on the slave, you must configure the master with port 15455.
>> see "server" directive.
>> of course, it will use port 15455 for all queries then.
> No, you're off the track here.
>
> Blason's config means this:
>
> The slave is configured to listen on port 15455.
Where in the slave's configuration is that specified? Rather the master
sends notifys on two ports: 53 and 15455.
>  The master has been
> told to send a NOTIFY to the slave. The master will originate this
> NOTIFY message from a random source port, and send it to the slave on
> destination port 15455.
>
> The slave is obviously receiving the NOTIFY message, as evidence by the
> log message on the slave:
>
> 06-Jul-2018 14:10:28.341 client x.x.x.x#10090: received notify for zone
> 'block.now'
>
> At this point, the slave should refresh the zone from the master. Blason
> says it's not refreshing.
>
> Blason, try debugging by using "dig" on the slave to manually transfer
> the zone from the master. Maybe that will give you a clue to the problem.
>
> Anand
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

"MALE BOVINE MANURE!!!" 

___
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: My IXFR/AXFR stopped suddenly

[Sten Carlsen]

Hi

On 06/07/2018 15.46, Blason R wrote:
> Hi Team,
>
> Any clue how do I troubleshoot why master to Slave IXFR/AXFR stopped?
> It was working before even my logs shows notifies..I can connect to my
> slave on customised port that NOTIFY messages are sent but then PULL
> from slave to master is not working.
>
> Master
> zone "block.now" {
>     type master;
>     file "/var/lib/bind/zones/block.now.db";
>     notify explicit;
>     also-notify {
>    2.2.2.2 port 15455;
>     };
>     allow-transfer {
>     2.2.2.2;
>     };
>    
>
> ON SLAVE
> zone "block.now" {
>     type slave;
>     file "/var/lib/bind/zones/block.now.db";
>     masters { x.x.x.x; };
>     allow-transfer { none; };
>     allow-query { localhost;};
>     allow-notify { x.x.x.x; };
>     };
>
Maybe I am missing something but how will the slave know that it must
use port 15455?
> 06-Jul-2018 14:10:28.341 client x.x.x.x#10090: received notify for
> zone 'block.now'
> 06-Jul-2018 14:14:54.988 client x.x.x.x#10093: received notify for
> zone 'block.now'
>
>
>
>
>
> ___
> 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



pEpkey.asc
Description: application/pgp-keys
___
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: Data exfiltration using DNS RPZ

[Sten Carlsen]

Interesting, the Dnssec records with their by definition random and
large content seems to be the most interesting vehicle, at least at
first sight.

Will e.g. the google DNS server or any other resolver deliver and fetch
this data? At the moment I can't think of any reason it should not do so.

To really block this, I think you would need to actually verify the
correctness of the data.


On 17-06-2018 08.43, Blason R wrote:
> Hi Team,
>
> Can someone please guide if DNS exfiltration techniques can be
> identified using DNS RPZ? Or do I need to install any other third
> party tool like IDS to identify the the DNS beacon channels.
>
> Has anyone used DNS RPZ to block/detect data exfiltration?
>
>
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

"MALE BOVINE MANURE!!!" 

___
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: extranet.aro.army.mil - not resolving

[Sten Carlsen]

On 31/05/2018 21:42, Con Wieland wrote:
> agreed but why would my server not resolve it while others do?
For what its worth.
My server has never seen this request before and resolves it:

silver4-2:~ carlsen$ dig extranet.aro.army.mil

; <<>> DiG 9.10.6 <<>> extranet.aro.army.mil
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29942
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 3, ADDITIONAL: 4

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;extranet.aro.army.mil.        IN    A

;; ANSWER SECTION:
extranet.aro.army.mil.    487    IN    CNAME   
aro.army.mil.apps.gcds.disa.mil.
aro.army.mil.apps.gcds.disa.mil. 969 IN    CNAME   
aro.army.mil.edgekey.dmz.akamai.csd.disa.mil.
aro.army.mil.edgekey.dmz.akamai.csd.disa.mil. 100 IN CNAME
e1008.d.akamaiedge.akamai.csd.disa.mil.
e1008.d.akamaiedge.akamai.csd.disa.mil.    19 IN A    214.48.244.31

;; AUTHORITY SECTION:
disa.mil.        21597    IN    NS    NS1.csd.disa.mil.
disa.mil.        21597    IN    NS    NS.JTFGNO.mil.
disa.mil.        21597    IN    NS    NS.CYBERCOM.mil.

;; ADDITIONAL SECTION:
NS1.csd.disa.mil.    21597    IN    A    152.229.110.235
NS.JTFGNO.mil.        21597    IN    A    214.3.125.231
NS.CYBERCOM.mil.    21597    IN    A    131.77.60.235

;; Query time: 4576 msec
;; SERVER: 192.168.16.20#53(192.168.16.20)
;; WHEN: Thu May 31 21:59:28 CEST 2018
;; MSG SIZE  rcvd: 307


-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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: DNSSEC validation without current time

[Sten Carlsen]

 risks and costs
> of a defense.
>
> Bootstrapping requires some reasonably accurate time source.  The
> easiest way to get there is with a locally trusted source.  You can
> add an RTC - again, here's one from Adafruit -
> https://www.adafruit.com/product/3386 about $5 (US).  [Same
> disclaimer.]  The RTCs (I haven't run this one) in general have poor
> accuracy(2) - but if resynchronized with NTP time once in a while,
> easily good enough to bootstrap DNSSEC.  The one I use (1) is good to
> less than 1PPM with the help of some drift compensation that I put
> into the utility that manages the clock.  [It's a replacement for
> 'hwclock' that drives this RTC.]  (This reduces the jump when NTP
> starts, and helps keep logs straight.  If you don't care about that,
> just update the RTC from NTP time every week or two - that's more than
> sufficient for DNSSEC & NTP bootstrap.)
>
> Alternatively, as previously discussed, if you need the best (non PTP)
> time, add a GPS receiver, with pool backup.
>
> You can skip the DNS cyclic dependency completely if you have
> locally-trusted NTP and DHCP servers - provide your clients with the
> NTP server addresses via DHCP.  (They're sent as IP addresses, not
> names.)  This isn't as hard as it appears.  If you run NTP on all your
> machines (yes, there's NTP for windows), your Pi can get time from them.
>
> Further, since you run your own DNS server - presumably within some
> firewall - you can trust it to serve your local zones.  DNSSEC not
> required.  If you include your local machines in your NTP
> configurations, everything is under your control.  It then becomes a
> sequencing issue only if your entire site goes down.   (If so, you
> want your local master to be up first.  Otherwise, the rest will coast
> using other NTP sources.)  If you're really serious, you run at least
> 3 local clocks - preferably something like GPS, WWV (or other radio
> source), and a local atomic (or at least, TXCO)  clock.  If you start
> looking at failure scenarios, it gets more interesting.
>
> As previously noted, startup scripts need to have the "right"
> definition of "system time available" & dependencies for your
> applications (including named) to start.
>
> Because the draw minimal power (and so will run a long time with a
> modest UPS), I use an RPi with GPS & some pool servers as my preferred
> time source.  It boots using an RTC.  My edge router also runs NTP,
> preferentially taking time from the RPi - but also configured with
> other Public and local servers.  In case the RPi goes down, the local
> machines also participate - the low latency and dispersion pretty much
> ensures that they'll be taken over the public servers.  I may add
> another Pi with another GPS and/or radio receiver, when I acquire
> enough round TUITs.
>
> So, what to conclude?
>
>   * If you have other machines in your local network, use them as NTP
> sources and provide the addresses to your RPi via DHCP.  This is
> cheapest and easiest.
>   * If you don't need precise time (e.g. for purposes beyond DNSSEC),
> the next cheapest solution (in $ and time) is to just add an RTC.
>   * If you also want precise time, but don't need it to be highly
> available, add a GPS.
>   * For more availability, do both.  And possibly add other time
> sources (Radio, TCXO, geographically dispersed GPS, more RPis...).
>
> In any case, let us know what you end up with.
>
> Have fun!
>
> (1) This isn't an expensive problem to solve.  My RPi's RTC (TOY) uses
> a DS1302 - I got a bunch from e-bay for about $2 (including battery &
> shipping).  I could publish the software if there's interest.
>
>
> rtc/rtc-ctl --show --debug
> TOY Clock registers as read (UTC):
> 81: 57 RUN 57 sec
> 83: 42 42 min
> 85: 12 24H 12 hr
> 87: 18 18 date
> 89: 12 12 month
> 8B: 02 02 weekday
> 8D: 17 17 year
> 8F: 80  WP ctl
> Applying drift correction of -28.370 PPM to 10869574.837 seconds
> (125d 19h 19m 35s) elapsed
> TOY    time is Mon Dec 18 2017 07:48:05 EST
> System time is Mon Dec 18 2017 07:48:07.234 EST
> Remaining offset is -2.234 sec (-0.206 PPM)
>
> (2) 20 ppm is ~ one min/month.  Typical crystals can be 100 ppm or
> more (depending on temperature & PCB layout), so 5 min/month.  TSIG
> fudge is nominally 5 min, so resyncing every 1-2 weeks is close
> enough.  And also close enough for sane DNSSEC configurations.  You
> can resync more often, but it's a fair bit of bit-banging on a slow
> bus (I2C or SPI for most), and there's no point.
>
> Oh, why mention TSIG?  Because ... it's another time-sensitive part of
> named, and often used for DHCP - DNS updates...
>
> Timothe Litt
> ACM Distinguished Engineer
> --
> This communication may not represent the ACM or my employer's views,
> if any, on the matters discussed. 
>
>
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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-Format-Eroor

[Sten Carlsen]

 127.0.0.1#53
>
> > 
>
> > Non-authoritative answer:
>
> > Name:   MUMBAI-M.SITE
>
> > Address: 46.105.221.247
>
> > 
>
> > [harry@srv-rhsoft:/mnt/data/downloads]$ nslookup NS1.MUMBAI-M.SITE
>
> > Server: 127.0.0.1
>
> > Address:    127.0.0.1#53
>
> > 
>
> > Non-authoritative answer:
>
> > Name:   NS1.MUMBAI-M.site
>
> > Address: 46.105.221.247
>
> > 
>
> > [harry@srv-rhsoft:/mnt/data/downloads]$ nslookup NS2.MUMBAI-M.SITE
>
> > Server: 127.0.0.1
>
> > Address:    127.0.0.1#53
>
> > 
>
> > Non-authoritative answer:
>
> > Name:   NS2.MUMBAI-M.SITE
>
> > Address: 46.105.221.247
>
> > 
>
> >> Dec 17 05:35:39 ns20 named[1530]: DNS format error from
>
> >> 46.105.221.247#53 resolv ing ns1.mumbai-m.site/: reply has no
>
> >> answer
>
> >> 
>
> >> Dec 17 05:35:40 ns20 named[1530]: DNS format error from
>
> >> 46.105.221.247#53 resolv
>
> >>   ing ns2.mumbai-m.site/:
>
> >> reply has no answer
>
> >> 
>
> >> Dec 17 09:43:46 ns20 named[1530]: DNS format error from
>
> >> 46.105.221.247#53 resolv ing ns1.mumbai-m.site/: reply has no
>
> >> answer
>
> >> 
>
> >> Dec 17 09:43:46 ns20 named[1530]: DNS format error from
>
> >> 46.105.221.247#53 resolv ing ns2.mumbai-m.site/: reply has no
>
> >> answer
>
> >> 
>
> >> Dec 17 09:47:41 ns20 named[1530]: DNS format error from
>
> >> 46.105.221.247#53 resolv ing ns1.mumbai-m.site/: reply has no
>
> >> answer
>
> >> 
>
> >> Dec 17 09:47:41 ns20 named[1530]: DNS format error from
>
> >> 46.105.221.247#53 resolv ing ns2.mumbai-m.site/: reply has no
>
> >> answer
>
> >> 
>
> >> Dec 17 09:48:41 ns20 named[1530]: DNS format error from
>
> >> 46.105.221.247#53 resolv ing ns2.mumbai-m.site/: reply has no
>
> >> answer
>
> >> 
>
> >> Dec 17 09:48:41 ns20 named[1530]: DNS format error from
>
> >> 46.105.221.247#53 resolv ing ns1.mumbai-m.site/: reply has no
>
> >> answer
>
> >> 
>
> >> Dec 17 09:52:39 ns20 named[1530]: DNS format error from
>
> >> 46.105.221.247#53 resolv ing ns2.mumbai-m.site/: reply has no
>
> >> answer
>
> >> 
>
> >> Dec 17 09:52:39 ns20 named[1530]: DNS format error from
>
> >> 46.105.221.247#53 resolv ing ns1.mumbai-m.site/: reply has no
>
> >> answer
>
> >> 
>
> >> Dec 17 09:55:52 ns20 named[1530]: DNS format error from
>
> >> 46.105.221.247#53 resolv ing ns1.mumbai-m.site/: reply has no
>
> >> answer
>
> >> 
>
> >> Dec 17 09:55:52 ns20 named[1530]: DNS format error from
>
> >> 46.105.221.247#53 resolv ing ns2.mumbai-m.site/: reply has no
>
> >> answer
>
> >> 
>
> >> Dec 17 09:58:41 ns20 named[1530]: DNS format error from
>
> >> 46.105.221.247#53 resolv ing ns2.mumbai-m.site/: reply has no
>
> >> answer
>
> >> 
>
> >> Dec 17 09:58:41 ns20 named[1530]: DNS format error from
>
> >> 46.105.221.247#53 resolv ing ns1.mumbai-m.site/: reply has no
>
> >> answer
>
> >> 
>
> >> Thanks,
>
> >> 
>
> >> Mohammed Ejaz
>
> >> 
>
> >> Asst. Operation Director of Systems.
>
> >> 
>
> >> Cyberia SAUDI ARABIA
>
> >> 
>
> >> P.O.Box: 301079, Riyadh 11372
>
> >> 
>
> >> Phone:  (+966) 11 464 7114 Ext. 140
>
> >> 
>
> >> Mobile:  (+966) 562311787
>
> >> 
>
> >> Fax:  (+966) 11 465 4735
>
> >> 
>
> >> Website: http://www.cyberia.net.sa
>
> > ___
>
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>
> > unsubscribe from this list
>
> > 
>
> > bind-users mailing list
>
> > bind-users@lists.isc.org <mailto:bind-users@lists.isc.org>
>
> > https://lists.isc.org/mailman/listinfo/bind-users
>
>  
>
> --
>
> Mark James ELKINS  -  Posix Systems - (South) Africa
>
> m...@posix.co.za <mailto:m...@posix.co.za>   Tel: +27.128070590 
> Cell: +27.826010496
>
> For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
>
>  
>
> ___
>
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
>  
>
> bind-users mailing list
>
> bind-users@lists.isc.org <mailto: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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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-policy zones from spamhaus.org

[Sten Carlsen]

On 07-10-2017 21.36, MAYER Hans wrote:
>
> Dear All, 
>
> We are using response-policy zones as a service from spamhaus.org
> This is used for web access as well as for SMTP ( incoming and outgoing ) 
> Actually this worked fine over years. 
> Now we have the situation if I dig www.airindia.in I get as result 
>
> ;; ADDITIONAL SECTION:
> bad-nameservers.rpz.spamhaus.org. 60 IN SOA need.to.know.only. 
> hostmaster.spamhaus.org. 1507403414 300 60 432000 60
>
> This indicates that it is listed in the  bad-nameservers.rpz.spamhaus.org 
> database from spamhaus.org which I have configured as a slave zone in my DNS 
> server.
> Our employees are travelling a lot and therefore it is not acceptable that 
> the Indian Airline is not reachable. 
>
> Such zones are defined as type slave. Therefore it’s not possible to update 
> such a zone. 
> I also tried to define these records in my own RPZ and hoping it has higher 
> priorities. But it isn’t. 
> Finally I tried a forward only zone for airindia.in to a server in my 
> environment which does not use RPZ. But this doesn’t work too. 
>
> Any ideas how I could shade or overwrite the content of RPZ ? 
I would look at the mail server configuration. It might be possible to
add a positive list in front of the spamhaus lookup.
>
> I am using BIND 9.11.2
>
>
> Kind regards 
> Hans
>
> — 
>
>
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

"MALE BOVINE MANURE!!!" 

___
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: NOAA.GOV domain not working

[Sten Carlsen]

aa.gov.
> dig  www.nhc.noaa.gov @ns-nw.noaa.gov.
>
> and:
> dig  -4 www.nhc.noaa.gov @ns-e.noaa.gov.
> dig  -4 www.nhc.noaa.gov @ns-mw.noaa.gov.
> dig  -4 www.nhc.noaa.gov @ns-nw.noaa.gov.
>
> and
> dig  +tcp www.nhc.noaa.gov @ns-e.noaa.gov.
> dig  +tcp www.nhc.noaa.gov @ns-mw.noaa.gov.
> dig  +tcp www.nhc.noaa.gov @ns-nw.noaa.gov.
>
>
> and also:
> traceroute ns-e.noaa.gov.
> traceroute ns-mw.noaa.gov.
> traceroute ns-nw.noaa.gov.
>
>
> What address range are you coming from? It sounds like you cannot reach the 
> noaa.gov nameservers (or they cannot reach you!)
>
> W
>
>>
>> -Original Message-
>> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf 
>> Of John Miller
>> Sent: September 18, 2017 11:03 AM
>> Cc: bind-users@lists.isc.org
>> Subject: Re: NOAA.GOV domain not working
>>
>> Hi Ricky,
>>
>> Try running a "dig +trace www.nhc.noaa.gov," then query each record in the 
>> chain and see which one's slow to respond.  I don't see anything crazy in 
>> your named.conf.  Something you didn't mention: does clearing cache make a 
>> difference?
>>
>> John
>> --
>> John Miller
>> Systems Engineer
>> Brandeis University
>> johnm...@brandeis.edu
>>
>>
>> On Mon, Sep 18, 2017 at 8:03 AM, Levesque, Ricky (SNB) 
>>  wrote:
>>> Good day,
>>>
>>> I’ve been having an interesting issue with BIND and wondering if 
>>> anyone has had this before or knows how to fix it.
>>>
>>>
>>>
>>> The issue is,
>>>
>>> I have 2 recursive/caching DNS servers running BIND 
>>> 9.9.4-RedHat-9.9.4-51.el7, which are slow to query for this 
>>> particular domain.
>>>
>>> Noaa.gov (as well as its sub domains. Specifically – www.nhc.noaa.gov 
>>> )
>>>
>>> By slow I mean, it takes approximately 3500ms to query while most 
>>> other domains take less than 100ms to query.
>>>
>>> What’s worst, the domains (noaa.gov) becomes unqueriable after a few 
>>> hours or a day and I need to clear the DNS servers cache to allow it 
>>> to work again.
>>>
>>>
>>>
>>> The domains have very very low TTL’s (30s) and use DNSsec
>>>
>>>
>>>
>>> Error:
>>>
>>> ##dig www.nhc.noaa.gov
>>>
>>> ;; Got answer:
>>>
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52364
>>>
>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 12, AUTHORITY: 3, ADDITIONAL: 7
>>>
>>>
>>>
>>> ;; OPT PSEUDOSECTION:
>>>
>>> ; EDNS: version: 0, flags:; udp: 4096
>>>
>>> ;; QUESTION SECTION:
>>>
>>> ;www.nhc.noaa.gov.  IN  A
>>>
>>>
>>>
>>>
>>>
>>> Fixes I have attempted so far:
>>>
>>> Reboot servers (2 centos servers running on vmware)
>>>
>>> Update system
>>>
>>> Try a default config file
>>>
>>> Updated vmware tools
>>>
>>> Clear DNS cache (temporary fix)
>>>
>>> Checked firewall for abnormal data
>>>
>>> Updated root hints
>>>
>>>
>>>
>>> Config:
>>>
>>>
>>>
>>> acl internal {
>>>
>>> *removed*;
>>>
>>>localhost;
>>>
>>> };
>>>
>>>
>>>
>>> options {
>>>
>>> listen-on port 53 { *removed*;
>>>
>>> 127.0.0.1;
>>>
>>> ;
>>>
>>>};
>>>
>>> listen-on-v6 port 53 { none;
>>>
>>>#::1;
>>>
>>>   };
>>>
>>> directory   "/var/named";
>>>
>>> dump-file   "/var/named/data/cache_dump.db";
>>>
>>> statistics-file "/var/named/data/named_stats.txt";
>>>
>>> memstatistics-file "/var/named/data/named_mem_stats.txt";
>>>
>>>
>>>
>>> dnssec-enable no;
>>>
>>> dnssec-validation no;
>>>
>>> dnssec-lookaside auto;
>>>
>>>
>>>
>>> // Conform to RFC1035
>>>

Re: Different forwarder for certain response ip (result ip )

[Sten Carlsen]

On 16-09-2017 16.01, Omid Kosari via bind-users wrote:
> 2nd scenario is mine . Upstream manipulated everything on 53 tcp/udp . Even
> if i query a non-existent dns-server it returns result ;)
>
> C:\WINDOWS\system32>nslookup newsroom.fb.com 8.8.8.254
> Server:  UnKnown
> Address:  8.8.8.254
>
> Non-authoritative answer:
> Name:newsroom.fb.com
> Addresses:  1.2.3.4
>   1.2.3.4
>
> Note:1.2.3.4 is not what they really return . I've changed it for privacy .
> But it is one fixed ip address which returns in case of manipulation occurs
> .
>
>
>
> Sten Carlsen wrote
>> In case 2) something like your solution is needed. The use of port 443
>> is an obvious idea, however DNS uses UDP and HTTPS uses TCP. Your ISP
>> appears to be paranoid enough to block also port 443 UDP, so that might
>> be one issue.
> FYI https://en.wikipedia.org/wiki/QUIC uses udp 443 . Also i try to reduce
> the queries over 443 with the way i asked in my first post .
The fact that QUIC exists does not necessarily mean that the port is
open for you, it is still experimental.

As Harald mentioned DNS will fall back to TCP but the time to do that
may provide too long delay for your connection to work.

I guess you will have to investigate exactly what prevents your
connection, Wireshark is a good tool.

I have no other ideas to offer.
>
> Thanks
>
>
>
>
>
>
> --
> Sent from: http://bind-users-forum.2342410.n4.nabble.com/
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

"MALE BOVINE MANURE!!!" 


___
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: Different forwarder for certain response ip (result ip )

[Sten Carlsen]

On 16-09-2017 14.56, Matus UHLAR - fantomas wrote:
> On 16.09.17 04:19, Omid Kosari via bind-users wrote:
>> Actually my situation is a bit strange . But as explanation i can say
>> that
>> our upstream provider do dns manipulation on normal ports 53 tcp/udp
>> (please
>> don't ask why). We may not use vpn or tunnels . The only way is using
>> alternate ports as forwarders.
>
> that explains why you want forwarders on port 443.
>
> But it doesn't explain why you forward to google. I still think it's
> useless, unless your ISP blocks port 53 to public servers.
>
This is still not entirely clear to me. I see two possible scenarios,
please indicate which is closer to your situation:

1 - your ISP provides their own DNS servers as part of the service and
indicate those via DHCP. These servers give mangled replies.

2 - ALL traffic on port 53 is mangled in e.g. a router/switch along the
path according to some rule imposed by the ISP.

In case 1) which is common, I have used a DNS server locally without
forwarding with perfect results. It will never ask the ISP's server.

In case 2) something like your solution is needed. The use of port 443
is an obvious idea, however DNS uses UDP and HTTPS uses TCP. Your ISP
appears to be paranoid enough to block also port 443 UDP, so that might
be one issue.

Would there be any UDP ports open, like streaming services or games? If
so they may provide a possibility.

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

"MALE BOVINE MANURE!!!" 


___
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: designing the DNS from the scratch

[Sten Carlsen]

On 09/07/2017 20:51, Reindl Harald wrote:
>
> Am 09.07.2017 um 20:41 schrieb Warren Kumari:
>> On Sun, Jul 9, 2017 at 1:59 PM John W. Blue > <mailto:john.b...@rrcic.com>> wrote:
>>
>> Abdulhadi,
>>
>> __ __
>>
>> Honestly, I think that a design spec of getting DNS responses in 3ms
>> across the board is unrealistic.  My initial MX query for litc.ly
>> <http://litc.ly> took 367ms:
>>
>> __
>>
>>
>> Like many poorly written / articulated SLAs, the devil is in the
>> details.
>>
>> I could happily read this as the server / service must respond within
>> 3ms. The OP mentioned VIP, so this could be for auth DNS, in which
>> case responding to a query within 3ms is trivial...
>
> no it is not - at least not if there is an internet connection between
> customer and dns server since you hardly get even a 3 ms ping time
>
> on the server itself yes
>
> frankly even in a local network you end with ;; Query time: 1 msec for
> a "dig NS" and that a nameserver can respond on localhost below that
> is completly worthless
>
Thinking about this, the only solution that seems remotely possible is
to let the customer have the DNS server on his premises. That way all
queries that come from cache could be fast enough. Those it needs to
resolve from the Internet, will take longer time.

The next question is who shall maintain that server on his premises? All
sorts of questions come to mind.

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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: restarting bind fixes some resolution issues

[Sten Carlsen]

> On 9 Jul 2017, at 17:04, Matus UHLAR - fantomas  wrote:
> 
> On 09.07.17 14:36, Dario Corti wrote:
>> Hi, I occasionally have issues updating some packages, with the package 
>> manager saying that it cannot resolve deb.nodesource.com. I'm using 
>> 1:9.9.5.dfsg-9+deb8u11 and I verified that a bind restart fixes the problem 
>> every time (even if technically the domain CAN be resolved also before the 
>> restart).
> 
> https://mxtoolbox.com/SuperTool.aspx?action=dns%3adeb.nodesource.com&run=toolpage
> http://dnscheck.pingdom.com/?domain=deb.nodesource.com
> 
> both checkers report errors...
> 
>> I issued a dig before and after the restart and it does report something 
>> different, but I'm unable to understand it, so I wonder if anyone can 
>> suggest a possible reason for this.
>> 
>> Before: https://pastebin.com/7qZUmPKA
>> After: https://pastebin.com/U0DUhE20
> 
> i don't see any difference here, both cases report deb.nodesource.com to be
> a CNAME to d2buw04m05mirl.cloudfront.net - maybe you should look up that one
> next time problem appears.
The sequence of answers is different, this is not a difference as such, DNS 
does not normally use a specific sequence in the answers.

You should compare the answers so you verify that all the same records are 
present, sequence is of no meaning.
> 
> -- 
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> I intend to live forever - so far so good. 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
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 failing to start on new 9.9.4 server

[Sten Carlsen]

On 09-02-2017 15.31, Ray Bellis wrote:
> On 09/02/2017 14:28, Robert Moskowitz wrote:
>> I am migrating to Centos7 from Centos6.  Going from Bind 9.8.2 to 9.9.4,
>> I am building this on a new server.  I currently do not have DNSSEC
>> enabled, and not enabling it for the initial migration work.
>>
>> I have looked over changes in named.conf and believe I have made the
>> necessary changes.  My named.conf is  loading as are the zone files. 
>> This is what 'systemctl -l status named' shows:
> I'd suggest that you try starting named manually with the '-g' flag so
> that it sends all output to stderr without forking.
>
> This should hopefully reveal why it's failing to start.
I did a similar move, my problem was that the ownership and access
properties were not ok.
>
> Ray
>
>
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

"MALE BOVINE MANURE!!!" 

___
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: dnssec key events too often?

[Sten Carlsen]

Right, thank you so much. I now will look at logging to reduce the
clutter in the syslog since this does not call for any attention on my side.

Thanks.


On 27/01/2017 20:53, Mark Andrews wrote:
> In message , Sten Carlsen 
> writes:
>> Hi all
>>
>> I have recently started using dnssec on my authoritative zones. I have
>> bind 9.9.4 (Centos7).
>>
>> I see for each zone:
>>
>> ...
>>
>> general: info: zone s-carlsen.dk/IN/external (signed): next key event: 
>> 26-Jan-2017 02:03:40.860: 1 Time
>> (s)
>> general: info: zone s-carlsen.dk/IN/external (signed): next key event: 
>> 26-Jan-2017 03:03:40.860: 1 Time
>> (s)
>> general: info: zone s-carlsen.dk/IN/external (signed): next key event: 
>> 26-Jan-2017 04:03:40.860: 1 Time
>> (s)
>> general: info: zone s-carlsen.dk/IN/external (signed): next key event: 
>> 26-Jan-2017 05:03:40.861: 1 Time
>> (s)
>>
>> ...
>>
>> This happens every hour, I think this is probably way too often? Access to 
>> the name in question is probably
>>  a few times pr. day.
>>
>> The only reasonable conclusion is that I have done something stupid or not 
>> done the right thing.
>>
>> Question: what stupid thing might I have done (how to fix?)  or what did
>> I miss to do?
> Nothing.  You have key management in automatic mode and named needs
> to periodically check if you have created new keys or changed the
> timers of existing keys or removed a old key.
>  
> Mark
>
>> -- 
>> Best regards
>>
>> Sten Carlsen
>>
>> No improvements come from shouting:
>>
>>"MALE BOVINE MANURE!!!" 
>>
>>

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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

dnssec key events too often?

[Sten Carlsen]

Hi all

I have recently started using dnssec on my authoritative zones. I have
bind 9.9.4 (Centos7).

I see for each zone:

...

general: info: zone s-carlsen.dk/IN/external (signed): next key event: 
26-Jan-2017 02:03:40.860: 1 Time(s)
general: info: zone s-carlsen.dk/IN/external (signed): next key event: 
26-Jan-2017 03:03:40.860: 1 Time(s)
general: info: zone s-carlsen.dk/IN/external (signed): next key event: 
26-Jan-2017 04:03:40.860: 1 Time(s)
general: info: zone s-carlsen.dk/IN/external (signed): next key event: 
26-Jan-2017 05:03:40.861: 1 Time(s)

...

This happens every hour, I think this is probably way too often? Access to the 
name in question is probably a few times pr. day.

The only reasonable conclusion is that I have done something stupid or not done 
the right thing.

Question: what stupid thing might I have done (how to fix?)  or what did
I miss to do?

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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: view problem

[Sten Carlsen]

Please be aware that only one view is visible for any client. You have acl1 in 
both views indicating that you assume a host in acl1 can get info from both 
views - this is not possible. The list is searched from the top of the file and 
the first match, only the first,  will be the DNS service available to the 
client.

-- Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"



-- Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"


-- Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
> On 18 Oct 2016, at 10.28, RAM MOHAN, Hari Ganesh  
> wrote:
> 
> View concept works in order, as you have internal_lan view first, acl1 users 
> are falling to this view and not able to find vpn_zone.
> 
> You may try swapping order,
> 
> // vpn
> view "vpn" {
> match-clients { acl1; };
> 
> zone "vpn_zone" {
> type master;
> file "/etc/bind/zones/vpn.db";
> };
> 
> };
> 
> // zone1
> view "internal_lan" {
> match-clients { acl1; acl2; };
> include "/etc/bind/named.conf.default-zones";
> 
> zone "zone1" {
> type master;
> file "/etc/bind/zones/zone1.db";
> };
> 
> Thanks & Regards,
> 
> Hari Ganesh Ram Mohan
> 
> 
> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Pol 
> Hallen
> Sent: Tuesday, October 18, 2016 1:21 PM
> To: bind-users@lists.isc.org
> Subject: view problem
> 
> Hi all :-)
> 
> I've two zones: zone1 is an internal zone and another zone: vpn.
> 
> I need that acl1 can "see" internal vpn zone, the problem is that acl1 "see" 
> vpn zone as external zone because this zone is a FQDN, while should see vpn 
> as vpn.db.
> 
> 192.168.1.0/24 are clients with also openvpn clients, while
> 192.168.2.0/24 are not vpn clients.
> 
> sorry but I can't simplify :-/
> 
> acl1 {192.168.1.0/24; };
> acl2 {192.168.2.0/24; };
> 
> // zone1
> view "internal_lan" {
> match-clients { acl1; acl2; };
> include "/etc/bind/named.conf.default-zones";
> 
> zone "zone1" {
> type master;
> file "/etc/bind/zones/zone1.db";
> };
> 
> // vpn
> view "vpn" {
> match-clients { acl1; };
> 
> zone "vpn_zone" {
> type master;
> file "/etc/bind/zones/vpn.db";
> };
> 
> };
> 
> 
> Pol
> ___
> 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
___
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: adding zone forwards without restart

[Sten Carlsen]

I assume you did increase the serial, if not this is what I would expect
to happen.


On 21/09/16 10:53, Tony Finch wrote:
> Frank Even  wrote:
>
>> Is there a way to add forwarders for specific zones without a restart?
>> Everything I've read seems to indicate an "rndc reconfig" or an "rndc
>> reload" should take care of this, but they do not.  I add forwarders to
>> "named.conf" and neither will load the new forwarded zone until I do a full
>> daemon restart.
> I bet you are running chrooted, and you are editing named.conf outside the
> chroot, and the restart script copies it into the chroot.
>
> You need to find a way to run the copy independently of restarting the
> daemon.
>
> Maybe there is something like `systemctl reload named.service` which does
> a graceful reload ... but, looking at the srpm I think you might have to
> run `/usr/libexec/setup-named-chroot.sh /var/named/chroot on`. OBVIOUSLY.
>
> Tony.

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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: Postgresql 8.4 optimize heavy load

[Sten Carlsen]

You may want to explore the explain command and think about which indexes are 
missing.

-- Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"



-- Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"


-- Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
> On 17 Sep 2016, at 23.23, Charles Elliott  wrote:
> 
> All these titles are available on Amazon.com, and most are inexpensive if
> you buy them used:
> 
> Beginning PHP and PostgreSQL 8: From Novice to Professional (Beginning: From
> Novice to Professional)
> PostgreSQL 8 for Windows (Database Professional's Library)
> Beginning PostgreSQL 8Sep 25, 2006
> PostgreSQL 8 for Windows (Database (text only) by R.Blum2007
> Hexa Marathon Guide: PostgreSQL CE 8 Silver: MCQ on PGCES-02Aug 18, 2015
> (???)
> Beginning PHP and PostgreSQL 8: From Novice to Professional (Beginning: From
> Novice to Professional) 1st Edition...Mar 2, 2006
> PostgreSQL 8.4 Official Documentation - Volume I. The SQL Language by The
> PostgreSQL Global Development Group
> PostgreSQL 8.4 Official Documentation - Volume II. Server Administration by
> The PostgreSQL Global Development
> PostgreSQL (2nd Edition) by Korry Douglas (2005-08-05) (Not cheap)
> PostgreSQL Replication by Zoltan (Also expensive)
> [(PostgreSQL 8 for Windows )] [Author: Richard Blum] [Mar-2007]
> 
> If Amazon (books) are searched with 'PostgreSQL High Performance' (w/o '
> marks), a page of interesting titles result, but all of them relate to
> PostgreSQL 9.  You could look at one from Amazon.com or at a local
> (UNIVERSITY) library to see if any of it worked in PostgreSQL 8.4.
> 
> Charles Elliott
> 
> 
> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Job
> Sent: Saturday, September 17, 2016 10:02 AM
> To: bind-users@lists.isc.org
> Subject: Postgresql 8.4 optimize heavy load
> 
> Hello,
> 
> i would please like to have some suggestions to optimize Postgres 8.4 for a
> very heavy number of select (with join) queries.
> The queries read data, very rarely they write.
> 
> Thank you!
> Francesco
> ___
> 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
___
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: writeable file 'domain.com': already in use

[Sten Carlsen]

On 16/06/2016 15:57, Alan Clegg wrote:
> Change where it says:  file "foo"; so that you don't have two zones with
> "foo".
You might keep the names but put them in different folders. That would
eventually be different filenames.
>
> AlanC
>
> On 6/16/16, 4:16 AM, "Daniel Dawalibi"  on behalf of daniel.dawal...@idm.net.lb> wrote:
>
>> Do you have the correct syntax to be adjusted on both views?
>>
>> -Original Message-
>> From: bind-users-boun...@lists.isc.org
>> [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Ray Bellis
>> Sent: 16 June, 2016 11:04 AM
>> To: bind-users@lists.isc.org
>> Subject: Re: writeable file 'domain.com': already in use
>>
>> On 16/06/2016 07:53, Daniel Dawalibi wrote:
>>
>>> We are upgrading our DNS authoritative BIND version 9.10.4-P1 but we
>>> are facing "writing errors" on the slave zone files that are
>>> transferred from other Master DNS servers.
>>>
>>> Our configuration consists of two views  (local and inter) and the
>>> domain is configured in both views sections.
>>>
>>> The problem was solved after removing the zone from one VIEW but is
>>> there any workaround for this issue without removing the zone from the
>>> view section (either Local or Inter)?
>> BIND 9.10.4 doesn't allow you to use the same filename for the same zone
>> in
>> different views (since the content should be different).
>>
>> Simply change the "file" directive in one of the views and you should be
>> fine.
>>
>> Ray
>>
>>
>> ___
>> 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
>
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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 .ro domain

[Sten Carlsen]

 <http://sec-dns-b.rotld.ro>.
> ro. 172800  IN  NS  primary.rotld.ro
> <http://primary.rotld.ro>.
> ro. 172800  IN  NS  sns-pb.isc.org
> <http://sns-pb.isc.org>.
> ro. 86400   IN  NSECrocher. NS RRSIG NSEC
> ro. 86400   IN  RRSIG   NSEC 8 1 86400
> 2016022505 2016021504 54549 .
> LKnWJRnQdMQ67X7PVrChhY0CuT+A0hpLv1Yh2zOrdglKGGYFQGP+sO24
> A31Uj9g8SAKroH1XlJD000bhm+jTkd9Suf1uefDC8y3hV1HlmwkAzoIE
> cPQ1rKj66R0kVrEfsSYoXK7pau/mq583n7Hw24H6SSuWivQNbHUD+FLt 9rQ=
> ;; Received 624 bytes from 192.33.4.12#53(c.root-servers.net
> <http://c.root-servers.net>) in 7 ms
>
> ebsromania.ro <http://ebsromania.ro>.  86400   IN  NS 
> ns02.ebsromania.ro <http://ns02.ebsromania.ro>.
> ebsromania.ro <http://ebsromania.ro>.  86400   IN  NS 
> ns01.ebsromania.ro <http://ns01.ebsromania.ro>.
> ;; Received 112 bytes from 193.230.31.230#53(sec-dns-b.rotld.ro
> <http://sec-dns-b.rotld.ro>) in 20151 ms
>
> ;; connection timed out; no servers could be reached
>
> The server running the dig is in the US while a server in NL produces
> this:
>
> ; <<>> DiG 9.9.5-P1 <<>> @127.0.0.1 <http://127.0.0.1>
> ns01.ebsromania.ro <http://ns01.ebsromania.ro>. +trace
> ; (1 server found)
> ;; global options: +cmd
> .   92407   IN  NS  m.root-servers.net
> <http://m.root-servers.net>.
> .   92407   IN  NS  b.root-servers.net
> <http://b.root-servers.net>.
> .   92407   IN  NS  c.root-servers.net
> <http://c.root-servers.net>.
> .   92407   IN  NS  g.root-servers.net
> <http://g.root-servers.net>.
> .   92407   IN  NS  h.root-servers.net
> <http://h.root-servers.net>.
> .   92407   IN  NS  j.root-servers.net
> <http://j.root-servers.net>.
> .   92407   IN  NS  l.root-servers.net
> <http://l.root-servers.net>.
> .   92407   IN  NS  a.root-servers.net
> <http://a.root-servers.net>.
> .   92407   IN  NS  d.root-servers.net
> <http://d.root-servers.net>.
> .   92407   IN  NS  e.root-servers.net
> <http://e.root-servers.net>.
> .   92407   IN  NS  i.root-servers.net
> <http://i.root-servers.net>.
> .   92407   IN  NS  f.root-servers.net
> <http://f.root-servers.net>.
> .   92407   IN  NS  k.root-servers.net
> <http://k.root-servers.net>.
> .   518398  IN  RRSIG   NS 8 0 518400
> 2016022505 2016021504 54549 .
> Sh3DsQaxrP1CC31ZxY3fzM2QHKGdZ0sKb3DxI1G974dvdxLubBK7vG5N
> 4A+Cshd8ci/zQmJw6ASWeYL5uUFrS4szqr05FMS8oNLLntbVVWoQTPld
> X+vfmAZo8wQPrVqBHwxJyFucJrWFZN4rWUdhvxrbkoMbYpeqDHGCDioR oow=
> ;; Received 397 bytes from 127.0.0.1#53(127.0.0.1) in 1124 ms
>
> ro. 172800  IN  NS  dns-at.rotld.ro
> <http://dns-at.rotld.ro>.
> ro. 172800  IN  NS  dns-ro.denic.de
> <http://dns-ro.denic.de>.
> ro. 172800  IN  NS  sns-pb.isc.org
> <http://sns-pb.isc.org>.
> ro. 172800  IN  NS  primary.rotld.ro
> <http://primary.rotld.ro>.
> ro. 172800  IN  NS  sec-dns-a.rotld.ro
> <http://sec-dns-a.rotld.ro>.
> ro. 172800  IN  NS  sec-dns-b.rotld.ro
> <http://sec-dns-b.rotld.ro>.
> ro. 86400   IN  NSECrocher. NS RRSIG NSEC
> ro. 86400   IN  RRSIG   NSEC 8 1 86400
> 2016022505 2016021504 54549 .
> LKnWJRnQdMQ67X7PVrChhY0CuT+A0hpLv1Yh2zOrdglKGGYFQGP+sO24
> A31Uj9g8SAKroH1XlJD000bhm+jTkd9Suf1uefDC8y3hV1HlmwkAzoIE
> cPQ1rKj66R0kVrEfsSYoXK7pau/mq583n7Hw24H6SSuWivQNbHUD+FLt 9rQ=
> ;; Received 624 bytes from 198.97.190.53#53(h.root-servers.net
> <http://h.root-servers.net>) in 436 ms
>
> ebsromania.ro <http://ebsromania.ro>.  86400   IN  NS 
> ns02.ebsromania.ro <http://ns02.ebsromania.ro>.
> ebsromania.ro <http://ebsromania.ro>.  86400   IN  NS 
> ns01.ebsromania.ro <http://ns01.ebsromania.ro>.
> ;; Received 112 bytes from 192.162.16.18#53(primary.rotld.ro
> <http://primary.rotld.ro>) in 147 ms
>
> ns01.ebsromania.ro <http://ns01.ebsromania.ro>. 864

Re: A tale of two nameservers - resolution problems

[Sten Carlsen]

On 01/09/15 17:46, Robert Moskowitz wrote:
>
> There will be a lot of arm IoT boxes in the next few years needing
> their time on boot.  Of course booting will not be that frequent, but
> it will interesting to see how it plays out.   And check devices like
> the esp8266, as $6 IoT device.  It also gets its time once connected.
This will be very interesting when all those boxes have fixed addresses
in IPv4 and the environment goes to IPv6. Or those addresses disappear
for whatever reason.
Obsolete devices?
>
>> so you just need to make sure the correct order
>>
>> * ntpdate xx.xx.xx.xx
>> * start ntpd
>> * start named
>
> I will be looking more into this.  Obvious when you get ones nose
> dragged into time wrong on boot.  This is actually a broader problem
> on arm SoC booting.  Your logs all have the wrong time for the boot
> messages until there is a network to get time.  I have some ideas for
> a process that will set time a boot to the time of the last poweroff. 
> at least that is 'close enough' for starters.
>
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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: Setup our OWN DNS Server

[Sten Carlsen]

You might be interested in my setup:

I have 2 views, one accessible from inside my network and one from the
outside.

- Inside view is recursive as well as authoritative for my internal
hosts. Everything is in the 192.168.x.x range. This view is dynamically
updated by the DHCP server.

- Outside view is only authoritative for my public names. This view has
fewer entries and serves public IPs. It functions as a stealth master
for 5 public servers.


This setup provides full flexibility and allows me to use the same names
for the internal and the external IPs of my servers.

It is also faster in normal use in terms of resolution speed.


-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!"
___
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: can't-resolve

[Sten Carlsen]

If there is no firewall, then what about fixed routing that allows one IP 
access but not the other?

Your focus should be to find the difference between the two IPs in the network. 
If the same configuration works on one IP but not on the other, then the 
configuration should not be the main point of interest.

My 0.02$

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

  "MALE BOVINE MANURE!!!"

> On 28 Dec 2014, at 09:09, Ejaz  wrote:
> 
> Thanks for the suggestion 
> 
> I am sure No firewall at all.  Also See I now I have reassigned  the my
> previous IP which is 212.119.64.12, after that everything is fine. It
> wouldn't have worked with this IP if there is firewall on the box??
> 
> Regards,
> Mohammed Ejaz
> CYBERIAR SAUDI ARABIA
> P.O.Box 301079, Riyadh 11372, Saudi Arabia
> Tel: +966 11 464 7114 Ext. 140
> Fax: +966 11 465 4735
> 
> -Original Message-
> From: bind-users-boun...@lists.isc.org
> [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Warren Kumari
> Sent: Saturday, December 27, 2014 2:27 AM
> To: Barry Margolin
> Cc: comp-protocols-dns-b...@isc.org
> Subject: Re: can't-resolve
> 
> Also, from querying from the outside (with TCP):
> 
> ~# dig +tcp www.auth-servers.net   @212.119.64.228
> ; <<>> DiG 9.10.1-P1 <<>> +tcp www.auth-servers.net @212.119.64.228 ;;
> global options: +cmd ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20716 ;; flags: qr rd
> ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;www.auth-servers.net.  IN  A
> 
> ;; Query time: 8260 msec
> ;; SERVER: 212.119.64.228#53(212.119.64.228) ;; WHEN: Fri Dec 26 18:18:30
> EST 2014 ;; MSG SIZE  rcvd: 49
> 
> Then trying the same query a few seconds later:
> dig +tcp www.auth-servers.net   @212.119.64.228
> 
> ; <<>> DiG 9.10.1-P1 <<>> +tcp www.auth-servers.net @212.119.64.228 ;;
> global options: +cmd ;; connection timed out; no servers could be reached
> 
> This really looks like a firewall -- perhaps there is some firewall software
> on the box itself?
> 
> W
> 
> 
>> On Fri, Dec 26, 2014 at 6:17 PM, Warren Kumari  wrote:
>> What OS is this machine running?
>> 
>> Interestingly enough, it is unpingable, and a quick nmap fingerprints it
> as:
>> Running: Sun Solaris 8
>> OS CPE: cpe:/o:sun:sunos:5.8
>> OS details: Sun Solaris 8 (SPARC)
>> 
>> nmap could only find one open port (TCP 53 :-)) and so its 
>> fingerprinting is unreliable, but it *does* look like you are behind a 
>> firewall type devices.
>> It is unusual for machines themselves to not respond to pings.
>> 
>> fpdns says:
>> fingerprint (212.119.64.228, 212.119.64.228): ISC BIND 9.2.3rc1 --
>> 9.6.1-P1 [recursion enabled]
>> 
>> 
>> 
>> On Fri, Dec 26, 2014 at 5:55 PM, Barry Margolin 
> wrote:
>>> In article ,
>>> "Ejaz"  wrote:
>>> 
>>>> I am sure sir there is no firewall on  in the server you can make 
>>>> sure by telnet to the port 53 of this IP 212.119.64.228
>>> 
>>> That doesn't mean anything. The firewall may be blocking OUTGOING 
>>> packets to port 53, or they're blocking the returning replies (which 
>>> go to an ephemeral port).
>>> 
>>>> 
>>>> 
>>>> Regards,
>>>> Mohammed Ejaz
>>>> CYBERIAR SAUDI ARABIA
>>>> P.O.Box 301079, Riyadh 11372, Saudi Arabia
>>>> Tel: +966 11 464 7114 Ext. 140
>>>> Fax: +966 11 465 4735
>>>> 
>>>> -Original Message-
>>>> From: bind-users-boun...@lists.isc.org 
>>>> [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Matus UHLAR - 
>>>> fantomas
>>>> Sent: Friday, December 26, 2014 7:35 PM
>>>> To: bind-users@lists.isc.org
>>>> Subject: Re: can't-resolve
>>>> 
>>>>> On 26.12.14 19:21, Ejaz wrote:
>>>>> When  run "dig a yahoo.com @212.119.64.228 below is the ouput.
>>>>> 
>>>>> yahoo.com. (38)
>>>>> 17:39:41.363532 IP 212.119.64.228.37891 > 212.119.64.228.domain: 34168+
>>>>> [1au] A?   yahoo.com. (38)
>>>>> 17:39:42.246993 IP 212.119.64.228.53702 > 192.5.5.241.domain: 58238 
>>>>> [1au]
>>>> A?
>>>>> yah  oo.com. (38)
>>>>> 17:39:42.247012 IP 212.119.64.228.

Re: Digging to the final IP

[Sten Carlsen]

Would "host" be closer to what you want?


-- 
Best regards

Sten Carlsen

No improvements come from shouting:

  "MALE BOVINE MANURE!!!"

> On 19 Oct 2014, at 08:05, Karl Auer  wrote:
> 
>> On Sun, 2014-10-19 at 00:26 -0500, Frank Bulk wrote:
>> Is there a dig option that will list out the final (IPs) or query result??
>> By default, even with +short, it can list intermediate CNAME(s) and not what
>> IP(s) that CNAME may have.
> 
> Not great, but might be enough to be helpful:
> 
>   dig +nonssearch $1 | egrep -i "STATUS|^$1"
> 
> Regards, K.
> 
> -- 
> ~~~
> Karl Auer (ka...@biplane.com.au)
> http://www.biplane.com.au/kauer
> http://twitter.com/kauer389
> 
> GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882
> Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
> 
> 
> ___
> 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: test bind before moving to production

[Sten Carlsen]

On 03/07/14 16:39, Jeremy C. Reed wrote:
> On Thu, 3 Jul 2014, brian wrote:
> 
>> I'm new to bind. I want to be able to test the dns server on my local
>> machine before launching it by putting the domain names (ie example.com) in
>> my browser and browsing the site.
>>
>>
>> Both the dev and production machines are CentOS. I assume I'll need to edit
>> the host file to redirect to the local dns. But with this method I'm not
>> sure how it will resolve multiple domains (i.e. example.com and
>> example2.com).
> 
> The host file (/etc/hosts I assume) won't help. You can use 
> /etc/resolv.conf and have nameserver line point to your localhost for 
> testing.
> 
> Or use dig with the @ argument to set the address of the nameserver to 
> use. For example, "dig @127.0.0.1 www.example.com". Then also try that 
> from outside systems to using the @ with the network interface's 
> address.
And note that the name server will not be publicly used until it is
published through the whole DNS chain. That means there is no reason you
could not put everything in place even public facing servers - nobody
will use them until referenced properly.

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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!"
___
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: Promoting a slave to master gives syntax error

[Sten Carlsen]

gt;>
>>> Apparently the systems expects to see a zone file in text format but
>>> because it's in binary it fails. I also tested it with:
>>>
>>> # named-checkzone 24.3.10.in-addr.arpa
>>> /var/cache/bind/db.24.3.10.in-addr.arp
>>> ... Output omitted ...
>>> dns_master_load: /var/cache/bind/db.24.3.10.in-addr.arpa:16: syntax
>>> error
>>> dns_master_load: /var/cache/bind/db.24.3.10.in-addr.arpa:16: syntax
>>> error
>>> dns_master_load: /var/cache/bind/db.24.3.10.in-addr.arpa:16: syntax
>>> error
>>> dns_master_load: /var/cache/bind/db.24.3.10.in-addr.arpa:16: syntax
>>> error
>>> dns_master_load: /var/cache/bind/db.24.3.10.in-addr.arpa:16: syntax
>>> error
>>> dns_master_load: /var/cache/bind/db.24.3.10.in-addr.arpa:16: syntax
>>> error
>>> dns_master_load: /var/cache/bind/db.24.3.10.in-addr.arpa:17: syntax
>>> error
>>> /var/cache/bind/db.24.3.10.in-addr.arpa: file does not end with newline
>>> zone 24.3.10.in-addr.arpa/IN: loading from master file
>>> /var/cache/bind/db.24.3
>>> .10.in-addr.arpa failed: syntax error
>>> zone 24.3.10.in-addr.arpa/IN: not loaded due to errors.
>>>
>>> I know I must be doing something fundamentally wrong here but I
>>> couldn't
>>> find a guide how to do this properly. Any ideas?
>>>
>>> I am using bind version 9.9.5-3-Ubuntu ( the stock binary that comes
>>> with Ubuntu 14.04 64 bit) and the compiled parameters are:
>>> named[7817]: built with '--prefix=/usr' '--mandir=/usr/share/man'
>>> '--infodir=/usr/share/info' '--sysconfdir=/etc/bind'
>>> '--localstatedir=/var' '--enable-threads' '--enable-largefile'
>>> '--with-libtool' '--enable-shared' '--enable-static'
>>> '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld'
>>> '--with-geoip=/usr' '--with-atf=no' '--enable-ipv6' '--enable-rrl'
>>> '--enable-filter-' 'CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2'
>>>
>>> ___
>>> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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 doesn't work when I set allow-update statement

[Sten Carlsen]

On 29/04/14 14.50, Jeronimo L. Cabral wrote:
> Dear, thanks for your help.
>
> Please the last question: can I dynamically update a zone and -when
> necessary- make a freeze, manually add/delete records, and after that
> make a thaw to continue with the dynamic update In other words, a
> mix betwwen dynamic and manually update.
>
I do this, not often, works as expected. Do be careful not to interfere
with the DHCP administered entries.
> Thanks again,
>
> JeLo
>
>
> On Fri, Apr 25, 2014 at 6:04 PM, Evan Hunt  <mailto:e...@isc.org>> wrote:
>
> On Fri, Apr 25, 2014 at 05:29:30PM -0300, Jeronimo L. Cabral wrote:
> > But the master zone is not refreshed until I execute "service bind9
> > restart" ("service bind9 reload" doesn't refresh the master zone).
>
> The zone has been updated, but the changes are stored in a journal
> file
> ("zonefile.jnl").  You can look at the contents of the journal file
> with "named-journalprint ".
>
> If you want to dump the current version of the zone to disk so you
> can look at the whole thing, use "rndc sync ".
>
> (That's assuming this is a fairly recent BIND.  If it doesn't support
> sync, use "rndc freeze ; rndc thaw ".)
>
> --
> Evan Hunt -- e...@isc.org <mailto:e...@isc.org>
> Internet Systems Consortium, Inc.
>
>
>
>
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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 vs flood

[Sten Carlsen]

Doesn't this look like a DDOS attack on the spoofed origin of the queries?


On 27/02/14 16:18, Ben Croswell wrote:
> I guess I am missing why anyone on the internet should be able to open
> queries against your caching resolver. 
> 
> Why would in bound queries be allowed to servers that are for your
> people to get out?
> 
> On Feb 27, 2014 10:13 AM, "Ivo" mailto:i...@nic.lv>> wrote:
> 
> Hi Dmitry,
> 
> We observed that similar requests are landing on our cache resolver
> mostly from various home routers running dns server as open resolver
> and that also masquerades the original request source.
> We have a collection of ~60 domains involved and most of them are
> related to China. The problem is that attacker selects few domains
> and generates queries with random hostnames which therefore are not
> in the cache and server has to perform recursion for each query. So
> each query will consume one udp or tcp socket for at least 10
> seconds because remote DNS server is responding slowly or is down
> and based on a query volume it can effectively overload the cache
> server.
> 
> Initially we thought we could fix it with " resolver-query-timeout",
> but after bind code analysis it seems that everything less that 10
> seconds would be ignored, it would be great to mention this in the
> documentation.
> So one solution is to change MINIMUM_QUERY_TIMEOUT in resolver.c and
> recompile named, but  it would be nice to understand why 10 seconds
> as minimum value were selected in the first place, see
> /lib/dns/resolver.c
> 
> #define MAX_SINGLE_QUERY_TIMEOUT 9U
> #define MINIMUM_QUERY_TIMEOUT (MAX_SINGLE_QUERY_TIMEOUT + 1U) 
> 
> snip
> 
> void
> dns_resolver_settimeout(dns_resolver_t *resolver, unsigned int
> seconds) {
> REQUIRE(VALID_RESOLVER(resolver));
> if (seconds == 0)
> seconds = DEFAULT_QUERY_TIMEOUT;
> if (seconds > MAXIMUM_QUERY_TIMEOUT)
> seconds = MAXIMUM_QUERY_TIMEOUT;
> if (seconds < MINIMUM_QUERY_TIMEOUT)
> seconds =  MINIMUM_QUERY_TIMEOUT;
> resolver->query_timeout = seconds;
> }
> 
> We also tried to create local dummy zones for all these domains but
> since domains change frequently we started to block most active open
> resolvers and coordinate with local CERT.
> 
> It would be nice to have some kind of rate limits for query volume
> of different hosts inside a single zone.
> 
> Best regards,
> 
> Ivo
> 
> 
> On 2/27/14 7:59 AM, Dmitry Rybin wrote:
>> Over 2 weeks ago begins flood. A lot of queries:
>>
>> niqcs.www.84822258.com <http://niqcs.www.84822258.com>
>> vbhea.www.84822258.com <http://vbhea.www.84822258.com>
>> abpqeftuijklm.www.84822258.com
>> <http://abpqeftuijklm.www.84822258.com>
>> adcbefmzidmx.www.84822258.com <http://adcbefmzidmx.www.84822258.com>
>> and many others.
>>
>> Bind answers with "Server failure". On high load (4 qps) all
>> normal client can get Servfail on good query. Or query can execute
>> more 2-3 second.
>>
>> Recursion clients via "rnds status" 300-500.
>>
>> I can try to use rate limit:
>> rate-limit {
>> nxdomains-per-second 10;
>> errors-per-second 10;
>> nodata-per-second 10;
>> };
>> I do not see an any improvement.
>>
>> Found one exit in this situation, add flood zones local.
>>
>> What can we do in this situation?
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users@lists.isc.org <mailto: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 <mailto: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
> 

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!"
___
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: using views, normal to see non-authoritative for the views?

[Sten Carlsen]

On 21/02/14 19.11, Linda W wrote:
> I just started using views in bind-9.9.9-P2
>
> Where before I had my internal+external addrs listed, I offered
> responses/services via
> ACL to internalnets,
>
> Recently, I decided to use a split view config between external and
> internal
> (internal addrs being 192.168...).
I wonder why the external view does not have a "match-clients"
statement? When it is listed first, I would assume the internal view
never will be asked?
>
> I now get messages upon startup about my bind server being
> non-authoritative for
> both internal and external addrs (for each subnet I am a master for).
>
> I never used to get that message when they were all in a root config.
>
> Do I need to somehow "delegate" from the root to each zone, or why would
> I be getting non-authoritative for the same data that is now split
> into views?
>
> Any insights/hints would be appreciated -- since it's my first time
> using them, I've no clue if the messages indicate I did something
> wrong...
>
> Am attaching the basic named.conf setup.. with, what I hope,
> are the irrelevant parts deleted...
>
>
>
>
>
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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: SERVFAIL @google

[Sten Carlsen]

Did you check the serial? and double check. I mean the serial of your uploaded 
new data.

I have once missed that to the effect that no updates happened.

On February 10, 2014 12:29:41 PM CET, Lucio Crusca  wrote:
>In data lunedì 10 febbraio 2014 11:25:59, Steven Carr ha scritto:
>> On 10 February 2014 11:20, Lucio Crusca  wrote:
>> > Ok, so what should I do now? I want the NS records to point to
>> > ns0|1.virtual-bit.com. Should I change anything in my zone file or
>should
>> > I
>> > open a new ticket at my domain provider?
>> 
>> Contact the domain provider and ask them to either update the records
>> for you, or they will probably tell you to login to their portal and
>> update them yourself.
>
>I've already updated them myself through their portal a few days ago,
>so now I 
>suspect there's something wrong with their portal.
>
>Thanks for the help.
>___
>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

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.___
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 passthrough on no explicit result?

[Sten Carlsen]

;> a hard time searching for it because of that. (So I apologize if this
>> is then a dumb question).
>>
>> Any help you can offer is much appreciated. Thanks!
>> Steve
>>
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users@lists.isc.org <mailto: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
> 

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!"
___
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: Generic reasons for recursive performance not to peg CPU?

[Sten Carlsen]

Wild guess: network bandwidth runs out before CPU? Why the difference, I
have no clue.

On 13/01/14 02.16, Doug Barton wrote:
> Howdy,
>
> Without going into too much detail, doing some performance testing and
> am seeing a weird result. On the same systems authoritative queries
> will happily peg the CPU. However when running recursive queries (with
> a small zone, all data cached before testing) the CPU never gets above
> 80%. The disk is nearly inactive on both systems, and there is no
> swapping. Using BIND 9.9.4.
>
> Is there perhaps something obvious I'm overlooking here? Any
> suggestions are welcome.
>
> Doug
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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: Slowing down bind answers

[Sten Carlsen]

On 07/01/14 14.16, Bob McDonald wrote:
> > Unless the goal is to move all DNS services off that subnet.  Our
> network
> > staff would love to reclaim the /24 our DNS servers are tying up
> with very
> > little else on it wasting 250 addresses.
>
> I'm not sure I'm describing a properly configured anycast environment
> well.  Since in anycast the client never see the "physical" address of
> a DNS server, it matters not where they (the DNS server(s))
> "physically" are (only if they are in the anycast cloud or not).  You
> can move them around (insert/delete servers to/from the cloud) to your
> heart's content and the client doesn't know.  The requirement here (to
> avoid having clients left on legacy devices) is that all the affected
> servers be in the anycast cloud and all of your client devices point
> to the "logical" anycast address for DNS resolution NOT the "physical"
> address(es) of the DNS server(s).  You add the new server(s) to the
> cloud and delete the legacy server(s) from the cloud.  Easy peasey. 
> Obviously, this takes some up front planning and having a group of
> servers on the same subnet is probably not a good idea (although it
> could be interesting from a load sharing perspective...).  YMMV, it's
> just a thought.
If I understood the problem correctly, the address the anycast would
take is the address the clients actually use and the new servers can be
set anywhere. In this case they want to free that address for other
purposes.
Again if I understand this correctly anycast might be fine for future
but a bit too late in this case.
>
>
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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: Slowing down bind answers ?

[Sten Carlsen]

On 05/01/14 21.55, Nicolas C. wrote:
>
>
> As I said in my original request : I did the query logging / warning
> but it had no effect.
>
> I could hold them at gunpoint until they change their configuration
> but we have strict gun laws in France :)
>
Personally I would cut off access for all that is not a life support
system - that is also a kind of gun point?

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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: Slowing down bind answers ?

[Sten Carlsen]

You might also make a list of those who use the old server, send a
message (assuming the management system allows identification) that the
service goes down at a specific date in e.g. a month from that date. And
then remove it. Threats are not much worth if the are not followed through.

The point here is that noone can say they were not warned.

You might offer help to reconfigure to the people.


On 05/01/14 15:13, Phil Mayers wrote:
> On 05/01/2014 13:25, Timothe Litt wrote:
> 
>> To get people's attention, NXDOMAIN to www.* queries is often reasonably
> 
> Interesting idea; implemented how?
> 
>> It may be better to simply alias (if necessary, route) the old IP
> 
> Piece of advice for anyone not already doing this; when you deploy
> recursive resolvers, do them on "portable" IPs, not IPs from the subnet
> they live on, and direct the DNS traffic to them with static /32 or /128
> routes. You'll be glad you did later.
> 
>> instructions on how to reconfigure.  If you have the ownership data,
> 
> If you don't, you've got big(ish) problems ;o)
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!"
___
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 with several ip adessess

[Sten Carlsen]

I do this with views, the internal view has recursion the external does not.

I would be interested to hear other ways to do this.


On 30/12/13 10.27, Måns Hagström wrote:
> Hi,
>
> I'm running the same DNS for both my local and global adress-spaces. That is, 
> when I'm on my local net, I want the DNS to reply with my
> local 192.168.0.1-address, and when users from the 'outside' global net 
> queries my DNS, it shall return the global xxx.xxx.xxx.xxx ip-address.
>
> My problem is that I have to allocate both the local and the global address 
> to the same domain-name, giving the result that both my local and global
> ip-address are exposed for the users. Is it possible to isolate the query so 
> that the local users get the local ip-address and the global gets the global 
> ip-address for the same domain-name?
>
> I'm running BIND 9.9.2
>
> BR
> Mons
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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: Forward zone giving SERVFAIL

[Sten Carlsen]

IIRC "forward" means ask the forwarder to do a recursive lookup. If the
server you forward to does not do recursion, there is a problem here.

I think the advice is to look at stub zones, they might be useful here.

On 28/11/13 16.50, Neil Aggarwal wrote:
> Dave:
>
>> This is a shot in the dark, but is your server carrying a root zone or 
>> using hints? I vaguely recall running into similar a few weeks back when
> Bind complained about the pre-defined zones not being in a view when
> I added my views so I removed them.
>
> I added the following to my /var/named/named.zones file:
>
> zone "." in{
>   type hint;
>   file "named.ca";
> };
>
> include "/etc/named.rfc1912.zones";
>
> I restarted named and I am still getting the SERVFAIL error.
>
> It looks like having those zones is not making a difference.
>
> Thanks,
>   Neil
>
> --
> Neil Aggarwal, (972)834-1565, http://UnmeteredVPS.net/centos
> Virtual private server with CentOS 6 preinstalled
> Unmetered bandwidth = no overage charges
>
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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: script - automatic change A record

[Sten Carlsen]

On 25/11/13 15.00, Alan Clegg wrote:
> On Nov 25, 2013, at 7:55 AM, Pawe? Ch.  wrote:
>
>> Hi list,
>>
>> I would like to write script that change two entry in my zone file: SOA and 
>> A record.
>>
>> I have 2 web site: mail site site1.tld and backup site site2.tld. Script 
>> should monitor site1.tld and when site is unavailable it should change A 
>> record in zone file to indicate to site2.tld. If site1.tld is available 
>> again then A record should indicate to it.
>> Script should change SOA serial number.
If this really is mail only as I read from your mail, SMTP already takes
care to use the backup server, just put correct priority in DNS.
>>
>> Please help with writing a script.
> make the zone dynamic, read man page on nsupdate.
>
> AlanC
>
>
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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: stealth with views?

[Sten Carlsen]

This is pretty much what I do.

I have one server behind a NAT with two views: internal, resolving, has
all internal names - external, not resolving, has the master for my zones.

My DNS provider slaves my zones off the master on my LAN, I have not put
my master's IP in the zone data, what is in the file is not important.
Slaves transfer the zone data, not the file. I just checked and can not
find any trace of my IP in the output from the public servers.

I can check in my log when the slaves transfer the data, I have not had
any case where data ran out, set TTLs high enough.

I see a major panic when my ISP gives me a new IP (happens rarely, but
has happened), then I need to tell the slaves that a new master is in
place, can be done, but must be done right for this provider.


On 07/11/13 19.52, Jonathan Reed wrote:
> I'd like my global BIND server to slave a copy of my zone from the
> master being hosted on my LAN. It appears that this is called a
> stealth setup. I figured I'd achieve this by having the secondary on
> the internet slave a view, but I've read that this is not ideal from a
> security standpoint. The argument being that the zone file contains an
> IP address of it's master. So whats the best way to do this?
>
> A stealth scenario also seems susceptible to a higher chance where the
> connection is lost between master and slave (complicated by a LAN
> firewall/ISP in between) and the expire exceeding. We're hosting our
> global DNS through a provider, so there doesnt seem like an easy way
> to monitor and confirm a zone transfer from our master alone. Any
> recommendations?
>
>
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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: Install DNS Server

[Sten Carlsen]

Hi

I do that and more on an ATOM machine with 2GB RAM. I use Postfix
instead of qmail but see no reason qmail would not work.

I installed all the relevant RPMs, configured them and it works.

One thing to remember is that you need two or more DNS servers, I do
that by being a stealth master with several slaves on my 3rd party provider.


On 10/10/13 12.27, Chandran Manikandan wrote:
> Hi All,
> I am running Centos 5.7 32 bit server machine.
> I have installed and successfully run qmail,web,ftp with the same machine.
> Now am DNS hosting with third party. I would like to install and keep
> DNS hosting myself. 
> How to do that , How to install Dns server with the same machine or
> different machine as well what is the complete procedure and steps.
>
> Any one help me.
>
> -- 
> *Thanks,*
> *Manikandan.C*
> *System Administrator*
>
>
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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: moving DNSSEC to a hidden master

[Sten Carlsen]

This works for me and is the standard method:

rndc freeze
update serial
rndc thaw

Rndc freeze merges the .jnl files into the zone files and stops dynamic
updates. Thaw allows dynamic updates to resume.

On 04/10/13 02.12, David Newman wrote:
> Thanks all for your responses.
>
> On 10/1/13 6:42 PM, Mark Andrews wrote:
>> As Alan said copy the .key and .private files over.
>>
>> Disable updating on the old master.
>>
>> Transfer the zone contents by setting up as a slave
>> using "masterfile-format text"; or using by using dig.
>> This will give you the most up to date version of the
>> zone.
>>
>>  dig axfr zone +onesoa @oldmaster
>>
>> Check that the new server is working 
> Converting the new secondary to a new master worked. But incrementing
> the zone's serial number did not, producing an error after 'rndc reload'
> like this:
>
> Oct  3 16:00:29 host named[35249]: malformed transaction:
> dynamic/mydomain.com/mydomain.com.db.jnl last serial 2013092701 !=
> transaction first serial 2013092700
>
>> and you can update
>> the zone by using nsupdate.
> Although the zone file lives under dynamic/mydomain.com so DNSSEC
> updates can happen, I don't have dynamic updates configured, so nsupdate
> won't work. This arrangement -- with static zone files under the dynamic
> directory -- worked OK on the old master. Permissions are the same on both.
>
> This thread suggested the journal issue was separate views pointing to
> the same zone file:
>
> https://lists.isc.org/pipermail/bind-users/2008-June/070807.html
>
> Indeed I had pointers to the same zone file in separate views, but
> removing them and restarting named did not clear the issue. Now I have
> the zone in just one view, and still can't manually increment the serial
> number without that journal complaint.
>
> Thanks in advance for clues on resolving the journal version issue.
>
> dn
>
>> Convert the old master server into a slave.
>>
>> Update the other slaves to talk to a new master.
>>
> _______
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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: moving DNSSEC to a hidden master

[Sten Carlsen]

On 02/10/13 02.47, Alan Clegg wrote:
> On Oct 1, 2013, at 8:27 PM, David Newman  wrote:
>
>> On 10/1/13 2:16 PM, David Newman wrote:
>>> Is there a recommended order of operations when moving DNSSEC-enabled
>>> nameservers to a hidden-master setup?
>> Actually, this is really a more general question: Is there a recommended
>> order of operations when migrating zones between any two DNSSEC-enabled
>> nameservers, assuming the same version of bind on each?
> Eh... I'm not sure what the complexity here is.
>
> Set the "new" machine up as a slave, use the standard axfr mechanism to 
> replicate the zones, move the keying material and then convert the new system 
> form slave to master while taking the existing master off-line.
>
> What am I missing?
I believe that was the question, what is missing here - if anything.
Seems too easy, there has to be a catch.
Anything to do to catch up on internal states, How to be sure the new
master will continue exactly as the old one had done. Maybe it is that
simple, that would be great, but if you are not sure, it is a good
question to ask.
>
> AlanC
>
>
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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: Who is right?

[Sten Carlsen]

AFAIK dig any   will return whatever might be in the cache at the
time of the question.

On 06/09/13 9:27, Marco Davids (SIDN) wrote:
> dig ANY example.org @..
>
> Google Public DNS:
> --
> returns DS: no
>
> BIND 9.9.3-P2:
> --
> returns DS: yes
>
> Unbound 1.4.20:
> ---
> returns DS: no
>
> Personally I don't care much, but perhaps someone on this list has a
> strong opinion about these differences that I should know about?
>
> Thank you.
>
>
>
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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: Bind99 and a slave named server

[Sten Carlsen]

On 18/08/13 22:06, Dave Warren wrote:
> On 2013-08-18 10:39, LuKreme wrote:
>> Since it is all working, what I am looking for now is "how to convert
>> you master bind server to a slave".
>
> Change the zones from master to slave in your named.conf? There really
> isn't much more to it than that, assuming you have a new authoritative
> master is already configured and serving the zones.
>
> Watch the logs for any errors indicating that your
> former-master-now-slave has newer versions of zones than the
> new-master, as this might indicate errors, but outside of that, the
> fact that a server used to be a master makes very little difference.
Also look at permissions etc. The new master needs to be told that the
master-turned-to-slave is allowed to axfr and the new slave must know
who to look for as the master.

You need to consider whether you will be happy with the new binary file
format at the slave or you need to specify the text format.

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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: Troubleshooting DNSSEC issue w/ ic.fbi.gov

[Sten Carlsen]

>From here i see a fast response using the local server:
~
$ dig ic.fbi.gov

; <<>> DiG 9.7.6-P1 <<>> ic.fbi.gov
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: _/*NOERROR*/_, id: 2421
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;ic.fbi.gov.INA

;; AUTHORITY SECTION:
fbi.gov.600INSOAns1.fbi.gov. dns-admin.fbi.gov.
2013071601 7200 3600 2592000 43200

;; Query time: 158 msec
~
No error, but no address.

Using Google I get a servfail:
~
$ dig ic.fbi.gov @8.8.8.8

; <<>> DiG 9.7.6-P1 <<>> ic.fbi.gov @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: *_/SERVFAIL/_*, id: 11426
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ic.fbi.gov.INA

;; Query time: 102 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Jul 17 18:54:41 2013
;; MSG SIZE  rcvd: 28
~
SERVFAIL, so something is unclear.


On 17/07/13 18:49, Ray Van Dolson wrote:
> Hello;
>
> Running BIND 9.8.2 in RHEL6 (at the latest vendor provided version --
> bind-9.8.2-0.17.rc1) and trying to troubleshoot an issue resolving
> ic.fbi.gov that seems to be DNSSEC related.
>
> Am fairly certain of this because if I set dnssec-enable and
> dnssec-validation to no (have them at 'yes' normally), resolution
> succeeds.
>
> If I run a dig @nameserver ic.fbi.gov from a client machine, dig just
> hangs for a bit then eventually times out.  dig @nameserver fbi.gov
> works fine
>
> On my BIND server, I see the following in a packet capture:
>
>   0.00 1.1.1.1 -> 156.154.64.48 DNS Standard query A ic.fbi.gov
>   0.026504 156.154.64.48 -> 1.1.1.1 DNS Standard query response
>   0.026927 1.1.1.1 -> 156.154.69.48 DNS Standard query DS 
> 7PLEGSLCCDFUBJ53UG8E19T9MH9HIP2B.fbi.gov
>   0.042998 156.154.69.48 -> 1.1.1.1 DNS Standard query response, No such name
>   0.043485 1.1.1.1 -> 156.154.67.48 DNS Standard query DS 
> 97S2G907NEFOJ79P721E4FEQ9LR3IT1S.fbi.gov
>   0.048186 156.154.67.48 -> 1.1.1.1 DNS Standard query response, No such name
>   0.048595 1.1.1.1 -> 156.154.67.48 DNS Standard query DS 
> 6VTIGSHGMAR334K0PFDJ5ODURDL6CUFP.fbi.gov
>   0.053765 156.154.67.48 -> 1.1.1.1 DNS Standard query response, No such name
>  30.043683 1.1.1.1 -> 156.154.65.48 DNS Standard query DS 
> GON9PTIAV4KLS7E9NMHD9LG02RQD6K3I.fbi.gov
>  30.061169 156.154.65.48 -> 1.1.1.1 DNS Standard query response, No such name
>
> So it seems like the issue is related to the DS records queried not
> existing, but I've checked a few DNSSEC validation tools out there by
> plugging ic.fbi.gov in and things appear to check out.  This could be
> firewall related on my side (we have Checkpoint firewalls), but other
> DNSSEC queries appear to be working OK.
>
> A dig @8.8.8.8 +dnssec ic.fbi.gov works OK as well also making me think
> the issue is somehow on my side
>
> Am reading up on additional troubleshooting steps for DNSSEC, but still
> wrapping my head around concepts.
>
> Anyone have any tips as to where to start "digging" next based on what
> I'm seeing above?
>
> Thanks,
> Ray
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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: Reverse address entries

[Sten Carlsen]

On 02/07/13 21:02, Eduardo Bonsi wrote:
> I have been reading all your concerns about reverse FQDNS. In my
> example, we are a very small firm and I am the IT network admin
> responsible for configuring our server. One of the reasons I
> configured our server was because we deal with Photography, graphic
> design and occasionally presentations of Movies. These are fat files
> that are not viable to send thru emails. Our setup is far from being
> perfect and does not follow the ISC BIND advised rules of how I would
> like to follow to run a proper server. Like two different networks,
> one ip address for every ns.mydomain.com and web services and so
> forth. Believe me, I would love to do that if I had the budget for it.
> Therefore, that is not really my decision but it falls under the way
> my ISP charges $$$ for each ip address and reverse setup. 
Well, that means your setup is ok, lookups will go like this:
1 - your.mail.server -> some IP
2 - some IP -> a name in your ISP's DNS, typically very generic like
2-45-231-6-isp-dynamic-pool.xx
3 - 2-45-231-6-isp-dynamic-pool.xx -> back to "some IP".

The fact that numbers 2) and 3) match and could be done more times if
needed, is what SMTP is looking for. Hence you are not deemed to be a
spammer on that account.
> So, I decided to work with what I have and be happy with the
> limitations and at the same time try to work around them. I put a lot
> of thought in the beginning about the issue of: -Should I reverse my
> main NS or Should I just leave it alone since I do not do any transfer
> or run any email server from my server. I thought in the beginning;
> "Well, no spammer will attempt to relay through my server since this
> will be one more reason they will not get things to work properly."
> However, this is not really a concern. Like I said, my set up is not
> perfect but everything works fine from my end so far with limitations!
> …and Yes, I do occasionally have a very short delay between the main
> "www.mydomain" and "mydomain" but the same delay never happened with
> the other domains/websites I am running under the same ip address. I
> guess I could reverse my main domain to my one and only static ip
> address and my question would be: - Does that would affect the other
> websites I am serving using the same ip address? Thanks everyone for
> this wealth discussion!
>
> Eduardo

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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: Discover Unreferenced Zones/Records

[Sten Carlsen]

There might be some zones that are rarely used, you may see those as
dead using that method.

I was thinking of a script that would take your list of zones
(essentially the .conf file) and for each zone do something like a "dig
+trace" and look for whether your servers are listed as name servers for
that zone.

Those you are no longer listed in can be removed immediately, those
where you are listed but has no or very little traffic, you can make
inquiries about and act accordiingly.

Just my 0.02EUR

On 01/07/13 13:04, Bryan Harris wrote:
> Hi all,
>
> I have discovered that we have an excessive amount of old zones not
> being used.  Is there a trick, or a simple way to determine which
> zones have not been referenced in a long time?
>
> My best guess is to simply log queries and read the log files.  Would
> that be the recommended way?
>
> Our intent is to delete everything we don't need.
> Bryan
>
>
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:
   "MALE BOVINE MANURE!!!"

___
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: PTR files

[Sten Carlsen]

For what its worth, I run a web server behind a Dlink router(DIR-825). I
have done that for about 6 years, the same box. I have not seen that
type of messages.

It does not need a PTR record, it can run without any DNS , except it is
non-practical.

What it does need is to be included in the virtual servers list in the
D-link router.

I guess you will have to be more specific about exactly which situation
creates the message and if possible which SW-module is responsible
before it is possible to help.



On 18/06/13 1:04, Norman Fournier wrote:
> On 2013-06-17, at 4:11 PM, Charles Swiger wrote:
>
>> On Jun 17, 2013, at 3:00 PM, Norman Fournier  
>> wrote:
>>> [ ... ]
>>> (...Members of the httpd-users list says the same thing - its not an httpd 
>>> problem.
>> From what you've said below, they're quite right.
>>
>>> I am just trying to take possibilities off my list of potential errors, 
>>> sorry if I am annoying you, it's unintentional and symptomatic of my 
>>> ignorance, so I'm asking questions. I think that is a legitimate use of my 
>>> subscription to this list, and the list's raison d'être. Surely the list is 
>>> not exclusively for individuals who know what they're talking about?..)
>> This list is for discussion of ISC's BIND.
> For me, the list is called bind-users, not bind-discussion. BIND discussion 
> would be a higher echelon than a user list. I'm a bind user and I have a 
> Domain Name Server problem, somewhere, that I have been trying to solve for a 
> long time and am going over my steps once again. I need to get my webserver 
> online and there is a problem with the name or lookup or the router. I have 
> not found any errors in httpd, bind or the router configuration that have 
> solved it. The latest hint I got was an ostensible missing in-addr.arpa PTR 
> record, which, to me, made it relevant to BIND.
>
>> Let's assume that you've got a D-Link router which has a single public IP 
>> from your provider, and provides NAT translation for a private RFC-1918 
>> subnet, and you've placed your webserver on a VM which lives behind that 
>> D-Link router.  If so, you will need to enable static port forwarding for 
>> 80/tcp to the VM running the webserver, or perhaps place that IP in the 
>> router's "Enable DMZ Host" section of the firewall config.
>>
>> This is basic networking; it doesn't have any close relationship to either 
>> DNS or webservers.
> The ports forwarded to the 192.168.0.101 webserver are unchanged since 2005; 
> dns, http and ssh to appropriate ports. The router did change, the static ips 
> changed, as well as the physical location of the network and servers. I don't 
> know what the issue is, that's why I asked about including explicit PTR files 
> to the domain name, as well as the localhost in-addr.arpa, which is the 
> latest in a list of "possible irregularities" I have turned up so far that I 
> need to confirm one way or the other.
>
> I do appreciate you taking valuable time to answer. I have to wade into it 
> all again. I hope I am still welcome to ask questions here as I have seen 
> others do, since I subscribed to this list in an effort to learn about BIND 
> and DNS, a number of years ago.
>
> Norman
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:
   "MALE BOVINE MANURE!!!"

___
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 Amplification Attacks... and a trivial proposal

[Sten Carlsen]

Just a thought, below:
On 14/06/13 2:41, Ronald F. Guilmette wrote:
> In message <51b9fb6a.1090...@tiggee.com>,
> David Miller  wrote:
>
>> This could lead to wrong headed statements like, "Yes, we sent X GB of
>> traffic at your network.
> Yes.
>
> Last night I reconsidered at some length the scheme I put forward yesterday.
> (Please note that I am very deliberately calling it merely a "scheme"
> rather than a "proposal", because I do not think that it rises to the
> level of that honorable title yet.)
>
> Basically, please ignore everything I put forward yesterday and substitute
> instead the following in place of all that...
>
> 1)  A new DNS/UDP packet/message type is defined.  This new message
>   when sent from from machine A to machine B informs B that A would
>   really really appreciate it if B would cease and desist from sending
>   anything other than HIGHLY ABBREVIATED (12 byte) UDP DNS response
>   packets to the IP address of A for a period of 30 seconds.  (Said
>   highly abbreviated DNS/UDP response packets would all have the TC
>   bit set.)
>
>   In a hypothetical revised future DNS RFC it would be said that all
>   DNS servers attached to the public internet MUST be capable of
>   properly receiving, decoding and obeying any and all such client
>   requests.
>
I wonder what DNS-servers running older versions of the SW will respond
to that? If they silently discard the packet, no problem. If however
they respond with refused or anything else, you create your own storm.

-- 
Best regards

Sten Carlsen

No improvements come from shouting:
   "MALE BOVINE MANURE!!!"

___
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: Help on NXDOMAIN to try next forwarder in the list

[Sten Carlsen]

Well you can do that.

It does not change the fact that NXDOMAIN is a DEFINITIVE answer - it
does not exist, there is no reason to look further.


On 30/05/13 9:56, Ashok Agarwal wrote:
> Sorry, its not */etc/hosts* file rather its */etc/resolv.conf*.
>
>
> On Thu, May 30, 2013 at 1:25 PM, Ashok Agarwal
> mailto:ashokagarwal.s...@gmail.com>> wrote:
>
> One possible way can also be to set the number of nameservers to
> be looked upon in the /etc/hosts file.
>
> nameserver 8.8.8.8
> nameserver 4.4.2.2
> nameserver 4.1.2.2
>
> Regards,
> Ashok
>
>
> On Thu, May 30, 2013 at 1:05 PM, Steven Carr  <mailto:sjc...@gmail.com>> wrote:
>
> It's not possible. NXDOMAIN is NXDOMAIN, it doesn't exist, it
> doesn't
> mean try another server to see if you get lucky next time.
>
> Steve
>
>
> On 30 May 2013 08:26, sumsum 2000  <mailto:sum2h...@gmail.com>> wrote:
> > Hi,
> > I have the following change to be available from BIND9.
> >
> > I have zone forwarders as follows with BIND9 setup with
> forward only option
> > on a Non Authoritative DNS server
> >
> > zone  "mytestdomain101.com <http://mytestdomain101.com>" IN  {
> > type forward;
> > forwarders {8.8.8.8;4.2.2.1;8.8.4.4};
> > forward only;
> > };
> >
> >
> > If I am doing a dig on mytestdomain101.com
> <http://mytestdomain101.com>, the first DNS server gives
> > NXDOMAIN. In this example, say it tries 8.8.8.8 and returns.
> I would want
> > the other servers 4.2.2.1 and 8.8.4.4 to be tried and then
> finally return
> > NXDOMAIN to have the same functionality as that of the SERVFAIL.
> >
> > This is not currently possible and I have tried it on
> BIND9.8.2  version.
> > Could you please suggest if there is a way to do it.
> >
> > Thanks
> > Sum2hike
> >
> >
> >
> > ___
> > Please visit
> https://lists.isc.org/mailman/listinfo/bind-users to
> > unsubscribe from this list
> >
> > bind-users mailing list
> > bind-users@lists.isc.org <mailto: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 <mailto:bind-users@lists.isc.org>
>     https://lists.isc.org/mailman/listinfo/bind-users
>
>
>
>
> -- 
> Ashok
>
>
>
>
> -- 
> Ashok
>
>
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:
   "MALE BOVINE MANURE!!!"

___
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: Negative zones; NXDOMAIN responses

[Sten Carlsen]

>> These LAN have a BIND9 service to provide name resolving and caching for
>> internet access, and I want to intercept the .local domain to give a
>> NXDOMAIN response. The internet ISP returns positive values for .local
>> queries, and I need that LAN clients receive NXDOMAIN instead.
.local actually has meaning for most modern systems, so I would question
the wisdom of what you want to do.

You may find some functions of systems not working any more. Obviously
it is up to you in the end.
>>>
>>> Can I create a zone file for .local domain and specify there NXDOMAIN
>>> values for SOA and A RRs? How should be the content of the zone sheet?
>>>
>>>

-- 
Best regards

Sten Carlsen

No improvements come from shouting:
   "MALE BOVINE MANURE!!!"

___
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: Mailing list "reply-to" setting

[Sten Carlsen]

This is also the way I use mail, so +1.


On 09/05/13 23:02, Carlos M. martinez wrote:
> My mail setup is as limited as my eyesight. As I mentioned, I have
> emails in my inbox and filter afterwards in order to keep mbox size at
> reasonable levels. In this way I don't forget to check this or that folder.
>
> While on inbox I filter by looking at the tags. Works really well and I
> know quite a few people who do the same. I counted and I'm subscribed to
> over 50 mailing lists and this is the only one which does not tag the
> subject.
>
> Probably you've discussed this in the past (I'm a rather new
> subscriber), so I apologize for bringing up a dead horse.
>
> regards,
>
> Carlos
>
> On 5/8/13 10:53 PM, Michael McNally wrote:
>> On 5/8/13 9:43 AM, Carlos M. martinez wrote:
>>> Agreed, but, subject tagging is very useful for those who prefer to have
>>> things hit your inbox first, before archiving. And there seems to be a
>>> lot more agreement on the tagging issue than on the reply to.
>> Unless your mail setup is extremely restricted in what it can filter
>> on, you have several choices of header which can be used by an
>> automated filter to detect and classify appropriately according to list.
>>
>> Personally I have procmail file bind-users traffic based on the
>> "List-Id:" header, but I realize you may be in a different environment
>> with different tools available.)
>>
>>List-Id: BIND Users Mailing List 
>>
>> Michael McNally
>> ISC Support
>> ___
>> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:
   "MALE BOVINE MANURE!!!"

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

[Sten Carlsen]

I believe your major point is the routing tables because they determine
how the response is trying to get out.


On 08/05/13 22:22, Steven Carr wrote:
> You will need to have some form of automation in place to update the
> DNS zone to change the IP address which should now be accessed when
> one of the links goes down. You will also need to ensure you have a
> low TTL value on the records you want to update on link change so that
> the records are refreshed quickly.
>
>
>
> On 8 May 2013 20:40, Ward, Mike S  wrote:
>> Hello all, I was wondering if someone could me out.
>>
>> I am using Bind 9.2 on a Redhat Linux server. We have two ISPS on separate 
>> networks Lets call them A and B. My Linux Server can listen on A's Network 
>> as well as B's network.
>> I'm using fictitious IPs and names
>>
>> A 111.111.111.1  B 555.555.555.1 
>>Secondary A 111.111.222.1
>>
>>   Redhat & Bind
>>
>> Bind is listening on both IP addresses and we have a secondary server at 
>> 111.111.222.1
>>
>>
>> If A the ISP has a backbone router problem how can I get people trying to 
>> get to our web servers to use B's network? I have been think of different 
>> ways to do this, but have come up empty.
>>
>> Our network is really simple I just want to be able to use diverse ISPS in 
>> case we lose one we still have the other. Can anyone help me out. Any help 
>> appreciated.
>>
>> Thanks.
>>
>> ==
>> This email, and any files transmitted with it, is confidential and intended 
>> solely for the use of the individual or entity to which it is addressed. If 
>> you have received this email in error, please notify the system manager. 
>> This message contains confidential information and is intended only for the 
>> individual named. If you are not the named addressee, you should not 
>> disseminate, distribute or copy this e-mail. Please notify the sender 
>> immediately by e-mail if you have received this message by mistake and 
>> delete this e-mail from your system. If you are not the intended recipient, 
>> you are notified that disclosing, copying, distributing or taking any action 
>> in reliance on the contents of this information is strictly prohibited.
>> ___
>> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:
   "MALE BOVINE MANURE!!!"

___
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: architecture question

[Sten Carlsen]

You could also make a sub domain of your main domain and use that for
all students, unless of course the purpose is to teach how to set this up.

I have used .home my self, now I would take something that
nobody would ever think of using in the "real" world, in old days I did
consider .xxx, that is now a whole other thing than just something odd.
Generally you may want to consider the new options for people to make
actual TLDs to be their company name.

At the start of the course, you could make a draw among the students and
use the selected persons first name, that any coming thing like mdsn
would use that is not very likely. It also draws attention to the
significance of those letters.



On 08/05/13 19:33, Jeremy P wrote:
> I understand letter of the law, spirit of the law and playing it safe
> to avoid headaches.
>
> However, there are times where registering a real domain just isn't
> practical.  For example, I'm not going to ask all of the students in
> my courses to go out and register a .com for the semester.  It would
> be a waste of money as their systems never leave the local network,
> except through a NAT connection.  So in those types of instances, I'm
> assuming .lan or .test are safest?
>
>
> On Wed, May 8, 2013 at 11:20 AM, Steven Carr  <mailto:sjc...@gmail.com>> wrote:
>
> On 8 May 2013 18:09,  mailto:wbr...@e1b.org>> wrote:
> > This just came up with a site I support.  Thanks to this list
> and the
> > DNS-OARC list, I know better. Hopefully, I can redirect them to use
> > something below their real domain for Active Directory such as
> > ad.example.org <http://ad.example.org>.
>
> FWIW: MS now advises not to use .local for internal AD anymore. They
> suggest you use your owned/registered namespace to prevent domain
> collisions.
>
> http://support.microsoft.com/kb/909264
> Generally, we recommend that you register DNS names for internal and
> external namespaces with an Internet registrar... Registering your DNS
> name with an Internet registrar may help prevent a name collision.
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org <mailto: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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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: architecture question

[Sten Carlsen]

Don't forget that Bonjour actually uses .local and will be very sour if
it is sued for other purposes, I have tried.


On 08/05/13 16:56, Jeremy P wrote:
> I am building a lab environment where there are several separate
> domains, all of them ending in .local
>  
> I've setup a server for the .local TLD, but I'm undecided (or perhaps
> ignorant) as to the best way to have the individual domains
> (domain1.local, domain2.local, etc) refer to the local zone on my TLD
> server.  Currently I've also created a root server and set the root
> hints on domain1.local's dns server to refer to it.  This works for
> local resolution, but this means that domain1.local can't perform
> Internet lookups.
>  
> Thanks for any help,
> Jeremy
>
>
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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: resolver, search command....

[Sten Carlsen]

You probably want to use host myhost, that does use the resolv.conf as
the system normally would. And it works better than nslookup.

On 08/05/13 16:56, Evan Hunt wrote:
>> dig myhost
> By default dig only uses fully qualified domain names. "dig +search"
> does what you want.
>
>> It would search for that host in path1 or path2 listed above.? It does
>> not, a +trace shows the resolver querying the root servers for myhost.?
>> So it appears the search command does not work in environment.
>>
>> [root@server1 # dig myhost +trace
> ...but "dig +trace" behaves completely differently, searching for the
> name from the root zone down and never touching the local resolver at
> all, so this would have queried the root server even if you'd used a
> FQDN.
>

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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 geo-distribution

[Sten Carlsen]

On 30/04/13 10:30, Dave Warren wrote:
> On 2013-04-30 00:49, Sten Carlsen wrote:
>> Don't forget that most users will get the address out of "some"
>> cache, not directly from the authoritative servers.
>
> Absolutely. This is even more true in our case as many of our clients
> are serve very local areas and 2-3 ISPs and 3-4 mobile providers
> probably cover 90%+ of their clients.
Which essentially means that the time to get data from the authoritative
servers is irrelevant in almost all cases. Availability vs. network
problems would be more important in my book.
>
>
> On 2013-04-29 21:48, Chris Buxton wrote:
>> RTT means almost always hitting the fastest server.
>
> My concern with relying on RTT is that since most of our sites are
> very low volume, will it be effective or does it work better when a
> host has higher traffic? How long do resolvers remember a particular
> NS's RTT?
>
> We have a handful of Europe based clients, but their number is quite
> small, so I'm not sure if we'd be significantly hurting the majority
> by introducing a high-latency server into the mix or not, or even how
> to evaluate the results.
>
> I realize I've probably spent more time thinking about it than I'll
> possibly save anyone else anyway, so perhaps that's my answer.
>
> I appreciate all the input.
>
> -- 
> Dave Warren
> http://www.hireahit.com/
> http://ca.linkedin.com/in/davejwarren
>
>
>
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:
   "MALE BOVINE MANURE!!!"

___
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 geo-distribution

[Sten Carlsen]

Don't forget that most users will get the address out of "some" cache,
not directly from the authoritative servers.


On 30/04/13 6:48, Chris Buxton wrote:
> On Apr 29, 2013, at 9:01 PM, Dave Warren wrote:
>> With the vast majority of our customers being in North America (probably 75% 
>> of users are in Canada), would it make sense to add a Europe based NS or 
>> would this tend to return slower results on average since a potential user 
>> would have a 1/3 chance of hitting a NS with a higher latency?
> RTT means almost always hitting the fastest server.
>
> Chris Buxton
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:
   "MALE BOVINE MANURE!!!"

___
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: Looking for a pointer on getting reverse mapping with DDNS to work with DHCPD & Named.

[Sten Carlsen]

Apparently the DHCP server tries to put the change into BIND but times
out. What does the named log tell about this?

Either it did see the request or it will have an explanation why it
won't do it.

On 28/03/13 18:18, Jim Bucks wrote:
> Hi Mark, Graham, & others.
>
> I've spent the last day trying all sorts of things to get this working
> (to no avail).  I'm still at the stage of DHCP offering the lease IP
> address, but the DNS is not automatically updating the two "zones"
> files with the newly leased addresses.
>
> Here is a grief summary of what I tried/changed.
>- Added the group named to the dhcpd user
>- moved the two zones files into
> /var/named/chroot/var/named/slaves/  (was internal/)
>- added ENABLE_ZONE_WRITE=yes to /etc/sysconfig/named
>- grabbed a current version named.conf file and added the bare
> minimum config into into it.
>
> Attached are my configs.
>
> Any ideas on what I've hosed up?
>
> Thanks,
>
> Jim
>
>
>
> -- 
> Jim Bucks - IT Director 
> Colorado Studios <http://www.coloradostudios.com>, Mobile TV Group
> <http://www.mobiletvgroup.com>, HDNet <http://www.hd.net>, AXS.tv
> <http://www.axs.tv/>
> 8269 E. 23rd Ave. Denver, CO 80238 Main  303-388-8500
> jbu...@coloradostudios.com <mailto:jbu...@coloradostudios.com>
>Direct 303-542-5520
>
>
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

   "MALE BOVINE MANURE!!!" 

___
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