Re: broken ISP in china

[Sten Carlsen]

Just be sure that WHEN your master dies, the slaves will stay
authoritative for long enough that you can get the master up without
working night shift.

On 19/02/13 21:17, Dave Warren wrote:
> On 2/18/2013 23:20, Matus UHLAR - fantomas wrote:
>> On 19.02.13 10:25, Noel Butler wrote:
>>> One thing I need to point out, your SOA timings seem extreme...
>>>
>>> refresh 86400  drop that to 3h
>>> retry 3600, drop to 900
>>
>> I don't see the reason for doing these, unless NOTIFY does not work,
>> but in
>> such case it's the NOTIFY that should be fixed...
>
> I agree in principle. However, the costs of having a low refresh
> probably aren't that significant, whereas all it takes for a NOTIFY to
> get missed is a packet or three getting dropped, and having zones out
> of sync might be more significant.
>
> Or, put another way, dropping REFRESH from 24 hours to 3 hours is
> what, an additional 8 DNS queries per zone, per secondary, per day?
> Unless your zones normally receive only a few hundred queries a day,
> these numbers are so trivial that they probably don't matter, whereas
> having your secondaries return out of date responses is potentially
> more annoying.
>
> Retry too seems like a good candidate to keep very low since it only
> applies when there is a problem.
>
> But in an ideal world, we've probably just spent more time talking
> about it than will result in any savings from tweaking these numbers.
>

-- 
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: broken ISP in china

[Dave Warren]

On 2/18/2013 23:20, Matus UHLAR - fantomas wrote:

On 19.02.13 10:25, Noel Butler wrote:

One thing I need to point out, your SOA timings seem extreme...

refresh 86400  drop that to 3h
retry 3600, drop to 900


I don't see the reason for doing these, unless NOTIFY does not work, 
but in

such case it's the NOTIFY that should be fixed...


I agree in principle. However, the costs of having a low refresh 
probably aren't that significant, whereas all it takes for a NOTIFY to 
get missed is a packet or three getting dropped, and having zones out of 
sync might be more significant.


Or, put another way, dropping REFRESH from 24 hours to 3 hours is what, 
an additional 8 DNS queries per zone, per secondary, per day? Unless 
your zones normally receive only a few hundred queries a day, these 
numbers are so trivial that they probably don't matter, whereas having 
your secondaries return out of date responses is potentially more annoying.


Retry too seems like a good candidate to keep very low since it only 
applies when there is a problem.


But in an ideal world, we've probably just spent more time talking about 
it than will result in any savings from tweaking these numbers.


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

Re: broken ISP in china

[G.W. Haywood]

Hi there,

On Mon, 18 Feb 2013, Vernon Schryver wrote:


...


Recently I moved this domain(lcrcomputer.net) to a registrar that 
suports DNSSEC and inserted the DS record for this domain.  I checked 
DNSSEC via  http://dnsviz.net and 
http://dnssec-debugger.verisignlabs.com.  Both show DNSSEC is working 
just fine for lcrcomputer.net.


However, shortly after that one of my customers stopped receiving email 
from one of their clients in China.  They just brought that to my 
attention and I tried to email the client in China and got this back:


For  , Site 
(x.com.cn/) said: 559 sorry , your helo/ehlo and 
domain in mail are invalid, you don't connect from there. (#5.5.9)


This looks like an SPF issue.  It isn't possible to say for sure as
you've removed the information that's needed.

Your SPF record needs to be fixed anyway.  Remove at least "mx" and
"ptr" and preferably "a" as well so that there are no unnecessary DNS
lookups when your SPF record is checked.  Ideally a recipient server
needs only to know that the IP of the mail server sending the mail is
permitted to send mail on behalf of the domain to which the sending
server claims to belong.  This is a very efficient means of detecting
mail forgery -- if only it is used correctly.

On Mon, 18 Feb 2013, Vernon Schryver wrote:


I've not tried p=none, but recent experiments with
  300  TXT  "v=spf1 mx -all"


Don't use 'mx' in SPF records.

I do have experience of having a domain name used in forged mail, and I
can guarantee that you don't want the same experience.  Other than that
I'll avoid being drawn into an off-topic debate on the value of SPF.

