Re: [dns-operations] rndc problems
Hi Kevin On Wed, May 27, 2015 at 04:13:55PM +0800, Kevin C. wrote: Hello, Can you tell me why this rndc run failed? # rndc reload rndc: connection to remote host closed This may indicate that * the remote server is using an older version of the command protocol, * this host is not authorized to connect, * the clocks are not synchronized, or * the key is invalid. This is a BIND specific question, which is better discussed on the bind-users@ list: https://lists.isc.org/mailman/listinfo/bind-users As the error says, it could be any of the above reasons. Look in your named log. rndc: Version: 9.7.3 named: BIND 9.7.3 This is a very old version of BIND that is unsupported and likely has several security vulnerabilities. Please upgrade to one of the current versions in the 9.10 or 9.9 branches. Mukund pgp75T8OxnNu2.pgp Description: PGP signature ___ 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] Nice to see Amazon Route 53 remove the EDNS(1) filters for *.co.uk.
Overall question. Looking at the chart on that URL, it seems like things are trending the wrong way, with the possible exception of the one well-performing bunch - the Bottom 1000 Servers [sic]. Is that right? Excepting the one bump up on May 20, it seems like things are actually trending down, not up. On 5/27/15, 6:06, Mark Andrews ma...@isc.org wrote: The jump up on May 20 was the EDNS(1) block being removed from the Amazon Route 53 *.co.uk servers. Now for the other blocks of servers to stop block EDNS(1) queries. http://ednscomp.isc.org/compliance/ts/edns1resp.html There are some TLD operators who could do the same. Mark -- 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 smime.p7s Description: S/MIME cryptographic signature ___ 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] rndc problems
Thanks for all the helps.
Now I resolved the issues.
Just add the public IP of the VPS to named.conf below, restart bind and
it works.
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; 116.251.xx.xx; } keys { rndc-key; };
};
The kernel's routing may have problems, b/c talking to localhost
(127.0.0.1:953), but bind see it's from a public IP.
Thanks.
On 2015/5/27 星期三 16:59, Edward Lewis wrote:
Try more logging (debug / higher verbosity).
I don't know what any vpn might do to a host's internal routing.
___
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] Nice to see Amazon Route 53 remove the EDNS(1) filters for *.co.uk.
The jump up on May 20 was the EDNS(1) block being removed from the Amazon Route 53 *.co.uk servers. Now for the other blocks of servers to stop block EDNS(1) queries. http://ednscomp.isc.org/compliance/ts/edns1resp.html There are some TLD operators who could do the same. Mark -- 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] EDNS vs DDOS scrubbing - was Re: Nice to see Amazon Route 53 remove the EDNS(1) filters for *.co.uk.
I'm reacting because I see a case of someone observing symptoms, presenting eye-catchy colorful pictures and then running hard into the land of diagnosis. On 5/27/15, 7:10, Mark Andrews ma...@isc.org wrote: For others is is scrubbing / DoS services which are blocking EDNS(1) queries. This sounds like there might be a need to analyze a trade-off. Taking the leap of faith that the dropping EDNS(1) figures is caused by DDoS scrubbing services, the question is why? Is EDNS(1) and DDoS scrubbing incompatible? I will offer that, from what I've seen, DDoS scrubbing seems to offer value to the Internet. I.e., I don't think that it's not simply going to go away. (I'm remaining neutral on the question of value-for-money, in the sense that's not the topic here.) I seriously doubt that DDoS scrubbing services will go away because they interrupt EDNS(1) adoption. Perhaps there isn't a conflict, it is just that the testing is throwing packets into a hole and declaring failure. Perhaps the lost EDNS(1) traffic ought to be explained away as part of the flotsam that is DDoS traffic. I'm just skeptical that a technology or mechanism will see lowered adoption over time - if it is a good idea. I understand falling adoption during the phase out/retirement/etc. You point out the new TLD operators - but it's dropping across the board (except for the bottom 1000, which might be related to those cellar-dwellers not being subject to DDoS load, hence no scrubbing). I would have expected to see a chart showing over increase in adoption with perhaps a sector that is failing and needing attention. I don't see that in the chart. smime.p7s Description: S/MIME cryptographic signature ___ 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] rndc problems
And running this also got failed. # rndc -b 127.0.0.1 -s 127.0.0.1 -p 953 reload The log shows, named[1099]: rejected command channel message from 116.251.xx.xx#49422 I am strange why the request is from a public IP? (my named running on a openvz VPS). I am sure the key token both in rndc.conf and named.conf are right. Thanks. On 2015/5/27 星期三 16:13, Kevin C. wrote: Hello, Can you tell me why this rndc run failed? # rndc reload rndc: connection to remote host closed This may indicate that * the remote server is using an older version of the command protocol, * this host is not authorized to connect, * the clocks are not synchronized, or * the key is invalid. Thanks. Their versions, rndc: Version: 9.7.3 named: BIND 9.7.3 ___ 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] EDNS vs DDOS scrubbing - was Re: Nice to see Amazon Route 53 remove the EDNS(1) filters for *.co.uk.
In message d18b2214.bc32%edward.le...@icann.org, Edward Lewis writes: I'm reacting because I see a case of someone observing symptoms, presenting eye-catchy colorful pictures and then running hard into the land of diagnosis. On 5/27/15, 7:10, Mark Andrews ma...@isc.org wrote: For others is is scrubbing / DoS services which are blocking EDNS(1) queries. This sounds like there might be a need to analyze a trade-off. Taking the leap of faith that the dropping EDNS(1) figures is caused by DDoS scrubbing services, the question is why? Is EDNS(1) and DDoS scrubbing incompatible? No. Just different query - must be bad. Different query - don't know what to do - drop from firewall vendors. Had this sort of discussion years ago with a firewall vendor. Both firewall vendors and scrubbing services don't tend to drop different rather than figuring out is it dangerous / bad. Yes, EDNS compliance issues have been traced to scrubbing services and firewalls. I've had reports from server operators using both of theses. Both can be, or should be able to be, tuned to pass EDNS(1) queries or queries with EDNS options or queries with EDNS flags. .cisco is a example of a recently added tld. https://ednscomp.isc.org/ednscomp/47bd30e419 These errors should have been caught in testing prior to adding the delegation to the root zone. dig has supported +edns=value for a decade now. +ednsflags is new. I will offer that, from what I've seen, DDoS scrubbing seems to offer value to the Internet. I.e., I don't think that it's not simply going to go away. (I'm remaining neutral on the question of value-for-money, in the sense that's not the topic here.) I seriously doubt that DDoS scrubbing services will go away because they interrupt EDNS(1) adoption. Perhaps there isn't a conflict, it is just that the testing is throwing packets into a hole and declaring failure. Perhaps the lost EDNS(1) traffic ought to be explained away as part of the flotsam that is DDoS traffic. I'm just skeptical that a technology or mechanism will see lowered adoption over time - if it is a good idea. I understand falling adoption during the phase out/retirement/etc. You point out the new TLD operators - but it's dropping across the board (except for the bottom 1000, which might be related to those cellar-dwellers not being subject to DDoS load, hence no scrubbing). I would have expected to see a chart showing over increase in adoption with perhaps a sector that is failing and needing attention. I don't see that in the chart. -- 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
Re: [dns-operations] EDNS vs DDOS scrubbing - was Re: Nice to see Amazon Route 53 remove the EDNS(1) filters for *.co.uk.
On 27 May 2015, at 19:00, Mark Andrews wrote: Yes, EDNS compliance issues have been traced to scrubbing services and firewalls. Competent DDoS scrubbing EDNS0 problems, FYI. If that's happening with some specific scrubbing service, it's because those particular organizations are Doing It Wrong. --- Roland Dobbins rdobb...@arbor.net ___ 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] EDNS vs DDOS scrubbing - was Re: Nice to see Amazon Route 53 remove the EDNS(1) filters for *.co.uk.
On 27 May 2015, at 20:24, Edward Lewis wrote: I can accept that ... but are so many doing it so wrong that the graphs are headed in the wrong direction? I don't understand the bases behind the assumption that DDoS scrubbing services are a factor in EDNS0 failure? This statement: On 27 May 2015, at 19:00, Mark Andrews wrote: Yes, EDNS compliance issues have been traced to scrubbing services and firewalls. Is something that's new to me in terms of DDoS mitigation services - I personally have never run across this issue in that context. Stateful firewalls, of course, are a well-known culprit. Perhaps some of the less clueful DDoS mitigation service operators have fallen prey to the 'drop all UDP DNS responses 512 bytes' myth? But as noted, I personally haven't run into this in the field with regards to DDoS mitigation services. Here's an example of how I try to propagandize against this kind of thing, FWIW (see p.156): https://app.box.com/s/r7an1moswtc7ce58f8gg --- Roland Dobbins rdobb...@arbor.net ___ 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] Nice to see Amazon Route 53 remove the EDNS(1) filters for *.co.uk.
In message d18b1404.bc26%edward.le...@icann.org, Edward Lewis writes: Overall question. Looking at the chart on that URL, it seems like things are trending the wrong way, with the possible exception of the one well-performing bunch - the Bottom 1000 Servers [sic]. Is that right? Excepting the one bump up on May 20, it seems like things are actually trending down, not up. For the TLD's it is new TLD's coming on line with EDNS blocks in place. It isn't existing TLD's enabling blocks. ICANN should be testing and blocking the deployment until these blocks are removed. For others is is scrubbing / DoS services which are blocking EDNS(1) queries. Blocking EDNS(1) queries is pointless. They don't do harm. You can test your servers EDNS compliance here: https://ednscomp.isc.org/ednscomp/ Mark On 5/27/15, 6:06, Mark Andrews ma...@isc.org wrote: The jump up on May 20 was the EDNS(1) block being removed from the Amazon Route 53 *.co.uk servers. Now for the other blocks of servers to stop block EDNS(1) queries. http://ednscomp.isc.org/compliance/ts/edns1resp.html There are some TLD operators who could do the same. Mark -- 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 --B_3515552937_19685792 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS 4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1 IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3 kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC 4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8 MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw JAYIKwYBBQUHMAh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0 cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70 ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m 4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16 CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j
Re: [dns-operations] EDNS vs DDOS scrubbing - was Re: Nice to see Amazon Route 53 remove the EDNS(1) filters for *.co.uk.
On 5/27/15, 9:09, Roland Dobbins rdobb...@arbor.net wrote: On 27 May 2015, at 19:00, Mark Andrews wrote: Yes, EDNS compliance issues have been traced to scrubbing services and firewalls. Competent DDoS scrubbing EDNS0 problems, FYI. If that's happening with some specific scrubbing service, it's because those particular organizations are Doing It Wrong. I can accept that ... but are so many doing it so wrong that the graphs are headed in the wrong direction? (Asking in the sense : what's the right way to reverse the apparent trend? I say apparent because it might be the measurement that is faulty. -- Jes'sayin'. IOW - a starting question: is there really a problem?) smime.p7s Description: S/MIME cryptographic signature ___ 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] EDNS vs DDOS scrubbing - was Re: Nice to see Amazon Route 53 remove the EDNS(1) filters for *.co.uk.
On 27 May 2015, at 13:00, Mark Andrews wrote: No. Just different query - must be bad. Different query - don't know what to do - drop from firewall vendors. For an enterprise, given that there's no defined use, format (and therefore need) for EDNS(1), if your security posture is default deny, accept what we know we need then dropping DNS messages with EDNS(1) seems like exactly the right thing to do, doesn't it? I understand the point that this posture makes future development and deployment of EDNS(1) hard. I understand why that's a pain for protocol development in the DNS. You don't have to explain either of those things to me. (Just saying.) But it's not like anybody is going to succeed in getting an enterprise or their firewall vendor to say yes when the request they are hearing is can you please open up this hole for an experimental protocol that nobody apart from me knows anything about, so that I can play with it. Remember, these are the people that think ICMP is a security risk. Joe ___ 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] EDNS vs DDOS scrubbing - was Re: Nice to see Amazon Route 53 remove the EDNS(1) filters for *.co.uk.
On 27 May 2015, at 20:39, Roland Dobbins wrote: I don't understand the bases behind the assumption that DDoS scrubbing services are a factor in EDNS0 failure? doh, it was pointed out to me that we're talking about EDNS(1), not EDNS0. Apologies for my confusion. I haven't seen any issues with this in terms of DDoS mitigation services, either. Any pointers to specific anecdotes, on-list or off-list, would be helpful, so I can try and track this down and see if there's some kind of systemic problem. --- Roland Dobbins rdobb...@arbor.net ___ 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] Lack of tlsa support
On Wed, May 27, 2015 at 1:32 PM, Joe Abley jab...@hopcount.ca wrote:
On 27 May 2015, at 16:16, Mark Andrews wrote:
Do we really have to fight to get every new type supported?
Mark
marka@ednscomp ~/tld-report]$ awk '$4 == NS {print $1, $5}' root.db | sh
gentypereport tlsa | grep -v all ok
accountant. @156.154.144.195 (ns1.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.145.195 (ns2.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.159.195 (ns3.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.156.195 (ns4.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.157.195 (ns5.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.158.195 (ns6.dns.nic.accountant.): tlsa=timeout
It's hard to know what you're testing (what gentypereport does), but if
you're looking for TLSA records in the ACCOUNTANT zone above, I'm not sure
why; new gTLD operators are constrained by contract as to the RRTypes
they're allowed to publish, and TLSA isn't one of them. It's not obvious
that this is a problem for anybody, though; it's not like you'd expect to
see a TLSA RRSet in there.
What is the point you're making?
I think that point is that a timeout is not the right response.
For what it's worth, I have no problem getting a reasonable (negative)
response to ACCOUNTANT/IN/TLSA or SOMETHING.ACCOUNTANT/IN/TLSA from
156.154.144.195 with EDNS0.DO=1 or without EDNS0. Perhaps I'm special :-)
Unable to parse. Are you saying that you *are* getting a reasonable
(negative) response to ACCOUNTANT/IN/TLSA? Or that you would be OK
getting on if that is what they decided to send you?
I get:
dig TLSA accountant @156.154.144.195
; DiG 9.8.3-P1 TLSA accountant @156.154.144.195
;; global options: +cmd
;; connection timed out; no servers could be reached
Same thing for TYPE67 (unassigned):
dig TYPE67 accountant @156.154.144.195
; DiG 9.8.3-P1 TYPE67 accountant @156.154.144.195
;; global options: +cmd
;; connection timed out; no servers could be reached
NoERROR/NODATA (yes please), REFUSED, NOTIMP, etc are all better than
just not answering (which means the recursive and stub / app both hang
around burning state).
W
Joe
___
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
--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf
___
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] Lack of tlsa support
On 27 May 2015, at 19:14, Warren Kumari wrote: For what it's worth, I have no problem getting a reasonable (negative) response to ACCOUNTANT/IN/TLSA or SOMETHING.ACCOUNTANT/IN/TLSA from 156.154.144.195 with EDNS0.DO=1 or without EDNS0. Perhaps I'm special :-) Unable to parse. Unsure why. :-) Are you saying that you *are* getting a reasonable (negative) response to ACCOUNTANT/IN/TLSA? Yes. And also to SOMETHING.ACCOUNTANT, both with EDNS0.DO=1 and with no EDNS0 (see above). Joe ___ 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] Lack of tlsa support
Do we really have to fight to get every new type supported?
Mark
marka@ednscomp ~/tld-report]$ awk '$4 == NS {print $1, $5}' root.db | sh
gentypereport tlsa | grep -v all ok
accountant. @156.154.144.195 (ns1.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.145.195 (ns2.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.159.195 (ns3.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.156.195 (ns4.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.157.195 (ns5.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.158.195 (ns6.dns.nic.accountant.): tlsa=timeout
aig. @156.154.144.6 (ns1.dns.nic.aig.): tlsa=timeout
aig. @156.154.145.6 (ns2.dns.nic.aig.): tlsa=timeout
aig. @156.154.159.6 (ns3.dns.nic.aig.): tlsa=timeout
aig. @156.154.156.6 (ns4.dns.nic.aig.): tlsa=timeout
aig. @156.154.157.6 (ns5.dns.nic.aig.): tlsa=timeout
aig. @156.154.158.6 (ns6.dns.nic.aig.): tlsa=timeout
al. @194.119.192.8 (ns-al.isti.cnr.it.): tlsa=timeout
an. @65.174.238.100 (engine2.una.an.): tlsa=timeout
an. @200.26.199.102 (engine3.una.an.): tlsa=timeout
ao. @2c0f:f828:2::b (ns02.dns.ao.): tlsa=timeout
ar. @2801:140::10 (a.dns.ar.): tlsa=timeout
as. @204.74.112.1 (tld1.ultradns.net.): tlsa=timeout
as. @204.74.113.1 (tld2.ultradns.net.): tlsa=timeout
as. @199.7.66.1 (tld3.ultradns.org.): tlsa=timeout
as. @199.7.67.1 (tld4.ultradns.org.): tlsa=timeout
as. @192.100.59.11 (tld5.ultradns.info.): tlsa=timeout
as. @198.133.199.11 (tld6.ultradns.co.uk.): tlsa=timeout
axa. @156.154.144.20 (ns1.dns.nic.axa.): tlsa=timeout
axa. @156.154.145.20 (ns2.dns.nic.axa.): tlsa=timeout
axa. @156.154.159.20 (ns3.dns.nic.axa.): tlsa=timeout
axa. @156.154.156.20 (ns4.dns.nic.axa.): tlsa=timeout
axa. @156.154.157.20 (ns5.dns.nic.axa.): tlsa=timeout
axa. @156.154.158.20 (ns6.dns.nic.axa.): tlsa=timeout
best. @156.154.144.24 (ns1.dns.nic.best.): tlsa=timeout
best. @156.154.145.24 (ns2.dns.nic.best.): tlsa=timeout
best. @156.154.159.24 (ns3.dns.nic.best.): tlsa=timeout
best. @156.154.156.24 (ns4.dns.nic.best.): tlsa=timeout
best. @156.154.157.24 (ns5.dns.nic.best.): tlsa=timeout
best. @156.154.158.24 (ns6.dns.nic.best.): tlsa=timeout
bf. @193.50.53.3 (ns1.ird.fr.): tlsa=timeout
bf. @2001:5a0:d00:::42c6:9163 (ns2.as6453.net.): tlsa=timeout
bf. @66.198.145.99 (ns2.as6453.net.): tlsa=timeout
bid. @156.154.144.25 (ns1.dns.nic.bid.): tlsa=timeout
bid. @156.154.145.25 (ns2.dns.nic.bid.): tlsa=timeout
bid. @156.154.159.25 (ns3.dns.nic.bid.): tlsa=timeout
bid. @156.154.156.25 (ns4.dns.nic.bid.): tlsa=timeout
bid. @156.154.157.25 (ns5.dns.nic.bid.): tlsa=timeout
bid. @156.154.158.25 (ns6.dns.nic.bid.): tlsa=timeout
biz. @156.154.124.65 (a.gtld.biz.): tlsa=timeout
biz. @156.154.125.65 (b.gtld.biz.): tlsa=timeout
biz. @156.154.127.65 (c.gtld.biz.): tlsa=timeout
biz. @156.154.126.65 (e.gtld.biz.): tlsa=timeout
biz. @209.173.58.66 (f.gtld.biz.): tlsa=timeout
biz. @156.154.128.65 (k.gtld.biz.): tlsa=timeout
bm. @206.53.190.202 (ns1.bm.): tlsa=timeout
bm. @69.17.194.1 (ns2.bm.): tlsa=timeout
bt. @2405:d000:0:100::200 (ns1.druknet.bt.): tlsa=timeout
buzz. @156.154.144.29 (ns1.dns.nic.buzz.): tlsa=timeout
buzz. @156.154.145.29 (ns2.dns.nic.buzz.): tlsa=timeout
buzz. @156.154.159.29 (ns3.dns.nic.buzz.): tlsa=timeout
buzz. @156.154.156.29 (ns4.dns.nic.buzz.): tlsa=timeout
buzz. @156.154.157.29 (ns5.dns.nic.buzz.): tlsa=timeout
buzz. @156.154.158.29 (ns6.dns.nic.buzz.): tlsa=timeout
bw. @2c0f:ff00:0:4::2 (ns1.btc.bw.): tlsa=timeout
caravan. @156.154.144.32 (ns1.dns.nic.caravan.): tlsa=timeout
caravan. @156.154.145.32 (ns2.dns.nic.caravan.): tlsa=timeout
caravan. @156.154.159.32 (ns3.dns.nic.caravan.): tlsa=timeout
caravan. @156.154.156.32 (ns4.dns.nic.caravan.): tlsa=timeout
caravan. @156.154.157.32 (ns5.dns.nic.caravan.): tlsa=timeout
caravan. @156.154.158.32 (ns6.dns.nic.caravan.): tlsa=timeout
cartier. @156.154.144.34 (ns1.dns.nic.cartier.): tlsa=timeout
cartier. @156.154.145.34 (ns2.dns.nic.cartier.): tlsa=timeout
cartier. @156.154.159.34 (ns3.dns.nic.cartier.): tlsa=timeout
cartier. @156.154.156.34 (ns4.dns.nic.cartier.): tlsa=timeout
cartier. @156.154.157.34 (ns5.dns.nic.cartier.): tlsa=timeout
cartier. @156.154.158.34 (ns6.dns.nic.cartier.): tlsa=timeout
cbn. @156.154.144.35 (ns1.dns.nic.cbn.): tlsa=timeout
cbn. @156.154.145.35 (ns2.dns.nic.cbn.): tlsa=timeout
cbn. @156.154.159.35 (ns3.dns.nic.cbn.): tlsa=timeout
cbn. @156.154.156.35 (ns4.dns.nic.cbn.): tlsa=timeout
cbn. @156.154.157.35 (ns5.dns.nic.cbn.): tlsa=timeout
cbn. @156.154.158.35 (ns6.dns.nic.cbn.): tlsa=timeout
ceo. @156.154.144.37 (ns1.dns.nic.ceo.): tlsa=timeout
ceo. @156.154.145.37 (ns2.dns.nic.ceo.): tlsa=timeout
ceo. @156.154.159.37 (ns3.dns.nic.ceo.): tlsa=timeout
ceo. @156.154.156.37 (ns4.dns.nic.ceo.): tlsa=timeout
--
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
Re: [dns-operations] EDNS vs DDOS scrubbing - was Re: Nice to see Amazon Route 53 remove the EDNS(1) filters for *.co.uk.
In message 22b1aa19-3a88-401d-bcae-0ebce2332...@arbor.net, Roland Dobbins writes: On 27 May 2015, at 19:00, Mark Andrews wrote: Yes, EDNS compliance issues have been traced to scrubbing services and firewalls. Competent DDoS scrubbing EDNS0 problems, FYI. If that's happening with some specific scrubbing service, it's because those particular organizations are Doing It Wrong. I agree with you, which is why I said the rules can be changed. At least one scrubbing service was dropping queries based on EDNS extension use in the query within the last month or so based on the feedback on reporting a problem with a DNS server. Mark --- Roland Dobbins rdobb...@arbor.net ___ 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
Re: [dns-operations] Lack of tlsa support
Absolutely.
The technology is the easy bit. Deployment is the hard problem.
We are trying to make changes to a machine with ten billion components.
Every single one of which is more complex than the most complex machine
built before the moon landings and some of which are the product of more
human intellectual activity than the sum of all human thought prior to that
date.
Don't expect changing the Internet to be easy, it isn't.
On Wed, May 27, 2015 at 11:16 AM, Mark Andrews ma...@isc.org wrote:
Do we really have to fight to get every new type supported?
Mark
marka@ednscomp ~/tld-report]$ awk '$4 == NS {print $1, $5}' root.db |
sh gentypereport tlsa | grep -v all ok
accountant. @156.154.144.195 (ns1.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.145.195 (ns2.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.159.195 (ns3.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.156.195 (ns4.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.157.195 (ns5.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.158.195 (ns6.dns.nic.accountant.): tlsa=timeout
aig. @156.154.144.6 (ns1.dns.nic.aig.): tlsa=timeout
aig. @156.154.145.6 (ns2.dns.nic.aig.): tlsa=timeout
aig. @156.154.159.6 (ns3.dns.nic.aig.): tlsa=timeout
aig. @156.154.156.6 (ns4.dns.nic.aig.): tlsa=timeout
aig. @156.154.157.6 (ns5.dns.nic.aig.): tlsa=timeout
aig. @156.154.158.6 (ns6.dns.nic.aig.): tlsa=timeout
al. @194.119.192.8 (ns-al.isti.cnr.it.): tlsa=timeout
an. @65.174.238.100 (engine2.una.an.): tlsa=timeout
an. @200.26.199.102 (engine3.una.an.): tlsa=timeout
ao. @2c0f:f828:2::b (ns02.dns.ao.): tlsa=timeout
ar. @2801:140::10 (a.dns.ar.): tlsa=timeout
as. @204.74.112.1 (tld1.ultradns.net.): tlsa=timeout
as. @204.74.113.1 (tld2.ultradns.net.): tlsa=timeout
as. @199.7.66.1 (tld3.ultradns.org.): tlsa=timeout
as. @199.7.67.1 (tld4.ultradns.org.): tlsa=timeout
as. @192.100.59.11 (tld5.ultradns.info.): tlsa=timeout
as. @198.133.199.11 (tld6.ultradns.co.uk.): tlsa=timeout
axa. @156.154.144.20 (ns1.dns.nic.axa.): tlsa=timeout
axa. @156.154.145.20 (ns2.dns.nic.axa.): tlsa=timeout
axa. @156.154.159.20 (ns3.dns.nic.axa.): tlsa=timeout
axa. @156.154.156.20 (ns4.dns.nic.axa.): tlsa=timeout
axa. @156.154.157.20 (ns5.dns.nic.axa.): tlsa=timeout
axa. @156.154.158.20 (ns6.dns.nic.axa.): tlsa=timeout
best. @156.154.144.24 (ns1.dns.nic.best.): tlsa=timeout
best. @156.154.145.24 (ns2.dns.nic.best.): tlsa=timeout
best. @156.154.159.24 (ns3.dns.nic.best.): tlsa=timeout
best. @156.154.156.24 (ns4.dns.nic.best.): tlsa=timeout
best. @156.154.157.24 (ns5.dns.nic.best.): tlsa=timeout
best. @156.154.158.24 (ns6.dns.nic.best.): tlsa=timeout
bf. @193.50.53.3 (ns1.ird.fr.): tlsa=timeout
bf. @2001:5a0:d00:::42c6:9163 (ns2.as6453.net.): tlsa=timeout
bf. @66.198.145.99 (ns2.as6453.net.): tlsa=timeout
bid. @156.154.144.25 (ns1.dns.nic.bid.): tlsa=timeout
bid. @156.154.145.25 (ns2.dns.nic.bid.): tlsa=timeout
bid. @156.154.159.25 (ns3.dns.nic.bid.): tlsa=timeout
bid. @156.154.156.25 (ns4.dns.nic.bid.): tlsa=timeout
bid. @156.154.157.25 (ns5.dns.nic.bid.): tlsa=timeout
bid. @156.154.158.25 (ns6.dns.nic.bid.): tlsa=timeout
biz. @156.154.124.65 (a.gtld.biz.): tlsa=timeout
biz. @156.154.125.65 (b.gtld.biz.): tlsa=timeout
biz. @156.154.127.65 (c.gtld.biz.): tlsa=timeout
biz. @156.154.126.65 (e.gtld.biz.): tlsa=timeout
biz. @209.173.58.66 (f.gtld.biz.): tlsa=timeout
biz. @156.154.128.65 (k.gtld.biz.): tlsa=timeout
bm. @206.53.190.202 (ns1.bm.): tlsa=timeout
bm. @69.17.194.1 (ns2.bm.): tlsa=timeout
bt. @2405:d000:0:100::200 (ns1.druknet.bt.): tlsa=timeout
buzz. @156.154.144.29 (ns1.dns.nic.buzz.): tlsa=timeout
buzz. @156.154.145.29 (ns2.dns.nic.buzz.): tlsa=timeout
buzz. @156.154.159.29 (ns3.dns.nic.buzz.): tlsa=timeout
buzz. @156.154.156.29 (ns4.dns.nic.buzz.): tlsa=timeout
buzz. @156.154.157.29 (ns5.dns.nic.buzz.): tlsa=timeout
buzz. @156.154.158.29 (ns6.dns.nic.buzz.): tlsa=timeout
bw. @2c0f:ff00:0:4::2 (ns1.btc.bw.): tlsa=timeout
caravan. @156.154.144.32 (ns1.dns.nic.caravan.): tlsa=timeout
caravan. @156.154.145.32 (ns2.dns.nic.caravan.): tlsa=timeout
caravan. @156.154.159.32 (ns3.dns.nic.caravan.): tlsa=timeout
caravan. @156.154.156.32 (ns4.dns.nic.caravan.): tlsa=timeout
caravan. @156.154.157.32 (ns5.dns.nic.caravan.): tlsa=timeout
caravan. @156.154.158.32 (ns6.dns.nic.caravan.): tlsa=timeout
cartier. @156.154.144.34 (ns1.dns.nic.cartier.): tlsa=timeout
cartier. @156.154.145.34 (ns2.dns.nic.cartier.): tlsa=timeout
cartier. @156.154.159.34 (ns3.dns.nic.cartier.): tlsa=timeout
cartier. @156.154.156.34 (ns4.dns.nic.cartier.): tlsa=timeout
cartier. @156.154.157.34 (ns5.dns.nic.cartier.): tlsa=timeout
cartier. @156.154.158.34 (ns6.dns.nic.cartier.): tlsa=timeout
cbn. @156.154.144.35 (ns1.dns.nic.cbn.): tlsa=timeout
cbn. @156.154.145.35 (ns2.dns.nic.cbn.): tlsa=timeout
cbn. @156.154.159.35 (ns3.dns.nic.cbn.): tlsa=timeout
cbn. @156.154.156.35 (ns4.dns.nic.cbn.): tlsa=timeout
Re: [dns-operations] Lack of tlsa support
On May 27, 2015, at 6:16 PM, Mark Andrews ma...@isc.org wrote: Do we really have to fight to get every new type supported? Is this a trick question? The Empirical Evidence 8-ball would appear to say Yes. Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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] Lack of tlsa support
On 27 May 2015, at 16:16, Mark Andrews wrote:
Do we really have to fight to get every new type supported?
Mark
marka@ednscomp ~/tld-report]$ awk '$4 == NS {print $1, $5}' root.db
| sh gentypereport tlsa | grep -v all ok
accountant. @156.154.144.195 (ns1.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.145.195 (ns2.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.159.195 (ns3.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.156.195 (ns4.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.157.195 (ns5.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.158.195 (ns6.dns.nic.accountant.): tlsa=timeout
It's hard to know what you're testing (what gentypereport does), but if
you're looking for TLSA records in the ACCOUNTANT zone above, I'm not
sure why; new gTLD operators are constrained by contract as to the
RRTypes they're allowed to publish, and TLSA isn't one of them. It's not
obvious that this is a problem for anybody, though; it's not like you'd
expect to see a TLSA RRSet in there.
What is the point you're making?
For what it's worth, I have no problem getting a reasonable (negative)
response to ACCOUNTANT/IN/TLSA or SOMETHING.ACCOUNTANT/IN/TLSA from
156.154.144.195 with EDNS0.DO=1 or without EDNS0. Perhaps I'm special
:-)
Joe
___
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] Lack of tlsa support
On Wed, May 27, 2015 at 3:02 PM, Joe Abley jab...@hopcount.ca wrote: On 27 May 2015, at 19:14, Warren Kumari wrote: For what it's worth, I have no problem getting a reasonable (negative) response to ACCOUNTANT/IN/TLSA or SOMETHING.ACCOUNTANT/IN/TLSA from 156.154.144.195 with EDNS0.DO=1 or without EDNS0. Perhaps I'm special :-) Yah, /I/ know you are special -- but I don't know how 156.154.144.195 knows you are. Can you include a dig (or similar) showing you asking the question and getting an answer (not a timeout?). I've queried from multiple places with no love... W Unable to parse. Unsure why. :-) Are you saying that you *are* getting a reasonable (negative) response to ACCOUNTANT/IN/TLSA? Yes. And also to SOMETHING.ACCOUNTANT, both with EDNS0.DO=1 and with no EDNS0 (see above). Joe -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ 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] Lack of tlsa support
On Wed, May 27, 2015 at 3:40 PM, Warren Kumari war...@kumari.net wrote: On Wed, May 27, 2015 at 3:02 PM, Joe Abley jab...@hopcount.ca wrote: On 27 May 2015, at 19:14, Warren Kumari wrote: For what it's worth, I have no problem getting a reasonable (negative) response to ACCOUNTANT/IN/TLSA or SOMETHING.ACCOUNTANT/IN/TLSA from 156.154.144.195 with EDNS0.DO=1 or without EDNS0. Perhaps I'm special :-) Yah, /I/ know you are special -- but I don't know how 156.154.144.195 knows you are. Can you include a dig (or similar) showing you asking the question and getting an answer (not a timeout?). I've queried from multiple places with no love... W Here's a transcript of my attempt to query all the NS addresses at accountant for TLSA records (from one location, a datacenter in New Jersey). Quick summary: no response/timeout from all the IPv4 addresses, correct NODATA answers from all the IPv6 addresses. Hmm (and no, the machine originating the queries has working IPv4 and can query other records successfully): $ get-ns-ip accountant. ns1.dns.nic.accountant. 156.154.144.195 ns1.dns.nic.accountant. 2610:a1:1071::c3 ns2.dns.nic.accountant. 156.154.145.195 ns2.dns.nic.accountant. 2610:a1:1072::c3 ns3.dns.nic.accountant. 156.154.159.195 ns3.dns.nic.accountant. 2610:a1:1073::c3 ns4.dns.nic.accountant. 156.154.156.195 ns4.dns.nic.accountant. 2610:a1:1074::c3 ns5.dns.nic.accountant. 156.154.157.195 ns5.dns.nic.accountant. 2610:a1:1075::c3 ns6.dns.nic.accountant. 156.154.158.195 ns6.dns.nic.accountant. 2610:a1:1076::c3 $ get-ns-ip accountant. | while read hostname ip do echo $hostname $ip dig @$ip _443._tcp.accountant. TLSA echo done ns1.dns.nic.accountant. 156.154.144.195 ; DiG 9.10.1 @156.154.144.195 _443._tcp.accountant. TLSA ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached ns1.dns.nic.accountant. 2610:a1:1071::c3 ; DiG 9.10.1 @2610:a1:1071::c3 _443._tcp.accountant. TLSA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 45660 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;_443._tcp.accountant. IN TLSA ;; AUTHORITY SECTION: accountant. 7200 IN SOA ns1.dns.nic.accountant. hostmaster.neustar.biz. 189 900 900 604800 86400 ;; Query time: 8 msec ;; SERVER: 2610:a1:1071::c3#53(2610:a1:1071::c3) ;; WHEN: Wed May 27 15:50:11 EDT 2015 ;; MSG SIZE rcvd: 108 ns2.dns.nic.accountant. 156.154.145.195 ; DiG 9.10.1 @156.154.145.195 _443._tcp.accountant. TLSA ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached ns2.dns.nic.accountant. 2610:a1:1072::c3 ; DiG 9.10.1 @2610:a1:1072::c3 _443._tcp.accountant. TLSA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 8407 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;_443._tcp.accountant. IN TLSA ;; AUTHORITY SECTION: accountant. 7200 IN SOA ns1.dns.nic.accountant. hostmaster.neustar.biz. 189 900 900 604800 86400 ;; Query time: 79 msec ;; SERVER: 2610:a1:1072::c3#53(2610:a1:1072::c3) ;; WHEN: Wed May 27 15:50:27 EDT 2015 ;; MSG SIZE rcvd: 108 ns3.dns.nic.accountant. 156.154.159.195 ; DiG 9.10.1 @156.154.159.195 _443._tcp.accountant. TLSA ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached ns3.dns.nic.accountant. 2610:a1:1073::c3 ; DiG 9.10.1 @2610:a1:1073::c3 _443._tcp.accountant. TLSA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 46624 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;_443._tcp.accountant. IN TLSA ;; AUTHORITY SECTION: accountant. 7200 IN SOA ns1.dns.nic.accountant. hostmaster.neustar.biz. 189 900 900 604800 86400 ;; Query time: 8 msec ;; SERVER: 2610:a1:1073::c3#53(2610:a1:1073::c3) ;; WHEN: Wed May 27 15:50:42 EDT 2015 ;; MSG SIZE rcvd: 108 ns4.dns.nic.accountant. 156.154.156.195 ; DiG 9.10.1 @156.154.156.195 _443._tcp.accountant. TLSA ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached ns4.dns.nic.accountant. 2610:a1:1074::c3 ; DiG 9.10.1 @2610:a1:1074::c3 _443._tcp.accountant. TLSA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 21156 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;_443._tcp.accountant. IN TLSA ;; AUTHORITY SECTION: accountant. 7200 IN SOA ns1.dns.nic.accountant. hostmaster.neustar.biz. 189 900 900 604800 86400 ;; Query time: 8 msec ;; SERVER: 2610:a1:1074::c3#53(2610:a1:1074::c3) ;; WHEN:
Re: [dns-operations] Lack of tlsa support
On Wed, May 27, 2015 at 3:59 PM, Shumon Huque shu...@gmail.com wrote: Here's a transcript of my attempt to query all the NS addresses at accountant for TLSA records (from one location, a datacenter in New Jersey). Quick summary: no response/timeout from all the IPv4 addresses, correct NODATA answers from all the IPv6 addresses. Hmm (and no, the machine originating the queries has working IPv4 and can query other records successfully): Actually, I was wondering why those answers are NODATA rather than NXDOMAIN since presumably there aren't other record types at the name I queried. It looks like this is because this zone is in the controlled interruption mode (it has a wildcard at the apex for A, MX, etc). Shumon Huque. ___ 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] Lack of tlsa support
In message a5f5f06b-a4bd-4df5-9381-8f25b6677...@hopcount.ca, Joe Abley writ
es:
On 27 May 2015, at 16:16, Mark Andrews wrote:
Do we really have to fight to get every new type supported?
Mark
marka@ednscomp ~/tld-report]$ awk '$4 == NS {print $1, $5}' root.db
| sh gentypereport tlsa | grep -v all ok
accountant. @156.154.144.195 (ns1.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.145.195 (ns2.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.159.195 (ns3.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.156.195 (ns4.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.157.195 (ns5.dns.nic.accountant.): tlsa=timeout
accountant. @156.154.158.195 (ns6.dns.nic.accountant.): tlsa=timeout
It's hard to know what you're testing (what gentypereport does), but if
you're looking for TLSA records in the ACCOUNTANT zone above, I'm not
sure why; new gTLD operators are constrained by contract as to the
RRTypes they're allowed to publish, and TLSA isn't one of them. It's not
obvious that this is a problem for anybody, though; it's not like you'd
expect to see a TLSA RRSet in there.
genreport tests non meta types including a unknown type (below) and
checks the rcode returned. For a name that exists the rcode should
be NOERROR. You can also specify the type list on the command line
which is what I did for tlsa.
The next step for this will be to test subsets of Alexa zones so
we can get a more general picture of the state of type support.
Why one would treat CDS differently to CDNSKEY I don't know. It
doesn't make sense from a protocol perspective.
typelist=${typelist:-A NS MD MF CNAME SOA MB MG MR NULL WKS PTR HINFO MINFO MX
TXT RP AFSDB X25 ISDN RT NSAP NSAP-PTR SIG KEY PX GPOS LOC NXT SRV NAPTR
KX CERT A6 DNAME APL DS SSHFP IPSECKEY RRSIG NSEC DNSKEY DHCID NSEC3 NSEC3PARAM
TLSA HIP CDS CDNSKEY OPENPGPKEY SPF NID L32 L64 LP EUI48 EUI64 URI CAA DLV
TYPE666}
[marka@ednscomp ~/tld-report]$ grep accountant root.db | awk '$4 == NS {
print $1, $5}' | sh gentypereport
accountant. @156.154.144.195 (ns1.dns.nic.accountant.): MD=timeout MF=timeout
NXT=timeout TLSA=timeout CDS=timeout CDNSKEY=timeout OPENPGPKEY=timeout
NID=timeout L32=timeout L64=timeout LP=timeout EUI48=timeout EUI64=timeout
URI=timeout CAA=timeout TYPE666=timeout
accountant. @2610:a1:1071::c3 (ns1.dns.nic.accountant.): all ok
accountant. @156.154.145.195 (ns2.dns.nic.accountant.): MD=timeout MF=timeout
NXT=timeout TLSA=timeout CDS=timeout CDNSKEY=timeout OPENPGPKEY=timeout
NID=timeout L32=timeout L64=timeout LP=timeout EUI48=timeout EUI64=timeout
URI=timeout CAA=timeout TYPE666=timeout
accountant. @2610:a1:1072::c3 (ns2.dns.nic.accountant.): all ok
accountant. @156.154.159.195 (ns3.dns.nic.accountant.): MD=timeout MF=timeout
NXT=timeout TLSA=timeout CDS=timeout CDNSKEY=timeout OPENPGPKEY=timeout
NID=timeout L32=timeout L64=timeout LP=timeout EUI48=timeout EUI64=timeout
URI=timeout CAA=timeout TYPE666=timeout
accountant. @2610:a1:1073::c3 (ns3.dns.nic.accountant.): all ok
accountant. @156.154.156.195 (ns4.dns.nic.accountant.): MD=timeout MF=timeout
NXT=timeout TLSA=timeout CDS=timeout CDNSKEY=timeout OPENPGPKEY=timeout
NID=timeout L32=timeout L64=timeout LP=timeout EUI48=timeout EUI64=timeout
URI=timeout CAA=timeout TYPE666=timeout
accountant. @2610:a1:1074::c3 (ns4.dns.nic.accountant.): all ok
accountant. @156.154.157.195 (ns5.dns.nic.accountant.): MD=timeout MF=timeout
NXT=timeout TLSA=timeout CDS=timeout CDNSKEY=timeout OPENPGPKEY=timeout
NID=timeout L32=timeout L64=timeout LP=timeout EUI48=timeout EUI64=timeout
URI=timeout CAA=timeout TYPE666=timeout
accountant. @2610:a1:1075::c3 (ns5.dns.nic.accountant.): all ok
accountant. @156.154.158.195 (ns6.dns.nic.accountant.): MD=timeout MF=timeout
NXT=timeout TLSA=timeout CDS=timeout CDNSKEY=timeout OPENPGPKEY=timeout
NID=timeout L32=timeout L64=timeout LP=timeout EUI48=timeout EUI64=timeout
URI=timeout CAA=timeout TYPE666=timeout
accountant. @2610:a1:1076::c3 (ns6.dns.nic.accountant.): all ok
accountants. @2001:dcd:2::7 (demand.beta.aridns.net.au.): CDS=refused
accountants. @37.209.194.7 (demand.beta.aridns.net.au.): CDS=refused
accountants. @2001:dcd:1::7 (demand.alpha.aridns.net.au.): CDS=refused
accountants. @37.209.192.7 (demand.alpha.aridns.net.au.): CDS=refused
accountants. @2001:dcd:4::7 (demand.delta.aridns.net.au.): CDS=refused
accountants. @37.209.198.7 (demand.delta.aridns.net.au.): CDS=refused
accountants. @2001:dcd:3::7 (demand.gamma.aridns.net.au.): CDS=refused
accountants. @37.209.196.7 (demand.gamma.aridns.net.au.): CDS=refused
[marka@ednscomp ~/tld-report]$
What is the point you're making?
We have ICANN checking query rates and uptimes but not protocol
basics (like answering all non meta query types) prior to letting
new TLDs go live.
We have TLD operators all of whom have invested lots of money to
get to a TLD who have not done basic testing of the servers /
firewalls.
We have a attitude
Re: [dns-operations] EDNS vs DDOS scrubbing - was Re: Nice to see Amazon Route 53 remove the EDNS(1) filters for *.co.uk.
In message ad0f3c7e-72d4-4786-af6c-1bf9cbaf8...@hopcount.ca, Joe Abley writ es: On 27 May 2015, at 13:00, Mark Andrews wrote: No. Just different query - must be bad. Different query - don't know what to do - drop from firewall vendors. For an enterprise, given that there's no defined use, format (and therefore need) for EDNS(1), if your security posture is default deny, accept what we know we need then dropping DNS messages with EDNS(1) seems like exactly the right thing to do, doesn't it? TLD operators are there to provide a service to the public and to the delegated zone. Part of that service is a expectation that they will properly implement the protocol. Or you can educate firewall vendors that it really does hurt their customers when you block extension mechanisms. It makes life hard for their customer's customers. Nameservers do handle the extensions even if not always correctly (formerr rather than ignore or ignore rather than badvers depending upon the extension) so it is most a case of blocking just because they can rather than because it is protecting anything. Nameservers don't fallover these days, 20 years ago some did. I understand the point that this posture makes future development and deployment of EDNS(1) hard. I understand why that's a pain for protocol development in the DNS. You don't have to explain either of those things to me. (Just saying.) But it's not like anybody is going to succeed in getting an enterprise or their firewall vendor to say yes when the request they are hearing is can you please open up this hole for an experimental protocol that nobody apart from me knows anything about, so that I can play with it. No. It's tell me nicely that you don't support the extension. Dropping packets is just plain anti-social and always has been. A firewall can generate a BADVERS response, just like it can generate a TCP RST. You don't have to break the protocol, you can co-operate with the protocol. Remember, these are the people that think ICMP is a security risk. Joe -- 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
Re: [dns-operations] Lack of tlsa support
On May 27, 2015, at 10:32 AM, Joe Abley jab...@hopcount.ca wrote: It's not obvious that this is a problem for anybody, though; it's not like you'd expect to see a TLSA RRSet in there. Isn't this truly a problem because if my cache is cold (for the zone in question) my recursive name server could send it a query for _443._tcp.www.example.accountant. TLSA (to keep picking on them) which would then just timeout? DW smime.p7s Description: S/MIME cryptographic signature ___ 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] Lack of tlsa support
In message 0cff2137-a8b7-44bb-a2a7-6bd3cd0db...@verisign.com, Wessels, Duane writes: On May 27, 2015, at 10:32 AM, Joe Abley jab...@hopcount.ca wrote: It's not obvious that this is a problem for anybody, though; it's not like you'd expect to see a TLSA RRSet in there. Isn't this truly a problem because if my cache is cold (for the zone in question) my recursive name server could send it a query for _443._tcp.www.example.accountant. TLSA (to keep picking on them) which would then just timeout? Yes and you never know when a resolver will go back to a TLD to get a referral. DW -- 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
