Re: [dns-operations] Enom's name server broken?
In message d1ac4482bed7c04dac43491e9a9dbec301399...@bkexchmbx02.blacknight.loc al, Michele Neylon :: Blacknight writes: Surely that's an issue with your resolver and not with enom? Or am I misunderstanding the question .. No. Caches work like that. There will be a period where the losing servers continue to get queries after the delegation has been changed. For clean transfers of zones from one provider to the next the losing provide should slave the zones from the new provider. This ensures that caches only see current content regardless of whether they are talking to the new or old servers. (or maybe I need more coffee) Or are you expecting eNom to purge DNS records for domains for which they aren't currently authoritative? I expect losing providers to do the right thing while the zone's delegation is in a state of flux. The answer below is self inconsistent. It says there are no address records but stuffs a address record in the authority section along with a TXT record. The servers are clearly *broken*. Now one can argue about what the right thing is. Old zone contents, new zone contents or return responses as if the zone is removed. This answer matches none of those. No instruction, in any RFC, results in that response. Mark On 14 Jan 2013, at 17:53, Fan Of Network fanofnetw...@gmail.com wrote: Hello, We use Enom as a registrar and provider of name server for a few of our domains. Recently we decided to switch name servers provider to a different company. One could say that it is easy. Yes, but with Enom name server is seems to be a problem. Why? Let's assume that we query for a host record in xclusivmedia.com (one of our domains still registered at Enom). Our resolver will cache (depending if it is parent-centric on child-centric) NS records from .com authoritative name server (TTL of 2 days) or Enom's name server (TTL of 1h). Then, we change list of authoritative name server at Enom (here as registrar) and within minutes .com authoritative servers will be updated. However, our resolver will keep asking Enom's name server for our domain. What Enom's server will reply? Let's see: dig test1.xclusivmedia.com @dns1.name-services.com ; DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 test1.xclusivmedia.com @dns1.name-services.com ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 43753 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 0 ;; QUESTION SECTION: ;test1.xclusivmedia.com.IN A ;; AUTHORITY SECTION: test1.xclusivmedia.com. 1800IN A 91.102.91.61 test1.xclusivmedia.com. 1800IN TXT v=spf1 -all test1.xclusivmedia.com. 3600IN NS ns1.p28.dynect.net. test1.xclusivmedia.com. 3600IN NS ns2.p28.dynect.net. test1.xclusivmedia.com. 3600IN NS ns3.p28.dynect.net. test1.xclusivmedia.com. 3600IN NS ns4.p28.dynect.net. ;; Query time: 166 msec ;; SERVER: 98.124.192.1#53(98.124.192.1) ;; WHEN: Mon Jan 14 18:44:41 2013 ;; MSG SIZE rcvd: 166 Yes, this the whole zone dumped into authority section...Did you see something like that before? Any idea how to work it around? We tried Enom's support, but they don't see the problem in this and they are not willing to escalate. Is anyone from Enom reading this? If so, could you please contact me off the list? Thanks. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs Mr Michele Neylon Blacknight Solutions Hosting Domains ICANN Accredited Registrar http://www.blacknight.co http://blog.blacknight.com/ Intl. +353 (0) 59 9183072 US: 213-233-1612 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Facebook: http://fb.me/blacknight Twitter: http://twitter.com/mneylon --- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
[dns-operations] DNS continuity during registrar transfers (was Re: Enom's name server broken?)
On 13-01-15 8:46 AM, Mark Andrews wrote: In message d1ac4482bed7c04dac43491e9a9dbec301399...@bkexchmbx02.blacknight.loc al, Michele Neylon :: Blacknight writes: Surely that's an issue with your resolver and not with enom? Or am I misunderstanding the question .. No. Caches work like that. There will be a period where the losing servers continue to get queries after the delegation has been changed. I think he did misunderstand the question (as per Stefan Schmidt's response). But in reply to what you said below (sorry for the thread drift): For clean transfers of zones from one provider to the next the losing provide should slave the zones from the new provider. This ensures that caches only see current content regardless of whether they are talking to the new or old servers. I think this almost never happens in the real world when domains move from one set of auth nameservers to another. What the losing servers can do is continue to serve the data they have, especially in the case of a registrar transfer because in a lot of cases the zone data will be the same for an overlapping period of time. But... I expect losing providers to do the right thing while the zone's delegation is in a state of flux. Most do, some don't *cough* Netsol *cough* Godaddy *cough* Some will preemptively drop all DNS as soon as they see that a domain is transferring out effectively knocking a domain offline for a few hours (or however long it takes for the operators to update their zone delegation). I personally think they do it on purpose because it makes the gaining registrar look like a schmuck. - mark (or maybe I need more coffee) Or are you expecting eNom to purge DNS records for domains for which they aren't currently authoritative? I expect losing providers to do the right thing while the zone's delegation is in a state of flux. The answer below is self inconsistent. It says there are no address records but stuffs a address record in the authority section along with a TXT record. The servers are clearly *broken*. Now one can argue about what the right thing is. Old zone contents, new zone contents or return responses as if the zone is removed. This answer matches none of those. No instruction, in any RFC, results in that response. Mark On 14 Jan 2013, at 17:53, Fan Of Network fanofnetw...@gmail.com wrote: Hello, We use Enom as a registrar and provider of name server for a few of our domains. Recently we decided to switch name servers provider to a different company. One could say that it is easy. Yes, but with Enom name server is seems to be a problem. Why? Let's assume that we query for a host record in xclusivmedia.com (one of our domains still registered at Enom). Our resolver will cache (depending if it is parent-centric on child-centric) NS records from .com authoritative name server (TTL of 2 days) or Enom's name server (TTL of 1h). Then, we change list of authoritative name server at Enom (here as registrar) and within minutes .com authoritative servers will be updated. However, our resolver will keep asking Enom's name server for our domain. What Enom's server will reply? Let's see: dig test1.xclusivmedia.com @dns1.name-services.com ; DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 test1.xclusivmedia.com @dns1.name-services.com ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 43753 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 0 ;; QUESTION SECTION: ;test1.xclusivmedia.com.IN A ;; AUTHORITY SECTION: test1.xclusivmedia.com. 1800IN A 91.102.91.61 test1.xclusivmedia.com. 1800IN TXT v=spf1 -all test1.xclusivmedia.com. 3600IN NS ns1.p28.dynect.net. test1.xclusivmedia.com. 3600IN NS ns2.p28.dynect.net. test1.xclusivmedia.com. 3600IN NS ns3.p28.dynect.net. test1.xclusivmedia.com. 3600IN NS ns4.p28.dynect.net. ;; Query time: 166 msec ;; SERVER: 98.124.192.1#53(98.124.192.1) ;; WHEN: Mon Jan 14 18:44:41 2013 ;; MSG SIZE rcvd: 166 Yes, this the whole zone dumped into authority section...Did you see something like that before? Any idea how to work it around? We tried Enom's support, but they don't see the problem in this and they are not willing to escalate. Is anyone from Enom reading this? If so, could you please contact me off the list? Thanks. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs Mr Michele Neylon Blacknight Solutions Hosting Domains ICANN Accredited Registrar http://www.blacknight.co http://blog.blacknight.com/ Intl. +353 (0) 59 9183072 US: 213-233-1612 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090
Re: [dns-operations] Enom's name server broken?
On Wed, Jan 16, 2013 at 12:46:30AM +1100, Mark Andrews ma...@isc.org wrote a message of 126 lines which said: For clean transfers of zones from one provider to the next the losing provide should slave the zones from the new provider. This ensures that caches only see current content regardless of whether they are talking to the new or old servers. Note that it does not scale (think about the ACL to manage and the need to have a timer) and, in practice, is never done (despite the fact it is a contractual obligation for the .FR registrars and may be for the ICANN ones). ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Enom's name server broken?
On 15 Jan 2013, at 14:48, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Wed, Jan 16, 2013 at 12:46:30AM +1100, Mark Andrews ma...@isc.org wrote a message of 126 lines which said: For clean transfers of zones from one provider to the next the losing provide should slave the zones from the new provider. This ensures that caches only see current content regardless of whether they are talking to the new or old servers. Note that it does not scale (think about the ACL to manage and the need to have a timer) and, in practice, is never done (despite the fact it is a contractual obligation for the .FR registrars and may be for the ICANN ones). It's not a contractual requirement for ICANN accredited registrars We are contractually obliged to follow the inter-registrar transfer policy (http://www.icann.org/en/resources/registrars/transfers/policy-01jun12.htm ) but that has nothing to do with DNS zone transfers Most of the ccTLD don't put an obligation on us either And as Stephane points out, that kind of thing simply does not scale Regards Michele Mr Michele Neylon Blacknight Solutions ♞ Hosting Domains ICANN Accredited Registrar http://www.blacknight.co http://blog.blacknight.com/ Intl. +353 (0) 59 9183072 US: 213-233-1612 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Facebook: http://fb.me/blacknight Twitter: http://twitter.com/mneylon --- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Enom's name server broken?
Michele Neylon :: Blacknight writes: Surely that's an issue with your resolver and not with enom? I'm a little surprised I haven't seen someone comment on this issue with their servers (but maybe I missed it in my quick skim; if so, apologies for redundancy): On 14 Jan 2013, at 17:53, Fan Of Network fanofnetw...@gmail.com wrote: ; DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 test1.xclusivmedia.com @dns1.name-services.com ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 43753 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 0 ;; QUESTION SECTION: ;test1.xclusivmedia.com. IN A ;; AUTHORITY SECTION: test1.xclusivmedia.com. 1800 IN A 91.102.91.61 test1.xclusivmedia.com. 1800 IN TXT v=spf1 -all test1.xclusivmedia.com. 3600 IN NS ns1.p28.dynect.net. test1.xclusivmedia.com. 3600 IN NS ns2.p28.dynect.net. test1.xclusivmedia.com. 3600 IN NS ns3.p28.dynect.net. test1.xclusivmedia.com. 3600 IN NS ns4.p28.dynect.net. Why are the A and TXT record in the Authority section? ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Enom's name server broken?
On Tue, Jan 15, 2013 at 12:10 PM, Michele Neylon :: Blacknight mich...@blacknight.com wrote: Or are you expecting eNom to purge DNS records for domains for which they aren't currently authoritative? I'd expect Enom to keep replying to queries as they used to before list of authoritative name servers for my domain was changed. In ideal world they should do that for TTL on parent server (here .com so 2 days) Thanks. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Enom's name server broken?
On Jan 15, 2013, at 11:45 AM, Paul Vixie p...@redbarn.org wrote: Stephane Bortzmeyer wrote: ... dns1.name-services.com is not supposed to be recursive (it does not set the RA bit) but it is: % dig @dns1.name-services.com www.dns-oarc.net ... ;; ANSWER SECTION: www.dns-oarc.net .3600IN A 69.64.147.243 ;; Query time: 158 msec since the ttl isn't ticking down on repeated queries, i think it's not recursive, it's got a wildcard of some kind. try this: dig @dns1.name-services.com lihdsiuhswluswf.com soa Every time I see an email like this I'm tempted to run off and register e.g lihdsiuhswluswf.com, just to be difficult. I manage to resist, but... Am I just a bastard or do others suffer from this compulsion as well? W paul ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Militant Agnostic -- I don't know and you don't either... ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Enom's name server broken?
On Jan 15, 2013, at 10:41 AM, Warren Kumari wrote: since the ttl isn't ticking down on repeated queries, i think it's not recursive, it's got a wildcard of some kind. try this: dig @dns1.name-services.com lihdsiuhswluswf.com soa Every time I see an email like this I'm tempted to run off and register e.g lihdsiuhswluswf.com, just to be difficult. I manage to resist, but... Am I just a bastard or do others suffer from this compulsion as well? W Warren, Both, I don't think the two are mutually exclusive. :-) Rod ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Enom's name server broken?
* Fan Of Network: I'd expect Enom to keep replying to queries as they used to before list of authoritative name servers for my domain was changed. In ideal world they should do that for TTL on parent server (here .com so 2 days) In an ideal world, they would serve the new zone contents, with the new NS RRset in particular. 8-) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Can you force your IPv4/v6 DNS server to return v4 responses only on recursive lookups
The option in BIND is filter--on-v4 and has been available since 9.7, search for the option in http://ftp.isc.org/isc/bind9/cur/9.8/doc/arm/Bv9ARM.ch06.html for the full syntax of the option. Steve On 15 January 2013 21:55, Stephan Lagerholm stephan.lagerh...@secure64.com wrote: I believe they have a similar option but you will have to ask the Bind mailing list. Thanks, S From: McGhee, Karen (Evolver) [mailto:karen.mcg...@uspto.gov] Sent: Wednesday, January 16, 2013 1:42 AM To: Stephan Lagerholm; dns-operations@lists.dns-oarc.net Subject: RE: [dns-operations] Can you force your IPv4/v6 DNS server to return v4 responses only on recursive lookups I should have said, the name server is BIND 9.8 running on RHEL5.5. Thanks, k From: Stephan Lagerholm [mailto:stephan.lagerh...@secure64.com] Sent: Tuesday, January 15, 2013 3:09 PM To: McGhee, Karen (Evolver); dns-operations@lists.dns-oarc.net Subject: RE: [dns-operations] Can you force your IPv4/v6 DNS server to return v4 responses only on recursive lookups Hi Karen, There are a few vendors (disclaimer I work for one of them) that has implemented a “disable--on-v4-transport” feature that might be able to do what you are looking for. You can google for ‘yahoo dns hack’ to get more info. /Stephan From: dns-operations-boun...@lists.dns-oarc.net [mailto:dns-operations-boun...@lists.dns-oarc.net] On Behalf Of McGhee, Karen (Evolver) Sent: Wednesday, January 16, 2013 1:22 AM To: dns-operations@lists.dns-oarc.net Subject: [dns-operations] Can you force your IPv4/v6 DNS server to return v4 responses only on recursive lookups Hi, Is it possible to configure my IPv4/IPv6 DNS server to return v4 queries only when doing recursive lookups? Thanks, k ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS continuity during registrar transfers (was Re: Enom's name server broken?)
Are we talking about change of DNS operator or registrar transfer? I am confused as the subject talks about registrar transfer but people seems to talk about change of DNS provider. What I'm talking about happens when you are changing RARs and the losing RAR is also your DNS provider Sent from my iPhone Patrik ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Can you force your IPv4/v6 DNS server to return v4 responses only on recursive lookups
On 2013-01-15 at 15:11 -0500, McGhee, Karen (Evolver) wrote:
I should have said, the name server is BIND 9.8 running on RHEL5.5.
There's a configure-time option to bind9, `--enable-filter-`. _If_
it was given, then:
options {
filter--on-v4 yes;
};
That won't filter if DNSSEC records are present; use `break-dnssec`
instead of `yes` if you _really_ want to drop all records.
I'm assuming you know how connectivity to resolver != connectivity to
end-sites and you're instead just using this as a crude filter for
systems behind middleware that will break _all_ IPv6, and are telling
customers to configure their auth DNS servers via IPv6 address if they
want to be able to reach IPv6-only sites, and if the customers are
internal, you're providing a way for them to modify the DHCP assignment
they'll get, to manage this.
And that you have a transition plan to get the non-IPv6 customers fixed
before DNSSEC rolls out to enough sites that validating forwarding
resolvers run by your customers won't break for the IPv4-only customers
(which might, of itself, be a crude hammer to encourage fixes).
-Phil
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Can you force your IPv4/v6 DNS server to return v4 responses only on recursive lookups
We need an option like this `break-dnssec` feature to use RPZ for stopping user
access to DNSSEC-signed domains that are on a block list.
-Original Message-
From: dns-operations-boun...@lists.dns-oarc.net
[mailto:dns-operations-boun...@lists.dns-oarc.net] On Behalf Of Phil Pennock
Sent: Tuesday, January 15, 2013 5:55 PM
To: McGhee, Karen (Evolver)
Cc: DNS Operations
Subject: Re: [dns-operations] Can you force your IPv4/v6 DNS server to return
v4 responses only on recursive lookups
On 2013-01-15 at 15:11 -0500, McGhee, Karen (Evolver) wrote:
I should have said, the name server is BIND 9.8 running on RHEL5.5.
There's a configure-time option to bind9, `--enable-filter-`. _If_
it was given, then:
options {
filter--on-v4 yes;
};
That won't filter if DNSSEC records are present; use `break-dnssec`
instead of `yes` if you _really_ want to drop all records.
I'm assuming you know how connectivity to resolver != connectivity to
end-sites and you're instead just using this as a crude filter for
systems behind middleware that will break _all_ IPv6, and are telling
customers to configure their auth DNS servers via IPv6 address if they
want to be able to reach IPv6-only sites, and if the customers are
internal, you're providing a way for them to modify the DHCP assignment
they'll get, to manage this.
And that you have a transition plan to get the non-IPv6 customers fixed
before DNSSEC rolls out to enough sites that validating forwarding
resolvers run by your customers won't break for the IPv4-only customers
(which might, of itself, be a crude hammer to encourage fixes).
-Phil
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
[dns-operations] are we adding value?
maybe its just me, but I think most of the 'add complexity' being discussed here is fruitless, and devalues DNS. Its retrofit on a simple protocol to try and cover for situations not forseen, which I believe is very often counter-productive. We don't continue to use telnet in the wide any more, and moved to SSH. It doesn't mean that telnet option negotiations are 'wrong' but it does mean that the telnet protocol isn't the one which services the need we have any more, for telematic/interactive access services. telnet as it remains doesn't have a heap of post-2000 knobs added. If you want those features, you go somewhere else. Its been left fit for purpose in a narrowly defined role. I think the same is true of DNS. its a global label to value lookup service with a nice, small definition of the separator and the cut point, and some guidance on TTL/cacheing. We've retrofitted the beginnings of some security, but at considerable cost, and for an outcome which is now showing problems like the amplification attack effects. I think sending a stronger message about uRPF type defences, and asking other people to look at spoof source is better. Sometimes it pays to recognise you can't solve a problem, and look to who can. After all, if we reduced the amount of spoofed source, then we'd reduce attack modes in more than just DNS. the 'real' problem here isn't DNS spoofed-source attacks, its spoofed-source attacks. If for instance, somebody discovers a way to use this in HTTP and achieve a 1000x amplification, they won't just be using DNS will they? (I know, tcp doesn't work. But you get the sense of what I mean. spoofed UDP streams of video might work?) I realize it won't completely work, and that there will 'be' a problem to be solved here, and I also think that the kind(s) of solutions which increase the cost on the spoofer are probably the best we have right now, combined with some amount of probabilistic/heuristic dropping, but I still find myself thinking this is just turning the value equation in DNS right down We're in a world where the goal is to answer questions, quickly and accurately. The fixes are beginning to look like major attacks on that fundamental. I'm also confused about the 'no more ANY' discussion. Maybe I over-read, but I think ANY is a useful query, and I think ending it entirely would be a mistake. ANY allows for queries where you don't know the specific payload you need. DO we really want to remove that? -G ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] are we adding value?
yes, we are adding value. George Michaelson wrote: ... I think sending a stronger message about uRPF type defences, and asking other people to look at spoof source is better. i thought this in 2002. that's why i wrote http://archive.icann.org/en/committees/security/sac004.txt. been there, done that, traveled nearly 1M air miles and talked to everybody i met on every stage i was on. total result: squat. we've been overwhelmed by new cloud virtual servers running unpatched web apps. the bad guys have more firepower than ever, and most virtual hosting providers can't afford the manpower to either patch customer systems, handle complaints, or block spoofed-source attack flows. (those that try are probably bought out by those who don't, due to the difference in their profit margins.) so let me tell you from experience, what you're asking for is not better than complexifying DNS. more below. Sometimes it pays to recognise you can't solve a problem, and look to who can. ... we did that. see above. now we have to look to who actually will, or would, among others who can. that translates to those whose real ip addresses are revealed to victims. that means the amplifiers. we have never gained ground on those whose real ip addresses are not revealed during attacks, and we have for outside cause lost ground there. now we have to do what can be done, which means finding someone who can act whose identity is revealed and who can therefore hear complaints and who can also act. i'd rather fix this at the source, but failing that, _and we have in fact failed_, all we can do is fix the amplifiers. ... We're in a world where the goal is to answer questions, quickly and accurately. The fixes are beginning to look like major attacks on that fundamental. i think we need to hold a world wide kiss simplicity goodbye festival. because from now on all recursive name servers will have to be ACL'd, and all authority name servers will have to be RRL'd. there's no going back. paul ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Enom's name server broken?
The only time I've seen DNS being pulled or domains pointed at holding pages as described is with resellers of registrars Not saying that registrars don't do it ever, but I've never seen any do it Mr. Michele Neylon Blacknight http://Blacknight.tel Via iPhone so excuse typos and brevity On 16 Jan 2013, at 01:51, Mike Jones m...@mikejones.in wrote: On 15 January 2013 22:19, Matthew Ghali mgh...@snark.net wrote: TBH I've never even thought to have that expectation from a registrar; and in fact I'd never assume they do the right thing. My first domain registrar was the Internic, which probably explains the low bar. Many years later, working at a registrar (on a hosted DNS product!) only reinforced my beliefs. In an ideal world, you'd get exactly what you pay for. In reality you get less. Most people are definitely not paying for inter-provider coordination and a seamless service cutover. Heck, they're paying barely enough for service that answers *most* queries. Some registrars would probably argue 1 DNS server occasionally being up was good enough to meet their obligations for the free (meaning included in the price and you pay for it if you use it or not) service if past experience is anything to go by. but there's a difference between not 100% reliable which is acceptable to use on domains that aren't very important and we'll hijack your traffic to our landing page if you try to migrate away from us which I don't think is acceptable even for the least important domains I have. - Mike ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Can you force your IPv4/v6 DNS server to return v4 responses only on recursive lookups
From: Patrick, Robert (CONTR) robert.patr...@hq.doe.gov
We need an option like this `break-dnssec` feature to use RPZ for
stopping user access to DNSSEC-signed domains that are on a block list.
How should it differ from the break-dnssec yes/no modifier for the
response-policy{} statement mentioned in the ARM for BIND 9.9 and 9.8?
Look for break-dnssec in
http://ftp.isc.org/isc/bind9/cur/9.8/doc/arm/Bv9ARM.ch06.html
or
http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch06.html
There is a single break-dnssec bit for each view. It seems likely
that those who want to break DNSSEC with RPZ want to do it for the
entire view. In addition, the rules precedence rules (and code) for
choosing which polizy zone to apply are already too complicated without
a separate break-dnssec bit for each policy zone.
Vernon Schryverv...@rhyolite.com
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS continuity during registrar transfers (was Re: Enom's name server broken?)
On 15 jan 2013, at 23:40, Mark Jeftovic mar...@easydns.com wrote: What I'm talking about happens when you are changing RARs and the losing RAR is also your DNS provider My experience from operation of both in the .SE domain since DNSSEC started here many years ago is that the only way of be able to move forward in discussions like these (this is not the first time we have this discussion) is by clearly separating the case of changing registrar from the case of changing DNS provider. This because the result of the discussion (a set of best practices that nice players should follow) must clearly say what the donating and gaining registrar and dns providers should do. And, if they play nice, the changes of registrar and dns provider can not happen at the same time. So I do not, as you understand, think discussions like these will lead to much more than maybe a list of this will happen no matter what if one have one organisation that a) is dns provider, b) is registrar, c) is not cooperating. Maybe that is a list of things you want, but I think a list of things to think of where donating organisation _is_ cooperating is much more interesting. Patrik ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
