RE: NAMED LOGS
Dear Wander, Please stop this traffic! Thanks Best Regards, Grace INGABIRE ccTLD SYSTEM ADMINISTRATOR RICTA CELL:+250788424148 -Original Message- From: Matthäus Wander [mailto:matthaeus.wan...@uni-due.de] Sent: Tuesday, July 23, 2013 4:11 AM To: Mark Andrews Cc: Grace Ingabire; dns...@vs.uni-due.de; bind-us...@isc.org Subject: Re: NAMED LOGS * Mark Andrews [2013-07-23 03:36]: > How do you do that with a broken delegation? Did you think to ask > before delegating a zone to a zone not configured for it? What > does your Chancellor think about using uninformed third parties for > experiments like this? The method is described here (Figure 4): http://homes.cs.washington.edu/~gribble/papers/king.pdf Using a delegation is a technical detail. It's not different than sending a query directly to the zone servers. About sending queries unasked: I thought of the traffic this would cause, which should be a few queries per second on TLD servers and a few queries per minute on open resolvers. I do not expect this to have any negative operational effect. If you're having a different experience, or just don't like it as a matter of principle, let me know and I will stop sending packets to your server. Regards, Matt -- Universität Duisburg-Essen Verteilte Systeme Bismarckstr. 90 / BC 316 47057 Duisburg ___ Please visit https://lists.isc.org/mailman/listinfo/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 I change the zone file from command line?
In message
, Mike Hale writes:
> This seems pretty straight forward.
>
> Use your standard bash tools to modify the file when necessary, then
> you should simply be able to call rndc reload ZONENAME in the script.
Though why one would want to do this rather than just updating the
zone using DDNS is beyond me. It's not like DDNS can't be made
secure by using TSIG.
Normalize the zone file using named-checkzone.
Use awk or similar to change the relevent entries and update the SOA serial.
Use named-checkzone to confirm that the resulting file is still valid then
if it is rename it and reload the zone.
named-checkzone -D -q zone file |
awk '$1 == "server" && $4 == "A" { print $1, $2, $3, $4, NEWIP}
$4 == "SOA" { $7 = $7 + 1; print }' > temp
named-checkzone -q zone temp && mv temp file && rndc reload zone
Mark
> On Mon, Jul 22, 2013 at 10:28 PM, Mihamina Rakotomandimby
> wrote:
> > Hello,
> >
> > I did not catch what you're trying to achieve.
> > Please give more details.
> >
> >
> > On 2013-07-23 08:25, Manish Rane wrote:
> >
> > Hi Folks,
> >
> > Wondering if I can edit/change the static zone file as a result of certain
> > bash script. Well, I am trying to write a script which will monitor the
> > server on certain ports and it if fails to connect to the server it will
> > delete or add the entry from zone file so that traffic will be routed to
> > another server, possible?
> >
> > OR does any one aware of such solution available in open source?
> >
> >
> >
> > ___
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> > unsubscribe from this list
> >
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
> >
> >
> >
> > --
> > RMA.
> >
> >
> > ___
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> > unsubscribe from this list
> >
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
>
>
>
> --
> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Can I change the zone file from command line?
This seems pretty straight forward. Use your standard bash tools to modify the file when necessary, then you should simply be able to call rndc reload ZONENAME in the script. On Mon, Jul 22, 2013 at 10:28 PM, Mihamina Rakotomandimby wrote: > Hello, > > I did not catch what you're trying to achieve. > Please give more details. > > > On 2013-07-23 08:25, Manish Rane wrote: > > Hi Folks, > > Wondering if I can edit/change the static zone file as a result of certain > bash script. Well, I am trying to write a script which will monitor the > server on certain ports and it if fails to connect to the server it will > delete or add the entry from zone file so that traffic will be routed to > another server, possible? > > OR does any one aware of such solution available in open source? > > > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > > > > -- > RMA. > > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 ___ Please visit https://lists.isc.org/mailman/listinfo/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 I change the zone file from command line?
Hello, I did not catch what you're trying to achieve. Please give more details. On 2013-07-23 08:25, Manish Rane wrote: Hi Folks, Wondering if I can edit/change the static zone file as a result of certain bash script. Well, I am trying to write a script which will monitor the server on certain ports and it if fails to connect to the server it will delete or add the entry from zone file so that traffic will be routed to another server, possible? OR does any one aware of such solution available in open source? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- RMA. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Can I change the zone file from command line?
Hi Folks, Wondering if I can edit/change the static zone file as a result of certain bash script. Well, I am trying to write a script which will monitor the server on certain ports and it if fails to connect to the server it will delete or add the entry from zone file so that traffic will be routed to another server, possible? OR does any one aware of such solution available in open source? ___ Please visit https://lists.isc.org/mailman/listinfo/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: NAMED LOGS
In message <51ede640.8040...@uni-due.de>, =?ISO-8859-15?Q?Matth=E4us_Wander?= w rites: > * Mark Andrews [2013-07-23 03:36]: > > How do you do that with a broken delegation? Did you think to ask > > before delegating a zone to a zone not configured for it? What > > does your Chancellor think about using uninformed third parties for > > experiments like this? > > The method is described here (Figure 4): > http://homes.cs.washington.edu/~gribble/papers/king.pdf > > Using a delegation is a technical detail. It's not different than > sending a query directly to the zone servers. Send queries for domains that the server is NOT configured to accept is very different to sending queries for domains the server IS configured to accept. You just cost the rw adminstrators time and money investigation the source of unexpected traffic. You cost everyone on the list some time and money helping out the rw administrators. The actual cost of the traffic in inconsequential to the other costs that have resulted from your actions. TLD administrators actually need to look for abnormal traffic as they are high value targets. Mark > About sending queries unasked: I thought of the traffic this would > cause, which should be a few queries per second on TLD servers and a few > queries per minute on open resolvers. I do not expect this to have any > negative operational effect. > > If you're having a different experience, or just don't like it as a > matter of principle, let me know and I will stop sending packets to your > server. > > Regards, > Matt > > --=20 > Universit=E4t Duisburg-Essen > Verteilte Systeme > Bismarckstr. 90 / BC 316 > 47057 Duisburg -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NAMED LOGS
* Mark Andrews [2013-07-23 03:36]: > How do you do that with a broken delegation? Did you think to ask > before delegating a zone to a zone not configured for it? What > does your Chancellor think about using uninformed third parties for > experiments like this? The method is described here (Figure 4): http://homes.cs.washington.edu/~gribble/papers/king.pdf Using a delegation is a technical detail. It's not different than sending a query directly to the zone servers. About sending queries unasked: I thought of the traffic this would cause, which should be a few queries per second on TLD servers and a few queries per minute on open resolvers. I do not expect this to have any negative operational effect. If you're having a different experience, or just don't like it as a matter of principle, let me know and I will stop sending packets to your server. Regards, Matt -- Universität Duisburg-Essen Verteilte Systeme Bismarckstr. 90 / BC 316 47057 Duisburg smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NAMED LOGS
In message <51edcfad.5030...@uni-due.de>, =?ISO-8859-15?Q?Matth=E4us_Wander?= w rites: > > Hi, > > Grace Ingabire writes: > > > > Does anyone know what is going on here? As I can't understand why we do > > receive a lot of these messages in our logs. > > > > Jul 22 14:18:21 ns1 named[13045]: client 200.222.123.108#43576: query > > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > > > [...] > > I'm the zone owner of verteiltesysteme.net. What you're seeing there are > queries by open resolvers (more accurately: forwarders of open resolvers). > > This is part of a research project to measure the effect of the DNS > injection censorship method. www.minghui.org is a name being blocked by > by the Great Firewall of China via DNS injection. By querying for > www.minghui.org.SUFFIX we can test whether the open resolver has a > clean, uncensored path to your TLD nameservers. How do you do that with a broken delegation? Did you think to ask before delegating a zone to a zone not configured for it? What does your Chancellor think about using uninformed third parties for experiments like this? > I'll add the addresses of .rw to our blacklist, so you won't be seeing > any more of these queries. Sorry for inconvenience. > > Let me know if you have further questions. > > Regards, > Matthaus Wander > > -- > University Duisburg-Essen > Verteilte Systeme > Bismarckstr. 90 / BC 316 > 47057 Duisburg -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Question about cache reload
In message , Stanley We ilnau writes: > I have just set up DNSSEC on bind 9.9.3. I had set up the zone and put a DS > record out at the registrar. Several days later I found that I had set up th > e keys incorrectly using only NSEC verses NSEC3 so i changed the keys. I del > eted the old keys and DS record, and had bind resign everything and put out t > he new DS record. I used some testing sites and things looked good. I then > got a message from an administrator at a remote site running bind in strict m > ode stating my DNSSEC was broken. It turns out he had cached the old info an > d it had not updated. From this I am guessing that bind does not flush cache > if there is a problem like this, it just fails to resolve. > > The other question I am attempting to research is what is the best way to do > the yearly rekeying and updating of the DS records at the registrar to avoid > this in the future. > > -- > Stanley Weilnau You have NEVER been able to change anything in the DNS instananeously. DNSSEC just makes that more obvious as you get big breakages instead of little breakages. For example when you are changing nameservers the old servers should be configured to serve the new zone content with the new nameservers and the old nameservers only get turned off when once all the cached NS records referring to them have expired. If you don't do that caches can continue to query the old servers forever. Firstly you should not use NSEC3 unless you NEED to use NSEC3, NSEC is more than sufficient for most zones. NSEC3 is more expensive for both servers and clients. 99.999% of zones (forward and reverse) DO NOT need to use NSEC3. They derive NO benefit from NSEC3 compared to using NSEC. In most case NSEC3 is actually a negative as not only is is more computationally expensive it is harder to debug. NSEC3 is pointless for IP6.ARPA, IN-ADDR.ARPA and any other similarly structured zones. The structure defeats any attempt to prevent zone walking. For most forward zones preventing zone walking does NOTHING except give warm fuzzy feelings. It does NOT make your machines any safer. Yes I know that this is against all the advice you have received in the past but really it doesn't appreciably help and you are deluding yourself if you think it does. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NAMED LOGS
Hi, Grace Ingabire writes: > > Does anyone know what is going on here? As I can't understand why we do > receive a lot of these messages in our logs. > > Jul 22 14:18:21 ns1 named[13045]: client 200.222.123.108#43576: query > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > [...] I'm the zone owner of verteiltesysteme.net. What you're seeing there are queries by open resolvers (more accurately: forwarders of open resolvers). This is part of a research project to measure the effect of the DNS injection censorship method. www.minghui.org is a name being blocked by by the Great Firewall of China via DNS injection. By querying for www.minghui.org.SUFFIX we can test whether the open resolver has a clean, uncensored path to your TLD nameservers. I'll add the addresses of .rw to our blacklist, so you won't be seeing any more of these queries. Sorry for inconvenience. Let me know if you have further questions. Regards, Matthäus Wander -- Universität Duisburg-Essen Verteilte Systeme Bismarckstr. 90 / BC 316 47057 Duisburg smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: New warning message...
On Mon, 2013-07-22 at 08:50 -0500, Barry S. Finkel wrote: > > This was discussed here already, and imho this is anti-spf bullshit like > > all those "spf breaks forwarding" FUD. The SPF RR is already here and is > > preferred over TXT that is generik RR type, unlike SPF. > > > It is not Fear, Uncertainty, and Doubt that "SPF breaks forwarding". > SPF *DOES* break forwarding. I have a case I am researching right now > where forwarded mail is undeliverable due to SPF checking at the > new destination. > Nothing is perfect, every single gmail user coming via mailing lists also fails DKIM. There is no magic answer, but I wish more would enforce SPF, especially banks, but cant expect them to have any clue, their only expertise is ripping people off. signature.asc Description: This is a digitally signed message part ___ Please visit https://lists.isc.org/mailman/listinfo/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: NAMED LOGS
s210.ip4.verteiltesysteme.net has been delegated to you. See the address records in the referral. Complain to the parent zone administrators if this is in error otherwise configure your system to serve s210.ip4.verteiltesysteme.net. P.S. It would have helped matters if you had given the address of the name server receiving the queries. Fortunately there was enough in the logs to determine that you are a server for ORG.RW (ns1.ricta.ORG.RW 41.74.173.250) which gave a set of IP address to check. Mark ; <<>> DiG 9.10.0pre-alpha <<>> www.minghui.org.s210.ip4.verteiltesysteme.net @134.91.78.137 +norec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33218 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.minghui.org.s210.ip4.verteiltesysteme.net. IN A ;; AUTHORITY SECTION: s210.ip4.verteiltesysteme.net. 3600 IN NS ns.s210.ip4.verteiltesysteme.net. ;; ADDITIONAL SECTION: ns.s210.ip4.verteiltesysteme.net. 3600 IN A 41.74.173.250 ns.s210.ip4.verteiltesysteme.net. 3600 IN 2001:638:501:8efc::137 ;; Query time: 422 msec ;; SERVER: 134.91.78.137#53(134.91.78.137) ;; WHEN: Tue Jul 23 08:02:44 EST 2013 ;; MSG SIZE rcvd: 135 In message <011c01ce86d6$0b9bdb50$22d391f0$@ricta.org.rw>, "Grace Ingabire" wri tes: > > Dear Team, > > > > Does anyone know what is going on here? As I can't understand why we do > receive a lot of these messages in our logs. > > > > Jul 22 14:18:21 ns1 named[13045]: client 200.222.123.108#43576: query > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:21 ns1 named[13045]: client 201.228.140.4#25482: query (cache) > 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:21 ns1 named[13045]: client 201.228.139.161#63987: query > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:21 ns1 named[13045]: client 46.39.192.1#39972: query (cache) > 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:21 ns1 named[13045]: client 201.228.139.162#48785: query > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:21 ns1 named[13045]: client 200.148.23.5#37623: query (cache) > 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:21 ns1 named[13045]: client 177.19.209.110#64974: query (cache) > 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:21 ns1 named[13045]: client 200.45.48.238#30572: query (cache) > 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:21 ns1 named[13045]: client 200.45.191.41#24254: query (cache) > 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:22 ns1 named[13045]: client 46.39.192.1#6612: query (cache) > 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:22 ns1 named[13045]: client 200.222.123.108#23817: query > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:22 ns1 named[13045]: client 82.209.195.12#61851: query (cache) > 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:22 ns1 named[13045]: client 41.74.171.185#11223: update > forwarding 'org.rw/IN' denied > > Jul 22 14:18:22 ns1 named[13045]: client 78.136.107.50#58919: query (cache) > 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:22 ns1 named[13045]: client 46.140.67.168#37418: query (cache) > 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:22 ns1 named[13045]: client 200.40.220.201#4560: query (cache) > 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:22 ns1 named[13045]: client 118.69.241.180#23006: query (cache) > 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:22 ns1 named[13045]: client 84.232.1.100#52278: query (cache) > 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:23 ns1 named[13045]: client 195.229.242.133#46507: query > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:23 ns1 named[13045]: client 200.40.220.194#23686: query (cache) > 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:23 ns1 named[13045]: client 46.39.192.1#28150: query (cache) > 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:23 ns1 named[13045]: client 84.232.1.100#61843: query (cache) > 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:23 ns1 named[13045]: client 202.248.197.77#37917: query (cache) > 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:23 ns1 named[13045]: client 61.220.10.137#1475: query (cache) > 'www.minghui.org.s210.ip4.verteilt
Re: New warning message...
On Jul 22, 2013, at 1:24 PM, Barry S. Finkel wrote:
> On 7/22/2013 11:17 AM, bind-users-requ...@lists.isc.org wrote:
This was discussed here already, and imho this is anti-spf bullshit like
>>all those "spf breaks forwarding" FUD. The SPF RR is already here and is
>>preferred over TXT that is generik RR type, unlike SPF.
>> On 22.07.13 08:50, Barry S. Finkel wrote:
>>> >It is not Fear, Uncertainty, and Doubt that "SPF breaks forwarding".
>>> >SPF*DOES* break forwarding.
>
>> No, it does not. If a mail gets delivered to address, which is sending it
>> further ("forwarding it"), the envelope sender has to be changed, because
>> it's not the original sender who sends the another mail. Forwarding without
>> changing envelope address is already broken, it's just people don't care
>> without SPF.
>
>>> > I have a case I am researching right now
>>> >where forwarded mail is undeliverable due to SPF checking at the
>>> >new destination.
>> Rewrite the sender's address. You have more choices, SRS is one of them.
>>
>> -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
>
> I have no control over what my Mail User Agent does. And a quick reading
> of section 3.6.6 of RFC 5322 does not tell me what is the correct action
> on a forwarded message:
>
> 1) Change the "From:" address, or
>
> 2) Keep the "From:" address.
>
> My MUA, Thunderbird, does 1). And I do not see any configuration
> option. I am not sure which action is "correct".
>
> I do not know what implications for forwarding SMTP (RFC 5321) has.
Do not be confused by the From: address shown by your mail client. That is not
the envelope sender.
Chris
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Question about cache reload
I have just set up DNSSEC on bind 9.9.3. I had set up the zone and put a DS record out at the registrar. Several days later I found that I had set up the keys incorrectly using only NSEC verses NSEC3 so i changed the keys. I deleted the old keys and DS record, and had bind resign everything and put out the new DS record. I used some testing sites and things looked good. I then got a message from an administrator at a remote site running bind in strict mode stating my DNSSEC was broken. It turns out he had cached the old info and it had not updated. From this I am guessing that bind does not flush cache if there is a problem like this, it just fails to resolve. The other question I am attempting to research is what is the best way to do the yearly rekeying and updating of the DS records at the registrar to avoid this in the future. -- Stanley Weilnau ___ Please visit https://lists.isc.org/mailman/listinfo/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: New warning message...
On 7/22/2013 11:17 AM, bind-users-requ...@lists.isc.org wrote:
This was discussed here already, and imho this is anti-spf bullshit like
>>all those "spf breaks forwarding" FUD. The SPF RR is already here and is
>>preferred over TXT that is generik RR type, unlike SPF.
On 22.07.13 08:50, Barry S. Finkel wrote:
>It is not Fear, Uncertainty, and Doubt that "SPF breaks forwarding".
>SPF*DOES* break forwarding.
No, it does not. If a mail gets delivered to address, which is sending it
further ("forwarding it"), the envelope sender has to be changed, because
it's not the original sender who sends the another mail. Forwarding without
changing envelope address is already broken, it's just people don't care
without SPF.
> I have a case I am researching right now
>where forwarded mail is undeliverable due to SPF checking at the
>new destination.
Rewrite the sender's address. You have more choices, SRS is one of them.
-- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
I have no control over what my Mail User Agent does. And a quick reading
of section 3.6.6 of RFC 5322 does not tell me what is the correct action
on a forwarded message:
1) Change the "From:" address, or
2) Keep the "From:" address.
My MUA, Thunderbird, does 1). And I do not see any configuration
option. I am not sure which action is "correct".
I do not know what implications for forwarding SMTP (RFC 5321) has.
--Barry Finkel
___
Please visit https://lists.isc.org/mailman/listinfo/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: IPv4 not working reverse on > /24 cidr
I only mentioned rfc1918 as I am directly hosting them, versus my
upstream pointing cnames at me for other blocks. I didn't expect
anything different about them.
I thought, and it worked in the past (2008/2009 perhaps), that having
the full cidr notation and such in the named.conf files you are doing
the link.
e.g.
zone "0/27.1.10.10.IN-ADDR.ARPA" {
type master;
file "/usr/named/rev/10.10.1.0-27.rev";
};
And then that file announces
Origin 0/27.1.10.10.IN-ADDR.ARPA.
I always thought I had to break up the CIDR's into the proper blocks so
then my downstream customer can slave that partial zone. I don't want
them slaving 10.10.1/24... etc.. So to do that you break up the block
into all its parts, each with an origin, ttl, etc etc...
So now it appears I need both the 10.10.1.rev and each
10.10.1.XX-YY.rev file. Seems redundant.
Ryan Pavely
Net Access Corporation
http://www.nac.net/
On 7/22/2013 12:17 PM, Barry Margolin wrote:
In article ,
Ryan Pavely wrote:
So that would suggest any time any block > a /24 is hosted you must
actually host the parent zone, pointing to the larger cidr, and then
have your normal files for each cider in that block.
Of course. How else do you expect DNS to figure out that it should look
in the RFC 1918 zone? The CNAMEs are the link between the normal reverse
DNS name and the CIDR-style name. There's nothing automatic about RFC
1918.
___
Please visit https://lists.isc.org/mailman/listinfo/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: IPv4 not working reverse on > /24 cidr
On 22.07.13 12:29, Ryan Pavely wrote: I always thought I had to break up the CIDR's into the proper blocks so then my downstream customer can slave that partial zone. I don't want them slaving 10.10.1/24... etc.. So to do that you break up the block into all its parts, each with an origin, ttl, etc etc... So now it appears I need both the 10.10.1.rev and each 10.10.1.XX-YY.rev file. Seems redundant. It's not redundant. The /24 block owner has its own 1.10.10.in-addr.arpa zone which contains CNAMEs pointing to other zones. The clients have those "other zones" which the owner should slave. It's just recommended to give those zones names like 0/27.1.10.10.in-addr.arpa so it's clear what the zone does. Example is 1.1.10.10.in-addr.arpa CNAME 1.0/27.1.10.10.in-addr.arpa in the reverze zone. This will cause the lookups go to 0/27.1.10.10.in-addr.arpa maintained by the client. -- 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. BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease ___ Please visit https://lists.isc.org/mailman/listinfo/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: IPv4 not working reverse on > /24 cidr
In article , Ryan Pavely wrote: > So that would suggest any time any block > a /24 is hosted you must > actually host the parent zone, pointing to the larger cidr, and then > have your normal files for each cider in that block. Of course. How else do you expect DNS to figure out that it should look in the RFC 1918 zone? The CNAMEs are the link between the normal reverse DNS name and the CIDR-style name. There's nothing automatic about RFC 1918. -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: New warning message...
In article ,
Matus UHLAR - fantomas wrote:
> >>This was discussed here already, and imho this is anti-spf bullshit like
> >>all those "spf breaks forwarding" FUD. The SPF RR is already here and is
> >>preferred over TXT that is generik RR type, unlike SPF.
>
> On 22.07.13 08:50, Barry S. Finkel wrote:
> >It is not Fear, Uncertainty, and Doubt that "SPF breaks forwarding".
> >SPF *DOES* break forwarding.
>
> No, it does not. If a mail gets delivered to address, which is sending it
> further ("forwarding it"), the envelope sender has to be changed, because
> it's not the original sender who sends the another mail. Forwarding without
> changing envelope address is already broken, it's just people don't care
> without SPF.
>
> > I have a case I am researching right now
> >where forwarded mail is undeliverable due to SPF checking at the
> >new destination.
>
> Rewrite the sender's address. You have more choices, SRS is one of them.
They're talking about auto-forwarding, not people resending a message
they received. For instance, mail to bar...@alum.mit.edu is
automatically forwarded by the alum.mit.edu server to my ISP email
address. Many people also have vanity domains with auto-forwarding
enabled like this.
Who should the sender be changed to? AFAIK, it has never been standard
practice to rewrite the sender when simply forwarding to an alias, which
is what this is.
--
Barry Margolin
Arlington, MA
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: IPv4 not working reverse on > /24 cidr
Ryan Pavely
Net Access Corporation
http://www.nac.net/
On 7/22/2013 11:00 AM, Barry Margolin wrote:
In article ,
Ryan Pavely wrote:
Ok. What am I doing wrong? As far as I know this has worked for years
and sometime, weeks, months, years, ago it stopped.
This is for doing > /24 (greater in cidr smaller in size)
Example: we have a /25 that we host... and another /25 we host.. so we
split it up into smaller files unless we own the entire/24
The config is loaded.
Rndc reload reports all is well.
But a lookup fails.
Help?
BIND 9.9.3-P1 on Linux
== included file in named.conf
zone "128/27.1.10.10.IN-ADDR.ARPA" {
type master;
file "/usr/named/rev/10.10.1.128.rev";
};
Do you also have a 1.10.10.in-addr.arpa zone, and does it have all the
necessary CNAME records pointing x.1.10.10.in-addr.arpa to
x.128/27.1.10.10.in-addr.arpa?
I do not. 10.10.1.128/27 is a RFC1918 sample. In a real-world example
I also have some ATT address space 12.44.51.192/27 or so.. They point it
to me.
If I host a partial class, in this case 10.10.x.x I need to have a
parent file that cnames?
Am I correct I would do something like the following...
$GENERATE 128-160 $ CNAME $.128/27.1.10.10.IN-ADDR.ARPA.
What about when the block is already cnamed -> pointed -> delegated to
my host from an external source?
I tested this. It appears to be true. Interesting.
So that would suggest any time any block > a /24 is hosted you must
actually host the parent zone, pointing to the larger cidr, and then
have your normal files for each cider in that block.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: New warning message...
This was discussed here already, and imho this is anti-spf bullshit like
all those "spf breaks forwarding" FUD. The SPF RR is already here and is
preferred over TXT that is generik RR type, unlike SPF.
On 22.07.13 08:50, Barry S. Finkel wrote:
It is not Fear, Uncertainty, and Doubt that "SPF breaks forwarding".
SPF *DOES* break forwarding.
No, it does not. If a mail gets delivered to address, which is sending it
further ("forwarding it"), the envelope sender has to be changed, because
it's not the original sender who sends the another mail. Forwarding without
changing envelope address is already broken, it's just people don't care
without SPF.
I have a case I am researching right now
where forwarded mail is undeliverable due to SPF checking at the
new destination.
Rewrite the sender's address. You have more choices, SRS is one of them.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Fucking windows! Bring Bill Gates! (Southpark the movie)
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: IPv4 not working reverse on > /24 cidr
On Mon, 22 Jul 2013, Ryan Pavely wrote: Ryan Pavely Net Access Corporation http://www.nac.net/ So that would suggest any time any block > a /24 is hosted you must actually host the parent zone, pointing to the larger cidr, and then have your normal files for each cider in that block. This was on the list a few days ago: https://dougbarton.us/DNS/2317.html Dave -- David Forrest St. Louis, Missouri ___ Please visit https://lists.isc.org/mailman/listinfo/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: IPv4 not working reverse on > /24 cidr
In article ,
Ryan Pavely wrote:
> Ok. What am I doing wrong? As far as I know this has worked for years
> and sometime, weeks, months, years, ago it stopped.
>
> This is for doing > /24 (greater in cidr smaller in size)
> Example: we have a /25 that we host... and another /25 we host.. so we
> split it up into smaller files unless we own the entire/24
>
>
> The config is loaded.
> Rndc reload reports all is well.
> But a lookup fails.
>
> Help?
>
>
> BIND 9.9.3-P1 on Linux
>
> == included file in named.conf
> zone "128/27.1.10.10.IN-ADDR.ARPA" {
> type master;
> file "/usr/named/rev/10.10.1.128.rev";
> };
Do you also have a 1.10.10.in-addr.arpa zone, and does it have all the
necessary CNAME records pointing x.1.10.10.in-addr.arpa to
x.128/27.1.10.10.in-addr.arpa?
--
Barry Margolin
Arlington, MA
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
IPv4 not working reverse on > /24 cidr
Ok. What am I doing wrong? As far as I know this has worked for years
and sometime, weeks, months, years, ago it stopped.
This is for doing > /24 (greater in cidr smaller in size)
Example: we have a /25 that we host... and another /25 we host.. so we
split it up into smaller files unless we own the entire/24
The config is loaded.
Rndc reload reports all is well.
But a lookup fails.
Help?
BIND 9.9.3-P1 on Linux
== included file in named.conf
zone "128/27.1.10.10.IN-ADDR.ARPA" {
type master;
file "/usr/named/rev/10.10.1.128.rev";
};
--
Ryan Pavely
Net Access Corporation
http://www.nac.net/
___
Please visit https://lists.isc.org/mailman/listinfo/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: NAMED LOGS
> Date: Mon, 22 Jul 2013 14:21:51 +0200 From: "Grace Ingabire" Dear Team, Does anyone know what is going on here? As I can't understand why we do receive a lot of these messages in our logs. Jul 22 14:18:21 ns1 named[13045]: client 200.222.123.108#43576: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:21 ns1 named[13045]: client 201.228.140.4#25482: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:21 ns1 named[13045]: client 201.228.139.161#63987: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:21 ns1 named[13045]: client 46.39.192.1#39972: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:21 ns1 named[13045]: client 201.228.139.162#48785: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:21 ns1 named[13045]: client 200.148.23.5#37623: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:21 ns1 named[13045]: client 177.19.209.110#64974: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:21 ns1 named[13045]: client 200.45.48.238#30572: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:21 ns1 named[13045]: client 200.45.191.41#24254: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:22 ns1 named[13045]: client 46.39.192.1#6612: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:22 ns1 named[13045]: client 200.222.123.108#23817: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:22 ns1 named[13045]: client 82.209.195.12#61851: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:22 ns1 named[13045]: client 41.74.171.185#11223: update forwarding 'org.rw/IN' denied Jul 22 14:18:22 ns1 named[13045]: client 78.136.107.50#58919: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:22 ns1 named[13045]: client 46.140.67.168#37418: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:22 ns1 named[13045]: client 200.40.220.201#4560: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:22 ns1 named[13045]: client 118.69.241.180#23006: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:22 ns1 named[13045]: client 84.232.1.100#52278: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 195.229.242.133#46507: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 200.40.220.194#23686: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 46.39.192.1#28150: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 84.232.1.100#61843: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 202.248.197.77#37917: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 61.220.10.137#1475: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 46.39.192.1#57197: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 46.39.192.1#35102: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 189.1.87.5#42806: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 196.3.132.118#21462: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 74.125.178.21#56160: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:24 ns1 named[13045]: client 201.228.140.7#64057: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:24 ns1 named[13045]: client 200.168.137.39#41361: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:24 ns1 named[13045]: client 189.1.84.126#63800: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:24 ns1 named[13045]: client 201.228.140.7#40111: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:24 ns1 named[13045]: client 200.168.137.39#28376: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:25 ns1 named[13045]: client 46.39.192.1#36140: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:25 ns1 named[13045]: client 46.39
Re: NAMED LOGS
On 07/22/13 20:21, Grace Ingabire wrote: Dear Team, Does anyone know what is going on here? As I can’t understand why we do receive a lot of these messages in our logs. Jul 22 14:18:21 ns1 named[13045]: client 200.222.123.108#43576: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:21 ns1 named[13045]: client 201.228.140.4#25482: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:21 ns1 named[13045]: client 201.228.139.161#63987: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:21 ns1 named[13045]: client 46.39.192.1#39972: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:21 ns1 named[13045]: client 201.228.139.162#48785: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:21 ns1 named[13045]: client 200.148.23.5#37623: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:21 ns1 named[13045]: client 177.19.209.110#64974: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:21 ns1 named[13045]: client 200.45.48.238#30572: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:21 ns1 named[13045]: client 200.45.191.41#24254: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:22 ns1 named[13045]: client 46.39.192.1#6612: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:22 ns1 named[13045]: client 200.222.123.108#23817: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:22 ns1 named[13045]: client 82.209.195.12#61851: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:22 ns1 named[13045]: client 41.74.171.185#11223: update forwarding 'org.rw/IN' denied Jul 22 14:18:22 ns1 named[13045]: client 78.136.107.50#58919: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:22 ns1 named[13045]: client 46.140.67.168#37418: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:22 ns1 named[13045]: client 200.40.220.201#4560: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:22 ns1 named[13045]: client 118.69.241.180#23006: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:22 ns1 named[13045]: client 84.232.1.100#52278: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 195.229.242.133#46507: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 200.40.220.194#23686: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 46.39.192.1#28150: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 84.232.1.100#61843: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 202.248.197.77#37917: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 61.220.10.137#1475: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 46.39.192.1#57197: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 46.39.192.1#35102: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 189.1.87.5#42806: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 196.3.132.118#21462: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 74.125.178.21#56160: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied
Re: New warning message...
This was discussed here already, and imho this is anti-spf bullshit like all those "spf breaks forwarding" FUD. The SPF RR is already here and is preferred over TXT that is generik RR type, unlike SPF. It is not Fear, Uncertainty, and Doubt that "SPF breaks forwarding". SPF *DOES* break forwarding. I have a case I am researching right now where forwarded mail is undeliverable due to SPF checking at the new destination. --Barry Finkel ___ Please visit https://lists.isc.org/mailman/listinfo/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: NAMED LOGS
It looks like those clients are trying to query your DNS server for www.minghui.org.s210.ip4.verteiltesysteme.net and are being denied. Steve On 22 July 2013 13:21, Grace Ingabire wrote: > Dear Team, > > ** ** > > Does anyone know what is going on here? As I can’t understand why we do > receive a lot of these messages in our logs. > > ** ** > > Jul 22 14:18:21 ns1 named[13045]: client 200.222.123.108#43576: query > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:21 ns1 named[13045]: client 201.228.140.4#25482: query > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:21 ns1 named[13045]: client 201.228.139.161#63987: query > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:21 ns1 named[13045]: client 46.39.192.1#39972: query (cache) ' > www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:21 ns1 named[13045]: client 201.228.139.162#48785: query > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:21 ns1 named[13045]: client 200.148.23.5#37623: query (cache) > 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:21 ns1 named[13045]: client 177.19.209.110#64974: query > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:21 ns1 named[13045]: client 200.45.48.238#30572: query > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:21 ns1 named[13045]: client 200.45.191.41#24254: query > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:22 ns1 named[13045]: client 46.39.192.1#6612: query (cache) ' > www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:22 ns1 named[13045]: client 200.222.123.108#23817: query > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:22 ns1 named[13045]: client 82.209.195.12#61851: query > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:22 ns1 named[13045]: client 41.74.171.185#11223: update > forwarding 'org.rw/IN' denied > > Jul 22 14:18:22 ns1 named[13045]: client 78.136.107.50#58919: query > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:22 ns1 named[13045]: client 46.140.67.168#37418: query > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:22 ns1 named[13045]: client 200.40.220.201#4560: query > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:22 ns1 named[13045]: client 118.69.241.180#23006: query > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:22 ns1 named[13045]: client 84.232.1.100#52278: query (cache) > 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:23 ns1 named[13045]: client 195.229.242.133#46507: query > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:23 ns1 named[13045]: client 200.40.220.194#23686: query > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:23 ns1 named[13045]: client 46.39.192.1#28150: query (cache) ' > www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:23 ns1 named[13045]: client 84.232.1.100#61843: query (cache) > 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:23 ns1 named[13045]: client 202.248.197.77#37917: query > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:23 ns1 named[13045]: client 61.220.10.137#1475: query > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:23 ns1 named[13045]: client 46.39.192.1#57197: query (cache) ' > www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:23 ns1 named[13045]: client 46.39.192.1#35102: query (cache) ' > www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:23 ns1 named[13045]: client 189.1.87.5#42806: query (cache) ' > www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:23 ns1 named[13045]: client 196.3.132.118#21462: query > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:23 ns1 named[13045]: client 74.125.178.21#56160: query > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:24 ns1 named[13045]: client 201.228.140.7#64057: query > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:24 ns1 named[13045]: client 200.168.137.39#41361: query > (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Jul 22 14:18:24 ns1 named[13045]: client 189.1.84.126#63800: query (cache) > 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied > > Ju
NAMED LOGS
Dear Team, Does anyone know what is going on here? As I can't understand why we do receive a lot of these messages in our logs. Jul 22 14:18:21 ns1 named[13045]: client 200.222.123.108#43576: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:21 ns1 named[13045]: client 201.228.140.4#25482: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:21 ns1 named[13045]: client 201.228.139.161#63987: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:21 ns1 named[13045]: client 46.39.192.1#39972: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:21 ns1 named[13045]: client 201.228.139.162#48785: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:21 ns1 named[13045]: client 200.148.23.5#37623: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:21 ns1 named[13045]: client 177.19.209.110#64974: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:21 ns1 named[13045]: client 200.45.48.238#30572: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:21 ns1 named[13045]: client 200.45.191.41#24254: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:22 ns1 named[13045]: client 46.39.192.1#6612: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:22 ns1 named[13045]: client 200.222.123.108#23817: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:22 ns1 named[13045]: client 82.209.195.12#61851: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:22 ns1 named[13045]: client 41.74.171.185#11223: update forwarding 'org.rw/IN' denied Jul 22 14:18:22 ns1 named[13045]: client 78.136.107.50#58919: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:22 ns1 named[13045]: client 46.140.67.168#37418: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:22 ns1 named[13045]: client 200.40.220.201#4560: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:22 ns1 named[13045]: client 118.69.241.180#23006: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:22 ns1 named[13045]: client 84.232.1.100#52278: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 195.229.242.133#46507: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 200.40.220.194#23686: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 46.39.192.1#28150: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 84.232.1.100#61843: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 202.248.197.77#37917: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 61.220.10.137#1475: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 46.39.192.1#57197: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 46.39.192.1#35102: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 189.1.87.5#42806: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 196.3.132.118#21462: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:23 ns1 named[13045]: client 74.125.178.21#56160: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:24 ns1 named[13045]: client 201.228.140.7#64057: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:24 ns1 named[13045]: client 200.168.137.39#41361: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:24 ns1 named[13045]: client 189.1.84.126#63800: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:24 ns1 named[13045]: client 201.228.140.7#40111: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:24 ns1 named[13045]: client 200.168.137.39#28376: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:25 ns1 named[13045]: client 46.39.192.1#36140: query (cache) 'www.minghui.org.s210.ip4.verteiltesysteme.net/A/IN' denied Jul 22 14:18:25 ns1 named[13045]: client 46.39.192.1#13017: query (cache) 'www.minghui.org.s210.ip4.verteiltes
Re: New warning message...
On Mon, 22 Jul 2013, Jason Hellenthal wrote: It's exactly as it says... Instead of ... TXT "SPF ..." You now do ... SPF "SPF ..." On 22.07.13 11:26, G.W. Haywood wrote: Caution! The SPF record type is near enough dead. See in particular RFC6686 paragraph 5.6; paragraph 6.2; and Appendix A point 4. This was discussed here already, and imho this is anti-spf bullshit like all those "spf breaks forwarding" FUD. The SPF RR is already here and is preferred over TXT that is generik RR type, unlike SPF. -- 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. Emacs is a complicated operating system without good text editor. ___ Please visit https://lists.isc.org/mailman/listinfo/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: resolving-problem
On 07/21/13 17:55, Ejaz wrote: I have similar problem recently. Ejaz, I think your server can resolve the domain name correctly because it's resolv.conf set to a public dns server, try to resolve by itself and see what happen. About two month ago, my dns server have the similar problem on some domains, like cdn.sstatic.net, ecx.images-amazon.com and arduino.cc etc.. The nslookup will get "timeout" and bind debug log shows "host unreachable". here is part of bind error log: 08-Jul-2013 11:05:55.873 client: debug 3: client 183.12.39.180#52379: view publicad: query 08-Jul-2013 11:05:55.873 queries: info: client 183.12.39.180#52379: view publicad: query: arduino.cc IN A + 08-Jul-2013 11:05:55.873 security: debug 3: client 183.12.39.180#52379: view publicad: query (cache) 'arduino.cc/A/IN' approved 08-Jul-2013 11:05:55.873 client: debug 3: client 183.12.39.180#52379: view publicad: replace 08-Jul-2013 11:05:55.873 general: debug 3: clientmgr @0x8023b7000: createclients 08-Jul-2013 11:05:55.873 general: debug 3: clientmgr @0x8023b7000: recycle 08-Jul-2013 11:05:55.873 resolver: debug 1: createfetch: arduino.cc A 08-Jul-2013 11:05:55.873 client: debug 3: client @0x80a4cb500: udprecv 08-Jul-2013 11:05:55.873 resolver: debug 3: fctx 0x814004000(arduino.cc/A'): create 08-Jul-2013 11:05:55.873 resolver: debug 3: fctx 0x814004000(arduino.cc/A'): join 08-Jul-2013 11:05:55.873 resolver: debug 3: fetch 0x802242040 (fctx 0x814004000(arduino.cc/A)): crea ted 08-Jul-2013 11:05:55.873 resolver: debug 3: fctx 0x814004000(arduino.cc/A'): start 08-Jul-2013 11:05:55.873 resolver: debug 3: fctx 0x814004000(arduino.cc/A'): try 08-Jul-2013 11:05:55.873 resolver: debug 3: fctx 0x814004000(arduino.cc/A'): cancelqueries 08-Jul-2013 11:05:55.873 resolver: debug 3: fctx 0x814004000(arduino.cc/A'): getaddresses 08-Jul-2013 11:05:55.873 resolver: debug 3: fctx 0x814004000(arduino.cc/A'): query 08-Jul-2013 11:05:55.873 resolver: debug 3: resquery 0x81400a000 (fctx 0x814004000(arduino.cc/A)): s end 08-Jul-2013 11:05:55.873 resolver: debug 3: resquery 0x81400a000 (fctx 0x814004000(arduino.cc/A)): s ent 08-Jul-2013 11:05:55.873 resolver: debug 3: resquery 0x81400a000 (fctx 0x814004000(arduino.cc/A)): u dpconnected 08-Jul-2013 11:05:55.873 resolver: debug 3: fctx 0x814004000(arduino.cc/A'): add_bad 08-Jul-2013 11:05:55.873 lame-servers: info: host unreachable resolving 'arduino.cc/A/IN': 2607:f0d0 :1004:82::4#53 08-Jul-2013 11:05:55.873 resolver: debug 3: fctx 0x814004000(arduino.cc/A'): cancelquery I think there is same problem with this post, somebody can help? -- -- LiuGN ___ Please visit https://lists.isc.org/mailman/listinfo/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: New warning message...
Hi there, On Mon, 22 Jul 2013, Jason Hellenthal wrote: It's exactly as it says... Instead of ... TXT "SPF ..." You now do ... SPF "SPF ..." Caution! The SPF record type is near enough dead. See in particular RFC6686 paragraph 5.6; paragraph 6.2; and Appendix A point 4. -- 73, Ged. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
