Re: Problem resolving domain
In article , Stephan von Krawczynski wrote: > Hello all, > > I ran across a question I did not really expect. I am using bind 9.14.1 as > normal, standalone nameserver. When trying to resolve a certain domain I get a > SERVFAIL (with nslookup). Deeper inspection of the problem shows that the > domain uses 2 nameservers, where one works perfectly well, the other does not > know the domain at all. > I would have expected that bind finds the domain by using the working > nameserver and ignoring the dead one. But obviously it does not. > Did I misconfigure something? I thought both nameservers should be questioned > and the first working result be used, or not? Not quite. It performs failover if the first nameserver doesn't respond. But if it gets a response, it uses the response, even if it reports an error. -- Barry Margolin Arlington, MA ___ 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: Using different OS for Master and Slaves
In article , Reindl Harald wrote: > Am 12.11.19 um 14:00 schrieb G.W. Haywood via bind-users: > > Hi there, > > > > On Tue, 12 Nov 2019, Mundile wrote: > > > >> Is it good idea and possible to create Master and Slaves nameservers > >> using different OSes. > >> For example , Master OS =Centos 7 and Slaves Os=Ubuntu 18 or Windows > >> 2016 > > > > It depends on whether or not you enjoy pain > > there shouldn't be any pain from a technical point of view and there is > one security case which could be solved with mixing: I suspect the pain he was referring to is not really DNS-specific, but just due to having to manage servers with different operating systems. This means using a more diverse set of management tools, different configuration syntax, etc. -- Barry Margolin Arlington, MA ___ 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: CNAME as an alias to a TXT record
In article , Computerisms Corporation wrote: > Hi, > > I am wondering if it is possible to create a CNAME in one zone to > resolve as a TXT record in another zone. Can't find anything that says > it will work, but can't find any thing that says it won't, either. CNAME isn't type-specific. It simply makes one name an alias for another name. If the target name has a TXT record, then you'll get that when you look up TXT for the CNAME. -- Barry Margolin Arlington, MA ___ 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: Proper Way to Configure a Domain which never sends emails
In article , Kevin Darcy wrote: > [ Classification Level: PUBLIC ] Huh? Why does something sent to a public mailing list need an explicit "classification level"? > > MXes are for *receiving* mail of course. The request is about *sending* > mail. True, but there's a common assumption that mail is sent from a domain that can receive mail. Even email that says "Don't reply to this" usually comes from an account at a domain that can receive mail; they just ignore that mailbox. > > > > A common practice is to point the MX record to ".". > > > > -- > > Barry Margolin > > Arlington, MA -- Barry Margolin Arlington, MA ___ 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: Proper Way to Configure a Domain which never sends emails
In article , Ignacio GarcÃa wrote: > Hi there. > > Thanks for your support. First message to the list, sorry if already > posted a similar question, but I haven't found mention anywhere. > > I have to set up dns records for a domain just for a web site, for which > we will NEVER send emails (though we might receive some from old > customers), so I would like to announce somehow that emails sent from > this domain should always be disregarded. I was thinking of setting just > A and records for @ and www, NS records, MA records (for receiving) > and SPF with a record just consisting of v=spf1 -all , not declaring an > A and MX records at all. I'm not sure at all this is a proper way of > declaring this. In fact, what I would like is to EXPLICITELY mention > somehow that we will never send emails from that domain. Could anybody > help me with this? A common practice is to point the MX record to ".". -- Barry Margolin Arlington, MA ___ 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: A policy for removing named.conf options.
In article , Matthijs Mekking wrote: > ## Deprecating > > A configuration option that is candidate for removal will be deprecated > first. During this phase the option will still work, but we will be > communicating to users that the option is going to be removed soon. A > user that has deprecated options configured will see warnings in their > logs and needs to take action to get rid of those log messages. > Configuration options that are deprecated will be identified in the > Release Note for the release they are deprecated in. As others have said, I'm not sure how effective this will be. I suspect most people don't check the logs routinely, only when something goes wrong. Is it really much of a hassle to leave the obsolete options in the parser, but just ignore them? -- Barry Margolin Arlington, MA ___ 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: BIND ignores queries from specific privileged source ports
In article , Blake Hudson wrote: > Thank you Mark. A popular NAT appliance manufacturer has some logic that > attempts to keep the translated source port close to the untranslated > source port which can sometimes result in the behavior I've described > where DNS queries use the well known source port of protocols that are > abuse prone: Why would the original source port be close to any of these low port numbers? Source ports should normally be ephemeral ports. -- Barry Margolin Arlington, MA ___ 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: Question about Delegation/forwarder
In article , Gawan Re wrote: > Hello, > > I have a bind server with recursion disabled. So this should be an authoritative-only nameserver, not a resolving nameserver. > One of the subzone is delegated to external name servers for which we are > not authoritative. The records inside this subzone would not resolve as the > subzone is delegated to external name servers and I have recursion > disabled. Why is this a problem? The client nameserver should follow the delegation. Stub resolvers should not point to a server that has recursion disabled. > > My question is, While I have the delegation is in place (even though it is > useless), is there a way to override Delegation (and possibly replace with > forwarders) ? Forwarders are only used when recursing. If recursion is disabled, forwarders are useless. -- Barry Margolin Arlington, MA ___ 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: Help: BIND _ Recursive query
In article , Paul Kosinski wrote: > I gather "recursion yes" (explicit or default) controls whether BIND > *does* recursion itself, in the sense of querying other DNS servers for > data it doesn't have, not whether it *issues* queries with the > "recursion desired" flag set. (Somewhat confusing terminology, in my > opinion.) That's correct. It corresponds to sending answers with the "recursion available" flag set. > > So is the "recursion desired" flag only set when there are forwarders? > Presumably it is set in the case of "forward only", but what happens if > there are forwarders defined and both "recursion yes" (default) and > "forward first" (default) are specified? It's set for any type of forwarding, it doesn't matter whether it's "only" or "first". -- Barry Margolin Arlington, MA ___ 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: Help: BIND _ Recursive query
In article , vivek wrote: > thanks, that means for Bind service to work we have to have the "recursion > yes" else the forwarder will also not work. > > Actually I m bit confused between Recursive vs Iterative query mode , so > does this mean Bind will only work in Recursive query mode & this makes the > "Forwarder " to do his required job. > > Help in understand so in what scenarios will use/configure Bind in Iterative > query mode. "recursion yes" means that it will *answer* queries that require recursion, i.e. they ask for information in outside domains. When the nameserver does all lthe outside lookup work by itself, by working its way down from the root servers, that's called "iterative mode". When a client or nameserver asks another server to do all the work, it does that by sending a recursive query. This is the normal way that host resolver libraries work, and it's what BIND does when you configure "forwarders". -- Barry Margolin Arlington, MA ___ 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: repeated 16 hour interval spike in authoritative PTR lookups
In article , jm9386 wrote: > also the vast majority - over 95% of the queries we are seeing are coming > from open resolvers on the Internet - distributed all over the world. It > seems awfully suspicious for resolvers all over the world to decide to query > PTR records for our ISP related in-addr.arpa space every 16 hours. Maybe too obvious, but is 16 hours the TTL of your PTR records? Although even if it is, I'm not sure what would cause all these servers to sync up to the same 16-hour cycle. Maybe at some point you reduced the TTL (because you were reconfiguring things), then when you bumped it back up they all timed out the old records at about the same time, and ever since they've been refreshing at the same times. -- Barry Margolin Arlington, MA ___ 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: Reverse lookup for classless networks
In article , Nagesh Thati wrote: > Thanks Mark, > But is there any other way without using any CNAMEs? The alternative is to have a separate zone for each address, and delegate each of them to your server. So the parent zone would have: 0 IN NS ns1.yourdomain.com. IN NS ns2.yourdomain.com. 1 IN NS ns1.yourdomain.com. IN NS ns2.yourdomain.com. and so on... Either way, the parent zone needs to have specific records for each of the addresses in the subnet. The client always tries to look up w.x.y.z.in-addr.arpa, and only supports delegation at "." boundaries in the name. There's no way for it to know automatically that different "w" values are delegated to different servers. -- Barry Margolin Arlington, MA ___ 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: dig @ipv6-address
In article , Christian Weiske wrote: > Hello Timothe, > > > > > I only get an error when running dig: > > > > > >> $ dig @2a01:488:66:1000:53a9:2dde:0:1 cweiske.de > > >> couldn't get address for '2a01:488:66:1000:53a:53': not found > > > > This looks like a typo. And the error doesn't match the command given. > > > > I suspect that your actual 'dig' command was 'dig > > @2a01:488:66:1000:53a:53 cweiske.de', which will reproduce the error. > > > > '2a01:488:66:1000:53a:53' is not an IPv6 address.ï¾ You are missing > > a :: or a couple of words.ï¾ (There should be 8 16-bit words delimited > > by ':', or a single '::' ellipsis to represent a run of zeroes.) > > You are right, this was no full IPv6 address. > > I'm sorry for the noise, but I didn't see the difference in the two IP > addresses. Otherwise I would not have subscribed to this list and > written my lenghty mail. > > I scrolled back my terminal and now found where I got that partial > address from: The output of "netstat -tulpen". The listening address is > shortened there, which I did not know before: > > > Proto Recv-Q Send-Q Local Address Foreign Address > > udp6 0 0 2a01:488:66:1000:53a:53 :::* > > From there I copied it and tried to "dig @" my domain, which failed as > I wrote. > > Why there were different IPs in the command and the output of my > first example .. I have no idea. I somehow mixed up my notices. > > Sorry again. The last : in the netstat output is separating the IP address from the port number -- :53 means it's listening on port 53, the standard DNS port. But it also seems like it's using its own form of abbreviation, since there aren't 8 hex fields before that. -- Barry Margolin Arlington, MA ___ 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: forwarder selection logic by bind9
In article , József Lázár wrote: > Did you have a chance to look at my email below? Thanks again, Joe Have you tried googling "bind smoothed round trip time"? > > On Tue, 13 Nov 2018 at 10:42, József Lázár > wrote: > > > Ok, I see. However, could you please specify this "time to time" period? > > Does it depends of the dns traffic which the bind receives? > > I've tried the following scenario: > > Configured two dns forwarders, both of them worked at the beginning. After > > one minute I turned off the first dns forwarder and after an another minute > > I restarted it. > > Then I sent one dns request to bind in every 1,5 second for over one hour, > > but the first dns server didn't receive any request after the restart. > > > > Thanks, Joe > > > > On Sun, 11 Nov 2018 at 15:06, Matus UHLAR - fantomas > > wrote: > > > >> On 10.11.18 15:59, József Lázár wrote: > >> >I'm wondering what the selection logic in bind for forwarders. I tried to > >> >look for this information in the official documentation but couldn't find > >> >it. Could you please describe it for me briefly? > >> > > >> >Actually, the scenario is that I have two DNS servers and I'm using bind > >> to > >> >forward only the incoming DNS requests and if the "primary" one is failed > >> >for a short period of time then the bind will try to use the "secondary" > >> >one, but when the "primary" comes back, then it doesn't try to connect to > >> >it at all, only if the connection breaks for the "secondary" server. > >> > > >> >Is there any way to configure this logic somehow? > >> > >> No. BIND technically choses server that responds faster. If one of servers > >> doesn't respond (it's down), BIND uses the another one. However, time to > >> time, BIND rechecks the other server(s) to see if situation has changed. > >> > >> BIND does not differ between servers as primary and secondary. > >> > >> -- > >> 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. > >> They that can give up essential liberty to obtain a little temporary > >> safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759 > >> ___ > >> 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 > >> > > -- Barry Margolin Arlington, MA ___ 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: conflicting subdomain delegation
In article , Frank Liu wrote: > Thanks for confirming bind behavior matches what I saw. > I noticed other resolvers (eg: @8.8.8.8) works differently, c.b.a.com NS > host2 actually got used, not ignored as occluded data. That shouldn't be possible. The occluded data should never be given out by the authoritative server, so the resolver should never see it. Tell us the actual domains so we can see what's really happening. > Is this a bind specific implementation, not required by any RFCs? > >From authoritative dns perspective, Amazon Route53 allows you to add both > delegations in the a.com zone without any "out of zone data" error. > > > On Tue, Nov 13, 2018 at 1:50 PM Mark Andrews wrote: > > > > > > On 14 Nov 2018, at 4:04 am, Frank Liu wrote: > > > > > > Hi, > > > > > > Is there a RFC determining which nameserver to use if there is a > > conflicting subdomain delegation? > > > > > > eg: > > > In the zone of a.com, there are two NS delegations > > > > This one is used. > > > > > b.a.com NS host1 > > > > This one is ignored as it is occluded data. > > > > > c.b.a.com NS host2 > > > > > > On host1 in zone b.a.com, there is > > > c.b.a.com NS host3 > > > > Which is occluded data or glue depending upon the rest of the contents of > > the zone. > > > > > As you can see, there is a conflicting delegation for c.b.a.com. If I > > look a name d.c.b.a.com, will the nameserver host2 or host3 be used? > > > dig +trace seems to go to host2, but bind9 as a resolver goes to host3. > > > (the test was done on a centos7). > > > > dig +trace follows the returned delegations. > > > > > Any ideas? > > > Thanks! > > > ___ > > > 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 > > > > -- Barry Margolin Arlington, MA ___ 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: Rewrite/Override QTYPE with RPZ
In article , Tom wrote: > Hi all > Is there a way to override/rewrite QTYPE (ex. MX) with RPZ? If no, is > this planned in future releases of BIND? What would be the point? If a query is for MX, and you return A instead, the client won't be able to do anything with it. -- Barry Margolin Arlington, MA ___ 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: Modifying data files while named is reloading
In article , Anne Bennett wrote: > Laurent Weislo writes: > > > After a bunch of years and under heavy load on the master, we lost almost > > 4K records because the domain file seems to have been loaded while being > > generated. > > Wouldn't the best solution be to modify your generation process > to write to temporary files, and then to move them into place > when fully built, rather than leaving significant amounts of > time during which your zone file is in a partially built state? This is definitely the right solution. As long as you're moving within the same filesystem, this is an atomic rename operation. -- Barry Margolin Arlington, MA ___ 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: Question about visibility
In article , Dennis Clarke wrote: > On 10/11/2018 03:21 PM, Leonardo Rodrigues wrote: > > Em 11/10/18 16:13, Barry Margolin escreveu: > >> > >> If you accidentally, or someone else intentionally, create a link to the > >> site that uses the IP and put it on a web page that Google can get to, > >> it will probably find the page. > >> > >> > > > > Â Â Â robots.txt, on your website root, is your friend. Simply deny web > > crawling on it, and you're (probably) done. > > > > If you believe robots.txt means anything at all. Google is known to obey it, and the question was about avoiding getting your site indexed by Google. Of course, that doesn't mean someone won't find the site on their own. If the link to it is on some other page that isn't blocked by robots.txt, someone might stuble across that page and then click on the link. But if you're mainly worried about someone googling the words that are on your website and Google sending them to the development version instead of the production version, you're pretty safe. Actually, DNS has very little impact on this at all. AFAIK, Google doesn't crawl DNS, it just crawls web pages and follows links. My company's development server is in DNS, and it's not firewalled (we all work from our homes, there's no company network to restrict access with), but I've never heard of anyone accidentally being directed there by Google, because we don't publish links to this server. -- Barry Margolin Arlington, MA ___ 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: Question about visibility
In article , Admin Hardy wrote: > I realise this is not specifically a BIND/DNS question and a bit off > topic so please ignore if need be I realise people are often very busy. > > If you you have a website but the host IP you do not list with any > domain name in DNS, is it definite that this site could never be reached > via Google. I do not really know the nuts and bolts of how Google gets > access to pages. > > If for 'some particular reason' instead of developing a site on a local > dev machine on your LAN and then uploading/installing the site to a > remote server, you needed 'for what ever reason' to do the development > and testing on the final live host accessing it via the ip address, > would this be a way to be 'almost certain' of keeping it hidden from > unwanted accidental exposure? If you accidentally, or someone else intentionally, create a link to the site that uses the IP and put it on a web page that Google can get to, it will probably find the page. -- Barry Margolin Arlington, MA ___ 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: Issues configuring delegated subdomain zone
In article , "BARAJAS BERMEJO, Sergio" wrote: > Having said that, in my vps I have defined the following: > > ; BIND reverse data file for empty rfc1918 zone > ; > ; DO NOT EDIT THIS FILE - it is used for multiple zones. > ; Instead, copy it, edit named.conf, and use that copy. > ; > > $TTL 86400 > @ IN SOA sb1. sb2. mail. ( > 10 ; Serial > 604800 ; Refresh > 86400 ; Retry > 2419200 ; Expire > 86400 ) ; Negative Cache TTL > ; REGISTROS > NS sb1.principal.hosting.com. > NS sb2.principal.hosting.com. > IN MX 10 mail.midominio.principal.hosting.com. > sb1 IN A xxx.xxx.xxx.52 > sb2 IN A xxx.xxx.xxx.53 > www IN A xxx.xxx.xxx.53 > mail IN A xxx.xxx.xxx.53 > webmail IN CNAME mail > * IN A xxx.xxx.xxx.53 Not related to the problem, but the comments at the top don't accurately describe this file. It looks like they were copied from a completely unrelated file. -- Barry Margolin Arlington, MA ___ 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: SRV record not working
In article , Grant Taylor wrote: > On 08/18/2018 07:25 AM, Bob McDonald wrote: > > I don't think anyone hates nslookup (well maybe a few do ) I > > suppose the immense dislike stems from the fact that it's the default > > utility under Windows. Folks who use dig as their default realize that > > when used properly, dig provides much more functionality than nslookup. > > For example, try using TSIG with nslookup or getting a NSID response. > > These are only a couple of examples. There's other reasons to change. > > The output from dig is much more comprehensive. And, yes, if you install > > the bind tools from ISC under Windows, dig works quite well. > > I've been told that nslookup will lie and provide incorrect information > in some situations. I have no idea what situations that is. I would > love to learn what they are. > > If you know of such an example, please enlighten me. > > As such, I tend to use nslookup on platforms without dig when or until I > have reason to not do so. I don't think it "lies" much, but the output isn't as clear and unambiguous as dig's. When it reports errors, it can be difficult to tell specifically what the actual error was. One example I can think of is that for some reason it expects the nameserver to be able to reverse-resolve its own IP. If it can't, it reports this as an error, and you might think that it's reporting an error about the name you're actually trying to look up. -- Barry Margolin Arlington, MA ___ 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: Queries regarding forwarders
.55.83.30 > ttl = 103500 (1 day 4 hours 45 mins) > -> m.gtld-servers.net > IPv6 address = 2001:501:b1f9::30 > ttl = 163960 (1 day 21 hours 32 mins 40 secs) > -> d.gtld-servers.net > internet address = 192.31.80.30 > ttl = 77579 (21 hours 32 mins 59 secs) > > > Non-authoritative answer: > Name:e2867.dsca.akamaiedge.net > Address: 23.57.126.108 > Aliases: www.cisco.com > www.cisco.com.akadns.net > wwwds.cisco.com.edgekey.net > wwwds.cisco.com.edgekey.net.globalredir.akadns.net > > > C:\Users\Administrator> > ** -- Barry Margolin Arlington, MA ___ 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: Stopping name server abuse
In article , Paul Kosinski wrote: > Somebody who has irresponsibly (and apparently wantonly, given his > refusal to fix it) delegated his domain(s) to your DNS server is > essentially causing a (modest bandwidth) distributed denial of service > attack on your server. I don't think that the "responsible" thing to do > is to sit there and suffer from a significantly increased load. Good luck getting him prosecuted under any kind of computer abuse law. That would be like calling the cops on a sibling who is poking you, claiming that it's assault. > What should be done is to get the domain(s) revoked if the owner > continues to refuse to remedy the problem: it is *he*, not you, who is > being irresponsible. And if the queries are coming via an innocent > ISP's resolver, then they are inadvertently assisting in the attack, > and should be contacted and asked to help in the remediation. (Note > that *their* resources, as well as yours, are being wasted.) I doubt any ISPs will do anything about it. It's probably negligible relative to their total DNS volume, and would be more trouble than it's worth to add filters to block it. The domain registrar is the place to go, I expect most of them have standard procedures for exactly this problem. -- Barry Margolin Arlington, MA ___ 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: Stopping name server abuse
In article , Paul Kosinski wrote: > How does *not* responding to a UDP query take longer for the *server* > than responding to UDP a query? Both responding and (deliberately) not > responding require identifying the query, but not responding bypasses > the time the server would need to construct the response, plus time > spent in the network stack. (I'm assuming we don't care about client > side "expense".) If there's no response, the client retries several times. It will try all the servers that the zone is delegated to, so you'll put more load on multiple servers. NXDOMAIN responses are cached, it's one hit and then nothing for a while. -- Barry Margolin Arlington, MA ___ 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: Stopping name server abuse
In article , "Browne, Stuart" wrote: > If you're filtering on an upstream device that can do that level of analysis > without hurting your network, then maybe, but once again, you're > double-processing every legitimate query; you're only moving the cost to a > different device. An upstream firewall might already be parsing it, so telling it not to pass some of them through could be relatively cheap. -- Barry Margolin Arlington, MA ___ 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: Stopping name server abuse
In article , jo...@hasig.de wrote: > hi, > why dont you just delete the zones? That won't stop the queries from coming to the server. -- Barry Margolin Arlington, MA ___ 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: Timeout and SERVFAIL
In article , Matus UHLAR - fantomas wrote: > Use longer expire times if you expect to experience this kind of problems > more often. Who EXPECTS to be down longer than a week? :) -- Barry Margolin Arlington, MA ___ 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: Odd behavior on a secondary server
In article , Matus UHLAR - fantomas wrote: > On 22.03.18 10:13, John Miller wrote: > >We are setting up a secondary server and seeing something that may be > >normal, but I wanted to check. The time stamp on each zone file on the > >secondary is changing with each refresh cycle, even if there are no changes > >to the file. > > > >Is this normal or am I missing something. > > it's AFAIK a way to record when ther was last refresh attempt. > I don't know of any better way to records that Exactly right. Whenever it successfully refreshes a zone, it updates the file's modification time. This is how it implements the expiration time, by comparing the current time with the file timestamp. It could keep the refresh time in memory, but that would be lost whenever named restarts. -- Barry Margolin Arlington, MA ___ 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: questions on allow-query
In article , "Darcy Kevin (FCA)" wrote: > Other than the master server(s), where there is no choice but to be > authoritative, at one end of the spectrum, and border resolvers, for which > there is no choice but to be non-authoritative (since it's not practical to > replicate data for the vast diversity of namespaces on the Internet in which > to resolve queries), at the other end of the spectrum, there is a middle > ground, where there is a real *choice* as to whether to be authoritative > (i.e. a slave, possibly a "stealth slave") for internal zones or not. The > decision of whether to be authoritative or not, is driven by a number of > factors, such as worst-case-query-performance sensitivity, availability > requirements, query-frequency-versus-refresh-overhead, available bandwidth, > DNSSEC, etc. It is perfectly reasonable, architecturally, for a given DNS > instance to be a stealth slave for some zones and to either delegate, stub > and/or forward for other zones, or for the default to be one or the other > (auth-server as default implies having an internal root). Different zones > have different requirements, different use cases, query patterns, etc. so why > wouldn't a choice of different configurations for different zones be > appropriate? Being authoritative for your own zones, and recursive for everything else, is generally not a big problem. The problemat case is service providers being authoritative for customer domains and using the same servers for caching. What often happens is that a customer switches to another DNS provider, but doesn't inform their old provider. As a result, all the other customers who use these caching servers continue to get the obsolete version of this customer's domains. When I worked at an ISP a couple of decades ago, I wrote a script that periodically checked the delegations of all the domains we hosted, to make sure they still pointed to us. -- Barry Margolin Arlington, MA ___ 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: Minimum TTL?
In article , Grant Taylor wrote: > On 02/09/2018 09:37 AM, Barry Margolin wrote: > > As long as you understand the implications of what you're doing? > > I don't think my level of understanding has any impact of my ability to > override what the zone publisher sets the desired TTL (or any value) to be. > > I have the right to run my network the way that I want to, even in my > ignorance or while shooting myself in the foot. Just because you have the right to do something doesn't mean it's a reasonable thing to do. And if you're offering a service, you have responsibilities to your customers in addition to rights. They likely have expectations of the quality of your service. Sure, you have the right to disappoint them, but do you really want to do that intentionally if you have alternatives? -- Barry Margolin Arlington, MA ___ 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: Minimum TTL?
In article , Reindl Harald wrote: > > As long as you understand the implications of what you're doing? > > > > The zone owner may be using short TTLs to implement load balancing > > and/or quick failover. If you extend the TTLs, your users may experience > > poor performance when they try to go to these sites using out-of-date > > cache entries > > but that's my problem then and not yours - it's that simple Sure, but the Internet was designed on a philosophy of cooperation. An ISP could also drop every other packet, and say "that's my problem, not yours", but we wouldn't consider that to be a reasonable way to run a network. IMHO you should at least be transparent about it, so your users know what they're in for. -- Barry Margolin Arlington, MA ___ 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: Minimum TTL?
In article , Grant Taylor wrote: > On 02/08/2018 08:51 AM, Mukund Sivaraman wrote: > > Also, just for argument's sake, one user wants to extend TTLs to > > 5s. Another wants 60s TTLs. What is OK and what is going too far? > > I think what is "OK" is up to each administrator. > > Obviously the zone administrators have decided that they want people to > use the 2s TTL. > > That being said, it is up to each individual recursive server operator > if they want to honor what the zone administrators have published, or if > the recursive administrators want to override published desires. > > > It really is something for the zone owner to consider. > > Yes and no. Yes it's up to the zone owner to consider what intentions > that they want to publish. No, the zone owner has no influence on how I > operate my servers. I choose how I operate my servers. > > If I choose to operate my servers in a manner that ignores the zone > owner's published desires, that's on me. > > I feel like this discussion is really two issues: 1) Does the > capability to override published values and 2) should I use said > capability. They really are two different questions. I personally > would like to see BIND have the option to do #1, even if I never use it. As long as you understand the implications of what you're doing? The zone owner may be using short TTLs to implement load balancing and/or quick failover. If you extend the TTLs, your users may experience poor performance when they try to go to these sites using out-of-date cache entries. -- Barry Margolin Arlington, MA ___ 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: Minimum TTL?
In article , Reindl Harald wrote: > frankly, even *if* i pay for the service i would call it a good citizen > to produce less load and the "minimum-ttl" also reduces load from other > RBL's without any restriction If the service provider is worried about load, they should increase their TTL to reduce the frequency of queries. It's not your job to second-guess them. There are some servers that will avoid expiring records if the auth servers stop responding, as a fail-safe mechanism. I think Google Public DNS does this. So they obey TTL when deciding when to try to refresh the cache, but will continue returning whatever they've cached if necessary. -- Barry Margolin Arlington, MA ___ 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: Max slaves limit?
In article , "Barry S. Finkel" wrote: > On Sun, 17 Dec 2017 22:06:58 +0530, vijay bommareddy > wrote: > > Hello folks, > > > > I'm trying to find more information on the practical limitations of adding > > more slaves. > > Can someone tell me, how many number of slaves does BIND technically > > support? Is there a maximum limit per master server? > > > > Thank you > > Vijay > > A minor point - if there are too many slaves, then the NS list might > not fit into a UDP packet, causing TCP to be used. I do not know > how many NS records would be needed to exceed the UDP packet size; > it would depend upon the length of the nodenames of the DNS servers. That assumes all the slaves are named individually in NS records. You could be using anycast IPs so the same name refers to numerous different servers. FYI the root zone has 13 NS records. The NS records themselves fit, but not all the associated A and records that go into the Additional section. And if you're using DNSSEC, most responses don't fit in the traditional 500 byte UDP packet, and EDNS0 buffer size is usually used rather than switching to TCP. -- Barry Margolin Arlington, MA ___ 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: Max slaves limit?
In article , vijay bommareddy wrote: > Hello folks, > > I'm trying to find more information on the practical limitations of adding > more slaves. > Can someone tell me, how many number of slaves does BIND technically > support? Is there a maximum limit per master server? Why would there be any limit? The master doesn't need to keep track of slaves, it just responds to queries from them. The zone transfer queries they make have a little more overhead than "normal" queries, but they don't happen very often (only when the zone changes). To avoid all slaves hammering the master at the same time, NOTIFY messages are staggered after a change is loaded. -- Barry Margolin Arlington, MA ___ 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: DNSSEC validation without current time
In article , "G.W. Haywood" wrote: > Hi there, > > On Fri, 15 Dec 2017, Petr Men??k wrote: > > > ... current time is not available or can be inaccurate. > > ntpdate? I think the issue is that he needs to resolve the hostname of the NTP server. -- Barry Margolin Arlington, MA ___ 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: Email & PTR Issues
In article , Matthew Pounsett wrote: > I'm presuming swbell.net is your ISP. You either need to get them to > delegate reverse DNS for your address block to you, or have them set up the > PTR record(s) you require in their DNS. If you have residential Internet service, I'd estimate the chances of either to be 0%. This kind of thing is generally only provided to business accounts. What's strange, though, is that they don't have some kind of generic reverse DNS for the address. Like my Comcast IP has reverse DNS that resolves to c-71-192-114-133.hsd1.ma.comcast.net. -- Barry Margolin Arlington, MA ___ 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: Differences Between Recursion Desired and Recursion Available
In article , "Darcy Kevin (FCA)" wrote: > It should be noted that answering from cache, e.g. when a server gets an RD=0 > query, or if it doesn't happen to honor recursion for that particular client, > was originally (perhaps naively) unrestricted, but, given evolving > privacy/security concerns, is now restricted by default, in all (or almost > all) implementations. For BIND, it's controlled by allow-query-cache. It also makes sense from a technical perspective -- why should the result of a query depend on coincidences of history of the server? Cache is meant for performance improvement, but it shouldn't affect the semantics. -- Barry Margolin Arlington, MA ___ 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: Differences Between Recursion Desired and Recursion Available
In article , Harshith Mulky wrote: > What I am not able to understand is, What would happen when resolver does not > set Recursion Desired bit in the query it sends? If RD is not set, the server should simply not recurse. It answers with whatever it has in its cache or authoritative data. If it has the answer, it sends that; otherwise, if it has referral data, it sends that. -- Barry Margolin Arlington, MA ___ 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: edns responses not sent by DNS Server
In article , Harshith Mulky wrote: > Hello Mark, > > Yes the client is retrying the query over TCP. > > But initially I am getting no Answers > The ANSWER is as below > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18094 > ;; flags: qr aa tc rd ad ; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: > 1 > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ;; QUESTION SECTION: > ;pcr21381.dflt.vzb.com. IN NAPTR > > Should the server be sending some responses which are truncated (or) no > Responses in this case? BIND will omit the Additional Section (and maybe also the Authority Section?) if that allows the response to fit. Otherwise I believe it just sends an empty response, and the client is supposed to retry with TCP. The problem with sending a partial Answer Section is that there's no way for the client to know if the omitted answers are important. So it has to retry anyway. -- Barry Margolin Arlington, MA ___ 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: DNS forwarding
In article , Elias Pereira wrote: > Hello, > > Our scenario today consists of one: > > - DNS Server (Authoritative to our subdomains. Ex: www.mydomain.com*, > moodle.mydomain.com, etc) > - samba3 PDC server > - Openldap server (user base for samba) > > All our IPs are public. > > This scenario above works like a charm!! :D > > Now, I'm implementing a new samba4 AD server. > > In order for me to be able to put users in the AD domain, I need to > configure the samba4 AD IP as primary dns on the computers. In the bind > installed on samba4 AD I configured the "forwarder" variable with the IP of > our DNS server. > > The problem is that from this computer, if I need to access an internal > subdomain, for example our webserver*, I can not access. Gives resolution > error. For any other site, for example, google.com, I can access. > > I'm not finding the problem. Any idea? Is this server configured to be authoriative for your domain? Does it have delegation records for the subdomains? It won't follow forwarders if the query is in a zone it's configured to be authoritative for. -- Barry Margolin Arlington, MA ___ 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: Difference between delegation and forward zone
In article , "McDonald, Daniel (Dan)" wrote: > Yes, you can forward to a subdomain. Just define it as a separate zone and > include the forwarders and forward-only lines. I believe you need > allow-query-cache for this to work. This won't work reliably if the server is supposed to be authoritative for the parent domain. The problem is that queries from resolvers do not have the Recursion Desired flag set, and forwarding is only done when recursing. Also, if there are no delegation records for the subdomain, the parent server believes it's authoritative for them, despite having forwarders configured. Forwarding is generally only useful on resolvers, not authoritative servers. -- Barry Margolin Arlington, MA ___ 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: Bind master keeps saying it is not authoritative
In article ,
Ben Croswell wrote:
> Ensure that the allow-query clause on the master includes the slave. If the
> slave can't query for the SOA on the zone it can't do an xfer.
But it will be a different error than "Not authoritative".
He has no "allow-query" option, so it defaults to allowing everyone to
query. Which is normal for a non-hidden master.
>
> On Mar 2, 2017 6:34 AM, "Xavier Humbert"
> wrote:
>
> > The whole configuration, comments removed :
> >
> > -- Master --
> > acl my-slaves {
> > any;// DEBUG
> > };
> >
> > acl my-clients {
> > any;// DEBUG
> > };
> >
> > options {
> > // IP config
> > listen-on port 53 {172.29.16.135; 127.0.0.1; };
> > listen-on-v6 port 53 {none; };
> >
> > // Paths
> > directory"/var/named";
> > dump-file "/var/named/data/cache_dump.db";
> > statistics-file "/var/named/data/named_stats.txt";
> > memstatistics-file "/var/named/data/named_mem_stats.txt";
> >
> > // Behaviour
> > recursion no;
> > allow-transfer{ my-slaves; };
> > };
> >
> > // rndc key
> > include "/etc/rndc.key";
> >
> > controls {
> > inet 127.0.0.1 port 953
> > allow { 127.0.0.1; } keys { "rndc-key"; };
> > };
> >
> > // Logging
> > // omitted
> >
> > zone "in.acv.orion.education.fr" {
> > type master;
> > file "/etc/named/internal/in.acv.orion.education.fr.db";
> > allow-transfer {my-slaves; };
> > };
> >
> > -- Slave --
> > acl my-clients {
> > localhost;
> > any;//DEBUG
> > };
> >
> > options {
> > // IP config
> > listen-on port 53 {172.29.16.133; 127.0.0.1; };
> > listen-on-v6 port 53 {none; };
> >
> > // Paths
> > directory"/var/named";
> > dump-file "/var/named/data/cache_dump.db";
> > statistics-file "/var/named/data/named_stats.txt";
> > memstatistics-file "/var/named/data/named_mem_stats.txt";
> >
> > // Behaviour
> > recursion no;
> > allow-update{ 172.29.16.135; };
> > allow-transfer{ 172.29.16.135; };
> >
> > };
> >
> > // rndc key
> > include "/etc/rndc.key";
> >
> > // Logging
> > // Omitted
> >
> > zone "in.acv.orion.education.gouv.fr" {
> > type slave;
> > file "/etc/named/in.acv.orion.education.gouv.fr.db";
> > masters {172.29.16.135; };
> > };
> > zone "." IN {
> > type hint;
> > file "named.ca";
> > };
> >
> > include "/etc/named.rfc1912.zones";
> > include "/etc/named.root.key";
> >
> > --
> >
> > Really, reall basic !
> > Thanks
> >
> > --
> > Xavier Humbert
> > CRT Supervision et Exploitation de Niveau 1
> > Rectorat de Nancy-Metz
> > 03 83 86 27 39
> >
> >
> >
> > ___
> > 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
> >
--
Barry Margolin
Arlington, MA
___
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: Redirect only second and third level domains
In article , Andrea Gabellini wrote: > Hi, > > the server is a resolver for about 20K clients. My goal is to supply a > courtesy page if a domain is not found. For every domain. But a wildcard in the root domain doesn't just rewrite for NXDOMAIN, it rewrites *everything* that doesn't have a delegation. So even if you could somehow limit the number of levels it processes, it still wouldn't do what you want. -- Barry Margolin Arlington, MA ___ 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: bind 9 goes rogue and revert zone information
In article , Raul Dias wrote: > I have a very strange behavior that I am failing to understand. > > 2 to 5 times a week, a named server revert back to a previous version os > a master zone. > This happens during the night, usually around 20h EST. > > This zone has a serial of 3017020401 (yes, I typo the 3 somewhere in the > past). > When it reverts its zone information, it goes back to 3016060101. It sounds to me like there's a cron job restoring the zone from a backup. -- Barry Margolin Arlington, MA ___ 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: The DDOS attack on DYN & RRL ?
In article , Ben Croswell wrote: > The other option being having a master owned by your company and then > setting both external providers to secondary from your master. You to > maintain control over data and hqve diversity. Good point, although that means maintaining another service on your own infrastructure. Another thing that makes it hard for many companies to diversify their DNS providers is that they make use of DNS-based load balancing and failure (e.g. Amazon's Route 54, Akamai's Global Traffic Management). These services can't easily update each other. -- Barry Margolin Arlington, MA ___ 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: The DDOS attack on DYN & RRL ?
In article , Ben Croswell wrote: > I think what we see as a result of this attack is DNS provider diversity > being the new buzz phrase. The same as not relying on a single ISP link i > see more people using multiple DNS providers. > The size of these attacks will grow as IoT continues to grow. It makes > sense to have diverse providers to ensure your domains are serviceable if a > provider gets attacked. My boss asked me to look into this after the attack. The sticking point seems to be that most DNS providers don't allow zone transfers from their servers. We currently get our auth DNS from SoftLayer, the hosting provider for our primary web, application, and database servers. I contacted them to find out if it's possible to enable zone transfers to a third party slave service, they said no; they suggested that we simply set up both services as masters, which would mean we'd have to update them independently (or write our own scripts that make use of each service's API). The customers of Dyn are in the same situation. Maybe last week's incident will prompt enough big customers to demand this that they'll change their policies. -- Barry Margolin Arlington, MA ___ 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: The DDOS attack on DYN & RRL ?
In article , Jim Popovitch wrote: > On Mon, Oct 31, 2016 at 11:27 AM, Matthew Seaman > wrote: > > On 2016/10/31 14:53, Jim Popovitch wrote: > >> On Mon, Oct 31, 2016 at 10:25 AM, Matthew Seaman > >> wrote: > >>> This despite the fact that Dyn has a global anycast network with > >>> plenty of bandwidth, points of presence all round the world and > >>> each POP contains a bunch of top-of-the-line servers. > >> > >> It seems to me that anycast is probably much worse in the Mirai botnet > >> scenario unless each node is pretty much as robust as a traditional > >> unicast node. > > > > I couldn't really say whether unicast is more or less resistant to this > > sort of attack -- I'd guess either way it would be down to the capacity > > at each individual node. > > > > It was Dyn's USA POPs that bore the brunt of the attack, presumably > > because most of the Mirai bots were located in the USA. Even so, it > > still caused us plenty of grief in Europe. Apparently the effects were > > fairly minimal in the Far East. > > > > That makes one wonder if the EU Anycast nodes are reliant on the USA > node(s). I have no insights (and even less DNS knowledge) but it > makes one wonder if there's a fundamental design flaw in anycast DNS > that relies on one or more nodes... is anycast DNS really just > distributed cache DNS? "Anycast" just means that a single public IP address is routed to different POPs depending on where the source is. So if you query 4.2.2.1 or 8.8.8.8 from the US, you'll go to a US nameserver; if you query them from Europe, you'll go to a European server. While 4.2.2.1 and 8.8.8.8 are caching DNS, the same can be done with authoritative DNS, and that's what was attacked in the Dyn case (I'm not even sure if Dyn offers caching DNS). I heard that the impact of the attack was even narrower than just the US, it was mostly eastern US. That suggests some things about the granularity of Dyn's anycast network and the distribution of the Mirai botnet. -- Barry Margolin Arlington, MA ___ 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: view problem
In article , Pol Hallen wrote: > > Please be aware that only one view is visible for any client. > > mhmh... > > how I can solve my problem? > > all clients need to access to my zones but mobile clients (don't have > vpn client) needs to access to all zones exception vpn (but can use FQDN) > > any idea? If there are zones that both sets of clients should see, you have to duplicate them in both views. Overlapping views don't do this automatically. -- Barry Margolin Arlington, MA ___ 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: How to request ixfr updates against public ip directly instead of unicast ip in bind
In article , Matus UHLAR - fantomas wrote: > On 12.10.16 20:57, rams wrote: > >I have master and slave servers. When we have updates in master, slave is > >getting updating after 20 or 30 minutes. > >When I look into tcpdump pcakets, Slave is trying with master unicast ip to > >get updates. We don't have port opened slave to master with unicast ip and > >we have port opened slave to master with public ip. > > > >Do we have any option checking for SOA value directly with public ip of > >master instead of unicast ip. > > I don't get it. What do you mean by "unicast" and "public" IP? My guess was that he's doing Anycast DNS for his public IP, and the unicast address is the real address that the router forwards to. Or he's just confused about terminology, and used "unicast IP" to mean "private IP" -- Barry Margolin Arlington, MA ___ 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: How to request ixfr updates against public ip directly instead of unicast ip in bind
In article , rams wrote: > Hi, > Greetings!!! > I have master and slave servers. When we have updates in master, slave is > getting updating after 20 or 30 minutes. > When I look into tcpdump pcakets, Slave is trying with master unicast ip to > get updates. We don't have port opened slave to master with unicast ip and > we have port opened slave to master with public ip. > > Do we have any option checking for SOA value directly with public ip of > master instead of unicast ip. It uses whatever address is in the "master" statement in named.conf. -- Barry Margolin Arlington, MA ___ 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: R: Minimal responses and speeding up queries
In article , Job wrote: > I thought setting minimal_responses = yes should lower the number of queries > Do you think it is the opposite? Yes. With minimal_response = no, it doesn't fill in the Additional section with records related to the ones in the Answer section. If the client doesn't already have those records cached, it will need to make an additional query to get them. So instead of one query that returns everything the client needs, it needs to make two queries. -- Barry Margolin Arlington, MA ___ 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: adding second zone
In article ,
Pol Hallen wrote:
> Hi all
> I searching for about add a second zone to BIND but I didn't find how :-/
Add
zone "secondzone.com" {
...
};
to your named.conf.
>
> I've a standard zone: example1 IN SOA with record A 192.168.1.212
>
> this zone works perfectly
>
> I'd like add a second zone to network 192.168.10.0/24, the problem is
> that my server has 1NIC and is connect to hardware firewall with some
> NICS, so:
>
> WAN<-->LAN1 - 192.168.1.0/24 <---> BIND+DHCP server (works)
> LAN2 - 192.168.10.0/24 <---> DHCP only
> LAN3 [...]
> LAN4 [...]
>
> routing and NAT works between LAN1 and LAN2
>
> so, firewall will assign dhcp lease inside LAN2 with BIND on LAN1
None of this has anything to do with BIND zones. You can serve multiple
zones on the same nameserver IP.
--
Barry Margolin
Arlington, MA
___
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: adding zone forwards without restart
In article , Tony Finch wrote: > Benny Pedersen wrote: > > > > why does reload not flush ? > > Often you want to reload zone files without throwing away the cache. It shouldn't flush the entire cache, but it would certainly make sense to flush entries within a forwarding zone that's modified. -- Barry Margolin Arlington, MA ___ 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: Need of caching on bind server
In article , Harshith Mulky wrote: > Thank you John, Mukund, Barry and Dave for your insights and answers on this > Topic. > > > @Dave, Lets say we have a Web Page cached(when queried by User 1) and the > webpage has either moved the Link ( accessing the same Link from a different > user would result in '504 Timeout' as it was cached by the Server) > > So do we mean, every other user when querying the web page still gets the > same link which was cached and now not reachable? > > There should be some way, this should not happen > > [P.S: I was trying a web link yesterday, and i got into this issue, but I was > still able to open the cached web page link 2 days ago] Caching web pages has nothing to do with DNS caching. -- Barry Margolin Arlington, MA ___ 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: Need of caching on bind server
In article , Harshith Mulky wrote: > I am trying to understand why caching is required on the bind server, when > the client receiving the responses would be caching based on TTL values. A typical caching server has multiple clients. If they're an ISP, it will have thousands of clients, and public DNS servers like OpenDNS and Google DNS it may have hundreds of thousands. So even if the clients have caches of their own (which many do not), the cache is useful so that when different clients look up the same name they can be returned from cache. For example, consider all the thousands of lookups for things like google.com, twitter.com, etc. that an ISP receives every second. If they didn't cache these responses, DNS traffic might rival YouTube (OK, that's an exaggeration). -- Barry Margolin Arlington, MA ___ 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: Query on Bind Operations
In article , Harshith Mulky wrote: > Hello Experts, > > > Can > > > max-cache-ttl be used on the client( client which supports bind) to override > the default ttl time sent in response by Bind server for Positive Responses? That's the only place where it can be used. The authoritative server doesn't have the records in cache, it's loaded permanently. -- Barry Margolin Arlington, MA ___ 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: Selective forwarding from an internal only name server
In article , "Darcy Kevin (FCA)" wrote: > Barry, > Cloudflare has been doing this for a while, so that their customers > won't be > "limited by the DNS specifications (RFCs)" . Having done that, > they were compelled to offer another service -- so-called "CNAME flattening" > -- to fix the brokenness that's caused by their base offering. > > See > https://support.cloudflare.com/hc/en-us/articles/200169056-CNAME-Flattening-RF > C-compliant-support-for-CNAME-at-the-root > > I think Akamai also offers something similar. But these don't work by sending an actual CNAME record. The server that implements flattening looks ip the IP of the target, and returns it as an A record for the domain. That's why Cloudflare's method is "RFC-compliant", but what MS is doing with sharepoint.com is not. > > - Kevin > > -Original Message- > From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Barry > Margolin > Sent: Wednesday, August 17, 2016 4:34 PM > To: comp-protocols-dns-b...@isc.org > Subject: Re: Selective forwarding from an internal only name server > > In article , > "Darcy Kevin (FCA)" wrote: > > > Well, sharepoint.com is a CNAME to sharepoint.microsoft.com, so you > > might need to make arrangements for that to be resolvable as well. > > That doesn't seem valid to begin with. The .COM zone has delegation NS > records for sharepoint.com. Having a CNAME record for the same name is wrong. > > -- > Barry Margolin > Arlington, MA > ___ > 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 -- Barry Margolin Arlington, MA ___ 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: Selective forwarding from an internal only name server
In article , "Darcy Kevin (FCA)" wrote: > Well, sharepoint.com is a CNAME to sharepoint.microsoft.com, so you might > need to make arrangements for that to be resolvable as well. That doesn't seem valid to begin with. The .COM zone has delegation NS records for sharepoint.com. Having a CNAME record for the same name is wrong. -- Barry Margolin Arlington, MA ___ 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: weird transfer-source problems with one DNS node
In article , Ian Veach wrote: > So unless I'm crazy (possible, regardless)... named is reporting using 230, > but OS is showing 240 (and remote host logs confirm 240)!? Could something in iptables be transforming it at a lower level? -- Barry Margolin Arlington, MA ___ 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: Sending extra info in bind dns query packet
In article , Jan-Piet Mens wrote: > >I did not get this... am I posting this to wrong mailing list? > > This has been discussed several times on this list within the past few weeks. > > You should check the archives. > > -JP Weren't the past threads about sending additional information in the reply. This is about sending additional information in the request. I think the only acceptable way to do this would be via the EDNS0 extension mechanism. -- Barry Margolin Arlington, MA ___ 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: Resolving issue on specific domain
In article , Daniel Dawalibi wrote: > Hello > > > > We are facing a weird issue while resolving a specific domain name from our > authoritative DNS server running on BIND 9.10.4-P1 > > Server has only one public IP address. > > If you try to resolve the domain using either dig or nslookup you will not > get any result whereas if you specify @localhost you will get the answer > > Do you have any explanation about this behavior and what should be done to > fix this issue? This suggests that the problem is that the domain isn't delegated to your server. If you don't use @localhost, the query goes to your normal resolver, which follows the delegations from the root, and they don't lead to your server. -- Barry Margolin Arlington, MA ___ 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: Additional Section - TXT Format?
In article , Jun Xiang X Tee wrote: > Dear all, > > > I have a simple question here. Is it possible to have a TXT format tuple > appearing at the additional section? I don't think there's anything expressly prohibiting it. But the additional section is only supposed to contain records that would be helpful when processing the records in the Answer section. For instance, if you ask for NS or MX records, you're likely to need the addresses of the targets of those records, so they should be included in the answer to save you from having to request them separately. DNS is supposed to be a lightweight protocol, so it's inappropriate to return more data than is really needed. -- Barry Margolin Arlington, MA ___ 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: UDP Packet Hack
In article , Jun Xiang X Tee wrote: > (1) Does "dig" get its UDP packets from "named" server? Or "lwresd" server? > Or others? If you use the @server argument, it gets it from that server. Otherwise, it gets it from a server in your resolver configuration (/etc/resolv.conf on Unix). > (2) For hacking purpose, I should work on BIND9 source codes. I don't need > to install BIND9 using "apt-get install", right? Right, that just installs the binaries. > (3) Lastly, the most important question: How should I configure DNS server > for "dig"? > > What I am doing now is going into "bin/dig" folder and run something > like "./dig google.com". > > I think what I should do is "./dig @chosen_DNS_server google.com", > but I do not know how to configure the server. The default configuration of a DNS server should work for this. You only need to add extra configuration if your server will be authoritative for some domains, but your server just recurses (and adds extra data to the response). -- Barry Margolin Arlington, MA ___ 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: Forward record for WWW
In article , "Cuttler, Brian R. (HEALTH)" wrote: > Since this is only a test server not production, and lives in the DMZ it must > be blocked at the FW. > > # dig with no specification for query type and with "A" both give the same > result. Dig with q-type "any" is output included. > > Sorry that prior email had bad line breaks, looked ok when I wrote it but > they have moved us to outlook and I am apparently not sufficient proficient > in its use. The output shows that there clearly isn't an A record for the zone apex. You need to post the zone file if you want help with what you did wrong. My guess is you either forgot the "." at the end of the name, or didn't reload the server after updating the zone file. > > This is the output from dig against this server. > > [euclid] ~ 201> dig @199.184.16.7 wadsworth.org > > ; <<>> DiG 9.10.2-P3 <<>> @199.184.16.7 wadsworth.org > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8047 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;wadsworth.org. IN A > > ;; AUTHORITY SECTION: > wadsworth.org. 86400 IN SOA pauling.wadsworth.org. > qll.wadsworth.org. 1603081507 10800 3600 604800 86400 > > ;; Query time: 0 msec > ;; SERVER: 199.184.16.7#53(199.184.16.7) > ;; WHEN: Thu May 05 13:29:15 EDT 2016 > ;; MSG SIZE rcvd: 90 > > > > [euclid] ~ 213> dig any @199.184.16.7 wadsworth.org > > ; <<>> DiG 9.10.2-P3 <<>> any @199.184.16.7 wadsworth.org > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62021 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 5 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;wadsworth.org. IN ANY > > ;; ANSWER SECTION: > wadsworth.org. 86400 IN MX 10 smtptoo.wadsworth.org. > wadsworth.org. 86400 IN MX 10 smtpproxy.wadsworth.org. > wadsworth.org. 86400 IN MX 5 wish1.wadsworth.org. > wadsworth.org. 86400 IN TXT "v=spf1 ptr:wadsworth.org > ip4:199.184.28.0/22 ?all" > wadsworth.org. 86400 IN SOA pauling.wadsworth.org. > qll.wadsworth.org. 1603081507 10800 3600 604800 86400 > wadsworth.org. 86400 IN NS ns1.albany.edu. > wadsworth.org. 86400 IN NS pauling.wadsworth.org. > wadsworth.org. 86400 IN NS beacon.health.state.ny.us. > > ;; ADDITIONAL SECTION: > wish1.wadsworth.org.86400 IN A 199.184.16.38 > smtptoo.wadsworth.org. 86400 IN A 199.184.16.18 > smtpproxy.wadsworth.org. 86400 IN A 199.184.16.16 > pauling.wadsworth.org. 86400 IN A 199.184.16.6 > > ;; Query time: 0 msec > ;; SERVER: 199.184.16.7#53(199.184.16.7) > ;; WHEN: Thu May 05 13:30:49 EDT 2016 > ;; MSG SIZE rcvd: 369 > > [euclid] ~ 214> > > > -Original Message- > > From: Stephane Bortzmeyer [mailto:bortzme...@nic.fr] > > Sent: Thursday, May 05, 2016 12:12 PM > > To: Cuttler, Brian R. (HEALTH) > > Cc: Stephane Bortzmeyer ; bind-users@lists.isc.org > > Subject: Re: Forward record for WWW > > > > ATTENTION: This email came from an external source. Do not open > > attachments or click on links from unknown senders or unexpected emails. > > > > > > On Thu, May 05, 2016 at 04:06:06PM +, Cuttler, Brian R. (HEALTH) > > wrote a message of 34 lines which said: > > > > > I configured the change for my external test server only > > > (199.184.16.7, which is _probably_ available for external query) > > > > No. > > > > % dig @199.184.16.7 A wadsworth.org > > > > ; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> @199.184.16.7 A wadsworth.org ; (1 > > server found) ;; global options: +cmd ;; connection timed out; no servers > > could be reached -- Barry Margolin Arlington, MA ___ 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: Multiple SERVFAIL/REFUSED unexpected RCODE
In article , Mik J wrote: > Hello Mark, > Thank you for your answer. I'm not sure I've understood everything but I'll > read it numerous times if necessary.I have ACLs so I'm not surprised to see > these REFUSED, I also understand the SERVFAIL meaning. Your ACL is not relevant. The REFUSED response is coming from the server the reverse zone is delegated to. > I'm just trying to figure out where the problem comes from.You seem to point > out a device which should be on my network and who queries a PTR (something > like a mail server which want to check the domain of the user who sent the > email) The problem comes from bad reverse DNS delegations of remote addresses. Unfortunately, this has always been very common. > > What I didn't understand is"You could use whois to try to contact the > administrators of these zones to correct the servers or remove the > delegations."You mean this one "x.204.99.116.in-addr.arpa" which appeared in > my logs ? > Regards whois -h whois.apnic.net 116.99.204.0 role: VIETEL IPADMIN GROUP address:1 Tran Huu Duc, My Dinh, Tu Liem, Hanoi country:VN phone: +84-9-83000456 fax-no: +84-4-38460486 e-mail: tie...@viettel.com.vn remarks:send spam and abuse report to tie...@viettel.com.vn whois 88.165.16.0 role: Administrative Contact for ProXad address:Free SAS / ProXad address:8, rue de la Ville L'Eveque address:75008 Paris phone: +33 1 73 50 20 00 fax-no: +33 1 73 92 25 69 remarks:trouble: Information: http://www.proxad.net/ remarks:trouble: Spam/Abuse requests: mailto:ab...@proxad.net admin-c:APfP1-RIPE tech-c: TPfP1-RIPE nic-hdl:ACP23-RIPE mnt-by: PROXAD-MNT abuse-mailbox: ab...@proxad.net created:2002-06-26T12:46:56Z last-modified: 2013-08-01T12:16:00Z source: RIPE # Filtered > > Le Mardi 3 mai 2016 13h30, Mark Andrews a écrit : > > > > > In message <353379836.10168122.1462272936427.javamail.ya...@mail.yahoo.com>, > Mi > k J writes: > > > > Hello, > > In my named.log I can see a lot of SERVFAIL/REFUSED unexpected RCODE > > messages. Most of the time someone tries to resolve a PTR > > I can see an average of 10 messages per second like these > > May 3 10:46:26 dns named[7228]: REFUSED unexpected RCODE resolving > > 'x.204.99.116.in-addr.arpa/PTR/IN': 203.113.131.x#53 > > May 3 10:46:26 dns named[7228]: SERVFAIL unexpected RCODE resolving > > 'x.16.165.88.in-addr.arpa/PTR/IN': 193.0.9.x#53 > > > > The PTR records don't belong to me and the remote DNS servers are located > > around the world. > > Does anyone has an understanding of why I receive these type of requests > > ? Why do they query my DNS servers ? > > Thank you > > Something on your network is trying to convert 116.00.204.x and > 88.165.16.x addresses to names, presumably because they are seeing > traffic from those addresses. In both cases there appears to be > broken delegations involved. > > REFUSED usually means that the server is not configured for the > zone. > > SERVFAIL usually means that the server is configured for the zone > but doesn't have a current copy. > > You could use whois to try to contact the administrators of these > zones to correct the servers or remove the delegations. > > Mark -- Barry Margolin Arlington, MA ___ 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: also-notify and nsupdate doesnt work
In article , "Darcy Kevin (FCA)" wrote: > Apologies if this has already been asked, but are you sending these NOTIFYs > from a master which is _not_ in the "masters" clause of the nameserver which > is receiving it? That's precisely the use case for "allow-notify"... The use case for also-notify is when you have slave servers that aren't in the NS records of the zone. Otherwise, those slaves won't update until the Refresh timer goes off. -- Barry Margolin Arlington, MA ___ 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: Adding CNAME for the root domain issue
In article , Sam Wilson wrote: > In article , > "Baird, Josh" wrote: > > > Any thoughts on a service like Cloudfare's 'CNAME Flattening' [1]? > > > > [1] > > https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cname > > s-at-a-domains-root/ > > > Does anyone else find themselves mentally yelling "apex!" whenever they > read the word "root" in that document? > I've long since stopped getting bothered by sloppy language like this, ever since people started using "IP" as short for "IP address", or using "class A, B, C" to refer to /8, /6, and /24 prefixes, rather than the original address ranges. The context always makes it clear when root == apex. -- Barry Margolin Arlington, MA ___ 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: Adding CNAME for the root domain issue
In article , "Baird, Josh" wrote: > Any thoughts on a service like Cloudfare's 'CNAME Flattening' [1]? > > [1] > https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames- > at-a-domains-root/ Akamai has had a similar feature in their EDNS service for years. One problem that features like this have is that they don't play nice with CDN's, because the query for the target name comes from the auth server for the domain rather than the original resolver. When I was at Akamai, we only allowed this to be used to point to a server that immediately sent an HTTP redirect to the subdomain, which could then be managed using the normal load balancing algorithms. That was 5 years ago, they may have since integrated the two services, so that when resolving the CNAME it hooks into the CDN algorithms. -- Barry Margolin Arlington, MA ___ 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: Adding CNAME for the root domain issue
In article , "John Levine" wrote: > Assuming you mean this (notice the dots): > > Domain.com. CNAME x.y.com. > www CNAME x.y.com. > > it should work. Some people believe that you can't have other records > at names below a name with a CNAME, but they are mistaken. The problem isn't with names *below* the CNAME, it's with other records with the same name as the CNAME. In particular, the SOA record for domain.com. You would only be able to do this if you could put the CNAME record in the parent domain, instead of delegating domain.com to your own server. But do any domain registrars support that option? -- Barry Margolin Arlington, MA ___ 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: bind service was down
In article , é´æ¨å¥å²â大è wrote: > Dear > > Thank you for Vinå£ius Ferré»'s answer. > > I would like to know why it crashed. > > Would anyone tell me why it crashed Because it has a bug. -- Barry Margolin Arlington, MA ___ 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: Bind response to query's very small edns udp payload size
In article , John Wobus wrote: > >> What does bind try to do if the client specifies a udp size of less than > >> 512? > > > > From RFC 6891: > > > > Values lower than 512 MUST be treated as equal to 512. > > Doh. > > The behavior I saw was a shorter authority section and no additional section > (or TO) > when I specified a UDP buffer of 200 as opposed to sending a non-EDNS > request. > But I do see that an EDS request with UDP buffer size 512 gives me > exactly the same result as with buffer size 200. I speculate > bind will skip part of its usual authority section and provide no > TC bit as long as it can give the full answer section. RFC 2181 says: "The TC bit should be set in responses only when an RRSet is required as a part of the response, but could not be included in its entirety. The TC bit should not be set merely because some extra information could have been included, but there was insufficient room." https://tools.ietf.org/html/rfc2181#section-9 So if there are optional records that could be included in the Authority section, but they aren't required, it can leave them out without setting TC. -- Barry Margolin Arlington, MA ___ 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: when i check resolver.log just now , i found some error info about AAAA ( ipv6)
In article , "Darcy Kevin (FCA)" wrote: > Really, there's no excuse, in this day and age, for a DNS-serving device -- > even a load-balancer pretending to be a nameserver -- to botch its responses > to queries. Load balancers routinely botch requests for any type other than the specific type they're programmed to balance. There's never been an excuse for it in the first place (how hard would it have been for them to return NOERROR?), so there's no reason to expect them to treat any differently from other types that they don't know about. -- Barry Margolin Arlington, MA ___ 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: Bind response to query's very small edns udp payload size
In article , John Wobus wrote: > What does bind try to do if the client specifies a udp size of less than 512? > Iâve been trying queries and here is what Iâve seen: >From RFC 6891: Values lower than 512 MUST be treated as equal to 512. https://tools.ietf.org/html/rfc6891#section-6.2.3 So I expect BIND obeys this. -- Barry Margolin Arlington, MA ___ 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: Can bind be configured to not drop RR's from the cache when the upstream DNS server is unresponsive
In article , Ron wrote: > Barry, > > On Sat, Mar 26, 2016 at 3:13 AM, Barry Margolin wrote: > > In article , > > John Wobus wrote: > > > >> On Mar 18, 2016, at 6:28 AM, Barry Margolin wrote: > >> > In article , > >> > Mark Andrews wrote: > >> > > >> >> How do you actually expect this to ever work in real life? > >> > > >> > I'm pretty sure Google DNS does this. Other resolver operators often get > >> > complaints about "Why can't I look up through your DNS > >> > servers when I can do it through Google DNS?" > >> > >> Iâd guessed Google just re-queries before it needs to, which has > >> benefits > >> but > >> requires a more complex âclean out very-seldom-used recordsâ strategy. > >> Iâd imagine they'd use a somewhat-random amount of time to pre-query > >> as one of their measures against cache poisoning. > > > > When I was at Akamai we called this "prefresh". > > > > But it doesn't help much if the auth server doesn't respond, the record > > will still expire. > >> > >> In any case, I cringe at the thought of overriding TTLs. Theyâre there > >> for a reason. In some instances, overriding could âhelpâ, but in > >> others, > >> it > >> would be really, really bad. > > > > The main purpose of TTLs is to ensure that when the record is changed, > > the new value replaces the obsolete value within the specified window. > > But if the server isn't responding, clients aren't going to get the new > > value anyway. Which is more useful for end users, returning the old > > record past its TTL, or reporting an error saying that the name doesn't > > exist? > > > > I think this touches on the heart of the matter. > We have implemented an ansible-driven emergency plan, where we put > entries in /etc/hosts files whenever a situation like this happens. > > Not an ideal solution. And only useful for names you know ahead of time that you're going to need. -- Barry Margolin Arlington, MA ___ 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: Configuring different TTLs in multiple RRs for the same domain name, TYPE, and CLASS
In article , Dave Warren wrote: > On 2016-03-25 07:21, Barry Margolin wrote: > > In article , > > Dave Warren wrote: > > > >> I'm more interested in the impact from the perspective of an > >> authoritative server operator and in some respects sites that use short > >> TTLs will increase the odds of my longer-TTL's records staying in the > >> cache longer before it gets hit by a cache-size limit, but none of my > >> zones are really large enough to do A/B testing. > > IMHO, memory is so cheap these days that any server that has to eject > > cache entries because of memory limits means the server operator isn't > > really trying to do their job well. > > If you're running a dedicated public/ISP/massive-corporation resolver, > sure, this is true. But if your resolver is some random DNS server on a > small corporate Active Directory and one of dozens of services on a > $1000 server with 1-50 users, who cares if your DNS cache only carries 5 > minutes, 30 minutes, or 6 hours of cache? > > In fact, if your resolver just forwards queries to your ISP, and your > ISP has dedicated caches, there would be very little measurable > difference at all. I'm not a fan of forwarding, but many admins set it > up because it's there without considering whether it's needed or not. If you're running a resolver for a small organization, the cache isn't going to get huge in the first place. How many different names will 50 users access in a day? -- Barry Margolin Arlington, MA ___ 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: Can bind be configured to not drop RR's from the cache when the upstream DNS server is unresponsive
In article , John Wobus wrote: > On Mar 18, 2016, at 6:28 AM, Barry Margolin wrote: > > In article , > > Mark Andrews wrote: > > > >> How do you actually expect this to ever work in real life? > > > > I'm pretty sure Google DNS does this. Other resolver operators often get > > complaints about "Why can't I look up through your DNS > > servers when I can do it through Google DNS?" > > Iâd guessed Google just re-queries before it needs to, which has benefits > but > requires a more complex âclean out very-seldom-used recordsâ strategy. > Iâd imagine they'd use a somewhat-random amount of time to pre-query > as one of their measures against cache poisoning. When I was at Akamai we called this "prefresh". But it doesn't help much if the auth server doesn't respond, the record will still expire. > > In any case, I cringe at the thought of overriding TTLs. Theyâre there > for a reason. In some instances, overriding could âhelpâ, but in others, > it > would be really, really bad. The main purpose of TTLs is to ensure that when the record is changed, the new value replaces the obsolete value within the specified window. But if the server isn't responding, clients aren't going to get the new value anyway. Which is more useful for end users, returning the old record past its TTL, or reporting an error saying that the name doesn't exist? A secondary value of TTLs is that they'll keep the cache from filling up with names from domains that have been abandoned completely. That's why I suggested that there should be a cap on how long it should keep returning these old, cached records. An extra day should be plenty of time for the server operator to fix their problem. -- Barry Margolin Arlington, MA ___ 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: Configuring different TTLs in multiple RRs for the same domain name, TYPE, and CLASS
In article , Dave Warren wrote: > I'm more interested in the impact from the perspective of an > authoritative server operator and in some respects sites that use short > TTLs will increase the odds of my longer-TTL's records staying in the > cache longer before it gets hit by a cache-size limit, but none of my > zones are really large enough to do A/B testing. IMHO, memory is so cheap these days that any server that has to eject cache entries because of memory limits means the server operator isn't really trying to do their job well. -- Barry Margolin Arlington, MA ___ 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: Configuring different TTLs in multiple RRs for the same domain name, TYPE, and CLASS
In article , Dave Warren wrote: > On 2016-03-24 15:20, Tony Finch wrote: > > Dave Warren wrote: > >> On 2016-03-24 09:46, Ray Bellis wrote: > >>> On 24/03/2016 16:41, Tony Finch wrote: > >>> > >>>>> When I changed our TTLs from 24h to 1h last year, it didn't have a > >>>>> visible > >>>>> effect on authoritative server query load, much to my surprise. > >>> I'm not that surprised - there's definitely not a linear correlation > >>> between the TTL of an RRset and how frequently it's queried. > >>> > >>> Unless your TTL is very short, forced expulsion from cache (due to > >>> cache-size limits) would cause many clients to re-query for a record far > >>> more frequently than once-per-TTL. > >> Has anyone ever done any evaluation on this? For average resolvers, what > >> is the longest TTL that has any utility? > > There was a great paper published 15 years ago describing a study of DNS > > cache effectiveness at MIT. http://nms.csail.mit.edu/projects/dns/ > > > > It concluded (amongst other things) that NS records (and associated > > address records) are really important, but leaf records that users ask for > > don't matter so much. (Based on cache hits before TTL expiry, IIRC.) > > > > I don't know of a similar study performed more recently. > > The internet was a very different place 15 years ago, in particular, > this was before every Windows client machine had it's own DNS cache > service and largely before today's connected mobile devices were a thing. But it was also before the widespread use of CDNs (Akamai was founded only 3 years earlier). These days, the most heavily used web sites use CDNs, which make heavy use of short TTLs for the leaf CNAME and A records. -- Barry Margolin Arlington, MA ___ 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: Configuring different TTLs in multiple RRs for the same domain name, TYPE, and CLASS
In article , Ben Bridges wrote: > TXT records are multiple-purpose. They can be used for SPF records, Office > 365 "MS" records, DMARC records, or whatever arbitrary uses someone dreams > up, all for the same domain name. Microsoft wants a short TTL for their > Office 365 records, but I would prefer to generally use a longer TTL for most > records (including other TXT records) in order to reduce the query load on > our servers. It would be nice to be able to set a short TTL for the Office > 365 record but a longer TTL for other TXT records for the same domain name. The problem with this is that when the Office 365 records expire and are removed from the cache, but the other records have not, the server will not know that it should re-query for the O365 records. It still has TXT records in its cache, and it will return them in response to a query. It won't go back to the authoritative server until ALL the TXT records expire. During the period between the short TTL and the longest TTL, it will be as if the short-TTL records don't exist at all. -- Barry Margolin Arlington, MA ___ 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: Can bind be configured to not drop RR's from the cache when the upstream DNS server is unresponsive
In article , Mark Andrews wrote: > How do you actually expect this to ever work in real life? I'm pretty sure Google DNS does this. Other resolver operators often get complaints about "Why can't I look up through your DNS servers when I can do it through Google DNS?" > Caches will generally have expired / not learnt the records by the > time you realise that you want to keep records longer so there is > no point even coding support for this into caches. We don't have > time machines. Of course, if the record hasn't been cached in the first place, there's nothing you can do. But a heavily-used resolver will quickly cache most popular records. When a cached record expires, the server should try to refresh it. If it gets a valid response, it updates the cache. But providing the old record if there's no response is not an unreasonable approach to fault tolerance. It would be reasonable to have a configured maximum lifetime for these expired records, so that caches wouldn't fill up with lots of detritus from abandoned domains. A day seems like long enough for the authoritative server operator to fix their problem. -- Barry Margolin Arlington, MA ___ 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: Can bind be configured to not drop RR's from the cache when the upstream DNS server is unresponsive
In article , Dave Warren wrote: > My current logic is that I do a SOA query and check the serial number, > if it has changed, I query every needed hostname into a temp file, and > if every single query was successful, check the SOA again, and if it > still matches, update the /etc/hosts. If anything goes wrong (including > a mismatch between the SOA), dump the temp file and try again. That's feasible if you can reconfigure all the client machines to do this. It's not very scalable if you have a network of machines running different operating systems, and you'd like to have your central resolver take care of all the caching. -- Barry Margolin Arlington, MA ___ 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: Multiple A records and reverse DNS
In article , sch...@adi.com (Thomas Schulz) wrote: > This is not a BIND question but I hope people here will know the answer. > We are switching service providers and I understand that many email SPAM > prevention systems insist on the reverse DNS matching the forward DNS. > If I have two A records for our mail server and the reverse record matches > one of them, will that be good enough. Or will the fact that the other A > record does not match cause trouble. It should be OK. This is a fairly common situation for redundancy. -- Barry Margolin Arlington, MA ___ 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: A Zone Transfer Question
In article , John Miller wrote: > And if you actually want people to use your zone or you want NOTIFY > working, two NS records (and possibly glue) are really a must. He mentioned that these are internal nameservers, they're not reached via public delegation. So NS records are probably irrelevant to how they're used by clients. -- Barry Margolin Arlington, MA ___ 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: A Zone Transfer Question
In article ,
David Li wrote:
> Hi John,
>
> Well, I was wrong about the log. I did find some info about why zone
> transfer failed. On one server running zone rack1.com, I see:
>
> Feb 19 16:04:27 dli-centos7 named[13882]: client 10.4.3.101#20745
> (rack1.com): query 'rack1.com/SOA/IN' denied
> Feb 19 16:04:27 dli-centos7 named[13882]: client 10.4.3.101#52612
> (rack1.com): transfer of 'rack1.com/IN': IXFR ended
>
> Any idea why it's denied?
VM1 has the option:
allow-query {
10.4.1/24;
127.0.0.1;
};
10.4.3.101 isn't in 10.4.1/24. The slave has to be allowed to query the
master.
--
Barry Margolin
Arlington, MA
___
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: A Zone Transfer Question
ng here? Do I need to post my > >> zone file and named.conf? > >> > > > > Hi David - > > > > Yes, it'd certainly help if you posted your named.conf. I don't know > > that we need the whole zone file: the SOA and NS records would > > probably suffice in this case, especially if the zone has tons of > > records. > > > > I'll say: it sounds a little odd that you'd expect zone2 to be updated > > when zone1 changes. The master NS for zone1 will send out NOTIFY > > messages to the servers listed in the NS records for zone1; it'll also > > send NOTIFYs to anything you've put in an also-notify block. > > > > The 15-minute wait also sounds strange: NOTIFY happens as soon as the > > serial number of the master zone is incremented and the zone is > > reloaded. Also, a slave NS will automatically check its master for > > updates after the refresh interval (1st number after the serial) > > specified in the SOA record. If you have that set to 15 minutes (900 > > seconds), then yes--the slave would check its master for updates, but > > it's the _slave_ reaching out to the _master_ in that case. Likewise, > > slaves will reach out to their master NS when their zones are > > reloaded. > > > > I'm not going to worry about the DHCP dynamic updates piece yet - make > > sure your master and slave are set up properly before introducing > > dynamic updates to the mix. > > > > John -- Barry Margolin Arlington, MA ___ 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: How to check slave zone freshness
In article , Klaus Darilion wrote: > On 08.02.2016 20:49, Mark Andrews wrote: > > With a modern nameserver that supports the expire edns option you can > > also do "dig +expire soa zone @server" which will tell you how long > > until the zone will expire on this server. > > Aha, but isn't this a different kind of information? A zone which is not > fresh anymore (refresh interval expired and checks to the master failed) > may still be valid (not expired yet). Subtract the time until expiry from the SOA Expire field, and that tells you how long it has been since it last refreshed. -- Barry Margolin Arlington, MA ___ 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: Resolver optimization of auth selection - Truth or Myth?
In article , "Darcy Kevin (FCA)" wrote: > If you take a look at sections 4.1 & 4.2 - they seem to say > BIND 9.8 gets it a little backwards and starts to prefer > higher latency servers? It doesn't say it prefers high-latency servers. It occasionally tries the high-latency servers, because it decays the low-latency SRTT. The purpose of this is to prevent permanently blackholing a server when it's temporarily slow. So every now and then it will switch to the high-latency server. If it's still high latency, it will lose preference again, and it will go back to the low-latency servers. But if it has gotten better, it will continue to be used. Network distance is not the only reason for high latency, sometimes it can be because of heavy load on the server, or a congested network link, or other temporary conditions. -- Barry Margolin Arlington, MA ___ 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: Writeable file already in use
In article , Alan Clegg wrote: > On 1/5/16 6:26 AM, Jan-Piet Mens wrote: > >> This might make you sad if you have lots of zones or large zones. > > > > .. or even just want to look at what was transferred (whitout having to > > recurse to a `dig axfr'). > > > > I see no reason to omit 'file' (except on a diskless slave ;-) > > I ran into one exception to this rule - it seemed that the customer had > security requirements that did not allow "transient data" to be written > to disk. They had to make sure that if the physical device was stolen, > all of their zone data didn't follow it out the door. The in-memory copy is likely to end up in the swap partition. -- Barry Margolin Arlington, MA ___ 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: Query on ignoring additional section returned in replies
In article , Reindl Harald wrote: > Am 18.11.2015 um 16:47 schrieb Barry Margolin: > > In article , > > Reindl Harald wrote: > > > >> when a result looks like below it needs to be fixed and "Are there any > >> BIND specific workarounds?" is the wrong question becaus even if - the > >> domain owner is not in the position to place workarounds somewhere else > > > > While that's the pedantically correct answer, in practice it doesn't > > work well when your users complain "Google DNS deals with it, why don't > > you?" Your users don't care what happens to people somewhere else, they > > just want to get their work done. > > the pedantically correct answer would have been "if you can't convince > your DNS operator that something is wrong fire him and seek for somebody > with a clue what he is doing which implies running tools like the quoted > regulary" It's not your DNS operator, it's someone else's. > > > Google understands that there are lots of broken DNS configurations out > > there, but their users don't want to hear that it's someone else's fault > > the users shouldn't take notice of such config bugs at all because it > should not last for longer than a few hours until get proactive fixed The OP said he reported the problem to the domain owner. They ignored his report, because Google DNS doesn't have a problem resolving their domain. -- Barry Margolin Arlington, MA ___ 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: Query on ignoring additional section returned in replies
In article , Reindl Harald wrote: > when a result looks like below it needs to be fixed and "Are there any > BIND specific workarounds?" is the wrong question becaus even if - the > domain owner is not in the position to place workarounds somewhere else While that's the pedantically correct answer, in practice it doesn't work well when your users complain "Google DNS deals with it, why don't you?" Your users don't care what happens to people somewhere else, they just want to get their work done. Google understands that there are lots of broken DNS configurations out there, but their users don't want to hear that it's someone else's fault. -- Barry Margolin Arlington, MA ___ 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: root hints operation
In article , Grant Taylor wrote: > On 11/16/2015 06:56 PM, /dev/rob0 wrote: > > You either specify a hints file to use, or use the compiled-in root > > hints. > > Interesting. I was not aware that it was an exclusive or type situation. Did you think it combined the file with the built-in list? > Based on the way I read the link, I still believe my original post is > accurate. (Save for the XOR.) It is. I'm not even sure you misunderstood the XOR, since you wrote that it tries each server in the root hints file until it gets a successful response. That suggests that you understood that the built-in list is used in place of the file if no file is provided. -- Barry Margolin Arlington, MA ___ 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: Why two lookups for a CNAME?
In article , Steve Arntzen wrote: > I'm sure there's a good, simple reason for this, I just can't seem to find > the > answer searching on the Internet. > > > Why does named perform a lookup for the A record when its IP is returned with > the CNAME in the first answer? > > > Using dig, I find play.google.com is a CNAME for play.l.google.com. > > > When asked to resolve it, named will first look for play.google.com. The > result > will include the CNAME and the IP of the A record. > > > Named then makes a second request to resolve the A record. Are you sure about this example? That would be the correct behavior if the target of the CNAME were delegated to different servers than the CNAME itself. But both google.com and l.google.com are served by ns[1-4].google.com. You'll see additional queries like this if you look up servers hosted by the Akamai CDN, because the CNAME points from the original domain to one of Akamai's domains. -- Barry Margolin Arlington, MA ___ 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: SRV Request to DNS
In article , Mark Andrews wrote: > To answer the question. What you do when given a name and a port > is protocol specific. Read the protocol specification. Note if > the port is the well known port for the protocol then it may be > ignored. > > If the protocol does not specify most developers will just implement > the protocol over that port to the specified host taking into account > well known ports if needed. > > To used SRV with a protocol you need a specification that says to > do so. Using SRV without such a specification results in undefined > behaviour. Are there *any* current, well-known protocols that make use of SRV records to find the port? The examples I've seen just use it to find a server (analogous to the way MX records are used for mail). Theoretically, this could be useful for HTTP, so you wouldn't have to put :port# in URLs if the domain uses an alternate port. It would make things easier when you have servers for multiple domains behind a NAT router with a single public address. But AFAIK there's been no movement to require browsers to use SRV for this. -- Barry Margolin Arlington, MA ___ 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: Multiple queries for same host
In article ,
Alex wrote:
> HI,
>
> I have a fedora22 system with bind-9.10.2 that is configured to be
> authoritative for its domain and also provides recursive query
> services for a number of trusted hosts.
>
> I'm seeing a situation where multiple queries for the same host are
> occurring in the logs, and I don't understand why. In this case, it's
> queries to IPs at spamhaus, although I've changed my key and our
> public IP to 192.168.1.27 in this example:
>
> 16-Sep-2015 20:18:47.947 queries: client 192.168.1.27#34798
> (254.223.16.69.mykey.sbl.dq.spamhaus.net): query:
> 254.223.16.69.mykey.sbl.dq.spamhaus.net IN A +E (192.168.1.3)
> 16-Sep-2015 20:18:47.947 queries: client 192.168.1.27#34798
> (254.223.16.69.mykey.zen.dq.spamhaus.net): query:
> 254.223.16.69.mykey.zen.dq.spamhaus.net IN A +E (192.168.1.3)
> 16-Sep-2015 20:18:47.948 queries: client 192.168.1.27#34798
> (254.222.16.69.mykey.sbl.dq.spamhaus.net): query:
> 254.222.16.69.mykey.sbl.dq.spamhaus.net IN A +E (192.168.1.3)
> 16-Sep-2015 20:18:47.949 queries: client 192.168.1.27#34798
> (254.222.16.69.mykey.zen.dq.spamhaus.net): query:
> 254.222.16.69.mykey.zen.dq.spamhaus.net IN A +E (192.168.1.3)
> 16-Sep-2015 20:18:47.949 queries: client 192.168.1.27#34798
> (13.185.69.216.mykey.sbl.dq.spamhaus.net): query:
> 13.185.69.216.mykey.sbl.dq.spamhaus.net IN A +E (192.168.1.3)
>
> It appears to happen most frequently with spamhaus queries, but also
> occurs with random other domains.
If the client application doesn't have a cache, it will repeat queries
like this.
>
> Can someone help me understand why this is happening? Is the query
> being broken down into multiple pieces, perhaps?
What makes you think that? They're all the same full name, not broken
down.
>
> I've included my named.conf here in case I'm missing something, in
> hopes someone could help me review.
You need to be looking at the client, not the server, to see why it's
repeating the same query.
>
> acl "trusted" {
> { 127.0.0.0/8; };
> { 192.168.1.0/24; };
> };
>
> options {
> version "None of your business.";
>
> transfers-out 200;
>
> // The following paths are necessary for this chroot
> listen-on-v6 { none; };
> listen-on port 53 { 192.168.1.3; 127.0.0.1; };
>
> directory "/var/named";
> dump-file "/var/tmp/named_dump.db"; // _PATH_DUMPFILE
> pid-file "/var/run/named/named.pid";// _PATH_PIDFILE
> statistics-file "/var/named/data/named.stats"; // _PATH_STATS
> memstatistics-file "/var/tmp/named.memstats"; // _PATH_MEMSTATS
> // End necessary chroot paths
>
> check-names master warn;/* default. */
> datasize 20M;
> allow-transfer {
> 127.0.0.1;
> 192.168.1.3;
> 192.168.1.27;
> };
> // Prevent outsiders from using juggernaut
> // as their name server for unauthorized queries
> allow-query { trusted; };
> allow-recursion { trusted; };
> };
>
> logging {
>
> category default { named_info; };
> category general { named_info; };
> category lame-servers { null; };
>
> // Configure general default info
> channel named_info {
> file "/var/log/named.info.log" versions 4 size 10m;
> severity info;
> print-time yes;
> print-category yes;
> };
>
> };
>
> zone "." {
> type hint;
> file "/var/named/named.ca";
> };
>
> zone "localhost" {
> type master;
> file "masters/localhost";
> check-names fail;
> allow-update { none; };
> allow-transfer { any; };
> };
>
> zone "0.0.127.in-addr.arpa" {
> type master;
> file "masters/db.127.0.0";
> allow-update { none; };
> allow-transfer { any; };
> };
>
> zone "0/27.1.168.192.in-addr.arpa" {
> type master;
> file "masters/db.1.168.192";
> allow-query { any; };
> allow-transfer { trusted; };
> };
>
> zone "mydomain.com" {
> type master;
> file "masters/db.mydomain.com";
> allow-query { any; };
> allow-transfer { trusted; };
> };
--
Barry Margolin
Arlington, MA
___
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: BIND and RFC4074
In article , Tomas Hozza wrote: > Hi. > > I would like to ask if there is any documentation > describing if any version of BIND didn't comply > with RFC 4074. And in case there was such version, > in which release it was fixed? > > I tried to go through CHANGELOG and to Google it, > but without any luck. I'm pretty sure BIND has *always* worked correctly in this regard. The failures have generally come from standalone devices with minimal DNS implementations, often DNS-based load balancers. -- Barry Margolin Arlington, MA ___ 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: DNS Negative Caching
In article , "Darcy Kevin (FCA)" wrote: > Negative-caching TTL and regular TTL have little to do with each other; it's > not a reasonable assumption that one should stand in as a default for the > other. True, but that's water long under the bridge. Note that if a server is authoritative-only, caching is mostly irrelevant, so the negative cache TTL doesn't much apply. In this case, the SOA Minimum is just being used as the default TTL. > My opinion: named on the master should reject illegal zone files. As far as I can tell, nothing in RFC 2308 says that $TTL is required. I don't even see a SHOULD, let alone a MUST. Is there a later RFC that adds this requirement? If not, then a zone file without $TTL is legal. And for backward compatibility, it should continue to use the SOA Minimum field as the default TTL. -- Barry Margolin Arlington, MA ___ 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: DNS Negative Caching
In article , "Darcy Kevin (FCA)" wrote: > What's in a name? :-) > > RFC 2308 said that the use of the last field of the SOA to set > negative-caching TTL is "the new defined meaning of the SOA minimum field". > So you can *call* it "minimum", but it is *actually* supposed to function as > something else... > > Eventually I hope BIND will conform to the spirit of RFC 2308 and stop using > the last field of the SOA to set the default TTL, as a "fallback" in > scenarios where the file would otherwise be illegal (i.e. the first RR has no > explicit TTL set, and there is no $TTL directive preceding it). RFC 2308 is > so old, that if it were a person, it would be legal to buy cigarettes in some > parts of the world. It's long past time for folks to get with the program. Does the RFC specify some other default TTL if there's no $TTL directive? If not, the software needs to do something, and using the old method for compatibility is as good anything else (on the assumption that anyone who didn't put $TTL in the file was depending on this use of the SOA record). -- Barry Margolin Arlington, MA ___ 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: DNS Negative Caching
In article , Alan Clegg wrote: > > on the DNS Zone file we have these records > > $ORIGIN e164.arpa. > > @ IN SOA picardvm2.e164.arpa. e164-contacts.e164.arpa. ( > > 2002022404 ; serial > > 3H ; refresh > > 15 ; retry > > 1w ; expire > > *3h* ; minimum > > ) > > I wasn't really following this thread, but now that I see this, I would > like to add that the "expire" timer is also used as the default TTL for > resource records that do not have one specified, and if there is not an > explicit $TTL statement in the zone file. Is that really still true? I thought that use of the Minimum field went away when it was changed to be the negative cache TTL. -- Barry Margolin Arlington, MA ___ 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: response case in-sensitivity?
In article , Mark Andrews wrote: > In message <23dee83f-7476-432b-92b9-f8d34d617...@nau.edu>, Mathew Ian Eis > writes: > > Howdy BIND, > > > > Weve been troubleshooting an issue with iOS print discovery using DNS-SD > > for the last several weeks. We made a little bit of a breakthrough this > > evening when we observed in a packet trace that the response case was > > fully lowercase, regardless of the query case. It seems iOS is doing some > > kind of case sensitive comparison between the query and the response, > > causing DNS-SD to fail when they dont match. > > Then iOS (or the application) is broken. Domain names should always > be compared case insensitively. Please report a bug to the app > vendor and / or Apple. Isn't this the DNS 0x20 security enhancement? Clients send a random mix of case, and check that the response matches, to protect against spoofed responses. https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00 -- Barry Margolin Arlington, MA ___ 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
