bind classless slave from microsoft dns classful SOA?
Bind-users; I have been asked to slave a /24 from a microsoft SOA, however, their authority for the /24 is false in that they really only have authority to 192/26. Am I correct in that there is no way to slave said zone [x.y.z.in-addr.arpa] but serve it as a different zone [192/26.x.y.z.in-addr.arpa] without relying on some outside scripts to do the translation? For what it's worth, I am running the 9.8X series of BIND. Thanks- -Michael ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
.mil resolution problems?
Hello- Our recursive nameservers are having trouble with .MIL today. I see some public servers [8.8.8.8] are not. I am not running a dns-sec enabled recursive resolver. In the below I was expecting an 'ADDITIONAL' section, not based on the DIG header, but based on expecting delegation glue. A dig for the NIPR.MIL NS times out. Anyone else having problems or can perhaps point me in the right direction? Thanks- -Michael [...@trigger ~]$ dig MIL NS ; <<>> DiG 9.7.0-P2 <<>> MIL NS ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6544 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;MIL. IN NS ;; ANSWER SECTION: MIL.69821 IN NS EUR2.NIPR.MIL. MIL.69821 IN NS PAC2.NIPR.MIL. MIL.69821 IN NS EUR1.NIPR.MIL. MIL.69821 IN NS PAC1.NIPR.MIL. MIL.69821 IN NS CON1.NIPR.MIL. MIL.69821 IN NS CON2.NIPR.MIL. ;; Query time: 0 msec ;; SERVER: 128.104.254.254#53(128.104.254.254) ;; WHEN: Mon Oct 25 15:56:40 2010 ;; MSG SIZE rcvd: 140 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
general: error: socket.c:1577: unexpected error:
I recently [8/1/2009] upgraded to 9.5.1P3. Last evening there were two brief moments that the named process was not resolving out of cache. This is a recursive only server that is basically opened to all clients, mostly for historical reasons. The named process recovered on its own. While I have seen references to old bugs/issues https://lists.isc.org/mailman/htdig/bind-users/2005-January/055224.html This seems to be something different. We're [still] on Red Hat Enterprise Linux AS release 3. Any advice on what to investigate? Thanks- -Michael Aug 17 01:24:53 named[20688]: general: error: socket.c:1577: unexpected error: Aug 17 01:24:53 named[20688]: general: error: internal_send: 144.92.162.225#57060: Invalid argument Aug 17 01:24:53 named[20688]: client: warning: client 144.92.162.225#57060: error sending response: invalid file Aug 17 01:24:53 named[20688]: general: error: socket.c:1577: unexpected error: Aug 17 01:24:53 named[20688]: general: error: internal_send: 216.180.219.44#11059: Invalid argument Aug 17 01:24:53 named[20688]: client: warning: client 216.180.219.44#11059: error sending response: invalid file ... ... Aug 17 01:25:17 named[20688]: general: error: socket.c:1577: unexpected error: Aug 17 01:25:17 named[20688]: general: error: internal_send: 143.215.143.11#32833: Invalid argument Aug 17 01:25:17 named[20688]: client: warning: client 143.215.143.11#32833: error sending response: invalid file Aug 17 01:25:17 named[20688]: general: error: socket.c:1577: unexpected error: Aug 17 01:25:17 named[20688]: general: error: internal_send: 128.104.22.33#57369: Invalid argument Aug 17 01:25:17 named[20688]: client: warning: client 128.104.22.33#57369: error sending response: invalid file Aug 17 01:25:57 named[20688]: general: warning: checkhints: unable to get root NS rrset from cache: not found Aug 17 02:38:54 named[20688]: general: error: socket.c:1577: unexpected error: Aug 17 02:38:54 named[20688]: general: error: internal_send: 144.92.166.12#9500: Invalid argument Aug 17 02:38:54 named[20688]: client: warning: client 144.92.166.12#9500: error sending response: invalid file Aug 17 02:38:54 named[20688]: general: error: socket.c:1577: unexpected error: Aug 17 02:38:54 named[20688]: general: error: internal_send: 144.92.166.12#14442: Invalid argument Aug 17 02:38:54 named[20688]: client: warning: client 144.92.166.12#14442: error sending response: invalid file ... ... Aug 17 02:39:23 named[20688]: general: error: socket.c:1577: unexpected error: Aug 17 02:39:23 named[20688]: general: error: internal_send: 202.108.181.80#50110: Invalid argument Aug 17 02:39:23 named[20688]: client: warning: client 202.108.181.80#50110: error sending response: invalid file Aug 17 02:39:23 named[20688]: general: error: socket.c:1577: unexpected error: Aug 17 02:39:23 named[20688]: general: error: internal_send: 202.108.181.80#37064: Invalid argument Aug 17 02:39:23 named[20688]: client: warning: client 202.108.181.80#37064: error sending response: invalid file ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: general: error: socket.c:1577: unexpected error:
Hello again- Our issue is now appearing on multiple physical nameservers in our domain running 9.5.1-P3. The second server that is noticing this is Red Hat Enterprise Linux Server release 5.3 (Tikanga) 64 bit, complied 9.5.1-P3 from src with default configure options. So the problem seems to persist across vastly different linux environments [the first server we saw this on was Redhat AS 3]. I am not a heavy duty programmer but my understand based on src is that this may be related to the inability to send a UDP response and is perhaps a resource exhaustion issue. I'm not sure what ISC_R_NRESULTS 'invalid file' is trying to tell me. As before, the server seems to recover, but DNS resolution does stop for about a minute. -Michael Michael Hare wrote: I recently [8/1/2009] upgraded to 9.5.1P3. Last evening there were two brief moments that the named process was not resolving out of cache. This is a recursive only server that is basically opened to all clients, mostly for historical reasons. The named process recovered on its own. While I have seen references to old bugs/issues https://lists.isc.org/mailman/htdig/bind-users/2005-January/055224.html This seems to be something different. We're [still] on Red Hat Enterprise Linux AS release 3. Any advice on what to investigate? Thanks- -Michael Aug 17 01:24:53 named[20688]: general: error: socket.c:1577: unexpected error: Aug 17 01:24:53 named[20688]: general: error: internal_send: 144.92.162.225#57060: Invalid argument Aug 17 01:24:53 named[20688]: client: warning: client 144.92.162.225#57060: error sending response: invalid file Aug 17 01:24:53 named[20688]: general: error: socket.c:1577: unexpected error: Aug 17 01:24:53 named[20688]: general: error: internal_send: 216.180.219.44#11059: Invalid argument Aug 17 01:24:53 named[20688]: client: warning: client 216.180.219.44#11059: error sending response: invalid file ... ... Aug 17 01:25:17 named[20688]: general: error: socket.c:1577: unexpected error: Aug 17 01:25:17 named[20688]: general: error: internal_send: 143.215.143.11#32833: Invalid argument Aug 17 01:25:17 named[20688]: client: warning: client 143.215.143.11#32833: error sending response: invalid file Aug 17 01:25:17 named[20688]: general: error: socket.c:1577: unexpected error: Aug 17 01:25:17 named[20688]: general: error: internal_send: 128.104.22.33#57369: Invalid argument Aug 17 01:25:17 named[20688]: client: warning: client 128.104.22.33#57369: error sending response: invalid file Aug 17 01:25:57 named[20688]: general: warning: checkhints: unable to get root NS rrset from cache: not found Aug 17 02:38:54 named[20688]: general: error: socket.c:1577: unexpected error: Aug 17 02:38:54 named[20688]: general: error: internal_send: 144.92.166.12#9500: Invalid argument Aug 17 02:38:54 named[20688]: client: warning: client 144.92.166.12#9500: error sending response: invalid file Aug 17 02:38:54 named[20688]: general: error: socket.c:1577: unexpected error: Aug 17 02:38:54 named[20688]: general: error: internal_send: 144.92.166.12#14442: Invalid argument Aug 17 02:38:54 named[20688]: client: warning: client 144.92.166.12#14442: error sending response: invalid file ... ... Aug 17 02:39:23 named[20688]: general: error: socket.c:1577: unexpected error: Aug 17 02:39:23 named[20688]: general: error: internal_send: 202.108.181.80#50110: Invalid argument Aug 17 02:39:23 named[20688]: client: warning: client 202.108.181.80#50110: error sending response: invalid file Aug 17 02:39:23 named[20688]: general: error: socket.c:1577: unexpected error: Aug 17 02:39:23 named[20688]: general: error: internal_send: 202.108.181.80#37064: Invalid argument Aug 17 02:39:23 named[20688]: client: warning: client 202.108.181.80#37064: error sending response: invalid file ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Feature request - disable internal recursion cache
For those of us that are still running auth and recursive on the same IP, I believe the benefit would be to deploy a best practices recursive only nameserver on a different machine/IP address without getting, in my case, possibly hundreds of thousands of clients to change their DNS resolver IP address. In the surface, I too find this to be an interesting idea. -Michael Kevin Darcy wrote: Dmitry Rybin wrote: Niall O'Reilly wrote: I think, that be useful make this feature in bind: Add option to disable internal recursion cache, and forward all recursive queries to another daemon. Daemon as unbound, pdns-recursor - much faster in recursion queries, that bind. :( I don't see the point. If you need some code, other than BIND named, to handle recursive queries from your clients, why not just have that code listening on the addresses configured in the stub resolver on each of the client systems? I'll explain, why. Same Server is authoritative for internet/intranet and recursive for intranet and one large AS. Sometimes Auth/Rec server IP cannot be spited into different IP's. Bind answer authoritative for all clients, and forward (if allowed) recursive queries to recursive server. ___ Why not just point some or all of those recursive clients to the "other" recursive resolver? Seems like BIND ceases to add any value when it's just forwarding everything and not caching any results. - Kevin ___ 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: Feature request - disable internal recursion cache
Well, except then you need to update all of your delegations. That can not only be an administrative hassle, but can also get very expensive, especially if you have hundreds of them in ccTLDs, where you have to pay your "in-country agent" a fee for every registry change. It's quite a racket. You don't have to change all the domain registrations. You just have to change the A records of the nameserver names. Hopefully you haven't done something silly like use different nameserver names for each domain. Updating the adns A records is great but this doesn't automatically change firewall rulesets. I can't control what kind of good or bad assumptions folks that we are secondaries for made. I think we can agree that it can be a lot of effort to break auth and recursive into two IPs no matter what route you go. I agree that using adns for rdns proxy is suboptimal but sometimes the lower cost engineering solutions in practice are just as good as the painful ones. I mostly threw my hat in the ring so that it would be known that more than one BIND user could benefit from a feature like this. -Michael ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind Clustering
Doesn't DDNS rely on a single SOA? If so, is there a best practice on how to deal with this? -Michael On 4/8/2010 9:15 AM, Stephane Bortzmeyer wrote: On Thu, Apr 08, 2010 at 01:18:33PM +0200, Arnoud Tijssen wrote a message of 14 lines which said: Since everything nowadays is dependant on DNS I would like to cluster my primary server in case of a hardware failure or error. Why? I really do not see your point. You have three authoritative name servers (the master and two slaves), presumably in different locations. Isn't it enough? If no, you can still add slaves. So, how do I setup two primary bind servers that keep each other in sync one way or the other. Slaves keep in synch automatically. ___ 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: root.hind or named.hint file update
Agreed, using outdated built in hints and diligent logging does cause a minor annoyance (minor as it can be filtered after verifying the incident), so there is merit in updating even if automatic updates might not make sense. For example, an unfiltered log from a production resolver of ours would like to say the following :) 21-Sep-2016 00:01:02.859 general: warning: checkhints: l.root-servers.net/ (2001:500:9f::42) missing from hints 21-Sep-2016 00:01:02.859 general: warning: checkhints: l.root-servers.net/ (2001:500:3::42) extra record in hints 21-Sep-2016 00:01:03.580 general: warning: checkhints: l.root-servers.net/ (2001:500:9f::42) missing from hints 21-Sep-2016 00:01:03.580 general: warning: checkhints: l.root-servers.net/ (2001:500:3::42) extra record in hints 21-Sep-2016 00:01:05.102 general: warning: checkhints: l.root-servers.net/ (2001:500:9f::42) missing from hints 21-Sep-2016 00:01:05.102 general: warning: checkhints: l.root-servers.net/ (2001:500:3::42) extra record in hints 21-Sep-2016 00:01:05.174 general: warning: checkhints: l.root-servers.net/ (2001:500:9f::42) missing from hints 21-Sep-2016 00:01:05.174 general: warning: checkhints: l.root-servers.net/ (2001:500:3::42) extra record in hints 21-Sep-2016 00:01:06.087 general: warning: checkhints: l.root-servers.net/ (2001:500:9f::42) missing from hints -Michael -Original Message- From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Matus UHLAR - fantomas Sent: Friday, September 23, 2016 7:32 AM To: bind-users@lists.isc.org Subject: Re: root.hind or named.hint file update >Pol Hallen wrote: >> >> is it recommend put a cron script for auto-update root.hind and named.hint >> db? On 23.09.16 12:54, Tony Finch wrote: >No, it's best not to have a hints file and just use the one built in to BIND. i would not say that... it's better to use builtin hints file than having outdated hints file. But if someone does care about hints file, it's better to have current version, when the builtin one is older. -- 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. - Have you got anything without Spam in it? - Well, there's Spam egg sausage and Spam, that's not got much Spam in it. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Enforce EDNS
+1 to Alan. While I work at an ivory tower and support Mark's mission, in
practice I don't have operational time (nor is it necessarily the best use of
my time) to maintain a per-ip bypass.
100% in support of enabling this by default as long as their as an option to
disable.
-Michael
> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mark
> Andrews
> Sent: Tuesday, February 07, 2017 4:32 PM
> To: Reindl Harald
> Cc: bind-us...@isc.org
> Subject: Re: Enforce EDNS
>
>
> In message <4b0243b1-1c89-023b-f3f3-7279216d5...@thelounge.net>, Reindl
> Harald
> writes:
> >
> >
> > Am 07.02.2017 um 22:11 schrieb Mark Andrews:
> > > In message <3836f038-c480-9970-fd53-a5c87ad36...@thelounge.net>,
> Reindl Har
> > ald wr
> > > ites:
> > >>> Break them. That's the only way it will eventually get fixed
> > >>
> > >> if things would be that easy
> > >>
> > >> the admins of the broken servers ar the very last which are affected,
> > >> admins with a recent named have to bite the bullet of user terror and
> > >> users typically don#t give a damn when it worked yesterday
> > >>
> > >> the admins of the broken server don't give a damn about as long they can
> > >> point their fingers and say "look, the rest of the world has no lookup
> > >> errors"
> > >>
> > >> if it would be that easy the problem of spam would not exist for many
> > >> years while in reality you waste most of our time to write exceptions
> > >> here and there, disable rules or score them lower because you are not in
> > >> the position to educate every admin of sending servers out there
> > >
> > > You go over the admins head. You go to the board of directors.
> > > You go the the minister responsible (yes, I have had to do that
> > > along with a copy to the shadow minister and the company that the
> > > DNS was outsourced to for government domains). Good old snail mail
> >
> > if *you* do that from your position it may work but still takes time in
> > a world where it somestimes takes days and weeks to find somebody who
> > can instruct a admin to change a simple CNAME record from machine A to
> > machine B even with the directors OK and CC'ed in the message
>
> And you can fix the issue by hand while this is going on.
>
> server 74.113.204.34 { send-cookie false; };
> server 74.113.206.34 { send-cookie false; };
> server 117.56.91.203 { send-cookie false; };
> server 117.56.91.204 { send-cookie false; };
> server 117.56.91.234 { send-cookie false; };
> server 199.252/16 { send-cookie false; };
>
> (or request-sit no; for 9.10.x)
>
> There aren't lots of servers that drop EDNS or drop EDNS + DNS COOKIE.
>
> The big numbers are those that drop EDNS(1) which no one is using at
> this stage. See http://ednscomp.isc.org/
>
> > i doubt it works the same way for a ordinary admin in a small company
> > where you to make it work because *you* broke it with the named update
> > and so your advise will be "roll back that stuff to the state of
> > yesterday where it worked and no you have not the free time to call each
> > and every company and educate them"
> >
> > problem here is that as long it's not a critical mass anybody who
> > deployed the update breaking things have to bleed for it and so you have
> > to find enough people with the power to go over admins head *before* the
> > breaking updates
> >
> > and no, when in your company people can't work because DNS is broken you
> > don't call foreign admins and directors - you have to fix that *now* and
> > after you have fixed it you have no longer arumgents why call somebody
> > with no direct relations
> > ___
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> > unsubscribe
> > from this list
> >
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from
> this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
need another pair of eyes: edu/net (educause?) glue issues?
Hello- Sorry for the wide blast (and long email), but perhaps some fellow .edu's can help us through this one. I'm one of the DNS admins for wisc.edu. An academic group on campus has noticed an issue with the atecentral.net delegation, for which two of the listed NS are on campus. []$ dig atecentral.net NS +short dns2.scout.wisc.edu. <- on campus dns.scout.wisc.edu. <- on campus dns.axisdata.com. wisc.edu is authoritative for scout.wisc.edu and return the following correct A records []$ dig scout.wisc.edu NS +short | sort adns1.doit.wisc.edu. adns2.doit.wisc.edu. adns3.doit.wisc.edu. adns1.doit.wisc.edu:dns.scout.wisc.edu. 14400 IN A 144.92.170.201 adns2.doit.wisc.edu:dns.scout.wisc.edu. 14400 IN A 144.92.170.201 adns3.doit.wisc.edu:dns.scout.wisc.edu. 14400 IN A 144.92.170.201 adns1.doit.wisc.edu:dns2.scout.wisc.edu.14400 IN A 144.92.170.203 adns2.doit.wisc.edu:dns2.scout.wisc.edu.14400 IN A 144.92.170.203 adns3.doit.wisc.edu:dns2.scout.wisc.edu.14400 IN A 144.92.170.203 []$ dig @144.92.170.201 atecentral.net NS +short dns.axisdata.com. dns.scout.wisc.edu. dns2.scout.wisc.edu. It appears that there is some bad glue "somewhere" and I'm having trouble finding where it is coming from. dig +norecurse @b.gtld-servers.net atecentral.net NS ... ... ;; ADDITIONAL SECTION: dns.axisdata.com. 172800 IN A 162.255.164.103 dns.scout.wisc.edu. 172800 IN A 144.92.170.199 < WRONG dns2.scout.wisc.edu.172800 IN A 144.92.170.200 < WRONG note: local admins have enabled DNS servers on 170.199 and 170.200 as a short term measure until this can be resolved, so if you dig against those incorrect IPs directly you will get an answer (for now). We have asked the scout.wisc.edu folks to check the atecentral.net delegation and received the following response: "... I checked with Namecheap, where atecentral.net is registered, and they say that the glue record values are supplied to the root nameservers by the registrar for the top-level domain where the names are located (wisc.edu, in this case, so Educause/VeriSign) " And this matches my memory as well. As recent as June 2017 when an NS inside a .edu was also the NS for another domain (for example, a .org), wearing my wisc.edu DNS admin hat I would log into the educause domain portal and add/update glue, the production example being uwhealth.org which has NS inside the wisc.edu namespace. My suspicious is that the glue stuck in gtld is supplied by educause however educause (who recently went through a major facelift of their portal, net.educause.edu) is claiming no such thing has ever existed. I'm not convinced, but there is an off chance early senility is setting in. I have a screenshot from June 2017 (without URL, unfortunately) of our list of "glue" from what I'm 99% sure is the old net.educause.edu portal however educause is claiming adamantly (yes, we have escalated a ticket) that my screenshot is not from their old portal. I see other screenshots on the web of the old net.educause.edu website that shows basically the same design theme (color) as my screenshot. You'll note my screenshot from June 2017 from "somewhere" has the wrong IPs for dns.scout.wisc.edu and dns2.scout.wisc.edu. ours: https://stats.uwsys.net/educause-maybe.jpg found on web: https://image.slidesharecdn.com/edu-dnssec-151026011336-lva1-app6891/95/edu-dnssec-testbed-27-638.jpg?cb=1445822096 For info from an old thread related to a similar thing we did at wisc.edu ~10 years ago: https://arstechnica.com/civis/viewtopic.php?f=10&t=97332, but I digress. I can't dump the .edu zonefile and educause (for now) is denying culpability. My 'dig' foo is weak enough that I can't come up with a damning output to know where to go from here. Any ideas? -Michael ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
