Re: bind-users Digest, Vol 1769, Issue 1
On 2/21/14 3:39 AM, houguanghua houguang...@hotmail.com wrote: kevin, How does the local name server learn where is the 'stealth' slave? For the 'stealth' slave isn't in the NS records. Also-notify directive. Either in an options stanza or a zone stanza. thanks, Guanghua -- Daniel J McDonald, CISSP # 78281 ___ Please visit https://lists.isc.org/mailman/listinfo/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/23/13 7:36 AM, Matus UHLAR - fantomas wrote:
In article mailman.881.1374508134.20661.bind-us...@lists.isc.org,
Matus UHLAR - fantomas wrote:
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.
On 22.07.13 12:22, Barry Margolin wrote:
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.
Ok, but in this case you are trusting alum.mit.edu as a forwarder. And it
is specific to you as the recipient, not all of the people in the world
getting your mail. So add them to trusted-hosts and apply spf before the
last trusted... Problem solved. Or add enough whitelist points to
counteract SPF problems when a /^Received.{5,40}\balum.mit.edu/ header is
found in your mail. In either case, you have to either trust your forwarder
to evaluate SPF for you and trust the SPF evaluation headers they insert, or
consider that forwarder part of your mail infrastructure and instruct your
spf evaluator to ignore those headers.
But again, that's your choice for outsourcing part of your mail solution to
another entity.
...OK this is off-topic here. However this was already discussed and the
conclusion was that the SPF record is NOT dead. We just need enough time to
deal with these issues.
--
Daniel J McDonald, CCIE # 2495, CISSP # 78281
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Reverse address entries
On 7/2/13 8:42 AM, Sam Wilson sam.wil...@ed.ac.uk wrote: There may be a subtle language thing going on here. I read the original post above as saying, literally, you need PTR records because various software tries to match A and PTR records. It doesn't say you need PTR records because some systems require PTR records (and if you have them they will also need to match the A records). PTR records are nice but they aren't a general requirement. Can anyone here give examples of the types of various software that will not operate without a PTR record? I've had trouble with OSI-Soft PI historian without reverse entries. If there is no reverse, then the PI software would spend about 30 seconds looking in vain for a DNS answer before sending a SYN-ACK packet. Since the embryonic timer on a Cisco firewall is usually 20 seconds, the sessions would simply not come up. I've seen similar things with openssh. The other place reverse DNS is routinely queried is SMTP. If you care enough to send mail, you should care enough to set up your reverse entries realistically so that spam filters will recognize that you are trying to actively manage your email server and this isn't mail from a BOT... Now that IS a reason to add PTR for IP address, and they must point to hostnames that point to the same IP. I agree that if PTR records exist then they should match an A record. My experience (and IIRC correctly the word of several RFCs) is that PTRs are not required for most things to work. Sam -- Daniel J McDonald, CCIE # 2495, CISSP # 78281 ___ Please visit https://lists.isc.org/mailman/listinfo/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: disabling lame server logging
On 2/26/13 10:43 AM, Sten Carlsen st...@s-carlsen.dk wrote: On 26/02/13 15:50, Robert Moskowitz wrote: I would expect that a namecaching server on the mailserver would reduce traffic and resources all the way around. I don't need my mailserver to constantly be asking my name server about, say, zen.spamhaus.org. This is one reason my mailserver has a DNS server. No forward, that only slows down things. The question here is whether there is a good reason that this instance must not go directly to the roots? In my opinion mail servers that receive outside mail should point to root servers and nothing internally. Particularly if you have spam filtering that relies on any sort of dns lookup. A message will cause a spam filter to produce a predictable set of queries, so someone who can come up with a bind vulnerability can force your mail server to make potentially vulnerable requests. If the vulnerability involves cache poisoning, then the malware authors would be able to pollute your internal DNS by convincing your spam filter to query crafted entries. That's not to say that there is currently any cache-poisoning vulnerability that someone might exploit, or that any current malware makes use of this two-phase approach to exploit desktops. But why take the risk when setting up bind as a recursive server pointing at roots is so trivial? -- Daniel J McDonald, CCIE # 2495, CISSP # 78281 ___ Please visit https://lists.isc.org/mailman/listinfo/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: Export / Import all zone data
On 2/14/13 1:46 PM, Mailinglists mailingli...@wso.net wrote: I'm looking to migrate all of the zone data from one installation of Bind to another...hardware move. One machine is very old but running a pretty modern version of Bind 9.6-ESV-R8. The other server is running Bind 9.8.2 and is in use, so I'm merging existing zone data with new data, although none of the zones will overlap. The problem I see is that the actual zone files, the way they are structured, are in an old format. Bind 9.6 must still understand them, but I don't think they are structured the proper way. I was hopeful there was an export / import procedure whereby that process would sanitize the zone info and log any errors for manual fixing. Just make the new server a slave of the old one, let it do zone transfers of all of the old zones, then change the config on the new one from slave to master. -- Daniel J McDonald, CCIE # 2495, CISSP # 78281 ___ Please visit https://lists.isc.org/mailman/listinfo/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: transparent DNS load-balancing with a Cisco ACE
On 10/19/12 1:25 PM, John Miller johnm...@brandeis.edu wrote: Hello everyone, Perhaps a Cisco list is a better destination for this, but I've seen a similar post here in the past couple of months, so posting here as well. I'm trying to get our Cisco ACE set up appropriately to handle DNS traffic. So far, I've gotten it working using NAT (each rserver has a public and a private IP) and using transparent load-balancing (ACE talks directly to the public IP), aka direct server return. I've not bothered with nat - just place rservers with unique addresses behind the ACE, let them use the ACE as their default gateway, and then publish a vip. The rservers use their real address for zone transfers with the master, while clients only talk with the vip address. -- Daniel J McDonald, CCIE # 2495, CISSP # 78281 ___ Please visit https://lists.isc.org/mailman/listinfo/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:
On 5/7/12 8:29 AM, hugo hugoo hugo...@hotmail.com wrote: Dear all, I have the following situation in my zone migration for one server (A) to another server (B) The zone is called toto.be and contains the following record: www.toto.be 86400 IN CNAME www.titi.be == the zone titi.be is in the same server (A) but is not transferred to the server (B). I am assuming here that server B is not set up for recursion. If I do a dig @SERVER(A) www.toto.be == I receive the IP corresponding to www.titi.be The extra information is provided when it is known. If I do a dig @SERVER(B) www.toto.be == I do not receive the IP corresponding to www.titi.be Since there is no recursion allowed, all SERVER(B) can provide is the information for which it is authoritative. - Is this situation due to the fact that dig always and only contacts the server mentionned in the command ? Yes. Dig id not a complete resolver, it does not chase down incomplete references or glue. - Does the titi.be and toto.be be on the same server to correctly use CNAMES? No. A recursive resolver will determine the information using more than one query. -- Daniel J McDonald, CCIE # 2495, CISSP # 78281 ___ Please visit https://lists.isc.org/mailman/listinfo/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: Why does a non-delegated sub-domain work?
On 5/7/12 11:32 AM, M. Meadows sun-g...@live.com wrote: So ... if we have exacttarget.com delegated to ns1 and ns2.exacttarget.com nameservers and ... we manage the s6.exacttarget.com zone file from ns1 and ns2.exacttarget.com but we don't delegate s6 in the exacttarget.com zone file ... forgot to enter it in the zone file ... how is it that s6.exacttarget.com and its contents resolve properly from everywhere? Because bind can't distinguish between a query for s6.exacttarget.com from the exacttarget.com zone and a query for s6.exacttarget.com in the s6.exacttarget.com zone, so it employs longest match and returns the appropriate information. Seems BIND is helping us out behind the scenes somehow. Right? Bind is hiding your configuration error, yes. It won't work with DNSSEC and might fail if you have a secondary for s6.exacttarget.com that is not also authoritative for exacttarget.com -- Daniel J McDonald, CCIE # 2495, CISSP # 78281 ___ Please visit https://lists.isc.org/mailman/listinfo/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: Loadbalance caching dns server
On 3/20/12 7:15 AM, trm asn trm.nag...@gmail.com wrote: On Tue, Mar 20, 2012 at 4:40 PM, Stefan Certic ste...@routotelecom.com wrote: Hi, That can be achieved using iptables: iptables -A PREROUTING -i eth0 -p tcp --dport 53 -m state --state NEW -m nth --counter 0 --every N --packet 0 -j DNAT --to-destination 192.168.1.98:53 http://192.168.1.98:53 On Tue, Mar 20, 2012 at 10:11 AM, trm asn trm.nag...@gmail.com wrote: Dear List, Is there any mechanism to load balance Caching-DNS server. For example.. _ Requirement is slightly different. The client's request can go to any of the Caching server. If one of the Caching server down, then also it should serve the request from 2nd server. Is there any way where I can configure the VIP and that VIP will communicate to the down stream both the caching dns server. So the client will be configured with VIP in resolve.conf file. Multiple vips with a single serverfarm (or multiple anycast vips with multiple serverfarms) are fairly trivial to set up with a hardware load balancer I have configured this using Cisco ACE, F5, and A10 AX2500. -- Daniel J McDonald, CCIE # 2495, CISSP # 78281 ___ Please visit https://lists.isc.org/mailman/listinfo/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:
On 3/13/12 8:20 AM, hugo hugoo hugo...@hotmail.com wrote: == do I have to create in zone toto.be the following NS record: titi.toto.be. TTL IN NSns1.xxx.be I have found cases where this situation is present and other when it is not present...and both cases seems to work. What is the difference? The glue records aren't necessary when both the zone and subzone are on the same server, although it is good to have them for completeness. When the zones are on different servers you need the glue records. -- Daniel J McDonald, CCIE # 2495, CISSP # 78281 ___ Please visit https://lists.isc.org/mailman/listinfo/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: about the additional section
On 8/31/11 10:13 PM, 风河 short...@gmail.com wrote: Hello, I found that some queries have got the response which has additional section, but some haven't. For example, this query with www.google.com got the answer with additional section set: $ dig www.google.com ;; MSG SIZE rcvd: 236 $ dig www.google.com ;; MSG SIZE rcvd: 220 My question is under what condition the nameserver answers the query with additional section set? When there is sufficient space for the additional information in the packet, it is sent. If the answer and authority were too big to fit in the packet, then the DNS server is supposed to set the truncated data bit so that the resolver knows it is supposed to try TCP or EDNS0 to get a larger response. But the truncated data bit is not sent when the only things truncated are additional information records. When querying google.com A using edns=0, the size of the message is 271 bytes, including all 4 RRs in the additional section. -- Daniel J McDonald, CCIE # 2495, CISSP # 78281 ___ Please visit https://lists.isc.org/mailman/listinfo/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: no servers could be reached
On 7/28/11 3:16 AM, uifid...@gmail.com uifid...@gmail.com wrote: my czj.zone $TTL 86400 czj. IN SOA localhost. root.localhost. ( 1997022700 ; Serial 28800 ; Refresh 14400 ; Retry 360; Expire 86400 ); Minimum czj. IN NS localhost. kia IN A 192.168.18.1 Don't you need $ORIGIN czj. in order to add an unrooted entry? SOA and NS of localhost. seems wrong. localhost.localdomain. seems more likely. -- Daniel J McDonald, CCIE # 2495, CISSP # 78281 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind version problem
On 7/19/11 9:30 AM, almah...@ranksitt.net almah...@ranksitt.net wrote: Hi, If Bind version of primary dns is bind-libs-9.3.6-16.P1.el5 and for secondary dns bind-9.5.0-29.b2.fc9.i386. Is there create any problem?? In general, it creates no problem. If you happen to use an RR for which support was added in 9.5, then you might have odd results. Is it mandatory the same version for primary and secondary DNS. No. It's not even mandatory that the primary and secondary both be running bind. -- Daniel J McDonald, CCIE # 2495, CISSP # 78281 ___ Please visit https://lists.isc.org/mailman/listinfo/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: Disabling DNSSEC validation per zone?
On 7/11/11 12:15 PM, Tony Finch d...@dotat.at wrote: Daniel McDonald dan.mcdon...@austinenergy.com wrote: ; DiG 9.8.0-P4 @localhost ips.backscatterer.local ds ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 26308 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 Are you slaving the root zone? Not purposely. Tony. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Disabling DNSSEC validation per zone?
I have a number of zones being served by rbldnsd, with bind as a front-end. The zones are defined as forward only in named.conf. When I enable dnssec validatation, these zones report that they are insecure. 08-Jul-2011 08:55:58.700 dnssec: info: validating @0xb4260ad8: ips.backscatterer.local SOA: got insecure response; parent indicates it should be secure I¹m not really certain which parent is reporting this Is there a way to disable dnssec validation on these zones, while still requiring it elsewhere? -- Daniel J McDonald, CCIE # 2495, CISSP # 78281 ___ Please visit https://lists.isc.org/mailman/listinfo/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: Disabling DNSSEC validation per zone?
On 7/8/11 10:41 AM, Phil Mayers p.may...@imperial.ac.uk wrote: On 08/07/11 15:13, Daniel McDonald wrote: I have a number of zones being served by rbldnsd, with bind as a front-end. The zones are defined as forward only in named.conf. When I enable dnssec validatation, these zones report that they are insecure. 08-Jul-2011 08:55:58.700 dnssec: info: validating @0xb4260ad8: ips.backscatterer.local SOA: got insecure response; parent indicates it should be secure I¹m not really certain which parent is reporting this Well, backscatterer.local presumably. What does: dig @localhost ips.backscatterer.local ds ...say? NXDOMAIN [~]$ dig @localhost ips.backscatterer.local ds ; DiG 9.8.0-P4 @localhost ips.backscatterer.local ds ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 26308 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;ips.backscatterer.local.INDS ;; AUTHORITY SECTION: .7957INSOAa.root-servers.net. nstld.verisign-grs.com. 2011070800 1800 900 604800 86400 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Jul 8 11:05:23 2011 ;; MSG SIZE rcvd: 116 Is there a way to disable dnssec validation on these zones, while still requiring it elsewhere? I believe not. I guess that means I need to set aside a separate zone registered for my rbls (I have a fair number of them) and not sign it. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Dig +topdown
I set up a zone with dnssec, and wanted to verify that it was working
properly. But I appear to have trouble with the root KSK.
$ dig +dnssec danmcdonald.us +topdown
;; No trusted key, +sigchase option is disabled
; DiG 9.7.3-P1 +dnssec danmcdonald.us +topdown
I appear to have the managed-keys-zone loading properly:
In named.conf, I have the managed-keys stanza with the initial key. Named
loaded the mananged-keys-zone file and loads the zone at startup:
01-Jul-2011 08:40:54.738 general: info: managed-keys-zone ./IN: loaded
serial 2
[named]$ cat managed-keys.bind
$ORIGIN .
$TTL 0; 0 seconds
@IN SOA. . (
2 ; serial
[...]
I have the dnssec flags enabled in the options{} stanza:
dnssec-enable yes;
dnssec-validation yes;
It appears that sigchase is enabled in named:
[named]$ /usr/sbin/named -V
BIND 9.7.3-P1 built with 'x86_64-mandriva-linux-gnu' '--program-prefix='
'--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin'
'--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share'
'--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/lib64'
'--sharedstatedir=/usr/com' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--x-includes=/usr/include'
'--x-libraries=/usr/lib64' '--localstatedir=/var'
'--disable-openssl-version-check' '--enable-threads' '--enable-largefile'
'--enable-ipv6' '--enable-filter-' '--enable-epoll'
'--with-openssl=/usr' '--with-gssapi=/usr' '--disable-isc-spnego'
'--with-randomdev=/dev/urandom' '--with-libxml2=yes'
'--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-bdb=no'
'--with-dlz-filesystem=yes' '--with-dlz-ldap=yes' '--with-dlz-odbc=no'
'--with-dlz-stub=yes' 'build_alias=x86_64-mandriva-linux-gnu'
'host_alias=x86_64-mandriva-linux-gnu'
'target_alias=x86_64-mandriva-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wformat
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector
--param=ssp-buffer-size=4 -fstack-protector-all -DLDAP_DEPRECATED' 'LDFLAGS=
-Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -Wl,--build-id
-Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -Wl,--build-id
-Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -Wl,--build-id
-Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -Wl,--build-id'
'CPPFLAGS= -DDIG_SIGCHASE'
Any advise as to what I might be doing wrong?
--
Daniel J McDonald, CCIE # 2495, CISSP # 78281
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.7 Serial Number Decrease Problem
On 6/7/11 7:51 AM, Barry Finkel bsfin...@anl.gov wrote: There was a zone serial number mismatch, each zone expired three days ago, and new zones were transferred from the master. But the zone files on disk still have the higher serial numbers. There are no .jnl files on the disk. A dig on the server for the zone serial numbers shows the lower numbers, so BIND has those correct serial numbers. If you have multiple masters for which this server is a slave, then check the serial number on all of the masters. I think you will find that one of them is higher than the other... I assume that if I stopped BIND (rndc stop) and restarted it, then I would again see the serial number mismatches. I can try this during the day, as this server is not heavily used. Is there any debugging I need to run? Thanks. -- Daniel J McDonald, CCIE # 2495, CISSP # 78281 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
