Key ID from DNSKEY - how?
I would like to calculate the Key-ID from a DNSKEY record. I'd prefer to do this in PHP as this is inside some existing PHP (Web) scripts but I guess calling a C program would not be too inconvenient. I'd like to index records (ie DNSKEY and DS Records) according to their Key-ID - and present them grouped by Key-ID. DS keys are usually presented with their Key-ID - so are less problematic. Side issue - the RFC description for a DS Record on the wire gives the first 16 bytes as the Key-ID, followed by (8-bit) Algorithm, (8-bit) Digest type and (32 bytes - or so) Digest. Is all this info encoded into the Base-64 stuff that one can see as ascii in a zone? ... or is the base-64 ascii stuff just the Digest? I'd love to be able to validate both DS and DNSKEY records that people give me but I am still floundering around amongst the DNSSEC RFC's... I understand that key-ID's are not necessarily unique but as I'd usually not have more than about 4 or so in any one domain - I'm hoping that statistics will be with me 99.95% of the time. Anyway - does anyone have existing code snippets that might assist me? -- . . ___. .__ Posix Systems - (South) Africa /| /| / /__ m...@posix.co.za - Mark J Elkins, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 smime.p7s Description: S/MIME cryptographic signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
non-improving referral
Hi, We are in the process of migrating from bind-9.4-ESV-R2 to bind-9.7.2-P2. We have our authoritative servers migrated to bind-9.7.2-P2 and it all seems to work fine. While testing our caching resolvers with bind-9.7.2-P2 however, we noticed some errors in our logfiles we have never seen before. Oct 26 09:52:03 myhost named[21085]: DNS format error from 1.5.3.4#53 resolving 1.2.4.2.x.y.z.example.com/TXT for client 1.5.3.203#15637: non-improving referral Oct 26 09:52:03 myhost named[21085]: DNS format error from 1.5.2.2#53 resolving 1.2.4.2.x.y.z.example.com/TXT for client 1.5.3.203#15637: non-improving referral Obviously I have obscured some data here :) As you may guess this is a query for a TXT record from a blocklist-daemon. The nameservers on 1.5.3.4 and 1.5.2.2 are bind-9.7.2-P2. The queried domains are hosted by us and the hopefully relevant part of the zone looks like this: x.y.z.example.com. IN NS bl1a.example.com. x.y.z.example.com. IN NS bl1b.example.com. A dump of the cache shows NS and A records are in the cache for bl1[ab] however, on each non-cached query from the client both errorlines are printed in the log suggesting the resolver is not using the cached NS records. The client receives a valid answer, so my only real problem seems to be the amount of spam I get in our logfiles. The blocklist is served by rbldnsd, manually query-ing gives my a valid response. Could anybody tell me what problem bind is complaining about? Please CC me as I am not on this list. -- Leo Baltus, internetbeheerder /\ NPO ICT Internet Services/NPO/\ Sumatralaan 45, 1217 GP Hilversum, Filmcentrum, west \ /\/ beh...@omroep.nl, 035-6773555 \/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Key ID from DNSKEY - how?
On Wed, Oct 27, 2010 at 10:46 AM, Mark Elkins wrote: > I would like to calculate the Key-ID from a DNSKEY record. I'd prefer to > do this in PHP as this is inside some existing PHP (Web) scripts but I > guess calling a C program would not be too inconvenient. > See RFC 4034, Appendix B (http://tools.ietf.org/html/rfc4034#appendix-B ) > I'd like to index records (ie DNSKEY and DS Records) according to their > Key-ID - and present them grouped by Key-ID. DS keys are usually > presented with their Key-ID - so are less problematic. The key tag field in a DS RR is the key tag value computed from the DNSKEY RR to which it corresponds in the child zone. > Side issue - the RFC description for a DS Record on the wire > gives the first 16 bytes as the Key-ID, followed by (8-bit) > Algorithm, (8-bit) Digest type and (32 bytes - or so) Digest. Is > all this info encoded into the Base-64 stuff that one can see as > ascii in a zone? ... or is the base-64 ascii stuff just the > Digest? > See below for explanation of the following queries: $ dig +short org ds 21366 7 2 96EEB2FFD9B00CD4694E78278B5EFDAB0A80446567B69F634DA078F0 D90F01BA $ dig +noall +answer +multi org dnskey ;; Truncated, retrying in TCP mode. org.383 IN DNSKEY 257 3 7 ( AwEAAZTjbIO5kIpxWUtyXc8avsKyHIIZ+LjC2Dv8naO+ Tz6X2fqzDC1bdq7HlZwtkaqTkMVVJ+8gE9FIreGJ4c8G 1GdbjQgbP1OyYIG7OHTc4hv5T2NlyWr6k6QFz98Q4zwF IGTFVvwBhmrMDYsOTtXakK6QwHovA1+83BsUACxlidpw B0hQacbD6x+I2RCDzYuTzj64Jv0/9XsX6AYV3ebcgn4h L1jIR2eJYyXlrAoWxdzxcW//5yeL5RVWuhRxejmnSVnC uxkfS4AQ485KH2tpdbWcCopLJZs6tw8q3jWcpTGzdh/v 3xdYfNpQNcPImFlxAun3BtORPA2r8ti6MNoJEHU= ) ; key id = 9795 org.383 IN DNSKEY 256 3 7 ( AwEAAa1gQwarOzgSbmhYj2eRUf/1RcHuAed0zlnAmqJY ELF6iUGfPNSBfD0QDilro3Dxc307zVONrTK7qnWtaHXH NDFVbB3+qDs1E+9tUjfKt9OuFQBQuGSlVvnM7O5ASbxs Ex/8ms3mQFDCt4nTUmcELQGVE/EwLcDjxAUAmYBW9bQN ) ; key id = 61598 org.383 IN DNSKEY 256 3 7 ( AwEAAfyGacR9k8f85+1XqM6qLTLwdAEQDHUJJbScMrqq XesZN6GFZDqn4zahg2GllxlHbGMuQJsWXSotq2Jp1Khe /fp1547v0k2jnOaFv/18wLBmUGSQNNTWpBgp8Yzu8BOw 18kHmbXpQeju2mk6bHgiL7HkJfFoV1nsSTh15q92d5IR ) ; key id = 245 org.383 IN DNSKEY 257 3 7 ( AwEAAYpYfj3aaRzzkxWQqMdl7YExY81NdYSv+qayuZDo dnZ9IMh0bwMcYaVUdzNAbVeJ8gd6jq1sR3VvP/SR36mm GssbV4Udl5ORDtqiZP2TDNDHxEnKKTX+jWfytZeT7d3A bSzBKC0v7uZrM6M2eoJnl6id66rEUmQC2p9DrrDg9F6t XC9CD/zC7/y+BNNpiOdnM5DXk7HhZm7ra9E7ltL13h2m x7kEgU8e6npJlCoXjraIBgUDthYs48W/sdTDLu7N59rj CG+bpil+c8oZ9f7NR3qmSTpTP1m86RqUQnVErifrH8Kj DqL+3wzUdF5ACkYwt1XhPVPU+wSIlzbaAQN49PU= ) ; key id = 21366 The first value in the DS RR (21366) is the 16-bit key tag value computed from the org DNSKEY last in the list below. The second value (7) corresponds to the algorithm of this DNSKEY RR. The last field is the hex representation of the SHA-256 digest (designated by value "2" in the digest algorithm field of the DS RR) of DNSKEY RR 21366. > I'd love to be able to validate both DS and DNSKEY records that > people give me but I am still floundering around amongst the > DNSSEC RFC's... > > I understand that key-ID's are not necessarily unique but as I'd usually > not have more than about 4 or so in any one domain - I'm hoping that > statistics will be with me 99.95% of the time. > >From RFC 4034, section 8: 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. > Anyway - does anyone have existing code snippets that might assist me? See the code snippet in the RFC for starters. Casey ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Key ID from DNSKEY - how?
On 10/27/2010 1:46 PM, Mark Elkins wrote: > I would like to calculate the Key-ID from a DNSKEY record. I'd prefer to > do this in PHP as this is inside some existing PHP (Web) scripts but I > guess calling a C program would not be too inconvenient. [...] > Anyway - does anyone have existing code snippets that might assist me? You may want to look at "dnssec-dsfromkey" 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: Key ID from DNSKEY - how?
On 10/27/2010 06:46 PM, Mark Elkins wrote:
I would like to calculate the Key-ID from a DNSKEY record. I'd prefer to
do this in PHP as this is inside some existing PHP (Web) scripts but I
guess calling a C program would not be too inconvenient.
I use some Python code to do this in our debugging/management tools,
translated straight from the RFC; it might convert pretty easily into
PHP, although in my experience language number/bit-shift/overflow
behaviour can be a bit... odd.
def key2keytag(flags, alg1, alg2, keydata):
data = struct.pack('!HBB', flags, alg1, alg2)
data += keydata.decode('base64')
v = 0
for i in range(len(data)):
if i & 1:
v += ord(data[i])
else:
v += ord(data[i]) << 8
v += (v >> 16) & 0x
return v & 0x
Called like so:
tag = key2tag(257, 3, 5, 'AwEAA...')
Very handy during testing is:
dig +multi domain.com DNSKEY
...which displays the tag as a comment. HTH
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: limiting number of recursion/queries per IP address
In FreeBSD you can use pf to limit connections using tables and setting up rate limit. http://forums.freebsd.org/showthread.php?t=1727 Best regards, Shamrock On Tue, Oct 26, 2010 at 9:29 PM, Kebba Foon wrote: > On Tue, 2010-10-26 at 15:22 -0400, Todd Snyder wrote: > > What version of bind, on what OS? > > > I use Debian 5.0 with bind 9.6-ESV-R1 but also i thought that the OS > might have some security holes so i try FreeBSD 8.1 with BIND 9.7.1 but > still have ihave the same problems. > > > here may be some things you can do with iptables to limit connections > > > > http://www.debian-administration.org/articles/187 > > > i will just look into these but it done thing iptables will be the ideal > solution. > > I don't recall seeing anything native to BIND that would allow for limits > per src. > > > > t. > > > > -Original Message- > > From: bind-users-bounces+tsnyder=rim@lists.isc.org [mailto: > bind-users-bounces+tsnyder =rim.com@ > lists.isc.org] On Behalf Of Kebba Foon > > Sent: Tuesday, October 26, 2010 2:27 PM > > To: bind-users@lists.isc.org > > Subject: limiting number of recursion/queries per IP address > > > > Dear List, > > > > Is is possible to limit the number of recursion/queries per IP address. > > there is some kind of virus thats bombarding my dns servers with a lot > > of queries, i realize that when ever the total number of recursion > > clients reach 1000 dns resolution stop working. i have increase the > > recursive-clients to 1 but still these those not help. and also i > > have increase the number of max open files on my OS which at one point > > was complaining about too many open files. can someone please direct me > > to how best to solve this problem its some kind of DDOS. > > > > Thanks > > Kebba > > > > ___ > > bind-users mailing list > > bind-users@lists.isc.org > > https://lists.isc.org/mailman/listinfo/bind-users > > > > - > > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from your > system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawful. > > ___ > 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
out of place mx records.
Hi. I have taken over some dns servers, and the process of doing upgrade, half way through the process.. I have a question about the zone files , as there is some configuration here that I have not seen before and seems out of place. here is an excerpt of the zone file $TTL 14400 @ IN SOA example.com. postmaster.example.com. ( 2010042142 ; Serial 3600; Refresh (1 hours) 1200; Retry (20 minutes) 1728000 ; Expire (20 days) 14400 ; Minimum (4 hours) ) IN NS ns1.example.com. IN NS ns2.example.com. ; IN NS ns1.catalyst.net.nz. IN MX 10 mail01.example.com. IN MX 10 mail02.example.com. ; IN MX 20 mail03.example.com. IN A 202.xx.xx.2 ns1 IN A 192.168.xx.xx ns2 IN A 192.168.xx.xx listservIN A 202.xx.xx.2 IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 cache IN A 202.xx.xx.1 IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 captaincometIN A 202.xx.xx.1 IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 louie IN A 202.xx.xx.1 IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 mail01 IN A 192.168.xx.xx IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 mail02 IN A 192.168.xx.xx IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 nelson IN A 202.xx.xx.1 IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 My question is why would "INMX10mcvpemr01" and "INMX 10mcvpemr02" be repeated trough the zone file surely this is redundant ? Thanks Greg ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: out of place mx records.
Hello Gregory, Thu, 28 Oct 2010 13:04:58 +1300 Gregory Machin wrote: > Hi. > I have taken over some dns servers, and the process of doing upgrade, > half way through the process.. > > I have a question about the zone files , as there is some > configuration here that I have not seen before and seems out of > place. > > here is an excerpt of the zone file > > $TTL 14400 > > @ IN SOA example.com. postmaster.example.com. ( > 2010042142 ; Serial > 3600; Refresh (1 hours) > 1200; Retry (20 minutes) > 1728000 ; Expire (20 days) > 14400 ; Minimum (4 hours) > ) > IN NS ns1.example.com. > IN NS ns2.example.com. > ; IN NS ns1.catalyst.net.nz. > > IN MX 10 mail01.example.com. > IN MX 10 mail02.example.com. > ; IN MX 20 mail03.example.com. > > IN A 202.xx.xx.2 > > ns1 IN A 192.168.xx.xx > ns2 IN A 192.168.xx.xx > > listservINA 202.xx.xx.2 > IN MX 10 mcvpemr01 > IN MX 10 mcvpemr02 > cache INA 202.xx.xx.1 > IN MX 10 mcvpemr01 > IN MX 10 mcvpemr02 > captaincomet IN A 202.xx.xx.1 > IN MX 10 mcvpemr01 > IN MX 10 mcvpemr02 > louie IN A 202.xx.xx.1 > IN MX 10 mcvpemr01 > IN MX 10 mcvpemr02 > mail01 IN A 192.168.xx.xx > IN MX 10 mcvpemr01 > IN MX 10 mcvpemr02 > mail02 IN A 192.168.xx.xx > IN MX 10 mcvpemr01 > IN MX 10 mcvpemr02 > nelson INA 202.xx.xx.1 > IN MX 10 mcvpemr01 > IN MX 10 mcvpemr02 > > > My question is why would "INMX10mcvpemr01" and "INMX > 10mcvpemr02" be repeated trough the zone file surely this is > redundant ? These MX record sets aren't redundant as they belong to the different labels named "listserv", "cache" etc. -- Yours sincerely, Andrey G. Sergeev (AKA Andris) http://www.andris.name/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: out of place mx records.
Hi Gregory, >mail02 IN A 192.168.xx.xx > IN MX 10 mcvpemr01 > IN MX 10 mcvpemr02 >nelson IN A 202.xx.xx.1 > IN MX 10 mcvpemr01 > IN MX 10 mcvpemr02 >My question is why would "INMX10mcvpemr01" and "INMX > 10mcvpemr02" be repeated trough the zone file surely this is >redundant ? It looks like an old way of specifying the MX for each subdomain. Cheers Ian Manners http://www.os2site.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: out of place mx records.
To me it looks redundant, "named-compilezone -o - zone file" should show you how bind interprets these. My guess is that they will be listed only once in the output. I don't see how they could belong to each subdomain, to do that there should be a"@..." to set a new origin? On 28/10/10 2:14, Ian Manners wrote: > Hi Gregory, > >> mail02 IN A 192.168.xx.xx >> IN MX 10 mcvpemr01 >> IN MX 10 mcvpemr02 >> nelson IN A 202.xx.xx.1 >> IN MX 10 mcvpemr01 >> IN MX 10 mcvpemr02 >> My question is why would "INMX10mcvpemr01" and "INMX >> 10mcvpemr02" be repeated trough the zone file surely this is >> redundant ? > It looks like an old way of specifying the MX for each subdomain. > > Cheers > Ian Manners > http://www.os2site.com/ > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: out of place mx records.
Hello Sten, Thu, 28 Oct 2010 02:48:36 +0200 Sten Carlsen wrote: > To me it looks redundant, "named-compilezone -o - zone file" should > show you how bind interprets these. > My guess is that they will be listed only once in the output. > > I don't see how they could belong to each subdomain, to do that there > should be a"@..." to set a new origin? ; Set current origin to "mail02" mail02 IN A 192.168.xx.xx ; Two lines below are still under the same origin "mail02" IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 ; Time to set a new origin nelson IN A 202.xx.xx.1 [...] > On 28/10/10 2:14, Ian Manners wrote: >> Hi Gregory, >> >>> mail02 IN A 192.168.xx.xx >>> IN MX 10 mcvpemr01 >>> IN MX 10 mcvpemr02 >>> nelson IN A 202.xx.xx.1 >>> IN MX 10 mcvpemr01 >>> IN MX 10 mcvpemr02 >>> My question is why would "INMX10mcvpemr01" and "IN >>>MX 10mcvpemr02" be repeated trough the zone file surely >>> this is redundant ? >> It looks like an old way of specifying the MX for each subdomain. -- Yours sincerely, Andrey G. Sergeev (AKA Andris) http://www.andris.name/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: out of place mx records.
They prevent people who start a potentially rogue mailserver to receive mails. I.e. You centralize mails and make sure only your authorized mailserver receives them when you dont have full control over these boxes. -mat On Oct 28, 2010, at 8:48 AM, Sten Carlsen wrote: > To me it looks redundant, "named-compilezone -o - zone file" should show you > how bind interprets these. > My guess is that they will be listed only once in the output. > > I don't see how they could belong to each subdomain, to do that there should > be a"@..." to set a new origin? > > > > On 28/10/10 2:14, Ian Manners wrote: >> >> Hi Gregory, >> >>> mail02 IN A 192.168.xx.xx >>> IN MX 10 mcvpemr01 >>> IN MX 10 mcvpemr02 >>> nelson IN A 202.xx.xx.1 >>> IN MX 10 mcvpemr01 >>> IN MX 10 mcvpemr02 >> >>> My question is why would "INMX10mcvpemr01" and "INMX >>> 10mcvpemr02" be repeated trough the zone file surely this is >>> redundant ? >> It looks like an old way of specifying the MX for each subdomain. >> >> Cheers >> Ian Manners >> http://www.os2site.com/ >> >> ___ >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users > > -- > Best regards > > Sten Carlsen > > No improvements come from shouting: > >"MALE BOVINE MANURE!!!" > ___ > 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: non-improving referral
In article , Leo Baltus wrote: > Hi, > > We are in the process of migrating from bind-9.4-ESV-R2 to bind-9.7.2-P2. > > We have our authoritative servers migrated to bind-9.7.2-P2 and it all > seems to work fine. > > While testing our caching resolvers with bind-9.7.2-P2 however, we > noticed some errors in our logfiles we have never seen before. > > Oct 26 09:52:03 myhost named[21085]: DNS format error from 1.5.3.4#53 > resolving 1.2.4.2.x.y.z.example.com/TXT for client 1.5.3.203#15637: > non-improving referral > Oct 26 09:52:03 myhost named[21085]: DNS format error from 1.5.2.2#53 > resolving 1.2.4.2.x.y.z.example.com/TXT for client 1.5.3.203#15637: > non-improving referral > > Obviously I have obscured some data here :) As you may guess this is a > query for a TXT record from a blocklist-daemon. > > The nameservers on 1.5.3.4 and 1.5.2.2 are bind-9.7.2-P2. > > The queried domains are hosted by us and the hopefully relevant part of > the zone looks like this: > > x.y.z.example.com. IN NS bl1a.example.com. > x.y.z.example.com. IN NS bl1b.example.com. > > A dump of the cache shows NS and A records are in the cache for bl1[ab] > however, on each non-cached query from the client both errorlines > are printed in the log suggesting the resolver is not using the cached > NS records. It *is* using these NS records. It's complaining that there's a problem with the responses these machines are sending. > The client receives a valid answer, so my only real problem seems to be > the amount of spam I get in our logfiles. > > The blocklist is served by rbldnsd, manually query-ing gives my a > valid response. > > Could anybody tell me what problem bind is complaining about? > > Please CC me as I am not on this list. I think what it's complaining about is that the response to the query is a referral to the same or a higher level in the DNS hierarchy. It should be either an ordinary response, a referral to nameservers for a subzone, or an NXDOMAIN. Can you post the result of "dig 1.2.4.2.x.y.z.example.com @bl1a.example.com +norec"? -- 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: out of place mx records.
In article , Sten Carlsen wrote: > To me it looks redundant, "named-compilezone -o - zone file" should show > you how bind interprets these. > My guess is that they will be listed only once in the output. I suggest you try it, and you'll see that you guessed wrong. > > I don't see how they could belong to each subdomain, to do that there > should be a"@..." to set a new origin? @ doesn't set a new origin, $ORIGIN does. @ is simply a special token that gets replaced with the current origin. When you begin a record with blank space, it means that it uses the owner name from the previous line. So: mail02 IN A 192.168.x.x IN MX 10 mcvpemr01 IN MX 10 mcvpemr02 is equivalent to: mail02 IN A 192.168.x.x mail02 IN MX 10 mcvpemr01 mail02 IN MX 10 mcvpemr02 > > > > On 28/10/10 2:14, Ian Manners wrote: > > Hi Gregory, > > > >> mail02 IN A 192.168.xx.xx > >>IN MX 10 mcvpemr01 > >>IN MX 10 mcvpemr02 > >> nelson IN A 202.xx.xx.1 > >>IN MX 10 mcvpemr01 > >>IN MX 10 mcvpemr02 > >> My question is why would "INMX10mcvpemr01" and "INMX > >> 10mcvpemr02" be repeated trough the zone file surely this is > >> redundant ? > > It looks like an old way of specifying the MX for each subdomain. > > > > Cheers > > Ian Manners > > http://www.os2site.com/ > > > > ___ > > bind-users mailing list > > bind-users@lists.isc.org > > https://lists.isc.org/mailman/listinfo/bind-users -- 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: non-improving referral
In message <20101026161348.gj2...@omroep.nl>, Leo Baltus writes: > Hi, > > We are in the process of migrating from bind-9.4-ESV-R2 to bind-9.7.2-P2. > > We have our authoritative servers migrated to bind-9.7.2-P2 and it all > seems to work fine. > > While testing our caching resolvers with bind-9.7.2-P2 however, we > noticed some errors in our logfiles we have never seen before. > > Oct 26 09:52:03 myhost named[21085]: DNS format error from 1.5.3.4#53 resolvi > ng 1.2.4.2.x.y.z.example.com/TXT for client 1.5.3.203#15637: non-improving re > ferral > Oct 26 09:52:03 myhost named[21085]: DNS format error from 1.5.2.2#53 resolvi > ng 1.2.4.2.x.y.z.example.com/TXT for client 1.5.3.203#15637: non-improving re > ferral > > Obviously I have obscured some data here :) As you may guess this is a > query for a TXT record from a blocklist-daemon. > > The nameservers on 1.5.3.4 and 1.5.2.2 are bind-9.7.2-P2. > > The queried domains are hosted by us and the hopefully relevant part of > the zone looks like this: > > x.y.z.example.com. IN NS bl1a.example.com. > x.y.z.example.com. IN NS bl1b.example.com. > > A dump of the cache shows NS and A records are in the cache for bl1[ab] > however, on each non-cached query from the client both errorlines > are printed in the log suggesting the resolver is not using the cached > NS records. > > The client receives a valid answer, so my only real problem seems to be > the amount of spam I get in our logfiles. > > The blocklist is served by rbldnsd, manually query-ing gives my a > valid response. > > Could anybody tell me what problem bind is complaining about? > > Please CC me as I am not on this list. Run "dig +trace +all 1.2.4.2.x.y.z.example.com txt" and look at the results. Somewhere in that chain there will be a broken delegation. This may manifest itself as a authority section in the reply that doesn't match the delegation. > -- > Leo Baltus, internetbeheerder /\ > NPO ICT Internet Services/NPO/\ > Sumatralaan 45, 1217 GP Hilversum, Filmcentrum, west \ /\/ > beh...@omroep.nl, 035-6773555 \/ > ___ > 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: out of place mx records.
Hello Gregory, Thu, 28 Oct 2010 15:54:32 +1300 Gregory Machin wrote: > Hi Andrey. > Thanks for you input. > > OK .. but most of those hosts should not be accepting email > connections, buy my understanding. Or is it implied that email > destined for that host would be handled by the email servers > mcvpemr01 and mcvpemr02 on its behalf ? Yes. This is a nature of MX RR. If you don't want to handle mail traffic for some of your hosts (labels in terms of DNS) at all, then just route your mail as shown below: ; --- Method 1 --- ; This IP should be unreachable or the mail daemon at this host ; should refuse any connections attempts not-for-mail IN A 192.168.209.16 listserv IN A 202.xx.xx.2 IN MX 10 not-for-mail ; --- Method 2 --- listserv IN A 202.xx.xx.2 IN MX 10 not-for-mail.invalid-domain.tld. Another but more complex way is to handle such traffic at your mail relay which is silently delivers messages destined for some domains to /dev/null. > Regards > Gregory Machin > > > On Thu, Oct 28, 2010 at 1:09 PM, Andrey G. Sergeev (AKA Andris) > wrote: >> Hello Gregory, >> >> >> Thu, 28 Oct 2010 13:04:58 +1300 Gregory Machin wrote: >> >>> Hi. >>> I have taken over some dns servers, and the process of doing >>> upgrade, half way through the process.. >>> >>> I have a question about the zone files , as there is some >>> configuration here that I have not seen before and seems out of >>> place. >>> >>> here is an excerpt of the zone file >>> >>> $TTL 14400 >>> >>> @ IN SOA example.com. postmaster.example.com. >>> ( >>> 2010042142 ; Serial >>> 3600 ; Refresh (1 hours) >>> 1200 ; Retry (20 minutes) >>> 1728000 ; Expire (20 days) >>> 14400 ; Minimum (4 hours) >>> ) >>> IN NS ns1.example.com. >>> IN NS ns2.example.com. >>> ; IN NS ns1.catalyst.net.nz. >>> >>> IN MX 10 mail01.example.com. >>> IN MX 10 mail02.example.com. >>> ; IN MX 20 mail03.example.com. >>> >>> IN A 202.xx.xx.2 >>> >>> ns1 IN A 192.168.xx.xx >>> ns2 IN A 192.168.xx.xx >>> >>> listserv IN A 202.xx.xx.2 >>> IN MX 10 mcvpemr01 >>> IN MX 10 mcvpemr02 >>> cache IN A 202.xx.xx.1 >>> IN MX 10 mcvpemr01 >>> IN MX 10 mcvpemr02 >>> captaincomet IN A 202.xx.xx.1 >>> IN MX 10 mcvpemr01 >>> IN MX 10 mcvpemr02 >>> louie IN A 202.xx.xx.1 >>> IN MX 10 mcvpemr01 >>> IN MX 10 mcvpemr02 >>> mail01 IN A 192.168.xx.xx >>> IN MX 10 mcvpemr01 >>> IN MX 10 mcvpemr02 >>> mail02 IN A 192.168.xx.xx >>> IN MX 10 mcvpemr01 >>> IN MX 10 mcvpemr02 >>> nelson IN A 202.xx.xx.1 >>> IN MX 10 mcvpemr01 >>> IN MX 10 mcvpemr02 >>> >>> >>> My question is why would "IN MX 10 mcvpemr01" and "IN >>> MX 10 mcvpemr02" be repeated trough the zone file surely this is >>> redundant ? >> >> These MX record sets aren't redundant as they belong to the >> different labels named "listserv", "cache" etc. -- Yours sincerely, Andrey G. Sergeev (AKA Andris) http://www.andris.name/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
need to disable dnssec for pseudo TLD zone
When I recently installed the root dnssec initial key on our DNS it broke
it's ability to accept responses for forwarded requests for a DNS block
list zone served by another system. Other queries aren't affected. The
config for the forwarded zone looks like:
zone "dnsbl" {
type forward;
forward only;
forwarders {
10.0.0.124;
};
};
The server at 10.0.0.124 is running rbldnsd. Queries to our main resolver
DNS for anything in the 'dnsbl' zone generate a SERVFAIL and BIND logs
messages similar to the following:
error (chase DS servers) resolving 'sbl.dnsbl/DS/IN': 10.0.0.124#53
If I disable the root initial key, the forwarded queries work again. I
think the problem is that our pseudo TLD 'dnsbl' isn't a signed zone or
something like that. The RRs for the zone are retrieved from various spam
BL repositories.
Is there a way to disable dnssec validation on a per-zone basis for
internal pseudo TLDs?
Antonio Querubin
808-545-5282 x3003
e-mail/xmpp: t...@lava.net
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
