Re: DNS Amplification Attacks... and a trivial proposal
On 06/13/2013 05:33 AM, Phil Mayers wrote: On 06/13/2013 06:31 AM, Ronald F. Guilmette wrote: 1) If everyone on the planet were to somehow magically and immediately be converted over to DNSSEC tomorrow, then would DNS amplification attacks become a thing of the past, starting tomorrow? Does DNSSEC solve the DNS amplification attack problem? Or does it have no direct bearing on No, quite the opposite in fact. By increasing the size of responses, DNSSEC arguably makes the amplification problem (slightly) worse. slightly is generous. I would say dramatically. $ dig mx isc.org @ord.sns-pb.isc.org +noall +stats +nodnssec ; DiG 9.9.2-P1 mx isc.org @ord.sns-pb.isc.org +noall +stats +nodnssec ;; global options: +cmd ;; Query time: 223 msec ;; SERVER: 199.6.0.30#53(199.6.0.30) ;; WHEN: Thu Jun 13 11:28:49 2013 ;; MSG SIZE rcvd: 403 $ dig mx isc.org @ord.sns-pb.isc.org +noall +stats +dnssec ; DiG 9.9.2-P1 mx isc.org @ord.sns-pb.isc.org +noall +stats +dnssec ;; global options: +cmd ;; Query time: 242 msec ;; SERVER: 199.6.0.30#53(199.6.0.30) ;; WHEN: Thu Jun 13 11:28:54 2013 ;; MSG SIZE rcvd: 2427 DNS reflection attacks are all about amplification (a small request resulting in a response larger than the request). A 6 times greater response size is a large jump in amplification. DNSSEC is a good thing and necessary for other reasons, but it does not help amplification attacks. +1 2) Has anyone ever proposed adding to the DNS protocol something vaguely reminicent of the old ICMP Source Quench? If so, what became of that proposal? snip Basically, the whole idea is just simply to allow a victim to switch to safe TCP only mode with all of the intermediaries that are participating The problem with that idea is that it needs software updates on both the reflecting DNS server and the victim. It also seems to require keeping a lot of soft state in the endpoints. This would require both software updates and an update to the DNS protocol. This idea does require state at the endpoints. We seem to have already lost that battle - example RRL. Would this require more state at the endpoints than RRL? I think that this probably would require more state. One concern I have is that it turns the problem on its head and now the network that is the target of the attack is required to get packets out through their loaded equipment to stop the attack. This could lead to wrong headed statements like, Yes, we sent X GB of traffic at your network. You didn't implement DNS source quench? You should have. The chain of responsibility for these attacks is: 1. The person(s) originating the spoofed traffic. 2. The network(s) allowing the origination of spoofed traffic. 3. The network(s) transmitting the spoofed traffic. 4. The operators of nodes amplifying the traffic towards the victim. 5. The victim. A system that requires the victim to take action to stop attacks might be misconstrued by some to be abdicating the responsibility of the upper four levels. Altogether, it seems easier for everyone to just apply RRL patches, do BCP38 and de-peer with people who don't do BCP38. Agreed. Close all open resolvers as well. Using this strategy, however, you will have to do an awful lot of de-peering. -DMM ___ 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: Version statement...
On 8/17/2012 1:13 AM, Jeff Justice wrote:
I am trying to mask our DNS servers version output to a custom string, but it
doesn't seem to be working for me. In a nutshell, I have added this to my
options block of my named.conf:
version [DNS Server];
options {
version string;
works for me in 9.8. Maybe BIND doesn't like the square brackets?
But when I do a query, it still shows the actual version number i.e. BIND
9.9.1-P2, both from the command line and from an outside query tool.
What am I missing?
Jeff
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Getting a formerr 'invalid response' for winqual.microsoft.com. but dig +trace works.
On 2/8/2012 10:32 PM, Matt Doughty wrote: I have spend the afternoon trying to figure this out. The response I get back from their nameserver looks fine to me, and dig +trace works fine, but a regular dig returns a servfail. I have looked at the code for invalid response, but I don't quite follow what is going on there, and the comment 'responder is insane' leaves something to be desired. Any help would be appreciated here. I have included the dig +trace output below: dig +trace winqual.partners.extranet.microsoft.com. ; DiG 9.7.0-P1 +trace winqual.partners.extranet.microsoft.com. ;; global options: +cmd . 518004 IN NS j.root-servers.net. . 518004 IN NS e.root-servers.net. . 518004 IN NS l.root-servers.net. . 518004 IN NS c.root-servers.net. . 518004 IN NS m.root-servers.net. . 518004 IN NS d.root-servers.net. . 518004 IN NS b.root-servers.net. . 518004 IN NS h.root-servers.net. . 518004 IN NS k.root-servers.net. . 518004 IN NS a.root-servers.net. . 518004 IN NS g.root-servers.net. . 518004 IN NS i.root-servers.net. . 518004 IN NS f.root-servers.net. ;; Received 228 bytes from 172.16.255.1#53(172.16.255.1) in 1 ms com.172800 IN NS h.gtld-servers.net. com.172800 IN NS f.gtld-servers.net. com.172800 IN NS m.gtld-servers.net. com.172800 IN NS g.gtld-servers.net. com.172800 IN NS l.gtld-servers.net. com.172800 IN NS c.gtld-servers.net. com.172800 IN NS d.gtld-servers.net. com.172800 IN NS a.gtld-servers.net. com.172800 IN NS b.gtld-servers.net. com.172800 IN NS i.gtld-servers.net. com.172800 IN NS j.gtld-servers.net. com.172800 IN NS e.gtld-servers.net. com.172800 IN NS k.gtld-servers.net. ;; Received 497 bytes from 192.33.4.12#53(c.root-servers.net) in 18 ms microsoft.com. 172800 IN NS ns3.msft.net. microsoft.com. 172800 IN NS ns1.msft.net. microsoft.com. 172800 IN NS ns5.msft.net. microsoft.com. 172800 IN NS ns2.msft.net. microsoft.com. 172800 IN NS ns4.msft.net. ;; Received 235 bytes from 192.43.172.30#53(i.gtld-servers.net) in 67 ms partners.extranet.microsoft.com. 3600 IN NS dns10.one.microsoft.com. partners.extranet.microsoft.com. 3600 IN NS dns13.one.microsoft.com. partners.extranet.microsoft.com. 3600 IN NS dns11.one.microsoft.com. partners.extranet.microsoft.com. 3600 IN NS dns12.one.microsoft.com. ;; Received 236 bytes from 64.4.59.173#53(ns2.msft.net) in 3 ms winqual.partners.extranet.microsoft.com. 10 IN A 131.107.97.31 ;; Received 112 bytes from 131.107.125.65#53(dns10.one.microsoft.com) in 23 ms If I just dig at their servers for NS, I get a trunc and retry over TCP that times out. If I signal a bufsize, I get back a 777 byte response with NS that don't match the parent and an additional full of private 10/8 addresses # dig +norecurse +bufsize=1024 ns partners.extranet.microsoft.com @dns10.one.microsoft.com. ; DiG 9.8.1 +norecurse +bufsize=1024 ns partners.extranet.microsoft.com @dns10.one.microsoft.com. ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 10678 ;; flags: qr ra; QUERY: 1, ANSWER: 16, AUTHORITY: 0, ADDITIONAL: 17 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;partners.extranet.microsoft.com. INNS ;; ANSWER SECTION: partners.extranet.microsoft.com. 1076 IN NS tk5-ptnr-dc-02.partners.extranet.microsoft.com. partners.extranet.microsoft.com. 1076 IN NS kaw-ptnr-dc-02.partners.extranet.microsoft.com. partners.extranet.microsoft.com. 1076 IN NS co2-ptnr-dc-02.partners.extranet.microsoft.com. partners.extranet.microsoft.com. 1076 IN NS co2-ptnr-dc-01.partners.extranet.microsoft.com. partners.extranet.microsoft.com. 1076 IN NS tk5-ptnr-dc-01.partners.extranet.microsoft.com. partners.extranet.microsoft.com. 1076 IN NS db3-ptnr-dc-02.partners.extranet.microsoft.com. partners.extranet.microsoft.com. 1076 IN NS db3-ptnr-dc-01.partners.extranet.microsoft.com. partners.extranet.microsoft.com. 1076 IN NS tk5-ptnr-dc-03.partners.extranet.microsoft.com. partners.extranet.microsoft.com. 1076 IN NS
Re: host versus nslookup
On 10/12/2011 3:01 PM, Kevin Darcy wrote: On 10/12/2011 1:21 PM, Martin McCormick wrote: Many years ago, various flavors of unix began distributing a utility called host which did almost the same thing as nslookup. Host is what I use most of the time, now, and I actually thought that nslookup on unix systems was maybe going away. A coworker recently asked me about nslookup on our FreeBSD system and I verified the behavior he was asking about. Other than a different output format, what are the advantages of having both host and nslookup. On the FreeBSD system in question, nslookup is definitely a different binary than is host so one is not hard-linked to the other. The behavior he was asking about was simply that all foreign domains that one looks up with nslookup report as non-authoritative since the DNS one is using isnot authoritative for, say, microsoft.com or yahoo.com. This is not a problem. I am just curious. nslookup has lots of problems. Four that I can cite off the top of my head: 1) most versions of nslookup will stop dead in their tracks if they can't reverse-resolve the name of whatever resolver they're trying to use (even though that's basically irrelevant to the actual lookup that the user requested) 2) nslookup will by default use a searchlist, but it does this completely invisibly by default (unless a debugging option is turned on), and thus will often mis-represent the real result of the query (e.g. you look up foo.example1.com, that gets a SERVFAIL, then unbeknownst to the user, nslookup tries the searchlist'ed name foo.example1.com.example2.com and reports the resulting NXDOMAIN as the final error of the lookup, thus obscuring the real error -- SERVFAIL) 3) the default output format of nslookup doesn't distinguish the result of the query from the identity of the resolver clearly enough, so unsophisticated users will often think that the name they're looking up actually resolves to the address of the DNS resolver, and much hilarity ensues (mis-routed trouble tickets, drama, confusion, etc.) 4) some versions of nslookup display atypical DNS responses (e.g. dangling CNAMEs, referrals) in very confusing, non-intuitive ways. - Kevin Use dig. Always use dig. If dig isn't installed - install dig and then use dig. Make dig part of your default set of packages on all boxes. host vs nslookup? is asking whether you should hit your self in the head with a small or large hammer. Put down the hammer and use dig. -DMM ___ 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: NXDOMAIN redirection in BIND 9.9
On 9/30/2011 6:21 PM, Shawn Bakhtiar wrote: We came to the conclusion that no matter how much we wanted it to not be true, people find a way to do NXDOMAIN if they want to. The issue is not ours to push, it's between the ISP and the customer ultimately, and people will do it -- and more intrusively -- than BIND 9.9 will. That is just giving in. To what WILL end up being akin (is akin) to taking away access. The argument that everyone is doing it so let's just facilitate it is a bad one. This is a cave in to bad behavior which borders on freedom of speech violation, since your sanctioning the ability to arbitrarily redirecting (without redirecting) content. Important part being the sanctioning of. http://en.wikipedia.org/wiki/DNS_hijacking You get to run your network how ever you like. This is your right. Turn the feature on if you like -or- make sure it is off if you don't like it. You don't get to tell others how to run their networks. Well... you can tell them, but they don't have to listen to you... Many organizations want to do NXDOMAIN redirections on their resolvers on their own internal networks or on guest wireless networks or on whatever networks they control for whatever reasons they like. Other resolvers have had the ability to do NXDOMAIN redirections for many years. The pressures keeping ISPs from implementing NXDOMAIN redirections has never been the fact that BIND didn't support it. You are going to have a hard time making the case that NXDOMAIN redirections are a freedom of speech violation, but the place for that argument is in the court room. Instead of seeing this as a sky is falling event, why not see it as an opportunity to create your own resolving DNS service that does not do NXDOMAIN redirections? Then every ISP that implemented NXDOMAIN redirections (using BIND or any of the myriad of other software that will do it) would be another potential group of customers for you. -DMM ___ 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: nameserver registration
On 6/18/2011 12:24 PM, Lyle Giese wrote: On 06/18/11 09:30, Jorg W. wrote: Greetings, given my domain name is example.net, and my NS servers for example.net are: ns1.example.com ns2.example.com But, example.com itself's NS servers are the registrator's (for example, godaddy's). Under this case, I don't need any glue for ns[1-2].example.com. But why I still need to register them in the .com NS servers? Thanks. You are wrong. You do need glue records. Glue records registers the ip address of your name server(s) with the root name servers. Only TLDs/ccTLDs (com., org., xxx., etc.) insert name servers and glue into the root name servers. All second level domains (example.com., example.net., etc.) insert name servers and glue into their parent TLD/ccTLD's name servers. To be clear: name servers are NS records glue records are A/ records that point to IPv4/IPv6 addresses for hostnames that are name servers. In this case the glue records are associated with ns1 and ns2.example.com. The name servers need to be registered with the domain registrar for example.com and forwarded as glue records to the root name servers for .com. Root in DNS terms is .. Better to say to the authoritative DNS servers for .com. or just TLD/ccTLD name servers. Godaddy is a domain name registrar and does not run any root name servers. However, it is the responsibility of the domain name registrars to make sure proper glue records are maintained for any/all name servers used with a domain registered with them. All domains, at every level, have to configure their records such that the tree can be walked from root to their domain. Follow the .s. For: this.long.chain.example.com. com. must be delegated by . example.com. must be delegated by com. chain.example.com. must be delegated by example.com. long.chain.example.com. must be delegated by chain.example.com. this.long.chain.example.com. must be delegated by long.chain.example.com. The wikipedia article on DNS is quite good: http://en.wikipedia.org/wiki/Domain_Name_System In the particular case of the OP - example.net. has name servers under example.com. To make lookups for records under example.net., resolvers walk the tree from . to net. and get NS records - ns1.example.com. and ns2.example.com. You can't insert glue records into net. for name servers that exist under com., so now resolvers walk the tree from . to com. to get the name servers for example.com. which in the OP's case are - GoDaddy name servers. If there are no glue records in com. for ns1.example.com. and ns2.example.com., then resolvers will just ask the authoritative name servers for example.com. (which in the OP's case are - GoDaddy name servers) for the A/ records for ns1.example.com. and ns2.example.com. If the GoDaddy name servers provide A/ records for ns1.example.com. and ns2.example.com., then resolution works and everyone is happy. Glue is only required if that is the only way to traverse the tree to get to the IP addresses for the name servers for a domain. Can someone point to an RFC or BCP that says that *all* name servers *must* have glue present in their parent? -DMM ___ 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: incorrect dns returned by public servers for our domain
On 2/24/2011 1:19 AM, Matthew Seaman wrote:
On 24/02/2011 04:14, Noel Butler wrote:
You can pretty much remove the entire statement now, as all /8's are
issued as of about two weeks ago.
This works for me:
lucid-nonsense:~/src/namedb:% cat acl-ipv4-bogons.conf
// @(#) $Id: acl-ipv4-bogons.conf 800 2011-02-03 20:22:12Z matthew $
//
// Networks listed by IANA as test, RFC 1918, Multicast, Experimental,
// etc. (RFC 5735)
//
// See: http://www.team-cymru.org/Services/Bogons/bogon-bn-agg.txt
acl ipv4-bogons {
0.0.0.0/8;
10.0.0.0/8;
127.0.0.0/8;
169.254.0.0/16;
172.16.0.0/12;
192.0.0.0/24;
192.0.2.0/24;
192.168.0.0/16;
198.18.0.0/15;
198.51.100.0/24;
203.0.113.0/24;
224.0.0.0/3;
};
//
// That's All Folks!
//
All of which are special purpose networks listed in RFC 5735 which you
shouldn't be seeing any DNS query traffic from on the open internet.
This bogon list is going to be static for the foreseeable future.
+ 192.88.99.0/24 // 6to4 relay anycast - can be destination of packets,
*should* never be source
+ 240.0.0.0/4 // reserved for future use - likely to *never* be valid
source - I block, YMMV
-DM
Cheers,
Matthew
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind and blacklist IP file
On 10/11/2010 3:26 PM, Andrey G. Sergeev (AKA Andris) wrote: Hello Alans, Mon, 11 Oct 2010 20:07:40 +0300 Alans wrote: Why not? OpenDNS is a good example i think. Good example? Was it a joke? Do the traceroute on IP addresses of the two OpenDNS resolvers and you'll find that they both are behind the same router. Do you still trust the OpenDNS people who advertise their service as reliable? You are kidding right? ...or was this post a joke? OpenDNS is Anycast - http://en.wikipedia.org/wiki/Anycast Here is an DNS Stuff Vector Trace for 208.67.222.222 (one of OpenDNS' resolvers): http://www.dnsstuff.com/tools/vectortrace?ip=208.67.222.222token=26314c5ba0c8ae4e2c32430c19d55018 Note that end points are very local to the widely spread start points. From any one location an IP Anycast service will appear to be very local. That is the point. P.S. Please don't top-post - this breaks the logic of the discussion thread. Thank you. regards, Alans On 10/11/2010 07:37 PM, Matus UHLAR - fantomas wrote: On 11.10.10 14:16, Alans wrote: Thanks Dave, yes i know about OpenDNS, I'm trying to imlement somehting kind of similar to that in a small scale. So i was wondering about Bind dns capabilities and may be third party stuffs that could integrate with bind dns in addition to the ip/website list. This is NOT something BIND (or any DNS server) should do. Blocking web sites is business for web proxies, firewalls etc. Doing this stuff at DNS level could lead to many surprises. -- -___ David Miller Tiggee LLC dmil...@tiggee.com ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: non-24 bit subnets
On 10/6/2010 3:21 PM, Jay Ford wrote: On Wed, 6 Oct 2010, Alex McKenzie wrote: Unfortunately, we do have need -- or at least a use -- to have smaller subnets in multiple files, but without delegating authority. The problem is that some of those small subnets should have a shorter TTL, or other settings changed. If there's a way to change all the settings by host in a single file, that would at least make that easier. You could use one real zone file which is referenced by named.conf, with $INCLUDE directives in that zone file to pull in the parts of the zone from files containing the subsets you want. A $TTL directive at the top of each small file should give you the variable TTL defaulting you want. You can have a different TTL for each and every record, if you like, in the same zone file with no includes (the $TTL directive can appear multiple times). e.g. : $TTL 300; 5 mins *PTRhost-no-spec.example.com. $TTL 3600; 1 hour 17 PTR mail.example.com. $TTL 1800; 30 mins 18 PTR mail2.example.com. $TTL 86400; 1 day 19PTRwhatever.example.com 20PTRwhatever2.example.com 22PTRwhatever2.example.com ^^ This works for me. For larger subnets we can use multiple zones, but I'd hoped to avoid it if possible. It sounds from this like there isn't a way, though. Right. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- -___ David Miller Tiggee LLC dmil...@tiggee.com ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Master server offline
Secondaries need to 'know' that this old sec is now a master as well.
DNS is kind of critical (unless your internet presence is not important), so
... Knowing nothing about you org... Would rec that you priortise fixing DNS
pretty highly.
--
-___
David Miller
Tiggee LLC
dmil...@tiggee.com
On May 6, 2010 23:23, Barry Margolin lt;bar...@alum.mit.edugt; wrote:
In article lt;mailman.1415.1273200624.21153.bind-us...@lists.isc.orggt;,
Bruce Ray lt;bruce@zionsbancorp.comgt; wrote:
gt; You have until the expiry counter expires for a given zone.
gt;
gt; We typically run our expiries at a week to allow for this type of failure.
You can easily turn a slave into a master. Just go into its named.conf
file, change type slave to type master and comment out the masters
{...} clause.
gt;
gt;
gt; From: bind-users-bounces+bruce.ray=zionsbancorp@lists.isc.org
gt; lt;bind-users-bounces+bruce.ray=zionsbancorp@lists.isc.orggt;
gt; To: bind-users@lists.isc.org lt;bind-users@lists.isc.orggt;
gt; Sent: Thu May 06 21:37:35 2010
gt; Subject: Master server offline
gt;
gt; Our master server machine had a drive failure and looks like it will be
gt; offline for some time. Somewhere in the back of my mind, I thought I
gt; remembered that something bad can happen to the dns resolution for your
zones
gt; if the master is offline for too long. Is there anything to this or am I
just
gt; dreaming? As long as the secondary can answer request, we should be ok?
gt;
gt; Cheers,
gt;
gt; Dave
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
DNSSEC - Root zone - FUD
All, There has been quite a bit of FUD bouncing around the net regarding the May 5th signing of the root zone and the sky falling (or at least massive failures across the internet). I have been asked multiple times about how I was going to prevent the internet from collapsing for my users. Examples: http://www.theregister.co.uk/2010/04/13/dnssec/ http://www.itnews.com.au/News/173412,warning-why-your-internet-might-fail-on-may-5.aspx As I understand it, and please (PLEASE) correct me if I am wrong, the facts are: 1. All that is happening on May 5th is that the last root server to do so (J) will begin serving the DURZ (Deliberately Unvalidatable Root Zone). All of the other root servers have been serving the DURZ for quite a while already with no ill effects. Reference - http://www.root-dnssec.org/2010/04/14/status-update-april-2010/ 2. All of the root servers are currently responding to regular DNS queries (i.e. those that do not specifically request DNSSEC) as they have always done, and after May 5th the root servers will continue to respond to regular DNS queries as they have always done. 3. Only DNS queries that specifically request DNSSEC (i.e. set the DO bit in their request) will see any difference in their query responses from the J root name server on May 5th (all of the other root name servers are already serving the DURZ today - see 1 above - and have been responding with unvalidatable DNSSEC responses to queries that request DNSSEC for a while now). 4. DNSSEC will be in no way REQUIRED after May 5th. 5. In all likelihood, DNSSEC will never be REQUIRED. Even if the root zone were validly DNSSEC signed and every single TLD/ccTLD DNS zone on the internet were validly DNSSEC signed and every single DNS subdomain were validly DNSSEC signed today, a resolving name server that does not implement DNSSEC in any way would continue to function properly as it does today. Despite the Example articles above, which seem to state/imply that May 5th represents some massive shift/change in DNS on the internet, May 5th is an important milestone but should not affect any end users. Will implementing DNSSEC in individual infrastructures require investigating allowed DNS response sizes in those networks? Absolutely. Is this something that it is important for network operators to begin investigating? Yes. Will May 5th be the day that the internet died? No. -DM ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC
I assume that you are asking about providing authoritative DNS for example.com. Should you deploy DNSSEC? Yes, if you want your query responses to be validated by DNSSEC resolvers. Does this have anything to do with the DNSSEC signing of the root domain? No, not really. Unless your TLD's name servers will also be signed and your domain registrar will support loading your key(s) into your TLD's name servers, then you will still need to use DLV (regardless of whether the root is signed or not). In other words in the absence of a fully signed path from root to a zone you will need DLV to use DNSSEC Quote from: https://dlv.isc.org/ -DM On 4/30/2010 8:57 PM, Jeff Pang wrote: Hello, Since the global root DNS servers have deployed dnssec, as a hostmaster for the common domain like example.com, should we also deploy dnssec with named? Thanks. Regards. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