--

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

Re: broken ISP in china

[Matus UHLAR - fantomas]

On 19.02.13 10:25, Noel Butler wrote:

One thing I need to point out, your SOA timings seem extreme...

refresh 86400  drop that to 3h
retry 3600, drop to 900


I don't see the reason for doing these, unless NOTIFY does not work, but in
such case it's the NOTIFY that should be fixed...


expire 604800 change that to 4w


not needed but 


and negative cache value 86400  drop that to no more than 3600,
maybe even just use 600.


I agree with this one. Value 86400 for negative cache is widely used, but
mostly from obsolete understanding of SOA field name "minimum".

--
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.
The only substitute for good manners is fast reflexes. 
___

Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

OFF TOPIC Re: broken ISP in china

[Noel Butler]

apparently you have no comprehension of OFF TOPIC


I stopped reading at about the half dozen words because you once again
went off on your OFF TOPIC rants.

But each to our own, you hate it, many stand by it, its only fools like
you who cant accept that, thats your problem not mine.

Given that your reply to this will be even further off topic, I wont be
wasting my precious time with you any further.




On Tue, 2013-02-19 at 01:30 +, Vernon Schryver wrote:

> > I see no problem with your SPF IP records though so long as you dont try
> > use ns1. Ignoring most of Vernons anti SPF rhetoric, which  BTW this
> > list is NOT the place for  (go cry a river on mailop list), he is
> > correct that you shouldn't really be using PTR, or A for that mater,
> > just have your ip4: and ip6: ranges, and perhaps "mx" and along with
> > "-all"  you'll be fine, I have no problems with SPF and lists and have
> > been using it since very early days,
> 
> Instead of swallowing the SPF liturgy without chewing, use it and
> what anyone (including me) says as ideas for your own observations
> and tests.  Follow the DMARC instructions on http://www.dmarc.org/
> and get the DMARC reports telling you that your SPF -all prevents
> the delivery of some of your mail to this mailing list.
> 
> Then get Gmail and Hotmail mailboxes, configure Hotmail to forward
> to Gmail and send to Hotmail.  You will see in your DMARC reports
> from Google that your SPF -all causes your message to disappear in
> a blackhole between Gmail and Hotmail.
> 
> See also http://www.openspf.org/FAQ/Forwarding and note that neither
> Hotmail forwarding to Gmail nor many mailing lists including this
> list rewrite the sender addresses.  That has generally been considered
> a wrong thing to do since long before pobox.com existed.
> 
> Finally, look at the SPF records for AOL, Google, Yahoo, and Microsoft,
> and ask yourself whether those organizations don't care about SMTP
> forgery or don't believe SPF is an answer.  If they believed, wouldn't
> they use SPF -all?
> 
> > I have no problems with SPF and lists and have
> > been using it since very early days,
> 
> Maybe it was easier to ignore reality before DMARC.  On the other
> hand, http://www.openspf.org/FAQ/Forwarding is unambigous about
> the interaction of -all with mailing lists such as this.
> 
> 
> Vernon Schryverv...@rhyolite.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




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: broken ISP in china

[Vernon Schryver]

> I see no problem with your SPF IP records though so long as you dont try
> use ns1. Ignoring most of Vernons anti SPF rhetoric, which  BTW this
> list is NOT the place for  (go cry a river on mailop list), he is
> correct that you shouldn't really be using PTR, or A for that mater,
> just have your ip4: and ip6: ranges, and perhaps "mx" and along with
> "-all"  you'll be fine, I have no problems with SPF and lists and have
> been using it since very early days,

Instead of swallowing the SPF liturgy without chewing, use it and
what anyone (including me) says as ideas for your own observations
and tests.  Follow the DMARC instructions on http://www.dmarc.org/
and get the DMARC reports telling you that your SPF -all prevents
the delivery of some of your mail to this mailing list.

Then get Gmail and Hotmail mailboxes, configure Hotmail to forward
to Gmail and send to Hotmail.  You will see in your DMARC reports
from Google that your SPF -all causes your message to disappear in
a blackhole between Gmail and Hotmail.

