VeriSign's rapid DNS updates in .com/.net

Mailman List Mirror (Read Only)
1

VeriSign Naming and Directory Services (VNDS) currently generates new
versions of the .com/.net zones files twice per day. VNDS is
scheduled to deploy on September 8, 2004 a new feature that will
enable VNDS to update the .com/.net zones more frequently to reflect
the registration activity of the .com/.net registrars in near real
time. After the rapid DNS update is implemented, the elapsed time
from registrars' add or change operations to the visibility of those
adds or changes in all 13 .com/.net authoritative name servers is
expected to average less than five minutes.

The rapid update process will batch domain name adds and domain name
changes every few seconds. The serial number in the .com/.net zones'
SOA records will increase with each batch of changes applied. As
described in a message to the NANOG list in January [1], these serial
numbers are now based on UTC time encoded as the number of seconds
since the UNIX epoch (00:00:00 GMT, 1 January 1970).

VNDS will continue to publish .com/.net zone files twice per day as
part of the TLD Zone File Access Program. [2] These zone files will
continue to reflect the state of the .com/.net registry database at
the moment zone generation begins.

VNDS does not anticipate any negative consequences of deployment of
rapid updates to the .com/.net zones. However, as a courtesy we are
providing the Internet community with 60 days advance notice of the
change to the update process.

Some questions and answers about rapid updates for .com/.net are
available at http://www.verisign.com/nds/naming/rapid_update/faq.html.

Matt

2

Very cool! Kudos! This is good news from Verisign on NANOG for a change. :slight_smile: Does this also apply to domains with other registrars? From your message wording above, it appears that is the case which is great news. Does this apply to authoritative name server changes as well? Also, does this apply to customers who have had their domains suspended due to non-payment? That is always tough for our support desk to tell a customer they need to pay their bill to registrar X then wait 24-48 hours. If this will end that mess too, that's even better.

-Robert

Tellurian Networks - The Ultimate Internet Connection
http://www.tellurian.com | 888-TELLURIAN | 973-300-9211
"Good will, like a good name, is got by many actions, and lost by one." - Francis Jeffrey

3

Very cool! Kudos! This is good news from Verisign on NANOG for a change. :slight_smile: Does this also apply to domains with other registrars? From your message wording above, it appears that is the case which is great news. Does this apply to authoritative name server changes as well? Also, does this apply to customers who have had their domains suspended due to non-payment? That is always tough for our support desk to tell a customer they need to pay their bill to registrar X then wait 24-48 hours. If this will end that mess too, that's even better.

Seconded. This is very cool and something I think everyone has wanted for a long time.

