Re: bind 9.7.2-P3 does not resolve www.microsoft.com
> trying to resolve www.microsoft.com or microsoft.com results in a > "connection timed out; no servers could be reached" Well, for what it's worth - it's not just you having that issue. When testing from home and from work I get the same. Of course, I could be doing something wrong, but whenever I see an error I like to imagine it's somebody elses fault :D One of the nameservers for microsoft.com is ns1.msft.net with an IP address of 65.55.37.62. For some reason the response I get from it is truncated, and retrying using TCP doesn't work. Using EDNS0 also doesn't seem to work, I get FORMERR back: [eiv...@vimes ~]$ /usr/local/bin/dig any microsoft.com @65.55.37.62 ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.7.2-P2 <<>> any microsoft.com @65.55.37.62 ;; global options: +cmd ;; connection timed out; no servers could be reached [eiv...@vimes ~]$ /usr/local/bin/dig +edns=0 any microsoft.com @65.55.37.62 ; <<>> DiG 9.7.2-P2 <<>> +edns=0 any microsoft.com @65.55.37.62 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 6660 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;microsoft.com. IN ANY ;; Query time: 205 msec ;; SERVER: 65.55.37.62#53(65.55.37.62) ;; WHEN: Tue Dec 28 09:10:55 2010 ;; MSG SIZE rcvd: 42 [eiv...@vimes ~]$ Doing queries that give shorter answers work fine - look at these, notice the big (but still small enough) TXT reply, and then see how it fails on a query for "any": [eiv...@vimes ~]$ /usr/local/bin/dig +short any www.microsoft.com @65.55.37.62 toggle.www.ms.akadns.net. [eiv...@vimes ~]$ /usr/local/bin/dig +short mx www.microsoft.com @65.55.37.62 toggle.www.ms.akadns.net. [eiv...@vimes ~]$ /usr/local/bin/dig +short mx microsoft.com @65.55.37.62 10 mail.messaging.microsoft.com. [eiv...@vimes ~]$ /usr/local/bin/dig +short txt microsoft.com @65.55.37.62 "v=spf1 mx include:_spf-a.microsoft.com include:_spf-b.microsoft.com include:_spf-c.microsoft.com include:_spf-ssg-a.microsoft.com ip4:131.107.115.212 ip4:131.107.115.215 ip4:131.107.115.214 ip4:205.248.106.64 ip4:205.248.106.30 ip4:205.248.106.32 ~all" "FbUF6DbkE+Aw1/wi9xgDi8KVrIIZus5v8L6tbIQZkGrQ/rVQKJi8CjQbBtWtE64ey4NJJwj5J65PIggVYNabdQ==" [eiv...@vimes ~]$ /usr/local/bin/dig +short any microsoft.com @65.55.37.62 ;; Truncated, retrying in TCP mode. ;; connection timed out; no servers could be reached [eiv...@vimes ~]$ And in general, I don't have problems with EDNS0 or using TCP to look up other domains with big replies, for example I can use both both of these commands just fine: /usr/local/bin/dig +edns=0 any se. @a.ns.se /usr/local/bin/dig +vc any se. @a.ns.se So, to recap: at the risk of showing what a fool I am by doing something completely wrong here, I'm betting Microsoft has messed up their DNS - I would have expected queries over TCP to work, and I would not have expected EDNS to give a FORMERR (but ok, if a nameserver doesn't implement EDNS, giving a FORMERR is apparantly the right thing to do). ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.7.2-P3 does not resolve www.microsoft.com
>> trying to resolve www.microsoft.com or microsoft.com results in a >> "connection timed out; no servers could be reached" > > Well, for what it's worth - it's not just you having that issue. When > testing from home and from work I get the same. > works fine for me on linux and Solaris. -- Dennis Clarke dcla...@opensolaris.ca <- Email related to the open source Solaris dcla...@blastwave.org <- Email related to open source for Solaris ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.7.2-P3 does not resolve www.microsoft.com
> works fine for me on linux and Solaris. In my case it's using FreeBSD and Solaris. The problem might be related to where you do queries from? Anyway, I tried some other nameservers / "looking glass" sites, like these - I can't vouch for how good they normally are, but these were ones I found when searching for "dns looking glass": http://looking-glass.taide.net/ I can look up other domains fine, but when looking up "microsoft.com" it comes back with: connection timed out; no servers could be reached http://ipdnstools.com/ It times out when I do a "Get DNS Records" query for "microsoft.com" When testing for yourself, please keep in mind that limited queries seem to work fine (like, asking for A records, or MX), but doing any-queries which give everything seems to fail. Regards Eivind Olsen ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: bind 9.7.2-P3 does not resolve www.microsoft.com
It's working fine for me from RHEL5 Linux DNS servers and from Windows DNS servers. -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of Eivind Olsen Sent: Tuesday, December 28, 2010 4:16 AM To: bind-users@lists.isc.org Subject: Re: bind 9.7.2-P3 does not resolve www.microsoft.com > works fine for me on linux and Solaris. In my case it's using FreeBSD and Solaris. The problem might be related to where you do queries from? Anyway, I tried some other nameservers / "looking glass" sites, like these - I can't vouch for how good they normally are, but these were ones I found when searching for "dns looking glass": http://looking-glass.taide.net/ I can look up other domains fine, but when looking up "microsoft.com" it comes back with: connection timed out; no servers could be reached http://ipdnstools.com/ It times out when I do a "Get DNS Records" query for "microsoft.com" When testing for yourself, please keep in mind that limited queries seem to work fine (like, asking for A records, or MX), but doing any-queries which give everything seems to fail. Regards Eivind Olsen ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users Proud partner. Susan G. Komen for the Cure. Please consider our environment before printing this e-mail or attachments. -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Does anyone know where to find the ISC signing keys for source packages?
On 12/23/2010 4:09 PM, Casey Deccio wrote: On Thu, Dec 23, 2010 at 12:49 PM, Oisin McGuinness wrote: But I can't find any reference to current PGP or other signing keys; does anyone know where to find them on the www.isc.org web site or where to obtain them otherwise? http://www.isc.org/about/openpgp https://www.isc.org/about/openpgp will work as well. -- Dave ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ignoring incorrect nameservers in authority section
On 12/24/2010 2:51 AM, Sunil Shetye wrote: Here, I can see that the nameserver is giving the right replies to all queries except the NS queries. How can an authoritative server give "wrong" answers? I was hoping that either bind should catch such cases automatically or allow some workaround which need not be monitored later. You're asking BIND to deduce the intent of the domain owner. -- Dave ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.7.2-P3 does not resolve www.microsoft.com
On 12/28/10 00:26, Eivind Olsen wrote: So, to recap: at the risk of showing what a fool I am by doing something completely wrong here, I'm betting Microsoft has messed up their DNS - I would have expected queries over TCP to work, and I would not have expected EDNS to give a FORMERR (but ok, if a nameserver doesn't implement EDNS, giving a FORMERR is apparantly the right thing to do). Yes, see section 5.3 of RFC 2671, which defines EDNS. FORMERR is one of the expected responses for a server that doesn't support EDNS. 'dig any microsoft.com' likely results in an answer that exceeds 512 bytes. In such a situation, if either the server or the client do not support EDNS0, they must fall back to TCP. Microsoft either has (incorrectly) not implemented TCP on their nameservers, or is (incorrectly) blocking it at some intermediate firewall. Name servers are NOT allowed to NOT implement TCP. This is a good counter-example to those folks who periodically post to this list asking why they shouldn't be blocking TCP/53 at some firewall in front of their nameserver. As we can see, TCP can be necessary to properly resolve domain names. In other words, you are correct (and you do not appear to be doing something wrong): Microsoft has messed up their DNS. Moreover, the problem is not limited to resolvers running BIND. I can replicate the issue on a server running unbound 1.4.6. 'dig any microsoft.com' will easily replicate the error. The question remains as to why simply trying to resolve microsoft.com (i.e. the A record) caused truncation and fallback to TCP. In all cases I have tried, this record resolves. For the original poster, it's a good idea to double-check that YOUR server is capable of receiving answers longer that 512 bytes. Later versions of BIND will set the DO bit on queries and this will result in longer answers (e.g. in order to resolve the ns[12345].msft.net servers so that they can be queried). 'dig any berkeley.edu' is one way to test this out...:) michael ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.7.2-P3 does not resolve www.microsoft.com
On 12/28/10 06:07, Lightner, Jeff wrote: It's working fine for me from RHEL5 Linux DNS servers and from Windows DNS servers. It's not clear from this thread whether 'dig any microsoft.com @ns[12345].msft.net' works for anyone. I cannot get it to work from any of the msft.net servers on clients on the east and west coasts of the US, with different paths. If anyone can get this to work, *from* one of the msft.net servers, that's worth noting. I can effectively prime a cache by querying for microsoft.com NS, SOA, TXT, A, etc., and then querying my cache for ANY. The 'ANY' response I get back from cache is 639 bytes. A TXT query alone returns a response of 494 bytes, including authority. This looks broken on Microsoft's part. michael ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.7.2-P3 does not resolve www.microsoft.com
Michael Sinatra wrote: > On 12/28/10 06:07, Lightner, Jeff wrote: >> It's working fine for me from RHEL5 Linux DNS servers and from Windows >> DNS servers. > > It's not clear from this thread whether 'dig any microsoft.com > @ns[12345].msft.net' works for anyone. I cannot get it to work from > any of the msft.net servers on clients on the east and west coasts of > the US, with different paths. If anyone can get this to work, *from* > one of the msft.net servers, that's worth noting. > > I can effectively prime a cache by querying for microsoft.com NS, SOA, > TXT, A, etc., and then querying my cache for ANY. The 'ANY' response I > get back from cache is 639 bytes. A TXT query alone returns a response > of 494 bytes, including authority. > > This looks broken on Microsoft's part. > > michael > >From the Chicago area, I get 'Truncated, retrying in TCP mode' and then a connection timeout when doing: dig any microsoft.com @ns[12345].msft.net This however works: dig any www.microsoft.com @ns[12345].msft.net But it returns a cname entry to toggle.www.ms.adadns.net A traceroute shows our traffic hitting Level3's backbone in Chicago. Lyle Giese LCR Computer Services, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Does anyone know where to find the ISC signing keys for source packages?
> On 12/23/2010 4:09 PM, Casey Deccio wrote: > > On Thu, Dec 23, 2010 at 12:49 PM, Oisin McGuinness > > wrote: > > > >> But I can't find any reference to current PGP or other signing keys; does > >> anyone know where to find > >> them on the www.isc.org web site or where to obtain them otherwise? > > > > http://www.isc.org/about/openpgp > > https://www.isc.org/about/openpgp will work as well. > > -- > Dave It looks like I am a little dim today. Given gpg and the key, what steps do I do to verify a source package? Tom Schulz Applied Dynamics Intl. sch...@adi.com ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Does anyone know where to find the ISC signing keys for source packages?
At Tue, 28 Dec 2010 15:50:23 -0500 (EST), Thomas Schulz wrote: > > It looks like I am a little dim today. Given gpg and the key, what steps > do I do to verify a source package? General case: $ gpg --verify sigfile tarball Eg: $ gpg --verify bind-9.7.2-P3.tar.gz.sha256.asc bind-9.7.2-P3.tar.gz We probably should add this to the aforementioned web page. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: auto update signatures dnssec
sorry for the top box on alan clegg
Le lundi 27 décembre 2010 à 08:48 -0500, Alan Clegg a écrit :
> On 12/27/2010 1:07 AM, fakessh wrote:
>
> > good day and merry christmas.
>
> Thanks, and to you as well.
>
> > I just put in place guidelines in bind config to update the signatures
> > dnssec
> > I'm looking for options that require the least amount of maintenace that
> > all updates of signatures are performed without any external intervention
> >
> > i quote my named conf
> >
> > zone "fakessh.eu" {
> > type master;
> > file "/var/named/fakessh.eu.hosts";
> > auto-dnssec maintain;
> > update-policy local;
> > key-directory "/var/named/keyset-fakessh.eu";
> > allow-transfer { 213.251.188.140;87.98.164.164;
> > 195.234.42.1;94.23.59.30; };
> > };
> >
> > is what the guidelines are good options
>
> A bit more interesting is the command that you used to sign the zone.
> When signatures reach 3/4 lifetime, the associated record is
> automatically re-signed.
>
> Additionally, when new keys are made available signatures will created
> based on the timing meta-data in the keys..
>
> Overall, the defaults seem to be "good enough" for nearly everyone.
>
> AlanC
hello responsible bind community.
you gave me the answer, thank you to my question but I am having new
problems.
I encounter errors during the self resignatures
i quote my multiple error :
I do not know what it is
Dec 28 22:04:02 r13151
named-sdb[24511]: /var/named/renelacroute.fr.hosts.jnl: create:
permission denied
Dec 28 22:04:02 r13151 named-sdb[24511]: zone nicolaspichot.fr/IN:
zone_resigninc:dns_journal_open -> unexpected error
Dec 28 22:04:02 r13151 named-sdb[24511]: dns_dnssec_findzonekeys2: error
reading private key file fakessh.eu/DSA/9552: file not found
Dec 28 22:04:02 r13151 named-sdb[24511]: dns_dnssec_findzonekeys2: error
reading private key file fakessh.eu/DSA/47103: file not found
Dec 28 22:04:02 r13151 named-sdb[24511]: zone r13151.ovh.net/IN: sending
notifies (serial 2010111401)
Dec 28 22:04:02 r13151 named-sdb[24511]: zone renelacroute.fr/IN:
zone_resigninc:dns_journal_open -> unexpected error
Dec 28 22:04:02 r13151 kernel: Shorewall:fw2net:ACCEPT:IN= OUT=eth0
SRC=94.23.60.214 DST=88.191.64.64 LEN=148 TOS=0x00 PREC=0x00 TTL=64
ID=14118 PROTO=UDP SPT=41425 DPT=53 LEN=128
Dec 28 22:04:02 r13151 named-sdb[24511]: zone fakessh.eu/IN: setting
keywarntime to 1294213060 - 7 days
Dec 28 22:04:03 r13151 kernel: Shorewall:fw2net:ACCEPT:IN= OUT=eth0
SRC=94.23.60.214 DST=88.191.64.64 LEN=148 TOS=0x00 PREC=0x00 TTL=64
ID=14119 PROTO=UDP SPT=35445 DPT=53 LEN=128
Dec 28 22:04:03 r13151 named-sdb[24511]: zone nicolaspichot.fr/IN:
sending notifies (serial 2010120601)
Dec 28 22:04:03 r13151 named-sdb[24511]: dns_dnssec_findzonekeys2: error
reading private key file nicolaspichot.fr/DSA/37015: file not found
Dec 28 22:04:03 r13151
named-sdb[24511]: /var/named/fakessh.eu.hosts.jnl: create: permission
denied
Dec 28 22:04:03 r13151 named-sdb[24511]: zone fakessh.eu/IN:
zone_resigninc:dns_journal_open -> unexpected error
Dec 28 22:04:03 r13151 named-sdb[24511]: dns_dnssec_findzonekeys2: error
reading private key file nicolaspichot.fr/DSA/7246: file not found
Dec 28 22:04:03 r13151 named-sdb[24511]: zone renelacroute.fr/IN:
sending notifies (serial 2010120601)
Dec 28 22:04:03 r13151 named-sdb[24511]: dns_dnssec_findzonekeys2: error
reading private key file fakessh.eu/DSA/9552: file not found
Dec 28 22:04:04 r13151 named-sdb[24511]: dns_dnssec_findzonekeys2: error
reading private key file fakessh.eu/DSA/47103: file not found
Dec 28 22:04:04 r13151 named-sdb[24511]: dns_dnssec_findzonekeys2: error
reading private key file renelacroute.fr/DSA/64823: file not found
Dec 28 22:04:04 r13151
named-sdb[24511]: /var/named/nicolaspichot.fr.hosts.jnl: create:
permission denied
Dec 28 22:04:04 r13151 named-sdb[24511]: zone fakessh.eu/IN:
zone_resigninc:dns_db_getsigningtime -> not found
Dec 28 22:04:04 r13151 named-sdb[24511]: dns_dnssec_findzonekeys2: error
reading private key file renelacroute.fr/DSA/57237: file not found
Dec 28 22:04:04 r13151 named-sdb[24511]: zone nicolaspichot.fr/IN:
zone_resigninc:dns_journal_open -> unexpected error
Dec 28 22:04:04 r13151 named-sdb[24511]: zone renelacroute.fr/IN:
setting keywarntime to 1294212898 - 7 days
Dec 28 22:04:04 r13151 named-sdb[24511]: dns_dnssec_findzonekeys2: error
reading private key file nicolaspichot.fr/DSA/37015: file not found
Dec 28 22:04:05 r13151 named-sdb[24511]: dns_dnssec_findzonekeys2: error
reading private key file nicolaspichot.fr/DSA/7246: file not found
Dec 28 22:04:05 r13151
named-sdb[24511]: /var/named/renelacroute.fr.hosts.jnl: create:
permission denied
Dec 28 22:04:05 r13151 named-sdb[24511]: zone nicolaspichot.fr/IN:
zone_resigninc:dns_db_getsigningtime -> not found
Dec 28 22:04:05 r13151 named-sdb[24511]: zone renelacroute.fr/IN:
zone_resigninc:dns_journal_open -> unexpected error
>
> gpg --keyserver pgp.mit.e
Re: Does anyone know where to find the ISC signing keys for source packages?
Thomas Schulz pisze: >> On 12/23/2010 4:09 PM, Casey Deccio wrote: >> >>> On Thu, Dec 23, 2010 at 12:49 PM, Oisin McGuinness >>> wrote: >>> >>> But I can't find any reference to current PGP or other signing keys; does anyone know where to find them on the www.isc.org web site or where to obtain them otherwise? >>> http://www.isc.org/about/openpgp >>> >> https://www.isc.org/about/openpgp will work as well. >> >> -- >> Dave >> > > It looks like I am a little dim today. Given gpg and the key, what steps > do I do to verify a source package? > First, you get the tarball and the signature from isc.org (say http://www.isc.org/software/bind/972-p3/download/bind-972-p3targz ) Second, you issue gpg --verify bind-9.7.2-P3.tar.gz.asc bind-9.7.2-P3.tar.gz might work with only the signed name (gpg --verify bind-9.7.2-P3.tar.gz.asc), I'm not sure how about this case. Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec-lookaside != auto
Dnia 2010-12-28 09:26 Eivind Olsen napisał(a): >> >> trying to resolve www.microsoft.com or microsoft.com results in a >> >> "connection timed out; no servers could be reached" >> > > > >Well, for what it's worth - it's not just you having that issue. When > >testing from home and from work I get the same. > > > >Of course, I could be doing something wrong, but whenever I see an error I > >like to imagine it's somebody elses fault :D > > > >One of the nameservers for microsoft.com is ns1.msft.net with an IP > >address of 65.55.37.62. For some reason the response I get from it is > >truncated, and retrying using TCP doesn't work. Using EDNS0 also doesn't > >seem to work, I get FORMERR back: > [cut long listing of DNS tries] Same here, I cannot reach this server with TCP or EDNS, nor get longer replies (al with dig), nor can bind resolve it locally (although it works with simple A query) Confirmed, I can get TCP and EDNS replies from a.ns.se Gentoo, bind version 9.7.2_p3, server located somewhere in France, in OVH network. > >So, to recap: at the risk of showing what a fool I am by doing something > >completely wrong here, I'm betting Microsoft has messed up their DNS - I > >would have expected queries over TCP to work, and I would not have > >expected EDNS to give a FORMERR (but ok, if a nameserver doesn't implement > >EDNS, giving a FORMERR is apparantly the right thing to do). > Not being a bind expert myself (but having read and hopefully understood the RFC's) I have to agree with it. And, having other issues with Microsoft DNS server myself (althoug this could be the lameness of it's admins as well), I don't have a hard time believing this. Although, if it works when VM is duplicated but has no traffic, it looks like something else to me (maybe two completely different errors, but with similar apperance) Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: auto update signatures dnssec
fakessh @ pisze:
>>> zone "fakessh.eu" {
>>> type master;
>>> file "/var/named/fakessh.eu.hosts";
>>> auto-dnssec maintain;
>>> update-policy local;
>>> key-directory "/var/named/keyset-fakessh.eu";
>>> allow-transfer { 213.251.188.140;87.98.164.164;
>>> 195.234.42.1;94.23.59.30; };
>>> };
>>>
>>> is what the guidelines are good options
>>>
> hello responsible bind community.
>
> you gave me the answer, thank you to my question but I am having new
> problems.
>
> I encounter errors during the self resignatures
>
> i quote my multiple error :
>
> I do not know what it is
>
>
>
[cut most log entries]
> Dec 28 22:04:02 r13151
> named-sdb[24511]: /var/named/renelacroute.fr.hosts.jnl: create:
> permission denied
> Dec 28 22:04:02 r13151 named-sdb[24511]: dns_dnssec_findzonekeys2: error
> reading private key file fakessh.eu/DSA/9552: file not found
> Dec 28 22:04:02 r13151 named-sdb[24511]: dns_dnssec_findzonekeys2: error
> reading private key file fakessh.eu/DSA/47103: file not found
>
First, where are the key files, related to bind directory (the one in
options { directory })?
Are the names correctly given to bind?
it looks like bind cannot find them.
Second, you need to give the user runing bind (probably named) rights to
write to /var/named/renelacroute.fr.hosts.jnl directory.
Torinthiel
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.7.2-P3 does not resolve www.microsoft.com
Ok, trying to send the same email third time, maybe it will get to the right recipient and with the right subject at last. Damn webmail, damn trying to resend from thunderbird. Dnia 2010-12-28 09:26 Eivind Olsen napisał(a): >> >> trying to resolve www.microsoft.com or microsoft.com results in a >> >> "connection timed out; no servers could be reached" >> > > > >Well, for what it's worth - it's not just you having that issue. When > >testing from home and from work I get the same. > > > >Of course, I could be doing something wrong, but whenever I see an error I > >like to imagine it's somebody elses fault :D > > > >One of the nameservers for microsoft.com is ns1.msft.net with an IP > >address of 65.55.37.62. For some reason the response I get from it is > >truncated, and retrying using TCP doesn't work. Using EDNS0 also doesn't > >seem to work, I get FORMERR back: > [cut long listing of DNS tries] Same here, I cannot reach this server with TCP or EDNS, nor get longer replies (al with dig), nor can bind resolve it locally (although it works with simple A query) Confirmed, I can get TCP and EDNS replies from a.ns.se Gentoo, bind version 9.7.2_p3, server located somewhere in France, in OVH network. > >So, to recap: at the risk of showing what a fool I am by doing something > >completely wrong here, I'm betting Microsoft has messed up their DNS - I > >would have expected queries over TCP to work, and I would not have > >expected EDNS to give a FORMERR (but ok, if a nameserver doesn't implement > >EDNS, giving a FORMERR is apparantly the right thing to do). > Not being a bind expert myself (but having read and hopefully understood the RFC's) I have to agree with it. And, having other issues with Microsoft DNS server myself (althoug this could be the lameness of it's admins as well), I don't have a hard time believing this. Although, if it works when VM is duplicated but has no traffic, it looks like something else to me (maybe two completely different errors, but with similar apperance) Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Does anyone know where to find the ISC signing keys for source packages?
> > At Tue, 28 Dec 2010 15:50:23 -0500 (EST), Thomas Schulz wrote: > > > > It looks like I am a little dim today. Given gpg and the key, what steps > > do I do to verify a source package? > > General case: > > $ gpg --verify sigfile tarball > > Eg: > > $ gpg --verify bind-9.7.2-P3.tar.gz.sha256.asc bind-9.7.2-P3.tar.gz > > We probably should add this to the aforementioned web page. It looks like I have to somehow make the public key available. When I issue the above command I get: gpg: Can't check signature: public key not found Tom Schulz Applied Dynamics Intl. sch...@adi.com ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Does anyone know where to find the ISC signing keys for source packages?
On Tue, Dec 28, 2010 at 1:37 PM, Thomas Schulz wrote: >> >> At Tue, 28 Dec 2010 15:50:23 -0500 (EST), Thomas Schulz wrote: >> > >> > It looks like I am a little dim today. Given gpg and the key, what steps >> > do I do to verify a source package? >> >> General case: >> >> $ gpg --verify sigfile tarball >> >> Eg: >> >> $ gpg --verify bind-9.7.2-P3.tar.gz.sha256.asc bind-9.7.2-P3.tar.gz >> >> We probably should add this to the aforementioned web page. > > It looks like I have to somehow make the public key available. When I > issue the above command I get: > > gpg: Can't check signature: public key not found > Before checking the signature, you need to import ISC's public key into your key ring. Something like this will work: curl https://www.isc.org/files/pgpkey2009.txt | gpg --import Then you can run gpg --verify. Casey ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
to route specific dns query to specific dns server
I'm using Bind9 for my name server (SERVER EXT) and to give name resolution for who access from Internet to my domain (e.g. to access to my Web site or to write to my email addresses). My domain is example.com: www.Example.com test.h...@example.com This dns server maps only my pubblic addresses. This server has 2 nics: internal + external ip address. Some internal servers, as proxy or mail servers, send dns requests to this dns server to solve names. I have also internal MS domain (dns server is SERVER INT) which is different from the other, it's created by Domain Controllers + AD (activedirectory.com) and it's used to map machines into internal network. Now I my email server or proxy server (which are in internal network) need to synchronize time so they have to use my internal NTP server; these Linux machines use 'SERVER EXT' in /etc/resolv.conf, so how I can indicate to send request for specific internal name (ntp.activedirectory.com) to dns server INT ? I could insert it inot /etc/hosts but it's not dnss service !!! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
to route specific dns query to specific dns server
I'm using Bind9 for my name server (SERVER EXT) and to give name resolution for who access from Internet to my domain (e.g. to access to my Web site or to write to my email addresses). My domain is example.com: www.Example.com test.h...@example.com This dns server maps only my pubblic addresses. This server has 2 nics: internal + external ip address. Some internal servers, as proxy or mail servers, send dns requests to this dns server to solve names. I have also internal MS domain (dns server is SERVER INT) which is different from the other, it's created by Domain Controllers + AD (activedirectory.com) and it's used to map machines into internal network. Now I my email server or proxy server (which are in internal network) need to synchronize time so they have to use my internal NTP server; these Linux machines use 'SERVER EXT' in /etc/resolv.conf, so how I can indicate to send request for specific internal name (ntp.activedirectory.com) to dns server INT ? I could insert it inot /etc/hosts but it's not dnss service !!! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: auto update signatures dnssec
Le mardi 28 décembre 2010 à 16:42 -0500, Alan Clegg a écrit : > On 12/28/2010 4:12 PM, fakessh @ wrote: > > named-sdb[24511]: /var/named/renelacroute.fr.hosts.jnl: create: > > permission denied > > Permissions are wrong on /var/named -- the named process needs to be > able to write into it. > > > Dec 28 22:04:02 r13151 named-sdb[24511]: dns_dnssec_findzonekeys2: > > error reading private key file fakessh.eu/DSA/9552: file not found > > It seems that the .key and .private files are not in the right place. > > Fix those two and I bet the rest go away... > > AlanC what is the right place ? AlanC i look the permissions after correction this seems correct -- gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x092164A7 signature.asc Description: Ceci est une partie de message numériquement signée ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: auto update signatures dnssec
On 12/28/2010 5:04 PM, fakessh @ wrote: >>> Dec 28 22:04:02 r13151 named-sdb[24511]: dns_dnssec_findzonekeys2: >>> error reading private key file fakessh.eu/DSA/9552: file not found >> >> It seems that the .key and .private files are not in the right place. > what is the right place ? In your named.conf, you should have "key-directory <...>;" defined. The keys should be there (and readable by the named process). If you don't have a "key-directory" statement, then named will look in the working directory from which the process was started (which is normally a bad idea...) 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: ignoring incorrect nameservers in authority section
Quoting from David Sparro's mail on Tue, Dec 28, 2010: > >Here, I can see that the nameserver is giving the right replies to all > >queries except the NS queries. > > How can an authoritative server give "wrong" answers? Due to misconfiguration of the NS records. My guess is that the domain was transferred from one nameserver to another without updating the NS records and the domain registration was updated. Another reason could be that some ill-informed DNS administrators are replacing their NS records with 'blackhole' or 'fake' nameservers to avoid DNS attacks on their actual servers. > >I was hoping that either bind should catch such cases automatically or > >allow some workaround which need not be monitored later. > > You're asking BIND to deduce the intent of the domain owner. It is hard to say whether it is intentional or due to a misconfiguration. Note that my aim is to ensure that dig +trace (or a non-caching nameserver) should give the same answer as named (ignoring TTL). If dig +trace is always landing at the right server while named is always landing at the wrong server (till the cached NS records expire) (see case 3 below), it is very hard to debug the problem. Here are the detailed cases which are applicable here. When bind queries a nameserver, the following types of answers are expected (apart from referrals, refused replies, and other errors): Case 1: Authoritative Server Reply === $ dig +norecurse @a.iana-servers.net. example.org. ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;example.org. IN A ;; ANSWER SECTION: example.org.172800 IN A 192.0.32.10 ;; AUTHORITY SECTION: example.org.172800 IN NS a.iana-servers.net. example.org.172800 IN NS b.iana-servers.net. === This is the answer in the correct format. Both the A and NS records are cached. bind will give a similar reply back to the client. Case 2: Lame Server Reply === $ dig +norecurse @a.iana-servers.net. example.org. ;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;example.org. IN A ;; ANSWER SECTION: example.org.172800 IN A 192.0.32.10 ;; AUTHORITY SECTION: example.org.172800 IN NS ns1.example.org. example.org.172800 IN NS ns2.example.org. === This is a lame server reply. bind ignores this reply. bind will give a server fail reply to the client. Case 3: "Authoritative Server Reply with Lame NS Records" === $ dig +norecurse @a.iana-servers.net. example.org. ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;example.org. IN A ;; ANSWER SECTION: example.org.172800 IN A 192.0.32.10 ;; AUTHORITY SECTION: example.org.172800 IN NS ns1.example.org. example.org.172800 IN NS ns2.example.org. === Here, we are getting an authoritative reply. This means that the A record can be cached. However, note that NS section here does not list a.iana-servers.net. Should bind cache this authority section? If ns[12].example.org. were the real nameservers, we should have got a referral from a.iana-servers.net. and not an authoritative answer. If bind does cache this (as it currently does), the next query for example.org will go to ns[12].example.org. directly. However, here we can see that a.iana-servers.net. is actually the authoritative nameserver, which means that it is ready to answer all example.org queries. If bind does not cache the NS records, it will land via referrals back to a.iana-servers.net. for the next query and get the correct authoritative answer. What should bind reply back to the client? It would be safe to drop the authority section in the reply. === $ dig example.org. ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;example.org. IN A ;; ANSWER SECTION: example.org.172800 IN A 192.0.32.10 === Hope that this elaborate example clears the picture of what I am trying to convey. Note that querying of NS records will also have to be handled in a consistent manner. However, some more thought may be required there. -- Sunil Shetye. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
