On 7/5/2011 6:07 PM, Dave CROCKER wrote:
On 7/5/2011 3:12 PM, Joe Touch wrote:
The SRV record allows
DNS resolvers to search for particular applications and underlying
transports (for example, HTTP running over TLS, see [RFC2818]) and to
learn the domain name and port where that service
In message alpine.bsf.2.00.1107042329060.89...@joyce.lan, John R. Levine wri
tes:
The naive approach of reversing the address, converting to nibbles
and appending a suffix won't scale.
For IPv6 if you did the reverse of /48, /52, /56, /60 and /64
prefixes, which matches delegation
John R. Levine jo...@iecc.com wrote:
DNSBLs already set the min pretty low, e.g. 150 sec for Spamhaus. Doesn't
really matter how low it is if you have so many entries that they force out
the useful ones.
The really important records are the delegation chain NS records. It is
not so necessary
Mark Andrews ma...@isc.org wrote:
DNS[WB]L's have never been a good fit to the DNS, rather they have
not been a bad enough fit to require something better to be done.
Oh come off it, they are just as good a fit to the DNS as reverse DNS is.
The naive approach of reversing the address,
Keith Moore mo...@network-heretics.com wrote:
Yes, but rDNS PTR lookups always have been pretty much meaningless
anyway, and will only get worse in IPv4 due to LSN.
Reverse DNS for an LSN is just as informative as automatically populated
reverse DNS (and much more convenient than a whois
On Jul 5, 2011, at 6:58 AM, Tony Finch wrote:
Keith Moore mo...@network-heretics.com wrote:
Yes, but rDNS PTR lookups always have been pretty much meaningless
anyway, and will only get worse in IPv4 due to LSN.
Reverse DNS for an LSN is just as informative as automatically populated
The naive approach of reversing the address, converting to nibbles
and appending a suffix won't scale.
I don't understand why the setup is OK for reverse DNS but not blacklists.
One obvious reason is that the most widely used DNSBL server doesn't
return NODATA vs. NXDOMAIN according to
On 7/5/2011 3:56 AM, Tony Finch wrote:
Mark Andrewsma...@isc.org wrote:
DNS[WB]L's have never been a good fit to the DNS, rather they have
not been a bad enough fit to require something better to be done.
Oh come off it, they are just as good a fit to the DNS as reverse DNS is.
The naive
For an application that is likely to encounter a different IP address for
essentially every query, across a very large number of queries, the only
solution I see available is to use a different cache.
Seems reasonable. I gather that there are already caches with the
ability to partition
On 7/5/2011 10:31 AM, John Levine wrote:
For an application that is likely to encounter a different IP address for
essentially every query, across a very large number of queries, the only
solution I see available is to use a different cache.
Seems reasonable. I gather that there are already
Dave CROCKER d...@dcrocker.net wrote:
For an application that is likely to encounter a different IP address for
essentially every query, across a very large number of queries, the only
solution I see available is to use a different cache.
This has been operational common sense for many years.
On 7/5/2011 10:59 AM, Tony Finch wrote:
Dave CROCKERd...@dcrocker.net wrote:
For an application that is likely to encounter a different IP address for
essentially every query, across a very large number of queries, the only
solution I see available is to use a different cache.
This has
I believe that the solution is to have the applications, themselves,
distinguish the cache they are using (or the containing library). A
blocklist app needs to use a different library/cache than a web
browser.
You could do it either way. Either you could adjust the MTAs to have
a new parameter
Hi, all,
This doc also claims that:
The SRV record allows
DNS resolvers to search for particular applications and underlying
transports (for example, HTTP running over TLS, see [RFC2818]) and to
learn the domain name and port where that service resides in a given
administrative
On 7/5/2011 3:12 PM, Joe Touch wrote:
The SRV record allows
DNS resolvers to search for particular applications and underlying
transports (for example, HTTP running over TLS, see [RFC2818]) and to
learn the domain name and port where that service resides in a given
administrative domain.
On 04/29/2011 04:36 AM, John Levine wrote:
So my advice would be to back up and write down in one or two
sentences what problem this document is supposed to fix or at least
describe, and then see how much of the rest of it might be salvaged.
I was thinking of storing data in DNS and the
So my advice would be to back up and write down in one or two
sentences what problem this document is supposed to fix or at least
describe, and then see how much of the rest of it might be salvaged.
I was thinking of storing data in DNS and the document proved valuable to
determine whether its
In message alpine.bsf.2.00.1107040940090.60...@joyce.lan, John R. Levine wr
ites:
So my advice would be to back up and write down in one or two
sentences what problem this document is supposed to fix or at least
describe, and then see how much of the rest of it might be salvaged.
I was
Reverse IPv6 caches well. You just can't pre-populate servers with PTR
records for all 2^64 ptr records in a normal IPv6 subnet. You need to
use tools that add records for nodes that actually exist. Those tools
are a decade old now.
Over in e-mail land, we've been pondering the behavior of
In message alpine.bsf.2.00.1107041959400.29...@joyce.lan, John R. Levine wri
tes:
Reverse IPv6 caches well. You just can't pre-populate servers with PTR
records for all 2^64 ptr records in a normal IPv6 subnet. You need to
use tools that add records for nodes that actually exist. Those
Over in e-mail land, we've been pondering the behavior of spammers, who
will likely hop to a different IPv6 address for every spam. If you do rDNS
lookups, your cache will fill up with useless entries, maybe PTR, maybe
NXDOMAIN, it hardly matters. DNSBLs and DNSWLs, if done the same way as
they
On Jul 4, 2011, at 8:23 PM, John R. Levine wrote:
Reverse IPv6 caches well. You just can't pre-populate servers with PTR
records for all 2^64 ptr records in a normal IPv6 subnet. You need to
use tools that add records for nodes that actually exist. Those tools
are a decade old now.
Over
In message alpine.bsf.2.00.1107042151340.62...@joyce.lan, John R. Levine wri
tes:
Over in e-mail land, we've been pondering the behavior of spammers, who
will likely hop to a different IPv6 address for every spam. If you do rDNS
lookups, your cache will fill up with useless entries, maybe
The naive approach of reversing the address, converting to nibbles
and appending a suffix won't scale.
For IPv6 if you did the reverse of /48, /52, /56, /60 and /64
prefixes, which matches delegation patterns along with NXDOMAIN
synthesis, you would still be fine. You stop the search on
At 17:11 -0400 7/2/11, Danny McPherson wrote:
...that you meant to reference draft-iab-dns-applications-01
Oops.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStarYou can leave a voice message at +1-571-434-5468
I'm overly
On Apr 28, 2011, at 10:40 AM, Edward Lewis wrote:
These comments were sent to the IAB already. I was encouraged to send them
to the general IETF list. This is mostly a re-posting of the comments, with
one added paragraph (there's marker there).
The referenced document is:
It's hard to make comments on a document whose mission is not at all
clear. The problem I have is that the document has a faulty baseline
and incorrectly assesses extensions and variations. ...
My experience with the DNS is nowhere near as deep as Ed's but having
done my share of DNS hackery
27 matches
Mail list logo