[Devil's Advocate Hat On]

So domain hijacking can now take place in seconds in the middle of the night?

[Devil's Advocate Hat Off]

And you can fix hijacked domains in seconds!!

DJ

4

<Devil's Advocate Hat On>

Or social-engineer somebody to "fix" a "hijacked" domain in seconds.. :slight_smile:

<Hat Off>

5

all still dependent on the 'its hijackable' to begin with, right? So what
changed really?

6

all still dependent on the 'its hijackable' to begin with, right? So what
changed really?

The window to be notified and respond probably just shrunk by an enormous factor. Everything is hijackable.

DJ

7

I wasn't aware you got a notification upon hijack...

8

"Hmm... that phone call 2 hours ago sounded fishy.. I better re-double-check"

Working scam for 1 hour 50 minutes with 5 minute updates, good chance
of being stopped before deployment with 12 hour updates.

Yes, on the flip side, the hijacking is *stopped* sooner - but for many
classes of attacks that involve control of a nameserver, a few minutes
can be enough....

9

The window to be notified and respond probably just shrunk by an
enormous factor. Everything is hijackable.

I wasn't aware you got a notification upon hijack...

You may... you may not. If you don't its definitely a hijack. If you did and you were able to prevent it, its not a hijack. It really depends on the registrar I think.

As far as cancelling domains purchased with jacked credit cards... Verisign doesn't get a refund from ICANN or whoever if the domain is cancelled after the first two weeks or something... so why should Verisign cancel the domain when it helps their total-domains-registered rankings and THEY had to pay for it.

DJ

10

Does this also apply to domains with other registrars?

I'm not sure what you mean by "other registrars". VeriSign sold the
Network Solutions registrar in November 2003 (although it retains a
15% ownership).

The rapid updates apply to all changes from all registrars.

Does this apply to authoritative name server changes as well?

Do you mean, does it apply to glue records (i.e., A records for name
servers) in the .com/.net zones? Yes, it does: a change to a name
server's IP address will be reflected just as fast as a change to a
domain's (er, zone's) NS records.

Also, does this apply to customers who have had their domains
suspended due to non-payment?

I'm not sure what you mean here, but I think you're referring to
something that's ultimately a registrar issue. A domain can be placed
on hold status in the registry and its NS records will not appear in
the .com/.net zones. There are several different hold statuses and
they all prevent a domain's NS records from being published. It's
possible a registrar could put a domain on hold for non-payment. Any
changes to its name servers while it's on hold would be propagated
quickly under this new system, as would changes to its hold status, so
if it it was removed from hold, whatever changes that occurred while
it was on hold would be visible quickly.

One other issue: a few people have sent me private email asking if
we're planning on changing the 48-hour TTL for NS records and A
records in .com/.net. At this point we're not and the reason has a
lot to do with a little-known DNS behavior called credibility. It's
described in RFC 2181 ("Clarifications to the DNS Specification"),
Section 5.4.1, although the concept pre-dates that RFC and has been in
the BIND iterative resolver, for example, since version 4.9 (if memory
serves).

In a nutshell, DNS data has different levels of credibility or
trustworthiness depending on where it's learned from. That's relevant
here because the version of a zone's NS records from the zone's
authoritative servers is more trustworthy than the version obtained
from the zone's parent name servers. For example, the foo.com NS
records received from a foo.com authoritative server are believed over
the foo.com NS records received from a .com name server. Most
"positive" responses include the zone's NS records along with the
specific data requested (such as an A record). So in practice, here's
what happens:

- An iterative resolver chasing down, for example, A records for
  www.foo.com queries a .com name server and caches the foo.com NS
  records (with a 48-hour TTL) it receives.

- The resolver then queries one of the foo.com name servers for the
  www.foo.com A records.

- In the response the resolver receives the www.foo.com A records,
  along with foo.com's own version of the foo.com NS records--and this
  is the important part--which have the TTL set by the foo.com zone
  owner.

- According to the credibility scale, the just-received foo.com NS
  records are more credible than the cached foo.com NS records from
  .com, so the just-received records displace the cached ones, new TTL
  and all.

In other words, for all the iterative resolvers out there that have
this credibility mechanism, the 48-hour TTL on data in .com/.net isn't
particularly relevant.

Matt

11

Anyone noticing issues with Akamai and their DNS stuff?
Just wondering because I'm seeing strange responses regarding
www.foxnews.com, in that one of the Cnames a20.g.akamai.com
is changing every 20 seconds, and sometimes no response at all.

-Joe Blanchard

12

joe wrote:

Anyone noticing issues with Akamai and their DNS stuff?
Just wondering because I'm seeing strange responses regarding
www.foxnews.com, in that one of the Cnames a20.g.akamai.com
is changing every 20 seconds, and sometimes no response at all.

It's really too soon to tell, but there is certainly something out there
aimed right at the root servers. I saw a post from someone on full
disclosure claiming that there was a 0-day exploit against bind (although
the version wasn't named). There was huge activity for about four hours,
but it leveled off about 20-30 minutes ago. I'm still analyzing earlier
ethereal dumps, and logs, looking for the injection, or other evidence.

Some of this would probably explain any anomalies you see at akamai.

13

Is it just foxnews or other sites too? There's a thread on inet-access regarding foxnews and windows 2003 nameservers.

14

Keynote data shows a small spike in DNS errors for the KB40 index
from 8am to 8:30am EDT this morning. Normally we see less than
1 error per 4000 datapoints per half hour. During this period,
it was 22 errors. There was also a jump in "connection timed out"
from less than one to 18 during this period.

Looking at the deaggregated data, it appears that the spike was
due to brief problems on many of the measured sites, rather than
any one particular site.

It does not appear to be an Akamai-specific DNS issue at all. It
does not appear to be especially significant (22/4000 < .1%) either.

I'll do some more digging...

--Lloyd

15

Yup. Across the board from 8am to 8:15am EDT:

    http://web504.keynote.com/mykeynote/Post/KB40data_071004_081218.asp

(Scroll down about 25% to see the error-by-time chart)

Note that the time resolution of this chart is 15 minutes.

Not an Akamai issue.

--Lloyd

16

John,

    Thanks for the info/pointer to inet-access.
As far as I can tell, only www.foxnews.com, but there may be others.
Its the only one that was reported as an issue. Oddly, when I do a dig
against
it the response is as follows: (FYI this is from a linux system)
[root@rocknyou log]# dig www.foxnews.com
; <<>> DiG 9.2.1 <<>> www.foxnews.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38652
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 9, ADDITIONAL: 0

;; QUESTION SECTION:
;www.foxnews.com. IN A

;; ANSWER SECTION:
www.foxnews.com. 3578 IN CNAME
www.foxnews.com.edgesuite.net.
www.foxnews.com.edgesuite.net. 21579 IN CNAME a20.g.akamai.net.
a20.g.akamai.net. 20 IN A 66.77.165.235
<===note the TTL of 20 secs
a20.g.akamai.net. 20 IN A 66.77.165.227 <===
and the num of Cnames

;; AUTHORITY SECTION:
g.akamai.net. 1779 IN NS n8g.akamai.net.
g.akamai.net. 1779 IN NS n0g.akamai.net.
g.akamai.net. 1779 IN NS n1g.akamai.net.
g.akamai.net. 1779 IN NS n2g.akamai.net.
g.akamai.net. 1779 IN NS n3g.akamai.net.
g.akamai.net. 1779 IN NS n4g.akamai.net.
g.akamai.net. 1779 IN NS n5g.akamai.net.
g.akamai.net. 1779 IN NS n6g.akamai.net.
g.akamai.net. 1779 IN NS n7g.akamai.net.

;; Query time: 130 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Sat Jul 10 12:56:52 2004
;; MSG SIZE rcvd: 297

Now, less than 4 minutes later I get this response:
[root@rocknyou log]# dig www.foxnews.com
; <<>> DiG 9.2.1 <<>> www.foxnews.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44268
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 9, ADDITIONAL: 0

;; QUESTION SECTION:
;www.foxnews.com. IN A

;; ANSWER SECTION:
www.foxnews.com. 3361 IN CNAME
www.foxnews.com.edgesuite.net.
www.foxnews.com.edgesuite.net. 21362 IN CNAME a20.g.akamai.net.
a20.g.akamai.net. 20 IN A 66.77.165.225 <==
whoa, more CNames and they
a20.g.akamai.net. 20 IN A 66.77.165.227 <==
change every few minutes.
a20.g.akamai.net. 20 IN A 66.77.165.235
a20.g.akamai.net. 20 IN A 66.77.165.218
a20.g.akamai.net. 20 IN A 66.77.165.219

;; AUTHORITY SECTION:
g.akamai.net. 1562 IN NS n2g.akamai.net.
g.akamai.net. 1562 IN NS n3g.akamai.net.
g.akamai.net. 1562 IN NS n4g.akamai.net.
g.akamai.net. 1562 IN NS n5g.akamai.net.
g.akamai.net. 1562 IN NS n6g.akamai.net.
g.akamai.net. 1562 IN NS n7g.akamai.net.
g.akamai.net. 1562 IN NS n8g.akamai.net.
g.akamai.net. 1562 IN NS n0g.akamai.net.
g.akamai.net. 1562 IN NS n1g.akamai.net.

;; Query time: 17 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Sat Jul 10 13:00:29 2004
;; MSG SIZE rcvd: 345

While all this is going on, of course the MickeySoft DNSs do get messed up,
but
since I'm seeing it from various places and not just on my Biz IPOPs I was
wondering
if this might be fall out from the previous attack on Akamai.
Just odd I guess, and 1 more reason to push Nix as a DNS versus the M$
boxes.

Cheers
-Joe Blanchard

17

Anyone noticing issues with Akamai and their DNS stuff?
Just wondering because I'm seeing strange responses regarding
www.foxnews.com, in that one of the Cnames a20.g.akamai.com
is changing every 20 seconds, and sometimes no response at all.

It's saturday, and I can't resist...

Even Akamai can't make them fair and "balanced".

Har har.

Sorry,

Charles

18

It is cool, but where is any value in this (I mean - 5 minutes) rapid
updates for .com and other base domains? I wish rapid DNS when running
enterprise zone (with dynamic updates) or when running dynamic-dns service
(for those who use dynalic IP's); but for .com and .net, it is just a public
relation useless feature - registration time is 1 year, 5 minutes vs 1/2
day - do not makes any difference.

(I am not saying that it is bad; I just do not see any reason for the
celebration - anyway, DNS system have caches and delays measured in hours,
and when you register xxxx.com you are doing it for a few years).

19

It makes a big difference to people who sell web/mail/etc services to people that includes the domain name.

It means that someone who pays for a new website through an automated system doesn't have to wait 12-24 hours for it to be live, just a few minutes.

It also means that changes can be made to host records quickly which is important for people who don't plan well or have unexpected changes that they want propagated.

I'm appreciative of this change -- but fyi, they aren't the only TLD operators doing this, there are quite a few doing near-instant changes to their respective zones.

The only thing I would still want would be the ability to create multiple host records of the same name but with various values. At least the opposite, mutliple host names to the same value is now allowed. That's good enough for me. :slight_smile:

-davidu

20

Hmm... May be, you are correct - if you sell service to the 'consumers'
(inexperienced customers), they do not expect any delays between 'payment
completed' and 'I can see my brand new domain WWW.HOW-COOL-I-AM.COM. And
TTL's/caches do not prevent you from this, because you did not requested
this domain before.

This is still just Public relation, but very useful, I agree.

PS. I know about other operator, I just wanted to verify, who appreciate
this improvement - I agree that it is good for average consumer market (I
want to show my new WEB to my friends NOW, while I am on weekend
downloading my photos, and I do not want to know about 24h, IP hops, DNS
cliens, TTLs and so on ... ). One more step in making Internet the same
'simple to use' reality as houses, cars, TV....