See also http://www.openspf.org/FAQ/Forwarding and note that neither
Hotmail forwarding to Gmail nor many mailing lists including this
list rewrite the sender addresses.  That has generally been considered
a wrong thing to do since long before pobox.com existed.

Finally, look at the SPF records for AOL, Google, Yahoo, and Microsoft,
and ask yourself whether those organizations don't care about SMTP
forgery or don't believe SPF is an answer.  If they believed, wouldn't
they use SPF -all?

> I have no problems with SPF and lists and have
> been using it since very early days,

Maybe it was easier to ignore reality before DMARC.  On the other
hand, http://www.openspf.org/FAQ/Forwarding is unambigous about
the interaction of -all with mailing lists such as this.


Vernon Schryverv...@rhyolite.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

Re: [mailop] broken ISP in china

[Lyle Giese]

On 02/18/13 19:02, Tony Finch wrote:

Lyle Giese  wrote:

Recently I moved this domain(lcrcomputer.net) to a registrar that suports
DNSSEC and inserted the DS record for this domain.

Was it signed before this point? I am wondering if this is a DNS response
size problem - was the cause the addition of the DS record, or the
addition of DNSKEY and RRSIG records?

Tony.
The zone was signed before and was registered with ISC's look aside at 
dlv.isc.org and had been for quite a while(at least a year and maybe 
two).  I made NO changes to the lcrcomputer.net zone itself other than 
resign the data every 15 days. It appears to have broken on Feb 6th or 
so and that would have been about the time I inserted the DS record.  
The only change I have made was insert the DS record into my new 
registrar for publishing.


My customer's zone is not signed, has no DKIM and has no SPF records, 
never did.


But I am happy with this discussion as I get more than one set of eyes 
looking at what I have done and getting some opinions.  So I am getting 
back that nothing is really wrong.(yea a couple of things I could 
tweak..)  I had forgotten about those pesky SPF records and am happy to 
get rid of them!  I may do the same with the DKIM records also.


Thanks to everyone for the feedback.

Lyle Giese
LCR Computer Services, 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

Re: broken ISP in china

[Tony Finch]

Lyle Giese  wrote:
>
> Recently I moved this domain(lcrcomputer.net) to a registrar that suports
> DNSSEC and inserted the DS record for this domain.

Was it signed before this point? I am wondering if this is a DNS response
size problem - was the cause the addition of the DS record, or the
addition of DNSKEY and RRSIG records?

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
___
Please visit https://lists.isc.org/mailman/listinfo/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: broken ISP in china

[David Forrest]

On Mon, 18 Feb 2013, Lyle Giese wrote:

I am cross posting this as it might be a dns issue, but it effects email 
directly.  And I am quite aware of the 'Great Chinese Firewall' and realized 
that may be a large part of the issue.


LCR's mail filter and mail servers are all in the lcrcomputer.net domain.

Recently I moved this domain(lcrcomputer.net) to a registrar that suports 
DNSSEC and inserted the DS record for this domain.  I checked DNSSEC via 
http://dnsviz.net and http://dnssec-debugger.verisignlabs.com.  Both show 
DNSSEC is working just fine for lcrcomputer.net.


However, shortly after that one of my customers stopped receiving email from 
one of their clients in China.  They just brought that to my attention and I 
tried to email the client in China and got this back:


For  , Site 
(x.com.cn/) said: 559 sorry , your helo/ehlo and domain in 
mail are invalid, you don't connect from there. (#5.5.9)


Because this started within 24 hours of when I published the DS record for 
lcrcomputer.net, I am assuming that this is related.


Your nameserver seem to be answering fine in ipV6 +dnssec +norec: 
http://pastebin.com/S9LM6a59


Does your customer have a SPF record with old info (you show no TXT or SPF 
RRs) ?


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: broken ISP in china

[Noel Butler]

On Mon, 2013-02-18 at 16:07 -0600, Lyle Giese wrote:


