dig info
Sometime I dig a domain name, it returns the results below: ;; reply from unexpected source: 59.42.52.246#59721, expected 211.66.80.167#53 ;; reply from unexpected source: 59.42.52.246#59721, expected 211.66.80.167#53 ;; reply from unexpected source: 59.42.52.246#59721, expected 211.66.80.167#53 ;; connection timed out; no servers could be reached but sometime it returns the correct results. what happened to this domain's name server (AFAIK it's using bind-9.6). Thanks. Need a Holiday? Win a $10,000 Holiday of your choice. Enter now.http://us.lrd.yahoo.com/_ylc=X3oDMTJxN2x2ZmNpBF9zAzIwMjM2MTY2MTMEdG1fZG1lY2gDVGV4dCBMaW5rBHRtX2xuawNVMTEwMzk3NwR0bV9uZXQDWWFob28hBHRtX3BvcwN0YWdsaW5lBHRtX3BwdHkDYXVueg--/SIG=14600t3ni/**http%3A//au.rd.yahoo.com/mail/tagline/creativeholidays/*http%3A//au.docs.yahoo.com/homepageset/%3Fp1=other%26p2=au%26p3=mailtagline ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
named reloading
Hello, Just asked this question again, b/c it's not easy to test... When named is reloading with 'rndc reload' command, client's query is coming in, what will be happened? Will client's request be dropped? Thanks. Need a Holiday? Win a $10,000 Holiday of your choice. Enter now.http://us.lrd.yahoo.com/_ylc=X3oDMTJxN2x2ZmNpBF9zAzIwMjM2MTY2MTMEdG1fZG1lY2gDVGV4dCBMaW5rBHRtX2xuawNVMTEwMzk3NwR0bV9uZXQDWWFob28hBHRtX3BvcwN0YWdsaW5lBHRtX3BwdHkDYXVueg--/SIG=14600t3ni/**http%3A//au.rd.yahoo.com/mail/tagline/creativeholidays/*http%3A//au.docs.yahoo.com/homepageset/%3Fp1=other%26p2=au%26p3=mailtagline ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: named reloading
I tried to test it, steps as below:
(1) add a zone "x.test.com", and assign an A record into it:
ns.x.test.com.60 IN A192.168.1.246
(2) to reload bind every 1 second, using a shell script:
#!/bin/sh
while [ 1 ];do
/usr/local/bind/sbin/rndc reload
sleep 1
done
(3) to make DNS query to this named every 1/10 second, using a perl script:
use strict;
while(1) {
my @x = `dig ns.x.test.com \...@localhost +short`;
my $x = shift @x;
chomp $x;
print "wrong: $x\n" if ($x ne '192.168.1.246');
select(undef, undef, undef, 0.1);
}
(4) run both shell and perl scripts, and watch the results output of perl
script.
After tested for some time (ie, 10 minutes), I got nothing from perl script's
output.
So I assume that when named is reloading, it doesn't affect user's query.
Am I right? thanks for any helps.
--- On Mon, 18/5/09, Tech W. wrote:
> From: Tech W.
> Subject: named reloading
> To: bind-users@lists.isc.org
> Received: Monday, 18 May, 2009, 4:16 PM
>
> Hello,
>
> Just asked this question again, b/c it's not easy to
> test...
> When named is reloading with 'rndc reload' command,
> client's query is coming in, what will be happened? Will
> client's request be dropped?
>
Need a Holiday? Win a $10,000 Holiday of your choice. Enter
now.http://us.lrd.yahoo.com/_ylc=X3oDMTJxN2x2ZmNpBF9zAzIwMjM2MTY2MTMEdG1fZG1lY2gDVGV4dCBMaW5rBHRtX2xuawNVMTEwMzk3NwR0bV9uZXQDWWFob28hBHRtX3BvcwN0YWdsaW5lBHRtX3BwdHkDYXVueg--/SIG=14600t3ni/**http%3A//au.rd.yahoo.com/mail/tagline/creativeholidays/*http%3A//au.docs.yahoo.com/homepageset/%3Fp1=other%26p2=au%26p3=mailtagline
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Odd config problem
Hello all, I use the secure BIND template by Rob Thomas (http://www.cymru.com/Documents/secure-bind-template.html ). I have had a peculiar problem with this template conf, which I have not been able to resolve. My problem is that some slave zones return REFUSED when queried from the external view for ANY records while others return the expected values. For example: dig @194.86.83.21 ruoka.fi ANY returns nothing, but when queried from master zone: dig @194.86.83.27 ruoka.fi ANY returns expected values. Furthermore, a seemingly identical zone (see complete zone configs below) for another domain returns expected values from both servers: dig @194.86.83.21 tri.fi ANY <- slave dig @194.86.83.27 tri.fi ANY <- master I have so far figured out that changing the external view configuration options 'additional-from-auth' and 'additional-from- cache' both to 'yes' will cure the problem. However, I don't see the logic and I take it that's not really a desirable cure either. :) My BIND version is 9.4.3. Cheers, $ORIGIN . $TTL 38400 ; 10 hours 40 minutes tri.fi IN SOA ns.kirnauskis.com. hostmaster.kirnauskis.com. ( 1146160445 ; serial 10800 ; refresh (3 hours) 3600 ; retry (1 hour) 604800 ; expire (1 week) 38400 ; minimum (10 hours 40 minutes) ) NS ns.kirnauskis.com. NS ns2.kirnauskis.com. MX 0 smtp.kirnauskis.com. TXT "v=spf1 mx ip4:194.86.83.27 ip4:194.86.83.28 ip4:194.86.83.30 ip4:194.86.83.31 ip4:194.86.83.32 -all" $ORIGIN tri.fi. www A 194.86.83.31 $ORIGIN . $TTL 38400 ; 10 hours 40 minutes ruoka.fiIN SOA ns.kirnauskis.com. hostmaster.kirnauskis.com. ( 2004090608 ; serial 10800 ; refresh (3 hours) 3600 ; retry (1 hour) 432000 ; expire (5 days) 38400 ; minimum (10 hours 40 minutes) ) NS ns.kirnauskis.com. NS ns2.kirnauskis.com. MX 0 smtp.kirnauskis.com. TXT "v=spf1 ~all" $ORIGIN ruoka.fi. www A 194.86.83.32 -- Hans Vallden h...@vallden.com skype: hans.vallden ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Odd config problem
In message <61d78605-0cb2-485e-aa75-a49ba3c45...@vallden.com>, Hans Vallden wri tes: > Hello all, > > I use the secure BIND template by Rob Thomas (http://www.cymru.com/Documents/ > secure-bind-template.html > ). I have had a peculiar problem with this template conf, which I have > not been able to resolve. My problem is that some slave zones return > REFUSED when queried from the external view for ANY records while > others return the expected values. For example: > > dig @194.86.83.21 ruoka.fi ANY > > returns nothing, but when queried from master zone: > > dig @194.86.83.27 ruoka.fi ANY > > returns expected values. Furthermore, a seemingly identical zone (see > complete zone configs below) for another domain returns expected > values from both servers: What do you have infront of the nameserver? Firewall? NAT? Note the reply is to the wrong port. 00:15:38.593884 211.30.172.21.57914 > 194.86.83.21.53: 60775 ANY? ruoka.fi. (26) 00:15:38.935222 194.86.83.21.53 > 211.30.172.21.48599: 60775*- 5/0/0 SOA, NS ns2.kirnauskis.com., NS ns.kirnauskis.com., MX smtp.kirnauskis.com. 0, TXT v=spf1 ~all (167) > dig @194.86.83.21 tri.fi ANY <- slave > dig @194.86.83.27 tri.fi ANY <- master > > I have so far figured out that changing the external view > configuration options 'additional-from-auth' and 'additional-from- > cache' both to 'yes' will cure the problem. However, I don't see the > logic and I take it that's not really a desirable cure either. :) My > BIND version is 9.4.3. > > Cheers, > > > $ORIGIN . > $TTL 38400; 10 hours 40 minutes > tri.fiIN SOA ns.kirnauskis.com. hostmaster.kirnauski > s.com. ( > 1146160445 ; serial > 10800 ; refresh (3 hours) > 3600 ; retry (1 hour) > 604800 ; expire (1 week) > 38400 ; minimum (10 hours 40 minutes) > ) > NS ns.kirnauskis.com. > NS ns2.kirnauskis.com. > MX 0 smtp.kirnauskis.com. > TXT "v=spf1 mx ip4:194.86.83.27 ip4:194.86.83.28 ip > 4:194.86.83.30 > ip4:194.86.83.31 ip4:194.86.83.32 -all" > $ORIGIN tri.fi. > www A 194.86.83.31 > > $ORIGIN . > $TTL 38400; 10 hours 40 minutes > ruoka.fi IN SOA ns.kirnauskis.com. hostmaster.kirnauskis.com. ( > 2004090608 ; serial > 10800 ; refresh (3 hours) > 3600 ; retry (1 hour) > 432000 ; expire (5 days) > 38400 ; minimum (10 hours 40 minutes) > ) > NS ns.kirnauskis.com. > NS ns2.kirnauskis.com. > MX 0 smtp.kirnauskis.com. > TXT "v=spf1 ~all" > $ORIGIN ruoka.fi. > www A 194.86.83.32 > > -- > Hans Vallden > h...@vallden.com > skype: hans.vallden > > > > ___ > 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: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig info
In message <980168.77226...@web15605.mail.cnb.yahoo.com>, "Tech W." writes: > > Sometime I dig a domain name, it returns the results below: > > ;; reply from unexpected source: 59.42.52.246#59721, expected 211.66.80.167#5 > 3 > ;; reply from unexpected source: 59.42.52.246#59721, expected 211.66.80.167#5 > 3 > ;; reply from unexpected source: 59.42.52.246#59721, expected 211.66.80.167#5 > 3 > ;; connection timed out; no servers could be reached Is this a linux box dig is running on? Some linux kernels have the worst possible UDP port selection algorithms. They keep selecting the port that was last selected provided it is closed before you get the next port selection request. On a box with several short lived UDP sockets you will almost certainly get reply traffic destined to the last user of the port. This is what is happening here, dig seeing replies to whatever was using the port immediately before dig was run. > but sometime it returns the correct results. > > what happened to this domain's name server (AFAIK it's using bind-9.6). > Thanks. > > > > Need a Holiday? Win a $10,000 Holiday of your choice. Enter now.http:// > us.lrd.yahoo.com/_ylc=X3oDMTJxN2x2ZmNpBF9zAzIwMjM2MTY2MTMEdG1fZG1lY2gDVGV4dCB > MaW5rBHRtX2xuawNVMTEwMzk3NwR0bV9uZXQDWWFob28hBHRtX3BvcwN0YWdsaW5lBHRtX3BwdHkD > YXVueg--/SIG=14600t3ni/**http%3A//au.rd.yahoo.com/mail/tagline/creativeholida > ys/*http%3A//au.docs.yahoo.com/homepageset/%3Fp1=other%26p2=au%26p3=mailtagli > ne > ___ > 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: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig info
--- On Mon, 18/5/09, Mark Andrews wrote: > From: Mark Andrews > Subject: Re: dig info > To: "Tech W." > Cc: bind-users@lists.isc.org > Received: Monday, 18 May, 2009, 10:35 PM > > In message <980168.77226...@web15605.mail.cnb.yahoo.com>, > "Tech W." writes: > > > > Sometime I dig a domain name, it returns the results > below: > > > > ;; reply from unexpected source: 59.42.52.246#59721, > expected 211.66.80.167#5 > > 3 > > ;; reply from unexpected source: 59.42.52.246#59721, > expected 211.66.80.167#5 > > 3 > > ;; reply from unexpected source: 59.42.52.246#59721, > expected 211.66.80.167#5 > > 3 > > ;; connection timed out; no servers could be reached > > Is this a linux box dig is running > on? Some linux kernels > have the worst possible UDP port > selection algorithms. They > keep selecting the port that was last > selected provided it > is closed before you get the next port > selection request. > On a box with several short lived UDP > sockets you will > almost certainly get reply traffic > destined to the last > user of the port. > > This is what is happening here, dig > seeing replies to > whatever was using the port immediately > before dig was run. > > Yes Mark it's a linux box with kernel 2.6.24. But I still can't understand for your meanings. Could you please explain it with more clear way? Thanks again. Need a Holiday? Win a $10,000 Holiday of your choice. Enter now.http://us.lrd.yahoo.com/_ylc=X3oDMTJxN2x2ZmNpBF9zAzIwMjM2MTY2MTMEdG1fZG1lY2gDVGV4dCBMaW5rBHRtX2xuawNVMTEwMzk3NwR0bV9uZXQDWWFob28hBHRtX3BvcwN0YWdsaW5lBHRtX3BwdHkDYXVueg--/SIG=14600t3ni/**http%3A//au.rd.yahoo.com/mail/tagline/creativeholidays/*http%3A//au.docs.yahoo.com/homepageset/%3Fp1=other%26p2=au%26p3=mailtagline ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Are the TYPE65535 RRs necessary?
If you add DNSKEY records dynamically to a zone, BIND 9.6 signs the zone (provided the private keys are available) and it also creates TYPE65535 records at the zone apex (one for each key). I had assumed that these were necessary in some way for subsequent RRSIG refreshing, etc. But ... With BIND 9.6.1b1, I signed a new zone with dnssec-signzone (using lots of jitter so that signature expiry times were well distributed) and *then* added it to named.conf (with the private keys available, and allow-update not "none"). Named churned a bit, but did not create any TYPE65535 records. "Bother", I thought, "that probably means it's not going to refresh the RRSIGs as they approach expiry." But after leaving it for a bit, I found it was in fact refreshing them at the expected times after all, still with no TYPE65535 records being present. (And this state survives named being restarted.) So what are the TYPE65535 records actually for? -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Are the TYPE65535 RRs necessary?
> So what are the TYPE65535 records actually for? They indicate that the zone is in a transition state, such as being signed by a new key or having signatures from a deleted key removed. This should probably be documented better, but since that record is only for named's internal record-keeping (it ensures that the signing process can pick up where it left off if it was interrupted by a crash), it hasn't been. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Are the TYPE65535 RRs necessary?
> They indicate that the zone is in a transition state, such as being > signed by a new key or having signatures from a deleted key removed. > > This should probably be documented better, but since that record is > only for named's internal record-keeping (it ensures that the signing > process can pick up where it left off if it was interrupted by a > crash), it hasn't been. Oh, I should add: We recently found out that 65535 is reserved by IANA, so we changed it in 9.6.1b1 to 65534. So if you were grepping for the old value, you might've missed it. (The type number can be overridden by the sig-signing-type zone option.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig info
Tech W. wrote: --- On Mon, 18/5/09, Mark Andrews wrote: From: Mark Andrews Subject: Re: dig info To: "Tech W." Cc: bind-users@lists.isc.org Received: Monday, 18 May, 2009, 10:35 PM In message <980168.77226...@web15605.mail.cnb.yahoo.com>, "Tech W." writes: Sometime I dig a domain name, it returns the results below: ;; reply from unexpected source: 59.42.52.246#59721, expected 211.66.80.167#5 3 ;; reply from unexpected source: 59.42.52.246#59721, expected 211.66.80.167#5 3 ;; reply from unexpected source: 59.42.52.246#59721, expected 211.66.80.167#5 3 ;; connection timed out; no servers could be reached Is this a linux box dig is running on? Some linux kernels have the worst possible UDP port selection algorithms. They keep selecting the port that was last selected provided it is closed before you get the next port selection request. On a box with several short lived UDP sockets you will almost certainly get reply traffic destined to the last user of the port. This is what is happening here, dig seeing replies to whatever was using the port immediately before dig was run. Yes Mark it's a linux box with kernel 2.6.24. But I still can't understand for your meanings. Could you please explain it with more clear way? Thanks again. 1. Some (non-DNS) app gets assigned a socket with port X 2. It communicates with another device over that socket 3. It closes the socket before the other device is done sending data 4. The same socket with port X gets immediately re-assigned to a new "dig" instance 5. dig sends a query packet somewhere, listens for responses 6. Some of the packets from the previous (non-DNS) transaction arrive at the socket 7. dig complains, because the source address of the incoming packets doesn't match the destination of the original query that it sent - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Are the TYPE65535 RRs necessary?
In message , Chris Tho mpson writes: > If you add DNSKEY records dynamically to a zone, BIND 9.6 signs the > zone (provided the private keys are available) and it also creates > TYPE65535 records at the zone apex (one for each key). I had assumed > that these were necessary in some way for subsequent RRSIG refreshing, > etc. But ... > > With BIND 9.6.1b1, I signed a new zone with dnssec-signzone (using > lots of jitter so that signature expiry times were well distributed) > and *then* added it to named.conf (with the private keys available, > and allow-update not "none"). Named churned a bit, but did not create > any TYPE65535 records. "Bother", I thought, "that probably means it's > not going to refresh the RRSIGs as they approach expiry." But after > leaving it for a bit, I found it was in fact refreshing them at the > expected times after all, still with no TYPE65535 records being present. > (And this state survives named being restarted.) > > So what are the TYPE65535 records actually for? > There are several uses. 1. to tell named to restart adding/deleting signatures for the matching key 2. to tell the operator when a key has completed signing the zone so you can know that you can delete another key, publish a DS for it, publish it as a trust anchor, etc. It's still experimental. -- 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: Are the TYPE65535 RRs necessary?
In message <200905182258.n4imwd7k079...@drugs.dv.isc.org>, Mark Andrews writes: > > In message , Chris T > ho > mpson writes: > > If you add DNSKEY records dynamically to a zone, BIND 9.6 signs the > > zone (provided the private keys are available) and it also creates > > TYPE65535 records at the zone apex (one for each key). I had assumed > > that these were necessary in some way for subsequent RRSIG refreshing, > > etc. But ... > > > > With BIND 9.6.1b1, I signed a new zone with dnssec-signzone (using > > lots of jitter so that signature expiry times were well distributed) > > and *then* added it to named.conf (with the private keys available, > > and allow-update not "none"). Named churned a bit, but did not create > > any TYPE65535 records. "Bother", I thought, "that probably means it's > > not going to refresh the RRSIGs as they approach expiry." But after > > leaving it for a bit, I found it was in fact refreshing them at the > > expected times after all, still with no TYPE65535 records being present. > > (And this state survives named being restarted.) > > > > So what are the TYPE65535 records actually for? > > > There are several uses. > 1. to tell named to restart adding/deleting signatures for the matching key > 2. to tell the operator when a key has completed signing the zone so you can >know that you can delete another key, publish a DS for it, publish it as >a trust anchor, etc. > It's still experimental. The record's current layout is: buf[0] = dnskey.algorithm; buf[1] = (keyid & 0xff00) >> 8; buf[2] = (keyid & 0xff); buf[3] = (tuple->op == DNS_DIFFOP_ADD) ? 0 : 1; buf[4] = 0; When the last octet is non-zero the operation is complete. If the record relates to a key removal then the TYPE65535 record will be removed when the change completes. 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 -- 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
