Kevin C. | 24 May 14:47 2015

about resolveip command

Hello,

Do you know what's the special usage for resolveip command?
I saw it's not similiar to dig tool. for instance,

~$ dig www.sina.com.cn +short
jupiter.sina.com.cn.
ara.sina.com.cn.
121.14.1.190
58.63.236.248
121.14.1.189

~$ resolveip -s www.sina.com.cn
121.14.1.190

dig returns all three IPs, but resolveip returns only one avaiable.

Thanks.

BTW, this is the default usage,

$ resolveip
resolveip Ver 2.3, for debian-linux-gnu (x86_64)
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL license

Get hostname based on IP-address or IP-address based on hostname.

Usage: resolveip [OPTIONS] hostname or IP-address
   -?, --help          Displays this help and exits.
(Continue reading)

Jim Popovitch | 19 May 23:12 2015
Picon

com. Glue

Hello,

I'm stuck in the middle with $registrar saying glue exists, and
intodns, et.al., saying no glue exists.   I would appreciate any
insight into why there is no glue appearing for speedyiguana.com (a
mailman dev/test system that i use)

Link for the lazy: http://www.intodns.com/speedyiguana.com

FWIW, I see the following with dig:

~$ dig NS speedyiguana.com  <at> d.gtld-servers.net

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> NS speedyiguana.com  <at> d.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23738
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;speedyiguana.com.              IN      NS

;; AUTHORITY SECTION:
speedyiguana.com.       172800  IN      NS      dns1.domainmail.org.
speedyiguana.com.       172800  IN      NS      dns2.domainmail.org.
speedyiguana.com.       172800  IN      NS      dns3.domainmail.org.

;; Query time: 32 msec
;; SERVER: 192.31.80.30#53(192.31.80.30)
(Continue reading)