> 
> Recently I moved this domain(lcrcomputer.net) to a registrar that
> suports DNSSEC and inserted the DS record for this domain.  I checked
> DNSSEC via  http://dnsviz.net and
> http://dnssec-debugger.verisignlabs.com.  Both show DNSSEC is working
> just fine for lcrcomputer.net.



dig +dnssec lcrcomputer.net ds

; <<>> DiG 9.9.2 <<>> +dnssec lcrcomputer.net ds
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1749
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

the AD flag says its all working good


> However, shortly after that one of my customers stopped receiving
> email from one of their clients in China.  They just brought that to
> my attention and I tried to email the client in China and got this
> back:
> 
> For , Site (x.com.cn/) said: 559
> sorry , your helo/ehlo and domain in mail are invalid, you don't
> connect from there. (#5.5.9)
> 
> Because this started within 24 hours of when I published the DS record
> for lcrcomputer.net, I am assuming that this is related.
> 


Ensure your SPF records are kept up to date, and yes this is why, you'll
need to wait till the TTL cache expires on their end.
I see no problem with your SPF IP records though so long as you dont try
use ns1. Ignoring most of Vernons anti SPF rhetoric, which  BTW this
list is NOT the place for  (go cry a river on mailop list), he is
correct that you shouldn't really be using PTR, or A for that mater,
just have your ip4: and ip6: ranges, and perhaps "mx" and along with
"-all"  you'll be fine, I have no problems with SPF and lists and have
been using it since very early days, I note though your DKIM fails which
is typical of mailing lists.

One thing I need to point out, your SOA timings seem extreme...

refresh 86400  drop that to 3h
retry 3600, drop to 900 
expire 604800 change that to 4w
and negative cache value 86400  drop that to no more than 3600,
maybe even just use 600.

Cheers



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: broken ISP in china

[Vernon Schryver]

> From: Lyle Giese 

> attention and I tried to email the client in China and got this back:
>
> For  , Site 
> (x.com.cn/) said: 559 sorry , your helo/ehlo and 
> domain in mail are invalid, you don't connect from there. (#5.5.9)
>
> Because this started within 24 hours of when I published the DS record 

I'd remove the TXT record for lcrcomputer.net and try again in 24
hours after your TTL expires.  In other words, could your SPF record
be triggering the mail problem?  What is the relationship between
medtecs.com.cn and x.com.cn?  If your mail must be forwarded
to reach ro...@medtecs.com.cn, then your SPF record demands that
it be rejected after the first hop.
I also wonder about the "ptr" mechanism in your SPF record.  RFC 4408
discourages the use of "ptr".  The Received: header added by ISC
was unhappy with your reverse DNS, although it looks ok to me now:

   Received: from mail3.lcrcomputer.net (unknown [IPv6:2607:fcb8:1800:7::3])
 by mx.pao1.isc.org (Postfix) with ESMTP
 for ; Mon, 18 Feb 2013 22:07:46 + (UTC)
 (envelope-from l...@lcrcomputer.net)

Contrary to the early marketing manure followed by the years of cult
chanting, outside the narrow situations where it can be handy, SPF is
useless and ignored (~all or ?all) or harmful (-all).  SPF can be
useful for authenticating bulk mail, although DKIM is better because
of SPF's problem with forwarding.  (Of course, plenty of bulk mail is
not spam, such as this message after it hits the reflector.  Bulk mail
is any set of practically identical messages.  Spam is bulk email that
is also unsolicited.)

If you turn on DMARC to get reports about rejections by adding something
like this line to your DNS zone:
  _dmarc 300 TXT  "v=DMARC1; p=none; rua=mailto:x...@lcrcomputer.com;";
and send again to this mailing list, then within days or a week, the
mailbox x...@lcrcomputer.com should get reports of mail that would have
been rejected by your SPF record.  If any of your correspondents forward
private mail from you to Google, Microsoft, or similar, you will also
get reports about those rejections.

I've not tried p=none, but recent experiments with 
  300  TXT  "v=spf1 mx -all"
   _dmarc 300  TXT  "v=DMARC1; p=reject; rua=mailto:x...@rhyolite.com;";
generated reports of my messages being rejected because they had been
forwarded by lists.isc.org.  Look at the headers for your copies of
your own messages to this mailing list and consider your SPF record.
(I use short TTLs on _dmarc and SPF RRs to remove them quickly.)

