Re: Frequent timeout
Hi, > >> tcpdump -s0 -n -i eth0 port domain -w /tmp/domaincapture.pcap > >> > >> You don't need all of the extra stuff because -s0 captures the full packet. > > On 06.09.18 18:42, Alex wrote: > >This is the command I ran to produce the pcap file I sent: > > > ># tcpdump -s0 -vv -i eth0 -nn -w domain-capture-eth0-090518.pcap udp > >dst port domain > > and that is the problem. "dst port domain" captures packets going to DNS > servers, not responses coming back. > > "-vv" and "-nn" are useless when producing packet capture and "-s0" is > default for some time. I often add "-U" so file is flushed wich each packet. > > you can strip incoming queries by using filter > > "(src host 68.195.XXX.45 and dst port domain) or (src port domain and dst > host 68.195.XXX.45)" I've generated a new tcpdump file using these criteria and uploaded it here: https://drive.google.com/file/d/1F0VML8yPZJbcDZTys2hXDhjzv1UaBHuV/view?usp=sharing The SERVFAIL errors didn't really occur over the weekend. I believe it has something to do with mail volume, link congestion/bandwidth utilization. Thanks, Alex > > >I should also mention that, while eth0 is the physical device, there > >is a bridge set up to support virtual machines (none of which were > >active). Hopefully that's not the reason! (real IP obscured). > > not the reason, but using "-i br0" could be safer then. > > Note that the IP was seen in packet capture you have published, not needed > to hide it now. > > -- > 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. > They that can give up essential liberty to obtain a little temporary > safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759 > ___ > Please visit https://lists.isc.org/mailman/listinfo/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 will eventually generate Identical Key ID's
On Sun, Sep 9, 2018 at 2:30 PM Anand Buddhdev wrote: > On 09/09/2018 19:51, Mark Elkins wrote: > > > Never assume a KeyID is unique. :-) > > One of the DNSSEC RFCs specifically says that the KeyID is not meant to > be unique. I can't remember which one, and it's too late on a Sunday > evening to be reading RFCs :) > You are thinking of RFC4034, Section 8. Security Considerations: The key tag is used to help select DNSKEY resource records efficiently, but it does not uniquely identify a single DNSKEY resource record. It is possible for two distinct DNSKEY RRs to have the same owner name, the same algorithm type, and the same key tag. An implementation that uses only the key tag to select a DNSKEY RR might select the wrong public key in some circumstances. Please see Appendix B for further details. > > Even then, I've had the misfortune of dealing with a vendor whose > developers didn't read the RFCs properly, and designed their key store > using the key IDs as indexes. So one fine day, we had a zone signed with > one key, but the DS record came from another key. Boom. Yuck. What a > mess it was to sort out! > > Oooh, that sounds like fun to debug W > Regards, > 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 > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Scaling Bind-DLZ
Hi, we are using with a quite good satisfaction Bind-DLZ (with Postgresql 9.6.4) on Bind9. I know, it is a quite old driver, but we know very well how does it work. Due to traffic increase, we are experiencing some visible delays when the number of concurrent queries per second reach the value of 800/900 qps. By reading the original documentation, in performances chapter it says: "... With a top speed of 759 Queries Per Second, the database was actually handling close to 2277 SQL select queries each second..." (http://bind-dlz.sourceforge.net/postgresql_perf.html) It seems that the original driver cannot scale, even though system resources are really plentiful? Is there a way to scale a bit better without moving away from Bind-DLZ? Thank you for the help, best regards! 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
Re: DNSSEC will eventually generate Identical Key ID's
Mark Elkins wrote: > Never assume a KeyID is unique. :-) Good tools ensure that key IDs are unique per zone. For example, if you keep generating keys for a zone with `dnssec-keygen` it will eventually get into an infinite loop perpetually generating colliding keys! Apart from the footgun that Anand described, the reason for keeping key IDs unique per zone is so that a validator can quickly skip keys that can't possibly match an RRSIG or DS record. Tony. -- f.anthony.n.finchhttp://dotat.at/ Tyne, Dogger, Fisher: Southwest 5 to 7. Slight or moderate in Tyne, otherwise moderate or rough. Showers then rain. Good, occasionally poor.___ Please visit https://lists.isc.org/mailman/listinfo/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 will eventually generate Identical Key ID's
On 09/09/2018 18:51, Mark Elkins wrote: > Just for the record, although I do look from a curiosity point of view > for Identical Key ID's once every few month - I've never seen them - > until now. > > Now I have them - generated by BIND within a few days of each other... > > I've been running DNSSEC for 7 years and have around 400 DNSSEC keys for > 133 signed Domains. > I'm a smallish Registrar for ZA domains. > > Never assume a KeyID is unique. :-) It's inevitable that they won't be. With only a 16 bit key tag space (and in 2016 Roy Arends discovered that the effective space is only 15 bits) then due to the birthday collision paradox you only need of the order of sqrt(32k) different keys to get a 50% chance of a collision. 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