Davey Song (宋林健 | 17 May 19:56 2015
Picon

Workshop on future internet infrastructure (live and online)

Hi folks,

 

For your information, there is a workshop co-hosted by BII is going to be held in less than 10 hours in Beijing. (will start at 13:30 Beijing Time). David, Paul and Andrew are invited to join us and give talks on hot topics on Internet infrastructure especially on naming system. As far as I know, David and Paul are going to talk about future DNS Root service. Anybody who are interested can see the live broadcast online. Please visit http://blive.cuctv.com/ , and click the workshop in right-hand navigation bar, starting from 13:28, 05.18.

 

I’m honor to be the host and I do leave time for Q&A session for each speaker. But you know Chinese people are shy and not so active in Q&A session. So if anyone do have question, please send questions directly on the broadcasting page or off-line mail to me helping me to fill up the silence. As it is our firstly trial to broadcast the technical workshop online in China, I’m not sure the quality of online video received out of China. If it does not work well, please check the recoded video later. I will send the link later. Note that the workshop will be half English and half Chinese, because most audiences in site do not speak English as their first language.

 

Best Regards,

Davey

 

 

------------------------

Davey Song 宋林健
Director of BII Lab
Telephone: 86+13810106659

 

<div><div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Hi folks,<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">For your information, there is a workshop co-hosted by BII is going to be held in less than 10 hours in Beijing. (will start at 13:30 Beijing Time). David, Paul and Andrew are invited to join us and give talks on hot topics on Internet infrastructure especially on naming system. As far as I know, David and Paul are going to talk about future DNS Root service. Anybody who are interested can see the live broadcast online. Please visit <a href="http://blive.cuctv.com/">http://blive.cuctv.com/</a> , and click the workshop in right-hand navigation bar, starting from 13:28, 05.18.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">I&rsquo;m honor to be the host and I do leave time for Q&amp;A session for each speaker. But you know Chinese people are shy and not so active in Q&amp;A session. So if anyone do have question, please send questions directly on the broadcasting page or off-line mail to me helping me to fill up the silence. As it is our firstly trial to broadcast the technical workshop online in China, I&rsquo;m not sure the quality of online video received out of China. If it does not work well, please check the recoded video later. I will send the link later. Note that the workshop will be half English and half Chinese, because most audiences in site do not speak English as their first language. <p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">Best Regards,<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Davey<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">------------------------<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Davey Song </span><span>&#23435;&#26519;&#20581;</span><span lang="EN-US"><br>Director of BII Lab<br>Telephone: 86+13810106659<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
</div></div>
Davey Song (宋林健 | 16 May 07:48 2015
Picon

A dns-proxy for DNS over HTTP(s)

Hi folks,

 

There is an interesting open source project for DNS over HTTP(s): https://github.com/BII-Lab/DNSoverHTTP .

 

In this project we intend to provide an easy way to deploy and use the feature of HTTP(s) for DNS transactions which provides capability for privacy consideration, transparence to the middle box, persistent TCP connection etc. it is worth to mention that the protocol used by the dns_proxy service is alarmingly simple. There's no JSON or XML encoding provide; the DNS query and response are sent as raw binary via the "libcurl" library on the client side and the "libfcgi" library on the server side.

 

The current software is conceived and drafted by Paul Vixie during WIDE CAMP 2015-03. Engineers from BII lab help for testing and maintenance. Now It works for both IPv4/IPv6, UDP/TCP, EDNS0. We encourage more people to join us by forking, submitting optimized changes and using it. Now There is already serval servers running for testing:

 

http://[2001:559:8000:cd::5]

http://24.104.150.209

http://fcgi.dnsv6lab.net (IPv6-only)

 

For example when you install the client:

proxy_dns_gw -s "http://fcgi.dnsv6lab.net" -l ::,53  OR  proxy_dns_gw -s " http://24.104.150.209" -l 127.0.0.1,53

 

Please feel free to try and report any error or suggestions to us (Paul, Davey or just propose in this ML)

 

Cheers,

Davey

 

------------------------

Davey Song 宋林健
Director of BII Lab
Telephone: 86+13810106659

 

<div><div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Hi folks,<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">There is an interesting open source project for DNS over HTTP(s): <a href="https://github.com/BII-Lab/DNSoverHTTP">https://github.com/BII-Lab/DNSoverHTTP</a> . <p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">In this project we intend to provide an easy way to deploy and use the feature of HTTP(s) for DNS transactions which provides capability for privacy consideration, transparence to the middle box, persistent TCP connection etc. it is worth to mention that the protocol used by the dns_proxy service is alarmingly simple. There's no JSON or XML encoding provide; the DNS query and response are sent as raw binary via the "libcurl" library on the client side and the "libfcgi" library on the server side. <p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">The current software is conceived and drafted by Paul Vixie during WIDE CAMP 2015-03. Engineers from BII lab help for testing and maintenance. Now It works for both IPv4/IPv6, UDP/TCP, EDNS0. We encourage more people to join us by forking, submitting optimized changes and using it. Now There is already serval servers running for testing:<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US"><a href="http://%5B2001:559:8000:cd::5">http://[2001:559:8000:cd::5</a>]<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><a href="http://24.104.150.209">http://24.104.150.209</a><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><a href="http://fcgi.dnsv6lab.net">http://fcgi.dnsv6lab.net</a> (IPv6-only)<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">For example when you install the client: <p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">proxy_dns_gw -s "<a href="http://fcgi.dnsv6lab.net">http://fcgi.dnsv6lab.net</a>" -l ::,53&nbsp; OR&nbsp; proxy_dns_gw -s " <a href="http://24.104.150.209"><span>http://24.104.150.209</span></a>" -l 127.0.0.1,53<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">Please feel free to try and report any error or suggestions to us (Paul, Davey or just propose in this ML)<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">Cheers,<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Davey<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">------------------------<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Davey Song </span><span>&#23435;&#26519;&#20581;</span><span lang="EN-US"><br>Director of BII Lab<br>Telephone: 86+13810106659<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
</div></div>
bert hubert | 11 May 16:05 2015
Picon

Writeup of Spring Workshop

Hi everybody,

When I registered for the workshop I signed up as a volunteer and then
promptly forgot that and didn't volunteer for anything.

Perhaps to make up for that I wrote a summary of the wonderful workshop this
weekend, it can be found on:

http://blog.powerdns.com/2015/05/11/dns-oarc-spring-workshop-2015/

It has brief descriptions of all presentations, links to the videos and
provides some context.  Finally it has two things we discussed and I think
"we" should do regarding Linux/UNIX UDP performance and the "shut up
packet".

Enjoy!

	Bert
Stephane Bortzmeyer | 4 May 09:11 2015
Picon

[Security] Glue or not glue?

A new edition of the DNS security guide by ANSSI (French cybersecurity
agency) recommends to prefer delegations with glue because glueless
delegations "may carry additional risks since they create a
dependency". Is there any other "best practices" text which makes such
a recommendation?

http://www.ssi.gouv.fr/entreprise/guide/bonnes-pratiques-pour-lacquisition-et-lexploitation-de-noms-de-domaine/
(in french only)
Michael Smitasin | 30 Apr 01:27 2015

EDNS weirdness with certs.godaddy.com?

A few weeks ago we got reports of users unable to visit the
certs.godaddy.com site, which had previously worked. Digging into it, it
looks to be a DNS problem. We run our own name servers (BIND) so I do
have access to configurations, though to the best of my knowledge, no
config changes were made on our end. Running it through dnsviz.net also
reports a problem:

> secureserver.net. to where.secureserver.net.: The server(s) responded
> with a malformed response or with an invalid RCODE. (208.109.80.40,
> 208.109.132.40)secureserver.net. to where.secureserver.net.: The
> server(s) were not responsive to queries over TCP. (208.109.80.40,
> 208.109.132.40)
> certs.gd.where.secureserver.net./A: The response had an invalid RCODE
> (FORMERR) until EDNS was disabled. (208.109.132.40)
> certs.gd.where.secureserver.net./A: The response had an invalid RCODE
> (FORMERR) until EDNS was disabled. (208.109.80.40)

Taking packet captures on our name servers while querying themselves
(dig  <at> 127.0.0.1 certs.godaddy.com) will sometimes show a response from
the GoDaddy name server, but our name servers don't seem to register it,
they'll keep asking for NS records until the dig query times out. Other
times it'll return a Form-Err. I seem to be able to reproduce the
Form-Err reliably by doing a dig +trace, or querying the authoritative
name server for the target of the certs.godaddy.com CNAME
(certs.gd.where.secureserver.net):

dig  <at> gns1.secureserver.net certs.gd.where.secureserver.net +edns=0

(That query succeeds if you use +noedns instead)

Interestingly, we have 2 name servers, plus my own personal name
servers, which do not have this issue. As mentioned in the DNSviz
errors, the difference seems to be EDNS. I took a peek at some of the
packet captures, and this appears to be the only significant difference:

> <root>: type OPT
>     Name: <Root>
>     Type: OPT (41)
>     UDP payload size: 4096
>     Higher bits in extended RCODE: 0x00
>     ENDS0 version: 0
>     Z: 0x8000
>             1... .... .... .... = DO bit: Accepts DNSSEC security RRs
>             .000 0000 0000 0000 = Reserved: 0x0000
>     Data length: 0

Also interestingly, queries of the parent domain, secureserver.net, work
fine, though they have a completely different set of authoritative name
servers.

Anyone else run into this or have ideas what it could be? Does GoDaddy
have a firewall that's mangling EDNS queries?

Thanks,

-- 
Michael Smitasin
Network Engineer
LBLnet Services Group
Lawrence Berkeley National Laboratory

A few weeks ago we got reports of users unable to visit the
certs.godaddy.com site, which had previously worked. Digging into it, it
looks to be a DNS problem. We run our own name servers (BIND) so I do
have access to configurations, though to the best of my knowledge, no
config changes were made on our end. Running it through dnsviz.net also
reports a problem:

> secureserver.net. to where.secureserver.net.: The server(s) responded
> with a malformed response or with an invalid RCODE. (208.109.80.40,
> 208.109.132.40)secureserver.net. to where.secureserver.net.: The
> server(s) were not responsive to queries over TCP. (208.109.80.40,
> 208.109.132.40)
> certs.gd.where.secureserver.net./A: The response had an invalid RCODE
> (FORMERR) until EDNS was disabled. (208.109.132.40)
> certs.gd.where.secureserver.net./A: The response had an invalid RCODE
> (FORMERR) until EDNS was disabled. (208.109.80.40)

Taking packet captures on our name servers while querying themselves
(dig  <at> 127.0.0.1 certs.godaddy.com) will sometimes show a response from
the GoDaddy name server, but our name servers don't seem to register it,
they'll keep asking for NS records until the dig query times out. Other
times it'll return a Form-Err. I seem to be able to reproduce the
Form-Err reliably by doing a dig +trace, or querying the authoritative
name server for the target of the certs.godaddy.com CNAME
(certs.gd.where.secureserver.net):

dig  <at> gns1.secureserver.net certs.gd.where.secureserver.net +edns=0

(That query succeeds if you use +noedns instead)

Interestingly, we have 2 name servers, plus my own personal name
servers, which do not have this issue. As mentioned in the DNSviz
errors, the difference seems to be EDNS. I took a peek at some of the
packet captures, and this appears to be the only significant difference:

> <root>: type OPT
>     Name: <Root>
>     Type: OPT (41)
>     UDP payload size: 4096
>     Higher bits in extended RCODE: 0x00
>     ENDS0 version: 0
>     Z: 0x8000
>             1... .... .... .... = DO bit: Accepts DNSSEC security RRs
>             .000 0000 0000 0000 = Reserved: 0x0000
>     Data length: 0

Also interestingly, queries of the parent domain, secureserver.net, work
fine, though they have a completely different set of authoritative name
servers.

Anyone else run into this or have ideas what it could be? Does GoDaddy
have a firewall that's mangling EDNS queries?

Thanks,

--

-- 
Michael Smitasin
Network Engineer
LBLnet Services Group
Lawrence Berkeley National Laboratory

Randy Bush | 27 Apr 03:09 2015

traffic jam

i have two modest auth servers, a few MB/s each.  ten days ago, they
went to 80MB.  sources and dests are widely distributed.  so is it just
a ddos, or is there something for which i should be looking?

randy

i have two modest auth servers, a few MB/s each.  ten days ago, they
went to 80MB.  sources and dests are widely distributed.  so is it just
a ddos, or is there something for which i should be looking?

randy

Keith Mitchell | 23 Apr 13:12 2015
Picon

DNS-OARC Spring 2015 Workshop - 9/10th May : REGISTRATION DEADLINE REMINDER

A reminder that the the early registration deadline for our Amsterdam
workshop is *this Friday* the 24th:

	https://oarc-spring2015-amsterdam.eventbrite.com/

If you are planning to attend, please note that the registration fee,
increases from $150 to $250 for non-member attendees TOMORROW Friday
24th April. This includes lunch on both days and and evening social
event - help us plan, and keep our and your hotel venue costs down, by
registering ASAP. Discounted registration is also available to most OARC
members.

The agenda is now fully confirmed and as packed as ever, please see:

	https://indico.dns-oarc.net/event/21/timetable/#all

for details of all talks and timing.

The workshop will be held at the same location the subsequent RIPE70
meeting, and we're grateful to SIDN, Verisign, Nominum and Comcast for
being our sponsors this time.

For travel and additional venue information, see the workshop site, and
also the RIPE70 meeting site at:

	https://ripe70.ripe.net/venue/meeting-venue/

Additional sponsors for this meeting and the social event remain welcome
- please contact <sponsor@...> if interested.

Keith Mitchell
OARC President
Stephane Bortzmeyer | 22 Apr 15:12 2015
Picon

Authoritative name server replies NODATA for a non-existing domain

Strange behavior:

% for ns in $(dig +nodnssec +short NS adult.); do
echo $ns
dig  <at> $ns NS thisdomaincertainlydoesnotexist.adult |& grep status:
done
d0.nic.adult.
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 13433
c0.nic.adult.
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23111
a0.nic.adult.
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3358
a2.nic.adult.
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48334
b2.nic.adult.
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29932
b0.nic.adult.
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 58405

IMHO, all the name servers should reply NXDOMAIN, no?

DNSviz does complain:

http://dnsviz.net/d/adult/dnssec/?rr=all&a=all&ds=all&doe=on&ta=.&ta=dlv.isc.org.&tk=
Mark E. Jeftovic | 18 Apr 21:23 2015

named-checkzone warnings about missing SPF records


I am under the impression that the SPF RR type has been deprecated
(http://www.zytrax.com/books/dns/ch9/spf.html and RFC 7208)

Yet named-checkzone will still throw a warning if SPF data is present in
a TXT rec but has no accompanying SPF Rtype:

zone antiglam.com/IN: 'antiglam.com' found SPF/TXT record but no SPF/SPF
record found, add matching type SPF record

Will this warning be phased out?

(although I note that we use bind-dlz here, so I also wonder if the
named-checkzone package in that is slightly behind the stock bind one)

- mark

--

-- 
Mark E. Jeftovic <markjr@...>
Founder & CEO, easyDNS Technologies Inc.
+1-(416)-535-8672 ext 225
Read my blog: http://markable.com


Gmane