See http://www.dmarc.org/ about DMARC, but read it with marketing-speak
filters set to high.  For example, "DMARC Protects 60 Percent of Global
Consumer Mailboxes" makes sense only for a narrow meaning of "protect"
after you notice the absence of _dmarc records for Google, Yahoo, and
Microsoft.

See also http://www.dmarc.org/about.html   Some of the "receivers" on
that page probably send more mail than some of the "senders," so those
two words must have special meanings.  DMARC is evidently intended to let
"(bulk mail) senders" such as American Greetings, BoA, etc. monitor
and control their DKIM and SPF authenticators and check inbox placement
rates at "(bulk mail) receivers" such as AOL, Comcast, etc.

DMARC is also unintentionally great for showing the old "use SPF to
protect yourself from spammers" to be the marketing nonsense and cult
nonsense for in most cases that it has always been.


Vernon Schryverv...@rhyolite.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

Re: broken ISP in china

[Chuck Swiger]

Hi--

On Feb 18, 2013, at 2:07 PM, Lyle Giese wrote:
> Recently I moved this domain(lcrcomputer.net) to a registrar that suports 
> DNSSEC and inserted the DS record for this domain.  I checked DNSSEC via  
> http://dnsviz.net and http://dnssec-debugger.verisignlabs.com.  Both show 
> DNSSEC is working just fine for lcrcomputer.net.
> 
> However, shortly after that one of my customers stopped receiving email from 
> one of their clients in China.  They just brought that to my attention and I 
> tried to email the client in China and got this back:
> 
> For , Site (x.com.cn/) said: 559 sorry 
> , your helo/ehlo and domain in mail are invalid, you don't connect from 
> there. (#5.5.9)

You've removed too much of the error logging and context to reliably debug the 
issue.
Perhaps try asking postmas...@.com.cn to confirm that they are seeing 
current DNS records for your domain.

> Because this started within 24 hours of when I published the DS record for 
> lcrcomputer.net, I am assuming that this is related.
> 
> Had anyone else run across this?  Or do I have something misconfigured here?


Well, the nameserver at ns1.lcrcomputer.net aka 209.112.71.50 doesn't seem to 
be responding:

$ dig www.lcrcomputer.com @ns1.lcrcomputer.net
; <<>> DiG 9.6-ESV-R4-P3 <<>> www.lcrcomputer.com @ns1.lcrcomputer.net
;; global options: +cmd
;; connection timed out; no servers could be reached

That's not helping matters, but it shouldn't be fatal since the other two 
nameservers do seem to be responding.

Regards,
-- 
-Chuck

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

broken ISP in china

[Lyle Giese]

I am cross posting this as it might be a dns issue, but it effects email 
directly.  And I am quite aware of the 'Great Chinese Firewall' and 
realized that may be a large part of the issue.


LCR's mail filter and mail servers are all in the lcrcomputer.net domain.

Recently I moved this domain(lcrcomputer.net) to a registrar that 
suports DNSSEC and inserted the DS record for this domain.  I checked 
DNSSEC via  http://dnsviz.net and 
http://dnssec-debugger.verisignlabs.com.  Both show DNSSEC is working 
just fine for lcrcomputer.net.


However, shortly after that one of my customers stopped receiving email 
from one of their clients in China.  They just brought that to my 
attention and I tried to email the client in China and got this back:


For  , Site 
(x.com.cn/) said: 559 sorry , your helo/ehlo and 
domain in mail are invalid, you don't connect from there. (#5.5.9)


Because this started within 24 hours of when I published the DS record 
for lcrcomputer.net, I am assuming that this is related.


Had anyone else run across this?  Or do I have something misconfigured 
here?  I ran with DNSSEC against ISC's lookaside for a long time and 
published the necessary DNSSEC records and had no problem. This started 
right after I moved the domain registration and published a DS record 
for the domain.  I had already been publishing DNSSEC records and they 
checked out against ISC's lookaside stuff for quite a while.


Lyle Giese
LCR Computer Services, 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