Re: What are these entries in the log file - query: . IN NS +?
Tony Toews [MVP] tto...@telusplanet.net kirjoitti viestissä:p2vsn4leohtc8dm4a7m8rt4g6d4kem2...@4ax.com... Noel Butler noel.but...@ausics.net wrote: Surely windows can block access to an inbound IP request from some IP to local udp port 53 ? Not the firewall software built into Windows 2003 Server. If not, you know what my next reply will be don't you :) chuckleYeah, well switching to Linux ain't gonna happen. My friend and I have no experience with Linux and no desire to learn it. There are many free third party firewall packages that can be run in Windows 2003 Server, we use the Net Firewall. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What are these entries in the log file - query: . IN NS +?
On Tue, Jan 27, 2009 at 11:50:51AM +0100, Jan Buchholz 96de...@googlemail.com wrote a message of 38 lines which said: i think disable queries at the root-zone for not internal networks is another answer for this problem . Good practices about this attack (with specific BIND advice) is already there: https://www.dns-oarc.net/oarc/articles/upward-referrals-considered-harmful ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
On Jan 26, 2009, at 11:27 PM, David Ford wrote: hand because each line isn't strictly well-formed per RFC. If every vendor was as utterly asinine about absolutist conformance, sure, we'd have a lot less mess out there, but we'd have a lot less forward movement as well as a lot more fractioning of software packages. Since everyone wants to do the protocol their own way, we'd just have a multitude of protocol variations rather than more flexible interoperability. it could be argued, that if there was absolutist conformance to standards, we could move forward even faster. There is literally a 20% developer tax on debugging css and html to make it work with most browsers. Many compromises made to satisfy the lack of strictness. I am not totally disagreeing with you, I am not known to make ascii art in emails :) but I do think we would have a better systems if standards were more adhered to. -- Scott ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What are these entries in the log file - query: . IN NS +?
Hallo, i think disable queries at the root-zone for not internal networks is another answer for this problem . --- Jan 2009/1/27, Jukka Pakkanen jukka.pakka...@qnet.fi: Tony Toews [MVP] tto...@telusplanet.net kirjoitti viestissä:p2vsn4leohtc8dm4a7m8rt4g6d4kem2...@4ax.com... Noel Butler noel.but...@ausics.net wrote: Surely windows can block access to an inbound IP request from some IP to local udp port 53 ? Not the firewall software built into Windows 2003 Server. If not, you know what my next reply will be don't you :) chuckleYeah, well switching to Linux ain't gonna happen. My friend and I have no experience with Linux and no desire to learn it. There are many free third party firewall packages that can be run in Windows 2003 Server, we use the Net Firewall. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: delegation over authority?
On 26.01.09 17:09, Todd Snyder wrote:
I am trying to wrap my head around a weird configuration I ran across
today, and see if my assumptions are correct.
Working with the TLD .testdomain.
We have the record:
test2.testdomain. IN NS ns01.blahblah.testdomain.
But, on the same server, we also have the zone configured:
zone test2.testdomain in {
file slave/test2.testdomain;
type slave;
masters { all_masters; };
};
So, on the server, we have a delegation of test2.testdomain but we're
also authoritative for that domain.
My testing seems to indicate that the authorty overrides the delegation,
but I wanted to see if I was correct. Will it always override? Is this
a bad configuration? Will it cause any problems along the way?
yes, authority overrides delegation. However they should match because
mismatch could lead to strange results.
--
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.
WinError #98652: Operation completed successfully.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: contacting a external nameserver
On Tue, 27 Jan 2009, Luis Silva wrote:
Hi all,
I'm having a question related to querying external servers that hope you
could answer me. I'm sending a iterative query for an external server and
the server is sending a referral answer but only with the authoritive name
servers. After that, i send a query A asking the nameservers ip addresses.
This A query is supposed to be a recursive query or must be a iterative one?
Is there a standard that talks about this? thanks in advance.
Kind regards,
Luis
My external NS is one that that does so by virtue of these named.conf
entries:
view external { // Primary nameserver for maplepark.com.
match-clients { any; };
recursion no;
additional-from-cache no;
// https://www.dns-oarc.net/oarc/articles/upward-referrals-considered-harmful
zone maplepark.com{
type master;
notify yes;
allow-transfer { slave-name-servers; };
file /var/named/drf/external/maplepark.com.external.;
};
I do this because it then replies with a 28 byte message with only my
authoritative information (nothing) and does not then contribute to a DDoS
in an amplified reply to a request for the root servers ( . NS). If I
could, I would have it just not respond and let the attacker time out.
But that is not an option. At least I haven't found a way to do that.
A side effect of this config is that I don't send glue to legitimate
queries for my NS (just my authoritative information) but my secondaries
are easily found from the root servers. And if my NS is off-line, the
secondaries will be queried anyway. No information is returned for upward
referrals.
Dave Forrest
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
So then you disagree that the following example returns a valid address record for srv1? srv1 300 IN A 1.2.3.4 mx1 300 IN CNAME srv1.xyz.com. @ 300 IN MX 1 mx1.xyz.com. 1) Select Target Host: The MX query for xyz.com delivers mx1.xyz.com which is a CNAME. 2) Get Target Host Address: The A query for mx1.xyz.com delivers the address (A) record of srv1.xyz.com, 1.2.3.4, and also delivers the alias (CNAME) record of mx1.xyz.com. *** PLEASE don't copy me on replies, I'll read them in the group *** - Original Message - From: Mark Andrews mark_andr...@isc.org To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Tuesday, January 27, 2009 1:46 AM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal In message 10b3763032c94ae2ba4900b3137d1...@ahsnbw1, Al Stu writes: The paragraph you cite regarding LOCAL has a alias and the alias is listed in the MX records for REMOTE... is a peripery issue which is handled by not doing that. Them why are you complaining? The error message is only emitted when you add such a alias. No one is saying a CNAME is not permitted in response to a MX query. Well good then, we agree. No. The MX record data value can be a CNAME. No. That is what BIND is complaining about, and I in turn saying should be changed/removed. i.e. BIND should not complain about the following, but it does. It says the MX record is illegal. But it is not. srv1 300 IN A 1.2.3.4 mx1 300 IN CNAME srv1.xyz.com. @ 300 IN MX 1 mx1.xyz.com. The MX query for xyz.com delivers mx1.xyz.com which is a CNAME. The A query for mx1.xyz.com delivers the address (A) record of srv1.xyz.com, 1.2.3.4, and the alias (CNAME) record of mx1.xyz.com. *** PLEASE don't copy me on replies, I'll read them in the group *** - Original Message - From: Mark Andrews mark_andr...@isc.org To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 10:03 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal In message b3ba5e37553642e28149093cdee78...@ahsnbw1, Al Stu writes: Yes, the response to an MX query, that is the subject here. And a CNAME is in fact permitted and specified by the RFC's to be accepted as the response to an MX lookup. No one is saying a CNAME is not permitted in response to a MX query. If the response does not contain an error response, and does not contain aliases See there, alias is permitted. You just keep proving the my case. We are saying that when you lookup the address of the mail exchanger that you shouldn't get a CNAME record. MX - CNAME is not permitted. Others have quoted similar text from more recent RFC's. RFC 974 Note that the algorithm to delete irrelevant RRs breaks if LOCAL has a alias and the alias is listed in the MX records for REMOTE. (E.g. REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This can be avoided if aliases are never used in the data section of MX RRs. I am not taking it out of context. It is very explicitly stated. And the context is that of locating the target/remote host by first submitting an MX query, then submitting an A query of the MX query result. The text you quote is ONLY talking about the MX query. There is no then submitting an A query of the MX query result at this point in the RFC. The MX query result is permitted to be and alias, which in turn when submitted for an A query results in both the A and CNAME being returned. Thus meeting the SMTP RFC requirements. - Original Message - From: Mark Andrews mark_andr...@isc.org To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:41 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal In message 3c802402a28c4b2390b088242a91f...@ahsnbw1, Al Stu writes: RFC 974: There is one other special case. If the response contains an answer which is a CNAME RR, it indicates that REMOTE is actually an alias for some other domain name. The query should be repeated with the canonical domain name. And that is talking about the response to a MX query. The section from which you quote starts with: Issuing a Query The first step for the mailer at LOCAL is to issue a query for MX RRs for REMOTE. It is strongly urged that this step be taken every time a mailer attempts to send the message. The hope is that changes in the domain database will rapidly be used by mailers, and thus domain administrators will be able to re-route in-transit messages for defective hosts by simply changing their domain databases. and the paragraph after that which you quote is: If the response does not contain an error response, and does not contain aliases, its answer section should be a (possibly zero length) list of MX RRs for domain name
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
On 27.01.09 08:46, Al Stu wrote: So then you disagree that the following example returns a valid address record for srv1? srv1 300 IN A 1.2.3.4 mx1 300 IN CNAME srv1.xyz.com. @ 300 IN MX 1 mx1.xyz.com. 1) Select Target Host: The MX query for xyz.com delivers mx1.xyz.com which is a CNAME. 2) Get Target Host Address: The A query for mx1.xyz.com delivers the address (A) record of srv1.xyz.com, 1.2.3.4, and also delivers the alias (CNAME) record of mx1.xyz.com. They are two queries. If mx1 would be an A, it would be returned in the first query. Since it's a CNAME, the IP is not returned in the MX query. -- 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. It's now safe to throw off your computer. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Split view multiple zones
Hello,
sorry if such question has been asked before (couldnt find and the
documentation was unclear), but maybe somebody can help with such issue or
clarify:
Do you need (and there is no workarround) to specify all the zones in all
views?
To be specific:
1. I have Bind (9.4.3) with bunch of zones.
2. There is a need for one zone/domain to implement a split view.
3. 'custom-clients' is a specific client group (in my case on maxmind db
based country)
3. I have made:
view custom {
match-clients { custom-clients; }
zone customzone.com { ... };
}
view normal {
match-clients { any; };
zone customzone.com { ... };
zone otherzone.com { ... };
zone otherzone2.com { ... };
}
The problem is that if the client is matched against 'custom-clients' it
doesnt see the 'otherzone.com' or 'otherzone2.com' at all no matter that it
also matches the 'any' rule.
Is that expected?
Of course I could just copy and paste all the zones also in 'custom' view
but it doubles the configuration size.
Is there a workarround or hack to implement that all matching views should
be checked for a zone if it doesnt exist in the first view?
wbr
Reinis Rozitis
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Split view multiple zones
Reinis Rozitis wrote:
view custom {
match-clients { custom-clients; }
zone customzone.com { ... };
}
view normal {
match-clients { any; };
zone customzone.com { ... };
zone otherzone.com { ... };
zone otherzone2.com { ... };
}
The problem is that if the client is matched against 'custom-clients' it
doesnt see the 'otherzone.com' or 'otherzone2.com' at all no matter that
it also matches the 'any' rule.
Is that expected?
Yes. All zones must be in all views.
AlanC
signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Split view multiple zones
I've been using an include file for zones common between multiple views, it might help in your case too. Thanks somehow didnt think about this way. Pretty much takes to acceptable solution :) wbr Reinis Rozitis ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
e: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
Al Stu al_...@verizon.net wrote: How about these two? nullmx.domainmanager.com Non-authoritative answer: Name:mta.dewile.net Address: 69.59.189.80 Aliases: nullmx.domainmanager.com smtp.secureserver.net Non-authoritative answer: Name:smtp.where.secureserver.net Address: 208.109.80.149 Aliases: smtp.secureserver.net There are two reasons it does not blow up in peoples face. 1) If it is in the CNAME RR points to an A record in the same zone, both the A record and the CNAME record are returned, thus meeting the A record requirement. 2) SMTP servers are required to accept an alias and look it up. Thus there is no need for this. And no it does not matter if there are multiple MX records with different preferences values. You say, both the A record and the CNAME record are returned. We know that BIND does this. Is this part of the RFC? Do other DNS implementation return both the A and the CNAME? -- Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone:+1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 222, Room D209 Internet: bsfin...@anl.gov Argonne, IL 60439-4828 IBMMAIL: I1004994 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: disableing EDNS messages bind-9.5.0
I'm trying to troubleshoot why we are getting a lot of disabling EDNS messages in /var/log/messages. We are running bind-9.5.0.P2 on a linux box. Jan 27 11:42:23 ns0 named[27764]: too many timeouts resolving 'host2.centmine.com/' (in 'centmine.com'?): disabling EDNS Please consider using 9.5.1-P1 or 9.6.0-P1. They include EDNS improvements related to logging. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
contacting a external nameserver
I should have sent this to the list On Tue, Jan 27, 2009 at 11:42 AM, Serge Fonville serge.fonvi...@gmail.comwrote: Hi, Not sure what your endgoal is, but... If you want a specific zone to be queried on the external nameserver, you can create a forward zone. If you want all unresolvable queries to be forwarded to a specific nameserver, you can define forwarders. Perhaps some information about what your end result should be instead of suggesting solutions up front can be of use. Hope this helps. Regards, Serge Fonville On 1/27/09, Luis Silva luisfilsi...@gmail.com wrote: Hi all, I'm having a question related to querying external servers that hope you could answer me. I'm sending a iterative query for an external server and the server is sending a referral answer but only with the authoritive name servers. After that, i send a query A asking the nameservers ip addresses. This A query is supposed to be a recursive query or must be a iterative one? Is there a standard that talks about this? thanks in advance. Kind regards, Luis ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
When Section 5.1 of RFC 5321 says If a CNAME record is found, the resulting name is processed as if it were the initial name, it is referring to the situation where a query is sent for the MX record for xyz.com, and instead of an MX record being returned for xyz.com, a CNAME record is returned for xyz.com (e.g., xyz.com. IN CNAME abc.com.). In that case, the client is then expected to start the whole process over by querying for the MX record for abc.com. It is not referring to the case where a query is sent for the MX record for xyz.com and an MX record is returned for xyz.com having a CNAME for the RDATA (such as, XYZ IN MX 10 cn.xyz.com, where cn.xyz.com is a CNAME for srv1.xyz.com.) In fact, Section 5.1 of RFC 5321 goes on to discuss having CNAMEs returned in the RDATA of MX records and refers the reader to Section 10.3 of RFC 2181, which explicity forbids CNAMEs in the RDATA of either NS or MX records (The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias.). -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Al Stu Sent: Tuesday, January 27, 2009 12:13 PM To: bind-users@lists.isc.org Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal They are two queries. If mx1 would be an A, it would be returned in the first query. Since it's a CNAME, the IP is not returned in the MX query. So. RFC 5321 5.1, Locating the Target Host, says the CNAME is to be processed. The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found, the resulting name is processed as if it were the initial name. *** PLEASE don't copy me on replies, I'll read them in the group *** - Original Message - From: Matus UHLAR - fantomas uh...@fantomas.sk To: bind-users@lists.isc.org Sent: Tuesday, January 27, 2009 9:01 AM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal On 27.01.09 08:46, Al Stu wrote: So then you disagree that the following example returns a valid address record for srv1? srv1 300 IN A 1.2.3.4 mx1 300 IN CNAME srv1.xyz.com. @ 300 IN MX 1 mx1.xyz.com. 1) Select Target Host: The MX query for xyz.com delivers mx1.xyz.com which is a CNAME. 2) Get Target Host Address: The A query for mx1.xyz.com delivers the address (A) record of srv1.xyz.com, 1.2.3.4, and also delivers the alias (CNAME) record of mx1.xyz.com. They are two queries. If mx1 would be an A, it would be returned in the first query. Since it's a CNAME, the IP is not returned in the MX query. -- 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. It's now safe to throw off your computer. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Automation packages
Hi Bind experts, I'm looking to do some automation of bind administration - particularly adding and removing A Records, PTRs, and CNAMEs. Dynamic DNS is not appropriate as there is a strong requirement for change management on the zone files. Anyone have a strong belief in one or another tool, package, or approach? Thanks for your thoughts! John ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: disableing EDNS messages bind-9.5.0
Dean Clapper wrote:
I'm trying to troubleshoot why we are getting a lot of disabling EDNS
messages in /var/log/messages.
We are running bind-9.5.0.P2 on a linux box.
Jan 27 11:42:23 ns0 named[27764]: too many timeouts resolving
'host2.centmine.com/' (in 'centmine.com'?): disabling EDNS
Jan 27 11:42:24 ns0 named[27764]: too many timeouts resolving
'host1.centmine.com/' (in 'centmine.com'?): disabling EDNS
Jan 27 11:42:38 ns0 named[27764]: too many timeouts resolving
'pts1.abovecow.com/' (in 'abovecow.com'?): disabling EDNS
Jan 27 11:42:38 ns0 named[27764]: too many timeouts resolving
'pts2.abovecow.com/' (in 'abovecow.com'?): disabling EDNS
...
Jan 27 11:43:39 ns0 named[27764]: too many timeouts resolving
'196.198.117.216.zen.spamhaus.org/A' (in 'zen.spamhaus.org'?):
disabling EDNS
I started receiving these messages after updating from 9.4 - 9.5.
I've found a couple places to test packet sizes, but have not had any
problem. The messages about zen.spamhaus.org leads me to possibly
email related issues.
googling disabling EDNS would have been a start
anyway
add category edns-disabled { null; };
after verifying your nameserver(s) have an EDNS0 clear path
by trying the 2 tests mentioned below by Mark Andrews.
here's the comment from our named.conf template
We were somewhat concerned when seeing lots of these messages with 9.5:
edns-disabled: info: too many timeouts resolving 'query'
The description in ARM:
This is often due to the remote servers not being RFC 1034 compliant (not
always returning FORMERR or similar to EDNS queries and other extensions
to the DNS when they are not understood). In other words, this is targeted
at servers that fail to respond to DNS queries that they don’t understand.
Note: the log message can also be due to packet loss. Before reporting
servers
for non-RFC 1034 compliance they should be re-tested to determine the nature
of the non-compliance. This testing should prevent or reduce the number of
false-positive reports.
Note: eventually named will have to stop treating such timeouts as due to
RFC 1034 non compliance and start treating it as plain packet loss. Falsely
classifying packet loss as due to RFC 1034 non compliance impacts on DNSSEC
validation which requires EDNS for the DNSSEC records to be returned.
The following link
http://groups.google.com/group/comp.protocols.dns.bind/browse_thread/thread/cfa8c63ec6bd08d6
describes cases when EDNS is being blocked
* A Firewall that doesn't allow through DNS packets 512 bytes.
* A Firewall/NAT that doesn't allow IP fragments through.
dig +norec +dnssec example.com @a.root-servers.net
Can be used to test if you firewall supports packets 512.
dig +dnssec +norec +ignore dnskey se @A.NS.se
Can be used to test if IP fragments can get though at all.
The last sentence in Mark's message doesn't correspond to my experience:
These messages are rare events with a EDNS clear path
as I manually checked around 20 of these logged queries and found that
nearly
all resulted in dig reporting no servers could be reached. The messages
appeared in 9.5 because it always tries EDNS but I think they mostly come
from lame delegations (those 2 EDNS0 tests went OK).
Danny
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: What are these entries in the log file (blocking)
In message 260425.38131...@web38201.mail.mud.yahoo.com, W Sanders writes: The easy way to block people trying to DoS you, without needing a firewall, is to just null route their IP: add route 1.2.3.4 127.0.0.1. Of course this blocks ALL traffic from that IP, but in most cases the IP trying to DoS you is someo ne you don't care about anyway. If you have an authoritative server, this has the side effect of blocking them from get ting any DNS about your domain - USUALLY a good thing. Remember to remove the route after a while (in Unix with an at job) so a year from now you or another sysadmin isn't completely confused - the routing table on a server isn't exactly the first thing one looks at. You can also write a script that grabs these IPs out of the syslog and automatically null routes them. Call it intrusi on detection if you will. -w Which does collateral damage. Complain to your ISP if you are receiving these forged queries. they should be tracked back to their source and eliminated. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
In message d53c69e1f478453a8371b49b4f04c...@ahsnbw1, Al Stu writes: So then you disagree that the following example returns a valid address record for srv1? The MX query won't return the A record for srv1. The additional section processing rules say to add A / records not CNAME records. You fail to understand that the rule is there so that MX processing can be done in a deterministic manner. I don't care that when you look up mx1.xyz.com you eventually get a address record. The damage is done long before that lookup is performed. Email is processed in this order: Look up MX records. Process the MX RRset. Lookup address records and attempt to deliver the email. Mark srv1 300 IN A 1.2.3.4 mx1 300 IN CNAME srv1.xyz.com. @ 300 IN MX 1 mx1.xyz.com. 1) Select Target Host: The MX query for xyz.com delivers mx1.xyz.com which is a CNAME. 2) Get Target Host Address: The A query for mx1.xyz.com delivers the address (A) record of srv1.xyz.com, 1.2.3.4, and also delivers the alias (CNAME) record of mx1.xyz.com. *** PLEASE don't copy me on replies, I'll read them in the group *** - Original Message - From: Mark Andrews mark_andr...@isc.org To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Tuesday, January 27, 2009 1:46 AM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal In message 10b3763032c94ae2ba4900b3137d1...@ahsnbw1, Al Stu writes: The paragraph you cite regarding LOCAL has a alias and the alias is listed in the MX records for REMOTE... is a peripery issue which is handled by not doing that. Them why are you complaining? The error message is only emitted when you add such a alias. No one is saying a CNAME is not permitted in response to a MX query. Well good then, we agree. No. The MX record data value can be a CNAME. No. That is what BIND is complaining about, and I in turn saying should be changed/removed. i.e. BIND should not complain about the following, but it does. It says the MX record is illegal. But it is not. srv1 300 IN A 1.2.3.4 mx1 300 IN CNAME srv1.xyz.com. @ 300 IN MX 1 mx1.xyz.com. The MX query for xyz.com delivers mx1.xyz.com which is a CNAME. The A query for mx1.xyz.com delivers the address (A) record of srv1.xyz.com, 1.2.3.4, and the alias (CNAME) record of mx1.xyz.com. *** PLEASE don't copy me on replies, I'll read them in the group *** - Original Message - From: Mark Andrews mark_andr...@isc.org To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 10:03 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal In message b3ba5e37553642e28149093cdee78...@ahsnbw1, Al Stu writes: Yes, the response to an MX query, that is the subject here. And a CNAME is in fact permitted and specified by the RFC's to be accepted as the response to an MX lookup. No one is saying a CNAME is not permitted in response to a MX query. If the response does not contain an error response, and does not contain aliases See there, alias is permitted. You just keep proving the my case. We are saying that when you lookup the address of the mail exchanger that you shouldn't get a CNAME record. MX - CNAME is not permitted. Others have quoted similar text from more recent RFC's. RFC 974 Note that the algorithm to delete irrelevant RRs breaks if LOCAL has a alias and the alias is listed in the MX records for REMOTE. (E.g. REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This can be avoided if aliases are never used in the data section of MX RRs. I am not taking it out of context. It is very explicitly stated. And the context is that of locating the target/remote host by first submitting an MX query, then submitting an A query of the MX query result. The text you quote is ONLY talking about the MX query. There is no then submitting an A query of the MX query result at this point in the RFC. The MX query result is permitted to be and alias, which in turn when submitted for an A query results in both the A and CNAME being returned. Thus meeting the SMTP RFC requirements. - Original Message - From: Mark Andrews mark_andr...@isc.org To: Al Stu al_...@verizon.net Cc: bind-users@lists.isc.org Sent: Monday, January 26, 2009 8:41 PM Subject: Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal In message 3c802402a28c4b2390b088242a91f...@ahsnbw1, Al Stu writes: RFC 974: There is one other special case. If the response contains an answer which is a CNAME RR, it indicates that
Re: disableing EDNS messages bind-9.5.0
In message pine.neb.4.64.0901271203100.26...@tx.reedmedia.net, Jeremy C. Ree d writes: I'm trying to troubleshoot why we are getting a lot of disabling EDNS messages in /var/log/messages. We are running bind-9.5.0.P2 on a linux box. Jan 27 11:42:23 ns0 named[27764]: too many timeouts resolving 'host2.centmine.com/' (in 'centmine.com'?): disabling EDNS Please consider using 9.5.1-P1 or 9.6.0-P1. They include EDNS improvements related to logging. They also have this fix which can result in packets appearing to get lost. Mark 2504. [bug] Address race condition in the socket code. [RT #18899] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What are these entries in the log file - query: . IN NS +?
Tony Toews [MVP] tto...@telusplanet.net wrote: 26-Jan-2009 14:28:24.004 client 76.9.16.171#23101: query: . IN NS + 26-Jan-2009 14:28:58.254 client 63.217.28.226#28035: query: . IN NS + 26-Jan-2009 14:29:00.691 client 63.217.28.226#35549: query: . IN NS + 26-Jan-2009 14:29:26.332 client 76.9.16.171#19817: query: . IN NS + FWIW In the last 28 hours I have the following alleged IP addresses and count in my log file. Real lookups1665 204.15.80.504 3.217.28.2261144 4.57.246.1469541 6.9.16.171 577 63.217.28.226 1463 64.57.246.146 35163 65.173.218.96 1 67.192.144.01488 7.192.144.0 12054 76.9.16.171 1033 Tony -- Tony Toews, Microsoft Access MVP Please respond only in the newsgroups so that others can read the entire thread of messages. Microsoft Access Links, Hints, Tips Accounting Systems at http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: What are these entries in the log file - query: . IN NS +?
Jukka Pakkanen jukka.pakka...@qnet.fi wrote: There are many free third party firewall packages that can be run in Window= s = 2003 Server, we use the Net Firewall. Do you have a URL? I found http://www.ntkernel.com/wp.php?id=18 but it's not free. I'm also going to ask my fellow MVPs as well. Tony -- Tony Toews, Microsoft Access MVP Please respond only in the newsgroups so that others can read the entire thread of messages. Microsoft Access Links, Hints, Tips Accounting Systems at http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
In article glma06$8d...@sf1.isc.org, Mark Andrews mark_andr...@isc.org wrote: Liberal in what you accepts means don't die on arbitary input. You should still reject rubbish. But MX pointing to CNAME is not rubbish. It's a violation of the letter of the spec, but it's very clear what is intended. -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
In article glmqqb$jv...@sf1.isc.org, mlel...@serpens.de (Michael van Elst) wrote: Barry Margolin bar...@alum.mit.edu writes: customer.com. IN MX 10 mx.yourdomain.com. mx.yourdomain.com. IN CNAME mx.outsourcer.com. mx.outsourcer.com. IN A ... That's just the same as | customer.com. IN MX 10 mx.outsourcer.com. | mx.outsourcer.com. IN A ... except to people with half-a-knowledge about DNS queries. It's the same in layer 7, but not in layer 8. If you decide to change outsourcing companies, you have to get hundreds of customers to change their MX records, instead of just changing one CNAME record. I used to work at an ISP, and we provided slave DNS for many customers. At various times we had to change the names and/or addresses of our servers, as the business grew (e.g. when we acquired other companies, and wanted to migrate the domains they were hosting to our servers). We frequently saw obsolete glue records in our customers' domains years after these changes, and they often found their way into caches so they interfered with other domains we hosted as well. So anything you can do to avoid depending on customers to make changes at their end makes operating a business easier. -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
In article glnemv$10n...@sf1.isc.org, Matus UHLAR - fantomas uh...@fantomas.sk wrote: On 27.01.09 08:46, Al Stu wrote: So then you disagree that the following example returns a valid address record for srv1? srv1 300 IN A 1.2.3.4 mx1 300 IN CNAME srv1.xyz.com. @ 300 IN MX 1 mx1.xyz.com. 1) Select Target Host: The MX query for xyz.com delivers mx1.xyz.com which is a CNAME. 2) Get Target Host Address: The A query for mx1.xyz.com delivers the address (A) record of srv1.xyz.com, 1.2.3.4, and also delivers the alias (CNAME) record of mx1.xyz.com. They are two queries. If mx1 would be an A, it would be returned in the first query. Since it's a CNAME, the IP is not returned in the MX query. So what? If the IP isn't in the additional section, the client will do its own A query. There's no requirement that the response to the MX record include the A record. It's nice if it does, since it saves a query, but this is just an optimization. -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
On 27.01.09 08:46, Al Stu wrote: So then you disagree that the following example returns a valid address record for srv1? srv1 300 IN A 1.2.3.4 mx1 300 IN CNAME srv1.xyz.com. @ 300 IN MX 1 mx1.xyz.com. 1) Select Target Host: The MX query for xyz.com delivers mx1.xyz.com which is a CNAME. 2) Get Target Host Address: The A query for mx1.xyz.com delivers the address (A) record of srv1.xyz.com, 1.2.3.4, and also delivers the alias (CNAME) record of mx1.xyz.com. In article glnemv$10n...@sf1.isc.org, Matus UHLAR - fantomas uh...@fantomas.sk wrote: They are two queries. If mx1 would be an A, it would be returned in the first query. Since it's a CNAME, the IP is not returned in the MX query. On 27.01.09 23:51, Barry Margolin wrote: So what? If the IP isn't in the additional section, the client will do its own A query. so the client has to do an A query, because A is not returned in the MX query. There's no requirement that the response to the MX record include the A record. It's nice if it does, since it saves a query, but this is just an optimization. exactly. That's what I was trying to explain. -- 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. Windows 2000: 640 MB ought to be enough for anybody ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
